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