Closed Bug 1123766 Opened 11 years ago Closed 10 years ago

Implement email confirmation screen

Categories

(support.mozilla.org :: BuddyUp, defect, P2)

defect

Tracking

(Not tracked)

VERIFIED FIXED
2015Q1

People

(Reporter: atopal, Assigned: rehandalal+mozilla)

References

Details

(Whiteboard: p=1 s=bu.2015.3)

Attachments

(1 file)

No description provided.
Whiteboard: p=1 s=bu.2015.2
Whiteboard: p=1 s=bu.2015.2 → p=2 s=bu.2015.2
Assignee: nobody → rdalal
Status: NEW → ASSIGNED
moving to next sprint
Whiteboard: p=2 s=bu.2015.2 → p=1 s=bu.2015.3
Depends on: 1132115
Sorry, forgot to attach this when I filed it.
Attachment #8563376 - Flags: review?(anthony)
Comment on attachment 8563376 [details] [review] https://github.com/mozilla/buddyup/pull/77 I think this needs a new iframe approach to cover for other usage of this panel.
Attachment #8563376 - Flags: review?(anthony)
I looked into registration a bit more through my work on notifications. I don't understand how this flow can work. When we register a user, User.get_token() returns a 400 saying that 'User account is disabled'. Therefore, we don't store the user credentials in asyncStorage. So when we poll, User.get_user() is polling for the auto-generated account that we currently have. And it's already active.
Attachment #8563376 - Flags: review?(anthony)
Comment on attachment 8563376 [details] [review] https://github.com/mozilla/buddyup/pull/77 So we know this will need some refactoring when we display this window on app launch. But to move forward, let's already land this. Can you open the bug for app opening and mark it as a [blocker] so we account for it?
Attachment #8563376 - Flags: review?(anthony) → review+
Blocks: 1135276
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: