Invitation Codes

[MatthewTurk247]

Invitation Codes

♻️ Current situation & Problem

There is a new collection in Firestore called invitation code bucket called invitationCodes. During onboarding, we sign the user in anonymously so we can check if they have a valid code. If they do, we assign that code to their new de-anonymized account and remove it from invitationCodes so it cannot be used again. Some kind of verification step like this hedges against spam and unapproved use.

⚙️ Release Notes

• Adds an authentication step to onboarding whereby the user confirms against valid Firebase invitation codes that they are enrolled in the study.

📚 Documentation

See Firebase documentation.

✅ Testing

TBD.

Code of Conduct & Contributing Guidelines

By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

• I agree to follow the Code of Conduct and Contributing Guidelines.

[PSchmiedmayer]

@MatthewTurk247 I think invitation codes should not be stored in the storage bucket but in the firebase database. The storage bucket should only be used for large files like the consent document. That's probably the best use case we have for that now.

In addition, we are still missing the functionality in the cloud function like in the Spezi Study App: https://github.com/StanfordSpezi/SpeziStudyApplication.

This PR includes a few more things but demonstrates how we included a basic functionality in the app: StanfordSpezi/SpeziStudyApplication@4f5e88d.

The final cloud function and current logic is found in the study app repo. It has a multi-study approach which makes it a bit more complicated but follows the same approach to validate an invitation code:

• Cloud function: https://github.com/StanfordSpezi/SpeziStudyApplication/blob/main/functions/index.js
• Invitation Code View: https://github.com/StanfordSpezi/SpeziStudyApplication/blob/main/StudyApplication/[…]ng/OnboardingMechanisms/InvitationCode/InvitationCodeView.swift

I don’t think that we have to initially update SpeziOnboarding at this point, we can implement all that in the app but it might be eventually nice to move it out to one of the Spezi Package if needed.
The Spezi Study Application importantly does not include the mapping of the anonymous account to the other login (e.g. username or password). I think we should be able to do this without any changes to SpeziAccount.

In addition, it does not include the protection rule on SignUp to only allow this if you have a proper invitation code. This is not needed in the Spezi Study App as we don’t have any Accounts in there but will be necessary for PICS.
You can find more about these cloud functions here: https://firebase.google.com/docs/auth/extend-with-blocking-functions?gen=2nd

I would suggest to use the same function and structure as in the Study App. We have a functions folder that contains everything. The Firebase configuration (https://github.com/StanfordSpezi/SpeziStudyApplication/blob/main/firebase.json) includes that so you can test all the cloud functions locally in the emulator without ever needing to deploy them to the cloud project.

[codecov]

Codecov Report

Attention: Patch coverage is 73.28244% with 35 lines in your changes are missing coverage. Please review.

Project coverage is 54.97%. Comparing base (dfa0f6c) to head (91d3be6).

Additional details and impacted files

@@             Coverage Diff             @@
##             main      #54       +/-   ##
===========================================
+ Coverage   28.44%   54.97%   +26.53%     
===========================================
  Files          35       37        +2     
  Lines        1245     1370      +125     
===========================================
+ Hits          354      753      +399     
+ Misses        891      617      -274     

Files	Coverage Δ
PAWS/Onboarding/OnboardingFlow.swift	97.30% <100.00%> (+0.08%)	⬆️
PAWS/PAWSStandard.swift	29.65% <ø> (+26.22%)	⬆️
PAWS/ECGRecordings/ECGRecording.swift	0.00% <0.00%> (ø)
PAWS/Onboarding/InvitationCodeError.swift	0.00% <0.00%> (ø)
PAWS/Onboarding/InvitationCodeView.swift	79.84% <79.84%> (ø)

... and 15 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dfa0f6c...91d3be6. Read the comment docs.

[PSchmiedmayer]

Thank you for the improvements @MatthewTurk247! I had a few smaller comments; should be small stuff that we can to to get it across the finish line.

I committed a few smaller things that I noticed during the review.

[PSchmiedmayer]

@MatthewTurk247 Looks like some of the REUSE checks are still failing, you will most likely need to add <...>.license files for the remaining files: https://github.com/StanfordBDHG/PediatricAppleWatchStudy/actions/runs/8422279017/job/23061206134?pr=54#step:4:7

[PSchmiedmayer]

@MatthewTurk247 This release should unblock your issue thanks to @Supereg: https://github.com/StanfordSpezi/SpeziFirebase/releases/tag/1.1.0

[MatthewTurk247]

@PSchmiedmayer, the onboarding flow is almost there, but a failed account operation error still shows up, even though linking appears to work just fine in Firebase emulator now. And if I tap the sign-up button again, the error message says that the account already exists. I have a feeling that one or two lines of code might be missing somewhere, or something needs to be removed, but I cannot quite put a finger on it.

[PSchmiedmayer]

@MatthewTurk247 Thank you for all the additional improvements! The overall PR looks good to me; I only had a few smaller comments that would be great to be addressed before merging the PR.

Feel free to merge the PR once all of them are addressed 👍