On 10/19/20 11:32 PM, Mark Sapiro wrote:
On 10/19/20 7:42 PM, Brian Carpenter 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. Mailman 2 made this so easy and Mailman 3 made it impossible. I will let someone else file the bug report. You don't really think that
On 10/19/20 10:23 PM, Mark Sapiro wrote: this is an issue which means it will be years before it is addressed. So I will save me some time. I will learn to live with it.
I didn't say I didn't think it was a real issue. I mostly questioned whether a new subscription should change an existing display_name. I agree that there should be a way for a user to change the display_name associated with her address. I'm not so sure about a list admin.
Respectively, I think you are asking the wrong question here. The real question is why isn't a display_name being removed when a list subscriber is unsubscribed. Also list members being forced into a powerless role by Mailman 3's architecture have no way of changing a name except through a list owner unless they register an account but then again, *even that doesn't allow them to change their display name*. There are also other use cases in which a list owner will want to identify portions of their membership roster through the use of the display_name.
Most list members interact with a Mailing list program via email. I know you understand that. However it is List owners that are the "real" power users of Mailman and so the admin interface should be designed in such a way that empowers List owners. Taking the ability away from List owners (and List members to make), what should be a simple name change, weakens them.
And in any case, I'm only one person. I'm not the only one deciding what's important and what's not. I only decide what I want to work on, not what anyone else thinks is important or wants to work on, so even if I think something is not worth doing, that doesn't mean it won't get done, and once again for emphasis, I do thing a user should be able to change the display name associated with her address(es).
Again I think we are missing something here from this conversation: data is not being removed. A list subscriber being removed (unsubscribed) should have their information totally removed. It is not. I now have one list owner who realizes this and it is not good. How does this not violate GDPR? This is why I think all the mailman developers ought to make this issue a high priority. It is creepy to see a name returned out of nowhere when someone resubscribes to a list without associating a name with a second resubscribing. I think this puts List owners at a disadvantage.
Mailman 3 is totally different from Mailman 2.1 in this respect. Mailman 2.1 had no concept of user. All it knew was addresses subscribed to lists and an address subscribed to one list had no connection to the same address subscribed to another list or being an owner or moderator of a list.
I think this should still be the case for non-registered list members. List owners/moderators are different. They HAVE to be registered users of Postorius/Affinity in order to manage/moderate a list. I wonder what the majority of list members' scenarios are. Is the majority scenario in play today the one where most list members are only subscribed to a single list on a single mailman instance? Or is it the scenario that is in majority use the one where a single list member is subscribed to multiple lists? I think that it is important to find out because it should govern the development process to a certain degree. This single approach of having registered user account with multiple associated email accounts elevates one scenario at the expense of the other. It also assumes/requires that list members have a registered user account and I can tell you from my experience that is not going to happen. The majority of mailman 2 users will not registered with a Mailman 3 admin interface. Some will of course, the majority will not. Maybe the behavior should and will change but it will take years for that to happen. So what I am challenging and questioning here is the approach where such assumptions are being made already that results in the weakening of list owners.
Mailman 3 does have a concept of user and addresses belonging to a user. This complicates things in some ways. In Mailman 2.1 we could have "The Boss <user@example.com" as a member of one list and "Just a Peon <user@example.com>" as a member of another list. In Mailman 3 that is not possible unless the addresses are tweaked in some way to make them different.
Perhaps there is a better approach here to handle single member w/multiple subscriptions that doesn't hurt the ability of List owners to serve the needs of list members who do not have a registered user account and prevents the removal of data when a SINGLE user unsubscribes from a list.
You don't seem to be concerned about the case where I subscribe to a second list with a different display name and am surprised to find my display name changed on the first list, but it's something that I have to consider.
I am not concerned because I think such cases are in the extreme minority. Are you saying that people are now going to be using different real names associated with their other subscriptions as well and that is going to be so needed it warrants this complex system that you have come up with? If someone whats to have a different name associated with a different subscription/email address then I am going to tell them create a new user account and use a good password management program to keep track of their logins. Right now I think this minority use case scenario is negatively impacting other administrative tasks of Mailman, particularly in the removal of user data when someone unsubscribes from a list. Its the use of a square peg being forced into a round hole. Except in this case most of the holes are round but by golly, we are going to use that square peg regardless!
As far as filing or not filing an issue, issues in the GitLab trackers are how we track these things. Threads on mailing lists are appropriate for discussion of issues, but if something is going to get changed or fixed, an issue in the tracker is the way to ensure it doesn't get put aside and forgotten. If this is as important to you as it seems to be, please file the issue.
I will but what is disturbing is that you don't think that the non-removal of user data in cases of unsubscribing is not important or even an issue.
--
Brian Carpenter Harmonylists.com Emwd.com