Closed Bug 835462 Opened 11 years ago Closed 10 years ago

No way to change email address on Marketplace

Categories

(Marketplace Graveyard :: Consumer Pages, defect, P2)

Product:
Marketplace Graveyard
Component:
Consumer Pages
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: eviljeff, Unassigned)

References

Details

(Whiteboard: [see comment 28])

Attachments

(1 file)

Add another email address to persona
761.10 KB, image/png
Details 
There currently isn't any (obvious) way to change your email address that you use for your Marketplace account.  

This is a problem as your account is tied to both your purchases and your app submissions.
Could use product and UX advice here. If there are any questions about implementation limitations, ask away. Thanks!
I don't know the history as to why it isn't editable.  I know its tied to a Persona account, but don't know why it wouldn't be changeable.  

I assume there is some reason...

OK, I'll ask.  Are there any implementation limitations?
bumping this and increasing its importance - its surely a very basic requirement and actual users are going to expect it to be there.
Severity: normal → major
I'm not even sure how this would happen. All users are authenticated via Persona. We would need to transfer ownership of accounts. Do you have ideas here?
I'm not familiar with the Marketplace implementation, but I was asked by Bram to keep an eye on this bug and provide any relevant Persona info.

What I can say is that our general recommendation for sites using Persona is that they should ideally:

* not use email addresses as unique identifiers for users (i.e. use a numeric ID or something like that)
* allow users to have more than one email address in their account
* allow users to login with any of the email addresses associated with their account

With this kind of implementation, a change of address essentially consists of adding a new email address and then deleting the old one. (Of course, this can be rolled into a single step from a UX point of view, and the multiple email address functionality doesn't have to be exposed through the UI.)
David, how important is this ability from a Product perspective?  Personally, I think if we didn't allow email changes we'd be pretty much the only app store that forced a user to use the same email address for ever...
Flags: needinfo?(dbialer)
It is important but not a blocker on anything.  I think François had good guidance.  The suggested single step UX approach makes sense.
Btw, as AMO and Marketplace can share the same user details, it is possible right now for a user to change their email address on AMO and update their Marketplace account email, without Persona being involved*.  If anything (purchases?) is tied to the Persona email, as opposed to the Marketplace user ID, then are things going to stop working?

*steps:
1) register on AMO with email@hotmail.com;  User account 6666 is created.
2) login to Marketplace via Persona with email@hotmail.com;  User account 6666 is re-used;
3) purchase something on Marketplace. 
4) change email address for account 6666 on AMO to email@gmail.com; Marketplace account now has email set to email@gmail.com
- is the purchase listed on account 6666?  Or linked to email@hotmail still? (which now has no Marketplace account)
Flags: needinfo?(dbialer)
The problem here is that if we use Persona, we have to use your email as the unique identifier for the user. That's just how Persona works. Otherwise, we need to start managing passwords, which defeats the purpose of using Persona to begin with.

I'm inclined to move this bug over to identity.
Matt: I don't think Persona requires that you use the email addres as the unique identifier. All it really says is:

  "you need to log the user that has francois@mozilla.com in"

That user can be uniquely identified on your site by a username or a numeric ID. He can also have more than one email address. The important thing is that email addresses need to be unique in the DB, but that doesn't mean the email has to be the primary key.

(See my comment #5 for what we recommend that sites do.)
Yes, this is a marketplace bug.  It's just a really big change to a lot of legacy code and will probably be quite a while before being resolved.
I am not seeing a big issue here, though perhaps I am missing the use case.  I do think the best option would be * allow users to login with any of the email addresses associated with their account (multiple persona IDs can map to the Firefox Account).  I think we can do this today?
The other option would be disassociate the contact email from the identity email.  We allow the user to change their contact email address but not their Persona.  The contact email may initially auto-populate with the persona, but this would be an editable field.
Users already have a numeric ID in Marketplace (and a username) but neither are exposed to the user (on Marketplace anyway - they are on AMO).  

I guess the part I'm not clear on is how the user can login to Persona with a new email address while already being logged in with the old one. Does the user just type it in on Marketplace and we hope its correct for the next time they have to log in via Persona?
(In reply to David Bialer [:dbialer] from comment #13)
> The other option would be disassociate the contact email from the identity
> email.  We allow the user to change their contact email address but not
> their Persona.  The contact email may initially auto-populate with the
> persona, but this would be an editable field.

Can you expand on this identity/contact difference?  Wouldn't there still be a problem if the 'identity' email address is an address you no-longer have access to?  e.g. its an ISP provided address and you change ISP; its a company address and you leave; etc.
The larger issue is that we'd need to create a way to make sure users can't lock themselves out of their accounts. The reason Persona works is because it handles all of the email verification for us. We know that at the time of signup, there's someone on the other end.

We'd need to somehow sign the user in on a different domain (it needs to be a different origin than Marketplace), then forcibly sign them out, then ask them to sign in with their new Persona account.

> Wouldn't there still be a problem if the 'identity' email address is an address you no-longer have access to?

Yes, absolutely. This is, however, a flaw not in the Marketplace but in every site that uses Persona.

This does raise the question, though, of whether we really want a self-serve UI to do this. Would it be better to have the users email/call/chat with support and have support work this out?
So the issue is that if a user loses access to their email account used with Persona, the user would want to associate a new email address with their account as they may have to switch to a new Persona account for future verifications.  They might lose access to Persona with that email id, for instance, if they have to turn in their work PC if issued by their employer.  This seems like a Persona issue - the need to perhaps reassign an ID.

Can we fix this by allowing multiple Personas to be associated with a Marketplace account?  Have a primary (where email receipts etc. get sent to).  But as Basta points out, we would need some sort of UI to manage this, which could make this a larger effort.  

Would multiple Persona IDs to a single Marketplace account be a way to go here?
(In reply to David Bialer [:dbialer] from comment #17)
> Would multiple Persona IDs to a single Marketplace account be a way to go
> here?

It would be possible to allow mutliple emails per user in that way, but we would still need an off-origin page to perform the persona auth and verification (i.e.: how do you know which user to assign the new persona account to if you're signed into the new persona account).

We'd need APIs for this, also the ability to mark which email is the primary email (for mailing purposes). We'd also need to change the way login works to query against an email table rather than the email column on the user table.
Unless the multiple email addresses helps with the implementation here, I think its unnecessary.  I can see it impacting multiple places (user settings, lookup tool, for a start).
The thought here was to essentially have backup Personas associated with the account so that a user doesn't get locked out and can then change their account.  There are broad implications though.
(In reply to David Bialer [:dbialer] from comment #20)
> The thought here was to essentially have backup Personas associated with the
> account so that a user doesn't get locked out and can then change their
> account.  There are broad implications though.

User lock out is a concern but I think its a different bug/feature.  IMO question/answer reset would be more consumer friendly if we want to go implementing that.

Being able to swap one email address with a new one seems sufficient to me.
Keywords: uiwanted
See bug 881529 for an important user scenario we need to support regarding ownership of paid apps
This bug is marked uiwanted. Have we decided what is possible to do from an implementation standpoint here? Will we allow multiple addresses or just overwrite the old one with a new one? 

I think the latter will be sufficient and probably what the user would expect anyway.
(In reply to Maria Sandberg [:mushi] from comment #25)
> This bug is marked uiwanted. Have we decided what is possible to do from an
> implementation standpoint here? Will we allow multiple addresses or just
> overwrite the old one with a new one? 
> 
> I think the latter will be sufficient and probably what the user would
> expect anyway.

I think the latter is sufficient also - multiple email addresses wouldn't be a bad feature but I imagine it would impact more of the code.
random thought - if we always have a single email address and 'switch' it then the new email address could be unverified.  So do we either a) hold both the old email address and the new one, and only do the swap once the new one is verified, or b) make the change immediately and have some sort of account lockout until the new one is verified?
So, what I'm hearing is that we should create steps like:

1) User is logged in and viewing their profile page and clicks "change email address"
2) A persona window pops up asking them to log in
3) Persona either comes back with an email address or failure
4) If failure, no action.  If email address:  if the same email, no action, if new email, we change their email address in the users table and refresh their session.  Next time they log in it will need to be with the new address.

Is there a problem with the above flow?  The new address is already verified if it's inside of persona, right?
Wil, that sounds right to me. We would take the user to Persona where they can add another email address (see screenshot)
(In reply to Andrew Williamson [:eviljeff] from comment #27)
> random thought - if we always have a single email address and 'switch' it
> then the new email address could be unverified.  So do we either a) hold
> both the old email address and the new one, and only do the swap once the
> new one is verified, or b) make the change immediately and have some sort of
> account lockout until the new one is verified?

I think that holding both old and new email until the new one is verified will prevent potential breakages in these scenarios:

1) User cannot log into the mailbox in the first place
2) The Persona verification mail is filtered into Spam; user missed it
3) Email delivery is delayed (e.g. for some reason, user doesn’t receive a verification email right away)
4) New email address is mistyped (not an uncommon occurrence on the phone)

If no verify link is clicked, I was thinking that we should allow user to log in using their old email address. Would locking out the account make this action impossible?
(In reply to Maureen Hanratty from comment #29)
> Created attachment 775918 [details]
> Add another email address to persona
> 
> Wil, that sounds right to me. We would take the user to Persona where they
> can add another email address (see screenshot)

I don't know if we can link directly to that page or not.  Someone else will know though.


(In reply to Bram Pitoyo [:bram] from comment #30)
> (In reply to Andrew Williamson [:eviljeff] from comment #27)
> > random thought - if we always have a single email address and 'switch' it
> > then the new email address could be unverified.  So do we either a) hold
> > both the old email address and the new one, and only do the swap once the
> > new one is verified, or b) make the change immediately and have some sort of
> > account lockout until the new one is verified?
> 
> I think that holding both old and new email until the new one is verified
> will prevent potential breakages in these scenarios:
> 
> 1) User cannot log into the mailbox in the first place
> 2) The Persona verification mail is filtered into Spam; user missed it
> 3) Email delivery is delayed (e.g. for some reason, user doesn’t receive a
> verification email right away)
> 4) New email address is mistyped (not an uncommon occurrence on the phone)
> 
> If no verify link is clicked, I was thinking that we should allow user to
> log in using their old email address. Would locking out the account make
> this action impossible?

I'm under the impression that persona won't pass them through until they are verified.  It's entirely possible I'm mistaken - I haven't registered an account on persona in a long time.  What does Persona's new account flow look like - they let unverified users through?
(In reply to Wil Clouser [:clouserw] from comment #31)
> I'm under the impression that persona won't pass them through until they are
> verified. […] What does Persona's new account flow
> look like - they let unverified users through?

Persona won’t let unverified users through. For signed in users who added a new email address, the new email address won’t even show up on the list until the user clicks on the confirm link.
Is this still uiwanted?
Sounds like the flow in comment 28 is the one
Keywords: uiwanted
Whiteboard: [see comment 28]
Priority: -- → P2
Firefox Accounts will allow you to change emails, we are moving to that shortly as per https://wiki.mozilla.org/Marketplace/FirefoxAccounts
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: