Washington Odhiambo via Mailman-users writes:
A member requested to be subscribed to a list through the normal process (confirm and approve). I approved. Shortly after, I received an email they sent to one of the moderators requesting that their subscribed address be changed from the OLD to the NEW(ly subscribed) one. So I deleted the new address via Postorius.
In the list (subscription) view, I presume?
[Long story omitted]
In Mailman (core, and mirrored in Postorius), each textual address is backed by a unique Address object. It has a number of attributes, including the address as a string, a display name, and a User owner. The changeaddress command operates on an Address object, and simply substitutes one string for another in the address attribute. The relation is one-one, so if both addresses are in the database, each is owned by a different object. That's why you get the "address exists, can't change" error. I don't know if there is an admin accessible way to completely delete an Address once it has been created (other than "mailman shell", which is, of course, cheating!)
I believe that all you did was to remove the subscription. That's just a relation in the database. But the Address object for kevin@[REDACTED] remains.
I went into Django Admin US and searched for - and found the address still in there. I deleted it again.
That's a different database table. I'm not sure why the address was in there, I guess because it's the usual identification for a user when authenticating. You may have made it impossible for kevin@[REDACTED] to log in to Postorius.
Oh, and maybe we should have that changeaddress option in Postorius as well?
I don't think so. The changeaddress command is very dangerous because it operates directly on the database, changing something that we think of as user identification. Not to mention, I suspect it's broken (it SHOULD change the address Django uses for authentication, too, but I don't see how it can, since we don't even know if Django is in use). The only valid use I can think of is if the address string is a typo (but it's still broken!) In that case we do want the old string to be removed from the database without disturbing the User-Address and MailingList-Address relations.
If you want an atomic "subscribe new and unsubscribe old, perhaps globally" operation in Postorius, feel free to request it. But it's likely to be complicated, and most of its use cases are covered by having users subscribe their "primary address" rather than an explicit address. Adding and verifying a new address, then switching the primary to that would even be atomic (in the sense that a race between subscribing new and unsubscribing old won't cause the user to lose mail or get duplicates).
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan