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)