Changing subscription address
All,
I need help with this.
A subscriber is a member of 14 of the lists on my system (others have more subscriptions). This member needs to change the address and is dyslexic, so I’ve been asked to help.
I added the new address to her account in Django and set it as the preferred address. However, when she was subscribed, the system set her old address as the list subscription address, instead of her ‘preferred’ address. Well, I’m not sure of this as I cannot access her Settings, but that’s how it worked with one of my own addresses.
Will I now have to tell her to do this for each list she is subscribed to:
Select ‘Mailman Settings’ in dialog pulldown. Select one of the lists listed. Click on ‘Manage Subscription.’ In ‘Select Emai’, select the ‘Primary Address’ pulldown option Click on ‘Change email used for subscription.’
Please note that the “Global Mailman preferences’ nor the ‘Address-based preferences’ have the option to select the preferred address. I realize that once a member has an account in Django AND has preferred address set AND has selected the ‘Primary Address’ for each list, then this will be easier. However, I have 10000+ subscriptions by some 1500 members, most of whom were moved over from MM2 and have no Django accounts.
Someone on list some time ago advised me that it was possible to do this easily globally. I have spent a couple of hours on the system trying to find that way but the above per-list procedure is all I found.
Please make this easy, as I get these requests all the time and some, like this one, are on many lists.
Yours,
Allan
On 3/15/21 4:16 PM, Allan Hansen wrote:
Will I now have to tell her to do this for each list she is subscribed to:
If you have shell access to the server, you can do this:
$ /opt/mailman/mm/bin/mailman shell
Welcome to the GNU Mailman shell
Use commit() to commit changes.
Use abort() to discard changes since the last commit.
Exit with ctrl+D does an implicit commit() but exit() does not.
>>> um = getUtility(IUserManager)
>>> adr = um.get_address('old@examople.com')
>>> adr.email = 'new@example.net'
>>> commit()
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Allan Hansen writes:
Will I now have to tell her to do this for each list she is subscribed to:
Select ‘Mailman Settings’ in dialog pulldown. Select one of the lists listed. Click on ‘Manage Subscription.’ In ‘Select Emai’, select the ‘Primary Address’ pulldown option Click on ‘Change email used for subscription.’
Yes, that appears to be the case currently.
Someone on list some time ago advised me that it was possible to do this easily globally.
I think that what they are referring to is that if you
- Create a user account.
- Set and authenticate a primary email address.
- Allow all subscriptions to inherit from 'primary email address' (rather than setting any address explicitly)
*then*
- Changing the primary email address will change the subscribed address to all the lists.
Or they might have meant doing it with a script. But I didn't find a way in Postorius.
Please make this easy, as I get these requests all the time and some, like this one, are on many lists.
I don't have the Postorius knowledge to do this in a reasonable amount of time to help your user immediately, but how about this design:
In the 'Mailman Settings' screen, List-based Preferences' tab, currently each list has an active link at the list's posting address (which links to a page with the same options carefully documented), a plain text display of the subscribed address, and a row of options. Suppose we
- Add a popup menu of addresses and attach it to the displayed address for each subscription,
- Add a 'select subscription' checkbox to each subscription.
- Add an 'act on all selected subscriptions' fake subscription, whose checkbox has the effect of select or deselect all. I guess this should be at the top.[1]
Does that seem like what you have in mind? Any other needs you want to mention? (Suggestions for feature design are welcome, but "I do this often and there's got to be a better way" is good too.)
Regards, Steve
Footnotes: [1] Notes to implementers: The 'act on all' row needs tristate options. It should be at the top. The "fake list" itself can be a link to a heavily documented page like the regular per subscription page but with a couple of notes on the special behavior of the selection checkbox and the tristate options. When we "subscribe by address" (mass subscribe, email subscribe) rather than via a logged-in user, we should create a user, give it that primary address, and subscribe by primary address rather by that address literally.
Hi Steve,
My comments below:
On 3/15/21, 21:28 , "Stephen J. Turnbull" <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
I don't have the Postorius knowledge to do this in a reasonable amount of time to help your user immediately, but how about this design: < In the 'Mailman Settings' screen, List-based Preferences' tab,
You may mean the 'Subscriptions' tab.
currently each list has an active link at the list's posting address (which links to a page with the same options carefully documented), a plain text display of the subscribed address, and a row of options. Suppose we
- Add a popup menu of addresses and attach it to the displayed address for each subscription,
- Add a 'select subscription' checkbox to each subscription.
- Add an 'act on all selected subscriptions' fake subscription, whose checkbox has the effect of select or deselect all. I guess this should be at the top.[1]
Does that seem like what you have in mind? Any other needs you want to mention? (Suggestions for feature design are welcome, but "I do this often and there's got to be a better way" is good too.)
The above will work fine, Steve, as it will cover the special needs of people who have several addresses that they use for different lists. It's very flexible.
For the other 99% of my users, something much simpler is needed:
Under 'User profile for <name>', under the 'E-mail Addresses', add button to ensure that 'Primary E-mail' is used for all lists. Then they can
'Create account' if needed. 'Add E-mail'. 'Make Primary' the new e-mail. 'Use Primary For All Lists'. 'Remove' the old e-mail. This requires them to set up an account, but I'm OK with asking them to do that.
And, indeed, new subscriptions should default to 'Use Primary.'
That would be fine, but it can be even simpler, which I would much prefer:
Instead of the 'Use Primary For All Lists', may I suggest a tool that lets me set all subscriptions to 'Use Primarry' where there either is no account or where the primary e-mail is already chosen as the subscription address (which together form the 99% I mentioned). In that case, the procedure becomes much easier for me to explain to them, and no new functionality needs to be added (although what you suggested is fine).
'Create account' If needed. 'Add E-mail'. 'Make Primary'. "Remove' old email.
Is that possible now? Does a member have to have an account for me to set it up thus for them?
Thank you for considering this, Steven.
Yours,
AllanThank you for your comments, Allan!
Allan Hansen writes:
On 3/15/21, 21:28 , "Stephen J. Turnbull" <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
In the 'Mailman Settings' screen, List-based Preferences' tab,
You may mean the 'Subscriptions' tab.
I did mean the 'List-Based Preferences' tab. The 'Subscriptions' tab is non-functional. It's in some sense aesthetically more pleasing than 'List-Based Preferences', but you have to do extra, unnecessary work to get anything done from the 'Subscriptions' tab. It may make sense to just get rid of the current 'Subscriptions' tab and rename 'List-based Preferences' to 'Subscriptions'.
The only functionality of 'Subscriptions' over 'List-based Preferences' is that it lists you once for each role and address (member, non-member, moderator, owner) that you have for that list. This is possibly more confusing than helpful for non-owners. Moderators get informed of their role every time they need to do something. And it's possible to be both a member and a non-member of a list, which is pretty confusing.
Under 'User profile for <name>', under the 'E-mail Addresses', add button to ensure that 'Primary E-mail' is used for all lists.
If you define "ensure" strictly, this would be a fair amount of work because it would require overriding the normal "cascade" of preferences, and incidentally a way to turn off that override. I'd rather not make the implementation so complicated.
There does need to be a way to revert each option to inherit, and there currently doesn't seem to be one. The 'Preferences' interface I described in the previous post doesn't provide it either. I will think about that.
It should be normally unnecessary to use the 'Preferences' interface, because the default subscription should be "use primary address". For people using the current versions of Mailman 3, who are already have a bunch of subscriptions with the same *explicit* address, I think it is good enough. But if there's demand for a "revert all to use primary address" button, that would be easy enough to add.
Here's why I think such a button would be unnecessary in future versions of Mailman. What should happen if you subscribe by an address not already known to Mailman without creating an account in Postorius is
- Mailman registers the address.
- Mailman creates a User object to "own" that address, and makes that address the primary address for the User.
- Mailman creates a subscription which links the User (not the address) to the mailing list so that the primary address is used.
For addresses already known to Mailman, Mailman should look up the User registered to that address, and if the subscription address is the primary address, set "use primary address" for the subscription.
In this scheme, as far as I can see, your user doesn't need to do anything with the account until she wants to change the address. At that point she needs to activate the account:
- visit her personal options page in Postorius
- request a password reset (she doesn't have one yet, so she can't log in)
- click the special link
- set a password or link a social media account, and
- finally change the address.
Note that this is the bare minimum of work for her. She has to prove she can read mail at that address. Anything less, and *anybody* can change her subscriptions. We could omit requiring a new password, but it's not a lot of work once you've got to this point, while the "request, wait for email, click link, do work" dance is pretty annoying. Why make someone do it again next time?
This is problematic if she's already lost access to the old address, of course, but in that case you're probably going to have to intervene anyway.
I don't think Postorius requires her to do anything else, but if she wants to she can update her profile at that point.
I have to check the code, and probably also ask Barry and the other folks who designed the current subscription mechanism in case there's some fatal flaw in the scheme above. But I think that should do what almost all "one address" users want, and it's probably what the majority of people who have multiple addresses and use different ones for different purposes want most of the time, too.
Note to self of possible problems: (1) The primary address is where you would send administrative mail to the account holder and that might not be an appropriate address for the default subscription. (2) This is a pretty radical change from the current situation, so it might need to be an option for the list or domain owner.
And, indeed, new subscriptions should default to 'Use Primary.'
I agree. I'm astonished that there are situations where they don't, to be quite honest. That's the whole point of having accounts in the first place -- having *one* source of information about the user rather than spreading it out over a bunch of lists.
Is that possible now?
It is already the default for someone who subscribes by logging in to Postorius. I assume that it is *not* the default for someone who subscribes by email or mass subscription, otherwise you wouldn't have the problem.
Does a member have to have an account for me to set it up thus for them?
Yes. The primary address is an attribute of the account. Subscriptions can't know anything about a primary address unless there is an account. However, it should be possible to make this default for an account that hasn't been activated yet, such as in a mass subscription.
Regards, Steve
On Mar 18, 2021, at 8:29 PM, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Thank you for your comments, Allan!
Allan Hansen writes:
On 3/15/21, 21:28 , "Stephen J. Turnbull" <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
In the 'Mailman Settings' screen, List-based Preferences' tab,
You may mean the 'Subscriptions' tab.
I did mean the 'List-Based Preferences' tab. The 'Subscriptions' tab is non-functional. It's in some sense aesthetically more pleasing than 'List-Based Preferences', but you have to do extra, unnecessary work to get anything done from the 'Subscriptions' tab. It may make sense to just get rid of the current 'Subscriptions' tab and rename 'List-based Preferences' to 'Subscriptions'.
+1 We can do that. I don’t think I’ve ever used the subscriptions tab myself to do anything.
The only functionality of 'Subscriptions' over 'List-based Preferences' is that it lists you once for each role and address (member, non-member, moderator, owner) that you have for that list. This is possibly more confusing than helpful for non-owners. Moderators get informed of their role every time they need to do something. And it's possible to be both a member and a non-member of a list, which is pretty confusing.
Yeah, technically you can be subscribed to a list with all possible roles at the same time.
Under 'User profile for <name>', under the 'E-mail Addresses', add button to ensure that 'Primary E-mail' is used for all lists.
If you define "ensure" strictly, this would be a fair amount of work because it would require overriding the normal "cascade" of preferences, and incidentally a way to turn off that override. I'd rather not make the implementation so complicated.
There does need to be a way to revert each option to inherit, and there currently doesn't seem to be one. The 'Preferences' interface I described in the previous post doesn't provide it either. I will think about that.
The implementation of this isn’t very difficult, but the UX of this is something I don’t know how to implement in that page to be very honest.
It should be normally unnecessary to use the 'Preferences' interface, because the default subscription should be "use primary address". For people using the current versions of Mailman 3, who are already have a bunch of subscriptions with the same *explicit* address, I think it is good enough. But if there's demand for a "revert all to use primary address" button, that would be easy enough to add.
We do already have ability to switch from an explicit address to Primary Address subscription. I would imagine it would be more than just a button, but more like a dropdown to choose an email or primary address and switch all subscriptions to that.
Here's why I think such a button would be unnecessary in future versions of Mailman. What should happen if you subscribe by an address not already known to Mailman without creating an account in Postorius is
- Mailman registers the address.
- Mailman creates a User object to "own" that address, and makes that address the primary address for the User.
- Mailman creates a subscription which links the User (not the address) to the mailing list so that the primary address is used.
For addresses already known to Mailman, Mailman should look up the User registered to that address, and if the subscription address is the primary address, set "use primary address" for the subscription.
This is how Core actually does work1 if you subscribe via Email and you already have a primary address. It will lookup a user using the address and if the address is the primary address of the user, it will subscribe the primary address.
However, if it isn’t the primary address, and this is a new address, it will subscribe the address instead of user because the address isn’t verified at this point and hence can’t be a primary address. We could extend the subscription workflow to add an additional step to set this address as primary and subscribe the primary address.
Postorius has the full ability to define its own workflow because REST API provides full expression capability and doesn’t enforce anything. Previous versions didn’t had support for subscribing as Primary Address, but that has since changed and is the default one in the dropdown.
This is for authenticated subscription, the anonymous subscribe works similar to email -join command. Mass-subscribe is probably working the same way.
In this scheme, as far as I can see, your user doesn't need to do anything with the account until she wants to change the address. At that point she needs to activate the account:
- visit her personal options page in Postorius
- request a password reset (she doesn't have one yet, so she can't log in)
- click the special link
- set a password or link a social media account, and
- finally change the address.
Note that this is the bare minimum of work for her. She has to prove she can read mail at that address. Anything less, and *anybody* can change her subscriptions. We could omit requiring a new password, but it's not a lot of work once you've got to this point, while the "request, wait for email, click link, do work" dance is pretty annoying. Why make someone do it again next time?
This is problematic if she's already lost access to the old address, of course, but in that case you're probably going to have to intervene anyway.
I don't think Postorius requires her to do anything else, but if she wants to she can update her profile at that point.
I have to check the code, and probably also ask Barry and the other folks who designed the current subscription mechanism in case there's some fatal flaw in the scheme above. But I think that should do what almost all "one address" users want, and it's probably what the majority of people who have multiple addresses and use different ones for different purposes want most of the time, too.
Like mentioned above, it should be possible to do what you suggest. I am getting into the implementation details here, but the Subscription workflow would need an additional flag that would verify an address and use the flag to determine if it should subscribe the address or addresses’s user if an address is provided to the workflow.
Note to self of possible problems: (1) The primary address is where you would send administrative mail to the account holder and that might not be an appropriate address for the default subscription. (2) This is a pretty radical change from the current situation, so it might need to be an option for the list or domain owner.
And, indeed, new subscriptions should default to 'Use Primary.'
I agree. I'm astonished that there are situations where they don't, to be quite honest. That's the whole point of having accounts in the first place -- having *one* source of information about the user rather than spreading it out over a bunch of lists.
Is that possible now?
It is already the default for someone who subscribes by logging in to Postorius. I assume that it is *not* the default for someone who subscribes by email or mass subscription, otherwise you wouldn't have the problem.
Does a member have to have an account for me to set it up thus for them?
Yes. The primary address is an attribute of the account. Subscriptions can't know anything about a primary address unless there is an account. However, it should be possible to make this default for an account that hasn't been activated yet, such as in a mass subscription.
Primary Address is also an attribute of the Mailman User, so it should be possible for an admin to set that for a user if the user doesn’t have an account. When they sign up, they’d be able to manage and update accordingly.
I have started working on designing a User management page2 in Core which should make it easy for superuser to manage several things about a User, including the ones that don’t have an account in Postorius to manage their own. The list os “tasks” an admin can do isn’t decided, but please feel free to write comments there about things you’d like to be able to do as a server admin.
Regards, Steve
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- thanks, Abhilash Raj (maxking)
Abhilash Raj writes:
There does need to be a way to revert each option to inherit, and there currently doesn't seem to be one. The 'Preferences' interface I described in the previous post doesn't provide it either. I will think about that.
The implementation of this isn’t very difficult, but the UX of this is something I don’t know how to implement in that page to be very honest.
Oh, I can play Liz Warren on that one! :-) "I have a plan for that."
We do already have ability to switch from an explicit address to Primary Address subscription. I would imagine it would be more than just a button, but more like a dropdown to choose an email or primary address and switch all subscriptions to that.
Allan's situation is that for some reason he has a lot of users (or at least suspects he does) who would be happy to have only one address that there's only one place to change, but for some reason that address is copied to (not inherited by) each of several subscriptions.
We should address that, because I'm pretty sure his suspicion is correct. For example, until I changed one of them -- and got two emails about it for my discard pile :-) -- all of my python.org Mailman 3 subscriptions were explicit. I still have about 8 to go. :-)
This is how Core actually does work[1] if you subscribe via Email and you already have a primary address. It will lookup a user using the address and if the address is the primary address of the user, it will subscribe the primary address.
If you say so, I guess it's true. Nevertheless, both Allan and I have observed users with only one address, with that address subscribed literally each time to several (~10) lists.
However, if it isn’t the primary address, and this is a new address, it will subscribe the address instead of user because the address isn’t verified at this point and hence can’t be a primary address. We could extend the subscription workflow to add an additional step to set this address as primary and subscribe the primary address.
Yes, please, I think. Users who don't want this for subscriptions to the primary address are going to be (rare) edge cases. If we need an additional attribute on the user to handle the case of an unverified primary address, I think that's an acceptable cost. Note that to "claim" this User as her own, she has to verify that address. And if she *can* verify that address, we can't stop her from doing so, we can just make it more annoying.
Postorius has the full ability to define its own workflow because REST API provides full expression capability and doesn’t enforce anything. Previous versions didn’t had support for subscribing as Primary Address, but that has since changed and is the default one in the dropdown.
This is for authenticated subscription, the anonymous subscribe works similar to email -join command. Mass-subscribe is probably working the same way.
All of these should unify all subscriptions-by-this-address to one User, in my opinion.
Like mentioned above, it should be possible to do what you suggest. I am getting into the implementation details here, but the Subscription workflow would need an additional flag that would verify an address and use the flag to determine if it should subscribe the address or addresses’s user if an address is provided to the workflow.
I don't think so. Just do the lookup, if it succeeds and matches primary address, use inherit. If it doesn't succeed, create a User and use inherit. If it does succeed, and doesn't match, use the explicit address.
It seems to me that this flag would be impractical for email subscriptions (email commands with parameters are generally beyond the kind of user this is most important for) or mass subscriptions (how does the list owner know what the user wants?) anyway. If somebody really wants all their subscriptions via primary address to be copies of the primary address rather than user, I'm sorry, but they'll have to deal with that. I can't imagine that it's the usual case, and there's an easy workaround: make your primary address something other than your usual subscription address!
If you disagree with me about the relative burden, then maybe we shouldn't do this at all, but I'm pretty sure this is something we should either do for all subscriptions, or for none.
Primary Address is also an attribute of the Mailman User, so it should be possible for an admin to set that for a user if the user doesn’t have an account. When they sign up, they’d be able to manage and update accordingly.
True, but AIUI Allan has a *lot* of users and on average they're relatively needy compared to, say, my user population. The point of his request is to smooth workflows for admins with user populations where the admin *wants* to do many things for their users, or to have smooth user workflows when they teach their users to do it for themselves. That's why I'm focusing on the "I have one address and if it changes I want to change it once" case. I think it's both extremely common, and extremely annoying :-) to admins who have to deal with the current situation.
Steve
On Mar 20, 2021, at 4:36 AM, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Abhilash Raj writes:
There does need to be a way to revert each option to inherit, and there currently doesn't seem to be one. The 'Preferences' interface I described in the previous post doesn't provide it either. I will think about that.
The implementation of this isn’t very difficult, but the UX of this is something I don’t know how to implement in that page to be very honest.
Oh, I can play Liz Warren on that one! :-) "I have a plan for that."
We do already have ability to switch from an explicit address to Primary Address subscription. I would imagine it would be more than just a button, but more like a dropdown to choose an email or primary address and switch all subscriptions to that.
Allan's situation is that for some reason he has a lot of users (or at least suspects he does) who would be happy to have only one address that there's only one place to change, but for some reason that address is copied to (not inherited by) each of several subscriptions.
This is a common situation actually, given that Postorius until recently only allowed subscribing individual addresses. Also, any subscriptions imported from Mailman 2.1 are also subscribed as address.
We should address that, because I'm pretty sure his suspicion is correct. For example, until I changed one of them -- and got two emails about it for my discard pile :-) -- all of my python.org Mailman 3 subscriptions were explicit. I still have about 8 to go. :-)
+1
This is how Core actually does work[1] if you subscribe via Email and you already have a primary address. It will lookup a user using the address and if the address is the primary address of the user, it will subscribe the primary address.
If you say so, I guess it's true. Nevertheless, both Allan and I have observed users with only one address, with that address subscribed literally each time to several (~10) lists.
Well a couple of stars have to align for it to work unfortunately. I realized that Core will use the primary address if you *already* have one set during email -join command processing. Add to that you can’t set an address as primary using just email commands, you end up with what you are seeing.
Also, like I mentioned above, imported subscriptions are always address based.
Another thing I thought I should clarify is that when I said subscribed via Primary Address in this or previous emails, I really meant that the User was subscribed and subscription inherits whatever the primary address of the user is. As opposed to explicit address itself (which could also be the email address currently set as primary address).
However, if it isn’t the primary address, and this is a new address, it will subscribe the address instead of user because the address isn’t verified at this point and hence can’t be a primary address. We could extend the subscription workflow to add an additional step to set this address as primary and subscribe the primary address.
Yes, please, I think. Users who don't want this for subscriptions to the primary address are going to be (rare) edge cases. If we need an additional attribute on the user to handle the case of an unverified primary address, I think that's an acceptable cost. Note that to "claim" this User as her own, she has to verify that address. And if she *can* verify that address, we can't stop her from doing so, we can just make it more annoying.
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).
Postorius has the full ability to define its own workflow because REST API provides full expression capability and doesn’t enforce anything. Previous versions didn’t had support for subscribing as Primary Address, but that has since changed and is the default one in the dropdown.
This is for authenticated subscription, the anonymous subscribe works similar to email -join command. Mass-subscribe is probably working the same way.
All of these should unify all subscriptions-by-this-address to one User, in my opinion.
+1
Like mentioned above, it should be possible to do what you suggest. I am getting into the implementation details here, but the Subscription workflow would need an additional flag that would verify an address and use the flag to determine if it should subscribe the address or addresses’s user if an address is provided to the workflow.
I don't think so. Just do the lookup, if it succeeds and matches primary address, use inherit. If it doesn't succeed, create a User and use inherit. If it does succeed, and doesn't match, use the explicit address.
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?
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.
It seems to me that this flag would be impractical for email subscriptions (email commands with parameters are generally beyond the kind of user this is most important for) or mass subscriptions (how does the list owner know what the user wants?) anyway. If somebody really wants all their subscriptions via primary address to be copies of the primary address rather than user, I'm sorry, but they'll have to deal with that. I can't imagine that it's the usual case, and there's an easy workaround: make your primary address something other than your usual subscription address!
The flag I was talking was not really a user visible one but just thinking code flow. It might have to be a flag in API though to differentiate between the “verify this address and subscribe it” vs “verify this address, set it to primary and subscribe the User” cases.
I agree that in situations where we just have an address to subscribe and no user exists, we create a user, add the address and verify and set it to primary and then use inherit. This should apply to, mass subscribe, anonymous subscribe and -join command.
If you disagree with me about the relative burden, then maybe we shouldn't do this at all, but I'm pretty sure this is something we should either do for all subscriptions, or for none.
No, I think it shouldn’t be a big burden.
Primary Address is also an attribute of the Mailman User, so it should be possible for an admin to set that for a user if the user doesn’t have an account. When they sign up, they’d be able to manage and update accordingly.
True, but AIUI Allan has a *lot* of users and on average they're relatively needy compared to, say, my user population. The point of his request is to smooth workflows for admins with user populations where the admin *wants* to do many things for their users, or to have smooth user workflows when they teach their users to do it for themselves. That's why I'm focusing on the "I have one address and if it changes I want to change it once" case.
Makes sense.
-- thanks, Abhilash Raj (maxking)
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.
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.
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.
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!
Steve
- Stephen J. Turnbull (turnbull.stephen.fw@u.tsukuba.ac.jp) [210322 15:54]:
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.
[...]
Not sure which is the right mail to answer, so I'm trying with this one.
To make it more complex (perhaps?), I'd like to switch django to use the single sign on-system, which means: mail adresses and user accounts are managed elsewhere, and djano / mailman / whatever component consumes accounts (and verified mail adresse) from the central account store.
Reading your mails, I'm currently not sure what the impact is. But surely there will be some.
Andi
Andreas Barth writes:
To make it more complex (perhaps?), I'd like to switch django to use the single sign on-system, which means: mail adresses and user accounts are managed elsewhere, and djano / mailman / whatever component consumes accounts (and verified mail adresse) from the central account store.
Django *is* our single-sign-on system, and Mailman core *is* our central account store. That's why it's possible to mix and match Mailman core with other UI applications. This has been proved in practice by at least one commercial service.
That is, we don't do *any* authentication in Mailman core. And because authenticating general Internet connections is *hard*, we want to keep it that way![1] ;-) The single exception is the mail address verification dance, which is an extremely simple protocol with a well-known threat model that nobody can do anything about (somebody who can read your mail).[2]
So we delegate authentication and credentials management to Django, which already knows how to do passwords, OAuth and friends, and probably multifactor, too. That's *all* that the Django account functionality does for Postorius.[3] All the other user and admin information that Postorius exposes are ultimately backed by queries to Mailman core's REST API, not by Django's internal database.
This subthread is 100% about how to initialize the Mailman core user record in a way more consistent with user expectations. The other, closely related subthread is about presenting tables of subscriber data for multiple subscriptions, instead of requiring people to visit per-subscription pages. There's no need to change the division of labor between core and Postorius to implement either.
Steve
Footnotes: [1] We probably can't, in the long run. People definitely want Mailman systems distributed across multiple hosts, and there are limits to how well that can work with all the hosts behind a firewall. That implies authenticating connections to the REST API endpoints.
[2] Technically, in theory we could encrypt the verification email in case there's a miscreant-in-the-middle who can read plain text, but then we've got a key distribution problem and a user education problem. Encryption is like regexps but worse: whenever you have a problem and you adopt encryption as the answer, now you have *three* problems! :-P
[3] I'm not sure about HyperKitty. Mailman core doesn't know or care about web preferences, so I suppose HyperKitty has to store them somewhere.
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)
Abhilash Raj writes:
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.
OK, it sounds like we're thinking basically the same process, just using slightly different words to describe it (and mine have definitely been inaccurate about current logic at points, adding to the confusion :-P ).
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.
I wasn't aware of that. I haven't yet done a mass-subscribe from Postorius (I have a bunch of scripts for generating mailing lists from student rosters and just retargeted them to the REST API :-).
Steve
Core implementation details, so I beinging this here from Mailman Users @ mailman3.org.
Abhilash Raj writes:
I have started working on designing a User management page2 in Core which should make it easy for superuser to manage several things about a User, including the ones that don’t have an account in Postorius to manage their own.
I don't understand this design with a "page in Core". I was thinking about this kind of problem, and tentatively came to the conclusion that any reference to something that can be resolved to a User should generate a Django account for that User in Postorius or HyperKitty. Authorization to use that account would still require authentication via the usual email verification dance, or some level of admin privilege.
The thing is that emails that have not been added to a User are unique. They will be the only Address attached to User created to manage them until authenticated, and transitively the only address attached to an automatically-created Django account (since those are 1-1 with core Users if they exist AFAIK).
What's missing here is the ability to merge core Users and their corresponding Django accounts. Doing this with nothing more than the usual email verification dance is not *obviously* provably secure to me, so we need to be careful, but I think it probably will turn out to be as secure as you can get. It seems to me that User merging is the most pressing problem of this kind. (At least, it affects me on a couple of list hosts, as well as on GitHub and GitLab.)
I'll take a look tomorrow or early next week.
Steve
On Mar 20, 2021, at 6:22 AM, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Core implementation details, so I beinging this here from Mailman Users @ mailman3.org.
Abhilash Raj writes:
I have started working on designing a User management page2 in Core which should make it easy for superuser to manage several things about a User, including the ones that don’t have an account in Postorius to manage their own.
I don't understand this design with a "page in Core”.
Typo :( Page in Postorius is what I meant to say.
I was thinking about this kind of problem, and tentatively came to the conclusion that any reference to something that can be resolved to a User should generate a Django account for that User in Postorius or HyperKitty.
Is that necessarily required? Every user in Django has a corresponding user in Core, but the converse isn’t true and I am not sure if that is even required.
The purpose of a Django account is to manage my own email addresses and subscriptions. An admin can manage a Core User that does or doesn’t have a Django account. The only thing that changes is what they can do with that user. See below for my thoughts on the actions an admin would be able to perform.
The high level design of that user management page is that it will provide a list of Users straight from Core. When you go to an individual User’s management page,
You will be able to see:
- Does the user have a Django account?
- All Subscriptions for the User
- All addresses of the User
You will be able to perform following actions:
- Add or remove a user’s address
- Verify or un-verify an address
- Set any address as primary for the user
- Update display name of the user
- Update address on any of the subscriptions
If the User has a Django account, you also be able to:
- Manage the User’s password *if* they are using password for login and not social auth.
- Reset “social login” for the user?
- View some of the RO info about the Django User model, like last login, superuser status or few other attributes that we feel is useful for admin in any situation.
What I am on fence about:
- Provide a full blown preferences menu to the admin for that user. This will also make the UI extremely complex to see and implement.
Authorization to use that account would still require authentication via the usual email verification dance, or some level of admin privilege.
The thing is that emails that have not been added to a User are unique. They will be the only Address attached to User created to manage them until authenticated, and transitively the only address attached to an automatically-created Django account (since those are 1-1 with core Users if they exist AFAIK).
In Core, when a new address (email1) comes in, a Mailman User(user1) is created for it.
But, when you have an account in Django with a different email (email2) and a different Mailman user (user2) and you add a second email (email1) to your account and are able to prove ownership by verifying the address, Django will ask Core to add that second address (email1) to your Mailman user (user2) and absorb “user1”. This process is already implemented.
However, if two Django accounts are created for “user1” and “user2” then situation becomes more tricky and currently we don’t have a way to resolve that short of delete one of the accounts and add the addresses to other account.
What's missing here is the ability to merge core Users and their corresponding Django accounts. Doing this with nothing more than the usual email verification dance is not *obviously* provably secure to me, so we need to be careful, but I think it probably will turn out to be as secure as you can get. It seems to me that User merging is the most pressing problem of this kind. (At least, it affects me on a couple of list hosts, as well as on GitHub and GitLab.)
I'll take a look tomorrow or early next week.
It is far from actually usable, so you can actually skip it for now ;-) I can announce it when it is in semi-usable state.
-- thanks, Abhilash Raj (maxking)
Abhilash Raj writes:
Typo :( Page in Postorius is what I meant to say.
:D No problemo, mon, I just did it too ->
Is that necessarily required? Every user in Django has a corresponding user in Core, but the converse isn’t true and I am not sure if that is even required.
I meant "accessed from Postorius or HyperKitty." :-)
You will be able to see:
- Does the user have a Django account?
- All Subscriptions for the User
- All addresses of the User
You will be able to perform following actions:
- Add or remove a user’s address
- Verify or un-verify an address
- Set any address as primary for the user
- Update display name of the user
- Update address on any of the subscriptions
I don't think we *need* a Django account for what I'm thinking of. I do think that creating the account on User access from Postorius might make the implementation logic simpler.
What I am on fence about:
- Provide a full blown preferences menu to the admin for that user. This will also make the UI extremely complex to see and implement.
Wait to decide on that until I have a mockup or maybe a full MR.
But, when you have an account in Django with a different email (email2) and a different Mailman user (user2) and you add a second email (email1) to your account and are able to prove ownership by verifying the address, Django will ask Core to add that second address (email1) to your Mailman user (user2) and absorb “user1”. This process is already implemented.
Good.
However, if two Django accounts are created for “user1” and “user2” then situation becomes more tricky and currently we don’t have a way to resolve that short of delete one of the accounts and add the addresses to other account.
Delete "that" and add its attributes to "this" is what I had in mind. Again, thanks for explaining the existing logic.
Steve
On Mar 22, 2021, at 7:56 AM, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Abhilash Raj writes:
Typo :( Page in Postorius is what I meant to say.
:D No problemo, mon, I just did it too ->
Is that necessarily required? Every user in Django has a corresponding user in Core, but the converse isn’t true and I am not sure if that is even required.
I meant "accessed from Postorius or HyperKitty." :-)
You will be able to see:
- Does the user have a Django account?
- All Subscriptions for the User
- All addresses of the User
You will be able to perform following actions:
- Add or remove a user’s address
- Verify or un-verify an address
- Set any address as primary for the user
- Update display name of the user
- Update address on any of the subscriptions
I don't think we *need* a Django account for what I'm thinking of. I do think that creating the account on User access from Postorius might make the implementation logic simpler.
What I am on fence about:
- Provide a full blown preferences menu to the admin for that user. This will also make the UI extremely complex to see and implement.
Wait to decide on that until I have a mockup or maybe a full MR.
But, when you have an account in Django with a different email (email2) and a different Mailman user (user2) and you add a second email (email1) to your account and are able to prove ownership by verifying the address, Django will ask Core to add that second address (email1) to your Mailman user (user2) and absorb “user1”. This process is already implemented.
Good.
However, if two Django accounts are created for “user1” and “user2” then situation becomes more tricky and currently we don’t have a way to resolve that short of delete one of the accounts and add the addresses to other account.
Delete "that" and add its attributes to "this" is what I had in mind.
We could automate the absorb other account and copy all settings and subscriptions over in a user based workflow. I don’t see a lot of unknowns in implementing that.
You have to manually do it today, and deleting account will delete subscriptions so when you add them to your other account you have to resubscribe. So, the path could really use some changes. I think I have a ticket open in P to allow deleting P account but not delete the Mailman User and subscriptions, which would make this manual process much better.
-- thanks, Abhilash Raj (maxking)
participants (5)
-
Abhilash Raj -
Allan Hansen -
Andreas Barth -
Mark Sapiro -
Stephen J. Turnbull