On Mar 22, 2021, at 7:53 AM, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Abhilash Raj writes:
Well a couple of stars have to align for it to work unfortunately.
I'm not going to wait for the stars; I have backward-incompatible surgery in mind.
Add to that you can’t set an address as primary using just email commands, you end up with what you are seeing.
Right. The idea is that the first time an address is used, a User will be created and that address will be primary for that User. When the person wants to claim that address, they go to Postorius, create a Postorius account, do the address verification dance and set credentials, which links the Postorius account to the User via the Address.
This is why the ability to merge Users becomes an urgent need: people who subscribe via email are going to end up with multiple Users.
Well, it doesn’t change the situation much from status quo. You also have multiple users today, even if you subscribe via individual address since an address always has a User. And like we were discussing over on the other thread, when the owner decides to join in P and control both the addresses from single P account, we’ll merge both users.
We don’t necessarily need the flag on user to set an unverified primary address, we might be able to get away without that. We could set the address as primary *after* we verify it. We always verify addresses regardless of the choice of the subscription mode (user or address).
I'm not clear what you're saying. In general admins can't read your mail, so they can't verify you on a mass subscribe or an import.
What I meant was, we can set the address as primary after the verification dance with the user and then subscribe the primary address.
The existing subscription workflow is a multi-step process that can be paused and resumed. We pause when we send out a confirmation email and then resume when that confirmation token is somehow processed via email or API. So, post receiving the confirmation and before actually subscribing, we can se the address as primary if the user doesn’t have one and subscribe user as inhert. We don’t do any of that if user already has chosen a primary address and it doesn’t match the current address.
Also, mass-subscribe and import does allow you to verify an address by clicking this “Pre-verified” checkbox, which can be useful if you are migrating from a different service or you exported a list of users from somewhere you know to be valid.
Right now, P is explicit about it. You can choose if you want Primary Address or one of the explicit addresses added to your account. The primary address is the pre-selected choice, so if you go and just click on subscribe button, you get the primary address being subscribed. If you choose the explicit address then we subscribe the explicit address.
Is that something you think needs modifying?
No. The option to set a subscription to the literal primary address should still be available. I don't see a good reason to complicate the UI logic by comparing primary to literal addresses just to remove that one. I just want the primary address to be populated automatically, and inherit-from-primary be the default subscription address when the subscription address matches primary, *unless* the subscriber explicitly chooses that literal address in Postorius.
This is backward-incompatible, but I think it will be overwhelmingly popular with new users and old.
There would be no behavioral change for users using email commands. For those using P, I think will be able to manage and switch rather easily.
The email join command does the first part you suggested, (if the lookup succeed and matches primary address, use inherit) but doesn’t do the second part (it will create a user, add the address to it and then use the address to subscribe). We can and should fix that.
I think that's all we need to do going forward.
We do need a better UI for setting options (including address) for a selection of subscriptions, but that's an independent task.
Thanks for looking at this, Abhilash!
Of course :)
Steve
-- thanks, Abhilash Raj (maxking)