feat(thundermail-mvp): integrate sign in with thundermail and scan qr code buttons#10970
Conversation
|
I think listing the commits as part of the PR body, doesn't add value. If you consider this information is important, it should be added to the commit message as: |
The idea was to help the reviewer to know what the range of commits should be reviewed in this PR, as this contains all the commits from the parent PR as well. Maybe a diff statement would be better? I'm still trying to find the best solution for situations like that |
1223ec3 to
d7f61e6
Compare
…ermail and Scan QR code
… flow Move QR code scanning from account setup to dedicated Thundermail navigation module. Register Thundermail routes in FeatureLauncherNavHost and handle navigation between QR code scanning and account setup completion.
…reen Add separate callbacks for Thundermail sign-in and QR code scanning. Update ThundermailButtonPanel to handle both actions independently and reduce visibility of route constants to internal.
…or better visual balance on smaller screens
…ing with dependency injection
d7f61e6 to
5121787
Compare
dani-zilla
left a comment
There was a problem hiding this comment.
It does seem like importing via QR code still has an issue where you have to go into account settings to refresh the account monogram logo to be the initials on the account rather than "XX"
Besides that, I'm not seeing the crash I saw when importing accounts without the QR code.
However, I have noticed that if you use the QR code to pull up your account, don't sign in, choose later, go to the account and select server settings, it'll direct you to sign in. You can sign in, but nothing updates or shows that it's a functional account until you tap "Sync account."
| email?.let { put("email", it) } | ||
| name?.let { put("name", it) } |
There was a problem hiding this comment.
Would we ever need to execute everything if we don't have the email address, at least? Also, do we want to check for empty strings here? It should be pretty controlled, I take it, but I noticed we test for null specifically on them in the test, and wondered if empty strings would be similarly invalid
There was a problem hiding this comment.
Would we ever need to execute everything if we don't have the email address, at least?
The actual email derives from either the preferred_username or email field within the id_token. At least one of these two must be available, with preferred_username being the first pick.
Also, do we want to check for empty strings here? It should be pretty controlled, I take it, but I noticed we test for null specifically on them in the test, and wondered if empty strings would be similarly invalid
Although I think it is unlikely that an id_token would return an empty string for these fields, I don't think it hurts to check them. I would consider an empty string as a malformed claim in an id_token, but I need to double-check if that is really a case.
This is being handled by #10959
This is the same behaviour the current version on main has when importing from a QR code. |
4961140
into
thunderbird:feature/thundermail-mvp
Changes
thundermail_onboarding_enabledfeature flagThundermailButtonPanelwith sign-in with Thundermail and Scan QR codeThundermailButtonPanelto migration screen:feature:thundermail:internal:commonmoduleThundermailButtonPanelfor better visual balance on smaller screensScreenshots