Brian Carpenter writes:
I reported a serious problem.
Inability to change display name is an annoying problem that probably *will* affect quite a few users, and if they can't do it themselves, it will affect list admins and then site admins who are asked to do it for them.
Nobody has said we won't work on that, but it's not like we've had 1000 reports in the several years that Mailman 3 has been in production use. Nor is it all that big a deal: the user retains control of the display name in each post (modulo the DMARC mitigation). As far as I know the stored display name is only used cosmetically (in the UIs for user configuration of Postorius and HyperKitty and in administrative mail to the user).
The reply was to bring up assumptions that should not be made such as a list member is actually a registered user.
I'm not sure what you think is going on here. Users (registered) are the locus of authentication in Mailman, and as such they are more or less equivalent to Mailman's raison d'être, namely giving (human) users control of their own subscriptions. The difference between Mailman 2 and Mailman 3 is that in the former a user *is* an address, in the latter a user *has* an address (and maybe several).
The original "user == subscription" model of Mailman 2 is plausible, but it wasn't sustainable. The users and admins we hear from most are "heavy users": the users subscribe to dozens of lists, typically several on a single host. They *really* wanted a single user that could provide a dashboard with one authentication, convenient default settings for new subscriptions, and access to information about all subscriptions and the user profile in the dashboard. And that's why Mailman 3 has a model with users (the core concept corresponding to human beings), addresses, and subscriptions (memberships), where most addresses are backed by users.
As you said they [list members] are not [registered users].
I'm pretty sure I didn't say that, but if I did, it's *still false*. Users are the core concept. It's *possible* to have addresses (and maybe subscriptions?) without users, but the normal case is a user which has one or more addresses, which are subscribed to one or more lists.
Regardless of whether they are just a list member or a list member that is also a registered user, there is NO MECHANISM in place where you can change their associated display name
Ie, you agree. The *issue as originally reported* is that the display name cannot be changed in Mailman's database.
AND their data is not entirely removed when a reasonable assumption is being made that it has,
It's not reasonable for Mailman 3, as Mark and I have explained.
such as list unsubscribing.
If a user unsubscribes from a list, that unlinks *one* of the user's addresses from *one* list. Assuming that that has anything to do with existence of user data is unwarranted in Mailman 3, and it was extremely weak in Mailman 2 as well, since unsubscribing fron one list doesn't change the fact that the address may be subscribed to other lists on the same server, likely with the same metadata (really the password was the only important thing, but that confirms the principle).
If you want to automatically delete any associated user any time a list is unsubscribed in Affinity, you *can* do that. I don't think it's a good idea, not at all, but you *could*.
I deal with the case where the user has exactly *one* subscription below. But that is not the general case.
Sorry but I can't see how this behavior can be justified
Then you need to cool down, and think about how this actually could work, not how somebody who makes incorrect assumptions would like it to work.
and also not being made a high priority to fix.
Offer me 25,000 yen/hr and I'll do the display name change next week. Priorities differ.
Some may think that retaining data when there is a reasonable assumption that it is being removed
It's not a reasonable assumption in Mailman 3, though, as Mark and I have explained.
is immoral and not just a violation of GDPR.
I don't disagree for reasonable assumptions.
I'm well-aware of the ethical and legal issues here. We may want to add a facility so that users can delete themselves. But that's a *hard* problem if it's going to be "right to be forgotten" compatible because you can't keep backups -- we need to be sure that the user knows what they're doing (and if they've assumed that the data "should" be removed, we already know they don't know what they're doing!) I don't think we keep Bitcoin wallets in the Mailman metadata (yet ;-), so deleting your user won't bankrupt you. But you will lose all your *other subscriptions* and your default settings, etc. The latter is a PITA until we build up a nice suite of templates (and I don't think we have user templates yet anyway).
And once we do add that feature, it probably makes sense to offer to do so (after explaining the consequences) if the user deletes their last subscription.
But I just don't see this as a major issue, except maybe for corporate users under GDPR and friends. And I doubt *they* will even blink at my consulting rates. :-)
As I said in my reply to Mark, it is a big deal for list owners (admins) because they are the ones that are going to be interacting with Postorius/Affinity the most.
Technical question: Why do you include Affinity? As far as I know, Mark is correct, you can both change display names and delete users with mailmanclient, and therefore with the REST API (mailmanclient is just a wrapper around the REST API, it has no superpowers). In Affinity, this behavior is under *your* exclusive control.
I also don't agree with your claim about admins interacting most. Yes, they will interact more often, but in my experience most interactions are conducted by ordinary users, not admins. That may not be true for your hosted lists, since they're aimed at a very different population from my software devs and economics professors and university students, but there are large populations of users out here who are perfectly happy to manage their own subscriptions, thank you very much.
In any case, there's very little difference between users and admins for this kind of feature, *except* the scope of resources they can view and modify. If Postorius gives the feature to users, it will be trivial to enable it listwide for list admins, and vice versa. But deleting users is an even harder problem with respect to list admins: what if the user is subscribed to a list on a different virtual host that the list admin can't know about and the user may not realize is the same Mailman user? *Probably* it's good enough to refuse to delete the user in that case, but it's not obvious to me that users who make wrong assumptions will see it that way.
Most list members, especially those migrating from MM2, will not be registering with Postorius/Affinity.
I'm not sure what you mean. If you mean "the migration script will register them", OK, but they're still registered and still subject to the user-address-member model.
But Postorius is just a UI. Postorius does have its own database, which is often confusing, but the user-address-member model is in core. It's core where the important registrations for subscribers take place. You can have a user-less address in the database, but for the address's owner to do anything with it, such as subscribe to a list or set a list to vacation mode, they have to authenticate (that includes implicit authentication with the OTK used to confirm a new user), and to authenticate they have to have a registered user, not just an address. Most addresses will be associated with users.