I am a bit late to this thread, but I am going to try to respond to some of the points raised in the thread.
On 10/19/20 7:42 PM, Brian Carpenter wrote:
On 10/19/20 10:23 PM, Mark Sapiro wrote:
And the import21 created the user and address records for this user. Does the same thing for a new subscriber as well. So there is no pathway to change a real name that is associated with an email address. None. Zilch.
Yes, this is a limitation of the REST API, the display_name attribute can't be updated. Hence, Postorius can't provide a way for anyone to update the name. I have opened an issue for this1 and I think it should be allowed.
I am admin for a list. Users got subscribed with bulk import during transition from MM2 to MM3. So in a sense I am responsible for adding these to a db. BUT there is no way for me to remove them. Only mailman admin with access to the db can do it manually.
The fact that a user's memberships & User as an entity that owns email address is a design choice that Mailman developers made after some experience of using and administering Mailing lists running on Mailman 2. It was annoying to have to manage several different passwords and accounts to manage membership on same mailing list server.
The policy decision that Mailman would allow a user/address to exist even if there are no subscriptions on it isn't un-resonable in certain environments and maybe it is in some. I don't think anyone here denies that either of those behavior could be an expectation from someone using Mailman. But Mailman is an open source project with decent amount of extensibility via HTTP API & Python plugin system.
If the default policy doesn't match the expectations of some users, I don't think it is difficult to cleanup users/address with 0 subscriptions in a nightly cron script. It is trivial with some basic scripting and we are happy to help out with such a mechanism. I wouldn't be opposed to directly adding a command in Core that lets you clean up all sorts of stuff.
On Wed, Oct 21, 2020, at 10:20 AM, Apollinaris Schöll wrote:
There might be a handful of these.
But the bigger problem is a user can’t be removed entirely.
User can delete account and unsubscribe from all lists. But the email and user name is still kept in the db. Just tested with Affinity List admin can’t do it either.
Front-ends like Affinity should be able to implement such a policy by checking subscriptions of an address on every un-subscription call and delete the user & address if it comes out to be 0. The API is documented here2, but if there are gaps in there like I mentioned above in my email, please open issues so we know about them.
I think the correct action is to remove all records if a email is unsubscribed from all lists and that user has not registered for an account. If a user has registered for an account all information including display name must be removed from that particular list subscription. It should not matter if a user unsubscribes or a list admin unsubscribes. There shouldn’t be any data kept.
Also, like mentioned above, as a list admin, you can request the Site Admin to get the address fully scrubbed or if this is an expectation from all list admins, the Site Admin has the ability to automate such a task. The fact the Mailman doesn't do it by default is because the definition of "correct" action is different.
User should have the ability to delete themselves from the system and if it doesn't wipe everything yet from database, it should be considered a bug in Postorius and be fixed. Postorius track users separately than Core, so the it should make sure to delete in both places and there are appropriate APIs in core to delete Users and Addresses.
Now, the ability in Postorius to edit the display_name. The side effect of the model where User is a Site level thing, makes it impossible to customize user's display_name on a per-list basis, for both list admin and the user themselves. That is a trade-off and it is possible that there were use-cases where that was desirable in Mailman 2, but with the superior subscription management functionality in Postorius, I feel the decision is justified. I respect that some of y'all think that it probably isn't if it doesn't suit you particular use cases.
From the thread, I gather than folks mostly agree that a list admin shouldn't be allowed to edit a user's display name. Site Admins however should be able to edit that, which brings me to next point.
Like Mark brought up, there is definitely a big missing feature of User management in Postorius. This future management page would be for Site Admins (Superusers) to manage Users and have the ability to change pretty much everything about users including their addresses, memberships and preferences and also be able to wipe off the users from all the databases if they want to. If there are more features than that which folks think should be a part of this, please feel free to add to it. As it is hopefully implied from the description, it is a big task and needs substantial chunk of time, part of which this hasn't been picked up yet.
On Oct 21, 2020, at 1:43 AM, Jörg Schulz <info@joergschulz.de> wrote:
So, the issue seems to be, like in the following scenario
We imagine a list server for the domains fruiteaters and meateaters. We have two listadmins, anna (fruit) and carl (meat). They don't share anything. We have a user who subscribes to fruiteaters and meateaters using his address hunger@eatall.com
He wants to show up in the fruiteaters list as fullname wormy wonder, but in the meateaters list as fritz the cat. While he can do so using two different email addresses, he cannot do so using
wormy wonder <hunger@eatall.com> fritz the cat <hunger@eatall.com>
as from: addresses because all requests will be matched to the one email address.
Worse, if Carl would be able to change the name to from wormy wonder to fritz the cat, Anna would see that name change and like to change it back because the user she had known, user has been identified as wormy wonder.
So, if these user properties are stored somewhere not related to the lists, we don't seem to have a chance of display name changes by list admins as long as the data model isn't changed. This doesn't seem to be easy.
So, only some kind of super-Admin should currently be able to change these display names, and these changes would be visible for all lists, and one email address can only have one display name for all lists.
Not optimal for some rare conditions - that's the way it seems to be???
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/
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)