On 11/4/20 12:04 PM, Stephen J. Turnbull wrote:
Brian Carpenter writes:
If you mean if they don't have a Django user account, they can't unsubscribe?
The Django user account is more or less a proxy for the underlying Mailman User object, which is what we're concerned with here because that's where the data you want deleted is stored.
I think that is true if they are wanting to unsubscribe via the web interface. But sending an email to listname-unsubscribe@listdomain allows them to unsubscribe without such user authentication. Isn't that correct?
They don't need a Django password or social auth, but they'll still have to do the OTK dance. I don't see a reason to distinguish the methods of authentication. They all reduce to the OTK dance to prove ownership of a mailbox, then optional *delegation* to a password in Django or social auth via Gmail etc.
Please speak in simple terms. I am pretty sure my questions were straightforward but I have a sneaky suspicion you convoluted the issue with these replies. I feel like my questions were not answered.
I understand that your users don't understand this or care to. Thing is, some of *our* users care about the features that this architecture enables.
I think everyone should care that data should be removed when there is an expectation that it is being removed.
My intent in our changes is to give the list owner and member exactly what they expect: when they explicitly remove a subscription and/or user profile, that they expect their data to be totally removed.
That's fine, and you're welcome to implement that in Affinity. In fact, as I understand it, you have already done so. *I'm* not saying *nobody* should implement that.
I'm saying that *Mailman* shouldn't, because a lot of subscribers to Mailman lists won't like it. The whole point of Mailman 3 is to cater to users who want powerful control over their subscriptions. For Mailman (Postorius), prompting the user "If you delete this subscription, you will have no subscriptions linked to this account. Would you like to delete the account as well?" (as I have proposed three times now) is the right way to go. This can be implemented via email with a second OTK.
Since the account is a django account, I don't see why unsubscribing from a list has anything to do with that account except removing the user's prefer settings for a list that they are no longer subscribed to. For me I made this issue about those list members who unsubscribe from a single list AND does not have a django user account. This discussion has expanded to all kinds of scenarios.
Those who are the power users are not in play here. I am sure they intend to to keep their subscriptions active and their django account open. I am talking about those who want to leave a list or wants to remove their django user account permanently.
I can easily picture a scenario where an older list has a number of list members move to on to other things in life
And I can picture a scenario where they take a summer break and reactivate a decade later. I would be *pissed off* if my data got deleted in that scenario. (Yes, I've done that in the five year variant, if not the full decade.)
Why would you be mad? Am I missing something here? The data that is being kept are a few fields of data (email address, username, password, real-name, and some list preferences). Why would anyone expect to have such inactive accounts kept perpetually? Regardless, I am not talking about removing accounts/subscriptions without a user's permission. I am talking about when a user either does it themselves or asks a List Owner to do so.
and even abandon their email accounts totally.
Which is a totally different scenario. I deny your "imperative" in the former case; inactivity from the point of view of a list owner is (usually) not abandonment. I question it in the latter, because "abandon" is an inference drawn from lack of activity or bounces, either of which could be inadvertant (respectively the "summer break" scenario, and separation from an employer).
I worded that poorly. But remember if an email address that no longer exists (because a list member never unsubscribed from a list and closed their email provider account anyways) is removed due to bounces (as it should), that user data still exists. I think that is not good and such a scenario happens a lot.
In those cases it is imperative that those list addresses are removed either via bounce processing or list owner intervention and that no legacy data on such members remain.
But how do you propose to identify "legacy data"? In Mailman 3, members are *people*, not addresses. Do you really want it to be the case that if Albert signs up with albert@example.com, and later gets fired by example.com, then all his subscriptions get bounce-cancelled, and his User profile gets irreversibly trashed? Or some large email provider hosting lots of posters decides to suddenly implement some spam protection that causes a ton of bounces (as DMARC p=reject did in 2014) and hundreds of users have their accounts trashed?
It worked for Mailman 2 right? What happened in those cases? They just got resubscribed again. As you said, unsubscribing doesn't impact a django account anyways. So I don't understand your point here. Again I am talking about the scenario where a user is requesting to be removed or does the removal themselves and expects their data to be removed.
You just can't know without asking Albert what he wants done in his case and you can be quite sure you're doing the wrong thing in the DMARC-like case. In either case, resubscribing is a click per list if his data is retained (and Albert needs an OTK confirmation of another address). It's an annoying session of duplicating his configuration (including passwords and social auth links) if not, and probably some months of discovering that a configuration that built up over years wasn't accurately reproduced for some lists.
Apples and oranges here. For public lists and a user who does not have a Affinity/Django account, it is just a click per list. For those who have a django/Affinity account, well there account should still be there since they never asked for it to be removed or did not remove it themselves.
Personally I think I am going to implement some sort of backup generation tool for an Affinity account holder where they can download their profile/list settings in a json or equivalent format before account deletion. Then if they wish to create their account, they can rebuild their profile from that backup.
List owners, of course, can do what they want with their lists. If they want to add automation for their subscribers that simplify the lives of people who have simple needs, that's not something Mailman can, should, or will try to stop. That's *why* I support efforts like Affinity, Empathy, and Harmony.
Steve
I personally intend to get into the "power-user" market. That is the #1 reason for creating my UIs. I have that flexibility.
--
Brian Carpenter Harmonylists.com Emwd.com