On 10/20/20 11:19 PM, Mark Sapiro wrote:
On 10/20/20 6:54 AM, Brian Carpenter wrote:
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.
I'd like to understand the real requirement. It seems to me that this issue has come up because a list admin wanted to change the display name shown in the membership roster for a user. Since there is currently no UI to do this, the list admin tried to do it by unsubscribing and resubscribing the user. That didn't work which led to this "unsubscribing a user should remove the user's information" thread, but the real issue is the lack of a UI for changing display names. It seems if that UI existed and was available, the "unsubscribing a user should remove the user's information" issue would never have been raised.
There are two real requirements. One is to be able to do something as easy as changing a name for a list member. I did a lot of testing with the relationship between a name used for a subscription versus a name used for registering via the U.I. (Postorius/Django) and it is very confusing. I still am having a very difficult time understanding the logic presented here for the way Mailman 3 handles user information.
The second requirement is ALL data should be removed if someone unsubscribes from a list that is just a list member of a single list. I feel very strongly about that. I don't really care for the reasoning behind why the data is retained. I just think it should be removed for a list member who has no need for an account that manages multiple email address and is subscribed to multiple lists.
I host many single lists. So it is very important to me, and as an advocate for my clients, I will state very clearly how important it is to me (and my clients) regards of other user scenarios out there (looking at you Mr. Turnbull). I care about my own.
So perhaps what we should be talking about is UIs for changing user information, what they would look like and who should be able to change what.
That is a start and I thought I brought that up. We also need a separate conversation on the retention of data apparently.
Note that I personally am a member of many lists, an admin of multiple lists and a site admin for multiple mailman installations. I am well aware of the frustrations of list admins who wind up just doing it because it's way easier than instruction some users as to how to do it themselves. However, I don't think that is necessarily sufficient reason to hand over control of global, non-list specific user information to the admin of one particular list that the user happens to be a member of.
I never asked for global control for list owners. You have made that almost a necessity with the multiple email address per user account feature that you brought in. I don't think List owners should have global control but server owners certainly do. But the rightful avoidance of such control for List owners, I think has resulted in a wrongful limiting of what they can do currently.
I so disagree with S. Turnbull's disparaging comments that I think we ought to be designing for List owners primarily and not list members/users when it comes to user interfaces. From what I see, it is mostly server and list owners that are interacting with this (mailman-user) list and not list members/users. In my experience, I never hear from list members. Just list owners. Whatever issue list owners have with their own list members are easily handled by them when it comes to Mailman 2. Not so much with Mailman 3.
Even in mailman 2.1, while a list admin could go to a user's options page for the list and change things, the "change globally" check boxes only worked for the user, not for the list admin.
-- Brian Carpenter Harmonylists.com Emwd.com