Mailman, etc. upgrade woes and persistent bugs
I just had my Mailman suite upgraded. When it got started, I starting receiving messages that hundreds of subscribers to the lists had been disables, including several of the list moderators. This version started supporting bounce processing, but how in the world was this upgrade allowed to act on bounces that were being collected PRIOR to enabling bounce processing??
I got many angry emails, messages and phone calls asking what was going on, as they were bona fide list members. I was very surprised myself.
I then looked at several of the disabled accounts, but the subscription info page in Postorius had no information about whether an account was enabled or disabled. Why is this not displayed???. The members can't see if their account is enabled. Is this another example of the disconnect between Mailman and Postorius?
Further, even after the upgrade, the moderators still cannot access the list memberships even though all the lists are set to allow that. I would have asked the moderators to do this if this access bug had been fixed, but they can't get there.
As a result of these bugs, after consulting with Brian, who helped with the upgrade, I spent many hours re-enabling the several hundred accounts that had been disabled. I had to go through each email notification to find the address of a disabled account, then find the list, then the member, in Postorius, and finally enable the account (at which time Postorius DID show the enabled status).
Please, can the next upgrade include these very basic fixes/enhancements, which I requested a long time ago:
a. The ability of moderators to see the list membership (a bug). b. The ability of members to change their addresses for all lists they are subscribed to.
and further, now:
c. That when members go to look at their subscription info, they can actually see the settings.
Thank you,
Allan
hansen@rc.org writes:
I just had my Mailman suite upgraded. When it got started, I starting receiving messages that hundreds of subscribers to the lists had been disables, including several of the list moderators.
I'm sorry to hear about this.
This version started supporting bounce processing, but how in the world was this upgrade allowed to act on bounces that were being collected PRIOR to enabling bounce processing??
Well, if bounce processing were occurring as designed, there would be very few bounces in the queue. So it's a difficult thing to anticipate until it happens. And curiously I haven't heard of this before. I mean, if it were going to happen, I would expect that it would have happened at the very busy lists at python.org. So maybe you have an unusually large number of bounces? Not saying it couldn't have been anticipated that *somebody* would have that situation, but we'd have to be extremely lucky, or have a dedicated "red team" looking for ways the feature can break, to find it before installing it. I'm sorry it happened, but AFAICS it's "one of those things".
Technically, it appears that the model for bounce information is initialized based on the time of processing, rather than the (alleged) time of injection or the (presumably trustworthy) time of receipt by the local MTA. I don't have time to check further on if that's modified later, but "not modified" explains what you saw very well. I guess you must have had many hundreds of bounce messages in the queue.
Probably the simplest way to deal with this is to clear the bounce queue while upgrading, or at least offer the option. Losing a few hours' worth of bounce messages (if they're being processed normally) isn't going to hurt anything. It would also be simple to provide a report of who bounced and the most recent bounce, if desired.
I then looked at several of the disabled accounts, but the subscription info page in Postorius had no information about whether an account was enabled or disabled. Why is this not displayed???.
It is for me when I've authenticated, both for lists where I'm owner and for lists where I'm just a subscriber. (However, the lists where I'm subscriber are on python.org where Mark is the site admin, and may be a little ahead of released versions.)
The members can't see if their account is enabled.
I guess they are email-only members, and have not authenticated to Postorius? I don't think we will allow unauthenticated access to user info in Postorius in a distributed version. If you really need it, the fastest route would be to find a contractor to customize Mailman for that -- custom versions are not a priority for us.
Is this another example of the disconnect between Mailman and Postorius?
Hard to say. If it's not the users' failure to authenticate, I would guess this is most likely due to a skew in the upgrade process where the versions of Mailman core and Postorius were mismatched, but as I wrote above, I can see this in the user's setting page for both my "owned" lists and for my "just a subscriber lists".
It would be inconvenient in your situation because list admins have to visit the user's options page to see and modify it, but I *can* see it.
Further, even after the upgrade, the moderators still cannot access the list memberships even though all the lists are set to allow that.
This is a known bug being worked on. I'm sorry it was not fixed in time for your upgrade.
As a result of these bugs, after consulting with Brian, who helped with the upgrade, I spent many hours re-enabling the several hundred accounts that had been disabled. I had to go through each email notification to find the address of a disabled account, then find the list, then the member, in Postorius, and finally enable the account (at which time Postorius DID show the enabled status).
I'm quite sure that this situation could have been addressed quickly and efficiently with a Python script, or in an interactive session with mailmanclient. That doesn't help you now, but in the future feel free to ask us to help with that. We generally are able to respond within a few hours. It's probably not as fast as doing it by hand, but there's the consideration of your time spent. Or if there are Python programmers hanging around, a little fiddling with the mailmanclient command line will probably allow them to figure out what's what, enough to do this.
Please, can the next upgrade include these very basic fixes/enhancements, which I requested a long time ago:
a. The ability of moderators to see the list membership (a bug).
It's in the queue. I can't say when it will be released.
b. The ability of members to change their addresses for all lists they are subscribed to.
What exactly do you want here? I can think of a number of ways to implement that, depending on whether the old address is to be deactivated from the lists, unsubscribed from the lists, or deleted from the Mailman and/or Postorius Users. There may be other variables to consider, as well; I haven't thought about this. AFAICS this is not a trivial feature, and I'd really like to hear from people who want "something like" this about exactly what they want and their use cases. Or we'll release an insufficiently designed feature that causes somebody hundreds of problems....
c. That when members go to look at their subscription info, they can actually see the settings.
As far as I know, they already can if they have authenticated. If that's not true in your installation(s), we'll need to find out why, because it works for me.
Enabling access without authentication is a potentially dangerous change that I currently believe shouldn't happen at all in a Mailman distribution, and will certainly take time to design. If your requirements include unauthenticated access, I would not hold my breath, let alone expect it in the near future.
Regards, Steve
Hi Stephen,
Thank you for your response.
I have let my users/moderators know how few resources are available for developing Mailman - that it’s not a system supported by hundreds of highly paid developers, testers, security experts, product managers, etc., and that the software is public-domain code. My own involvement in this is similar to yours.
A note to flush bounces to people upgrading may be a good idea. And yes, the disabled accounts were mostly on busy lists, but not all. I should also mention that a heck of a lot of them were sbcglobal.net users, which was interesting. AT&T apparently is not doing a good job for their clients (and they do have armies of staff who could). Maybe your users have better service providers than mine.
As for looking at subscription options, I have an authenticated (verified) Django account that I use for testing (non-owner but moderator). When I log in to that account (or as list owner with my usual account), the only field that is filled out in the ‘Subscription options’ dialog is the ‘Select Email’ pulldown menu. So yes, I think that there is an issue here.
I agree with you that to provide access to this information for people who don’t have verified Django accounts does not make sense. But those who have set up accounts should, and the moderators and owners definitely should. If not being able to see these settings is specific to my installation, I would appreciate getting it fixed. If needed I can provide screen shots to prove authentication and issue. Once a setting is modified, it becomes visible then and afterwards!
I thought about contacting you all at the time, but figured that I needed to get this done promptly (based on the reactions from my users/moderators, which were very prompt). :-)
Finally, about the ‘Change Address’ feature:
It’s really not complicated, Stephen, or rather, it should not be. People all the time move from one provider (like sbcglobal, hopefully) to another (like gmail). When they do, they generally want all instances of their old address strings everywhere necessary in Mailman/Postorius to be replaced with the new address, so they can use that instead. This is how the ‘Apply Globally’ address change worked in MM2 and that was more than good enough. If there are other use cases where they need to retain the old address for whatever reason, they would not use this feature, but add the new address to their account and then manage the old in some other way. Of the thousands of subscribers I have, maybe a handful are interested in maintaining more than one subscription address. All the rest simply use one address and when they get a new email address they want to use that instead for all their subscriptions everywhere and never see the old one again (other than in the archives, of course). Period. It’s really that simple in 99.9 % of the cases. Please don’t hold this up for the 0.1%.
Yours,
AllanAllan Hansen writes:
I'll come back to the rest of your thoughtful response later, but this deserves a separate, emphatic response:
I thought about contacting you all at the time, but figured that I needed to get this done promptly (based on the reactions from my users/moderators, which were very prompt). :-)
Sure, I understand that. But let me emphasize that even if it's hard for me to say that open source volunteer developers are responsible for *anticipating* a fiasco like this, we are responsible for *addressing* it, both in fixed code and in support. Anyone in this kind of situation can write a quick, vague "Help!" message, and if we're online, there's a good chance they'll get an immediate response, and they might be able to halve the time to "done" in a case like this.
This is not a waste of our time even if one is going to get to work addressing it right away.
Of course the GNU GPL "NO WARRANTEE" still applies, but we care and we don't resent users with problems. We'll try.
Regards, Steve
- Stephen J. Turnbull (turnbull.stephen.fw@u.tsukuba.ac.jp) [210212 12:04]:
hansen@rc.org writes:
b. The ability of members to change their addresses for all lists they are subscribed to.
What exactly do you want here? I can think of a number of ways to implement that, depending on whether the old address is to be deactivated from the lists, unsubscribed from the lists, or deleted from the Mailman and/or Postorius Users. There may be other variables to consider, as well; I haven't thought about this. AFAICS this is not a trivial feature, and I'd really like to hear from people who want "something like" this about exactly what they want and their use cases. Or we'll release an insufficiently designed feature that causes somebody hundreds of problems....
I thought user could do that if they have an web account, and multiple mail addresses are associated with the account? Or does my memory serve me wrong there?
Andi
They need to resubscribe to each list they want the new address to be used for. Subscriptions involves permissions from the moderators. It’s not a simple process, especially if you are on many lists.
Yours,
Allan Hansen hansen@rc.org
On Feb 12, 2021, at 8:47 , Andreas Barth <aba@ayous.org> wrote:
- Stephen J. Turnbull (turnbull.stephen.fw@u.tsukuba.ac.jp) [210212 12:04]:
hansen@rc.org writes:
b. The ability of members to change their addresses for all lists they are subscribed to.
What exactly do you want here? I can think of a number of ways to implement that, depending on whether the old address is to be deactivated from the lists, unsubscribed from the lists, or deleted from the Mailman and/or Postorius Users. There may be other variables to consider, as well; I haven't thought about this. AFAICS this is not a trivial feature, and I'd really like to hear from people who want "something like" this about exactly what they want and their use cases. Or we'll release an insufficiently designed feature that causes somebody hundreds of problems....
I thought user could do that if they have an web account, and multiple mail addresses are associated with the account? Or does my memory serve me wrong there?
Andi
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/
On 2/12/21 10:27 AM, Allan Hansen wrote:
They need to resubscribe to each list they want the new address to be used for. Subscriptions involves permissions from the moderators. It’s not a simple process, especially if you are on many lists.
Not true if they have a Django account. See my reply at <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thank you, Mike. I will see how to get this across to my users. :-)
With love,
AllanOn Feb 12, 2021, at 11:55 , Mark Sapiro <mark@msapiro.net> wrote:
On 2/12/21 10:27 AM, Allan Hansen wrote:
They need to resubscribe to each list they want the new address to be used for. Subscriptions involves permissions from the moderators. It’s not a simple process, especially if you are on many lists.
Not true if they have a Django account. See my reply at <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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/
On 2/11/21 10:22 PM, hansen@rc.org wrote:
I just had my Mailman suite upgraded. When it got started, I starting receiving messages that hundreds of subscribers to the lists had been disables, including several of the list moderators. This version started supporting bounce processing, but how in the world was this upgrade allowed to act on bounces that were being collected PRIOR to enabling bounce processing??
I'm sorry about that. It's too late now, but the avoidance is discussed at <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/U...>.
I got many angry emails, messages and phone calls asking what was going on, as they were bona fide list members. I was very surprised myself.
I then looked at several of the disabled accounts, but the subscription info page in Postorius had no information about whether an account was enabled or disabled. Why is this not displayed???. The members can't see if their account is enabled. Is this another example of the disconnect between Mailman and Postorius?
If the user has a Django account, she can see all that info at (e.g. for
this list) <https://lists.mailman3.org/mailman3/accounts/subscriptions/>
She gets there from Mailman settings in the dropdown under her user
name. She can also get there via the Manage Subscription button on the
list's Info page. That takes her to List-based preferences for the
list. Any setting not selected there is inherited from the Address-based
preferences or Global Mailman preferences
Further, even after the upgrade, the moderators still cannot access the list memberships even though all the lists are set to allow that. I would have asked the moderators to do this if this access bug had been fixed, but they can't get there.
You've already reported this at <https://gitlab.com/mailman/postorius/-/issues/462>, and it's been previously reported at <https://gitlab.com/mailman/postorius/-/issues/369>.
As a result of these bugs, after consulting with Brian, who helped with the upgrade, I spent many hours re-enabling the several hundred accounts that had been disabled. I had to go through each email notification to find the address of a disabled account, then find the list, then the member, in Postorius, and finally enable the account (at which time Postorius DID show the enabled status).
I'm sorry you had to go through this. The potential issue and the avoidances should be better documented. Unfortunately, they aren't.
Please, can the next upgrade include these very basic fixes/enhancements, which I requested a long time ago:
a. The ability of moderators to see the list membership (a bug).
As I note above, this is a known issue. We are a small project with very feew core developers, all of whom are volunteers. There is a merge request at <https://gitlab.com/mailman/postorius/-/merge_requests/423> which purports to fix <https://gitlab.com/mailman/postorius/-/issues/369>, but as you can see from the comment thread, it is not complete and the author has apparently disappeared.
If you would like to take it over and address the deficiencies, we would welcome that.
b. The ability of members to change their addresses for all lists they are subscribed to.
Users can add addresses to their account and can then change their
subscribed address at (again, e.g. for this list)
<https://lists.mailman3.org/mailman3/accounts/list-options/mailman-users.mail...>
(Get there via the Manage Subscription button on the list's Info page.)
If one is subscribed to lists via their primary address, one can go to
E-mail Addresses in their account settings and make a new address
primary and that will change all their subscriptions.
and further, now:
c. That when members go to look at their subscription info, they can actually see the settings.
They can if they go to Mailman settings in the dropdown or the Manage Subscription button on the list's Info page and look at all the tabs.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Fri, Feb 12, 2021, at 11:52 AM, Mark Sapiro wrote:
On 2/11/21 10:22 PM, hansen@rc.org wrote:
I just had my Mailman suite upgraded. When it got started, I starting receiving messages that hundreds of subscribers to the lists had been disables, including several of the list moderators. This version started supporting bounce processing, but how in the world was this upgrade allowed to act on bounces that were being collected PRIOR to enabling bounce processing??
I'm sorry about that. It's too late now, but the avoidance is discussed at <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/U...>.
I got many angry emails, messages and phone calls asking what was going on, as they were bona fide list members. I was very surprised myself.
I then looked at several of the disabled accounts, but the subscription info page in Postorius had no information about whether an account was enabled or disabled. Why is this not displayed???. The members can't see if their account is enabled. Is this another example of the disconnect between Mailman and Postorius?
If the user has a Django account, she can see all that info at (e.g. for this list) <https://lists.mailman3.org/mailman3/accounts/subscriptions/> She gets there from
Mailman settingsin the dropdown under her user name. She can also get there via theManage Subscriptionbutton on the list's Info page. That takes her toList-based preferencesfor the list. Any setting not selected there is inherited from the Address-based preferences or Global Mailman preferences
IIUC, I think what Allan is trying to point out is that if your account was disabled due to bounces, there is no real visual indication about that if you go to any of the Preferences pages (either, Global preferences, List based preferences of address based preferences).
Even if you login as an admin and go to Member Option's view, you won't see any visual indication about the delivery being disabled.
The is definitely a bug, caused due to the fact that "Delivery Status" field only has two options, "Enabled" and "Disabled". Internally, this field can have 4 values, "enabled", "by_user" (maps to "Disabled" in Postorius), "by_admin" (means disabled by admin) and "by_bounces" (means disabled due to bounces). So, when the value of the field is among the last two options, it appears as "unset" with no options selected, which unfortunately is also how it looks by default since all options are "unset" from start.
The "fix" for this issue would be simply adding a new choice to the delivery_status field with a caveat that it is only a Readonly option to see that delivery is disabled due to bounces and not choosable as a valid delivery_status value by user or admin when submitting the form.
https://gitlab.com/mailman/postorius/-/issues/469
We could also go a step further and show it on the List's info page when their delivery is disabled due to excessive bounce and allow the them to re-enable it themselves without admin intervention. This would ofcourse show only when you log into your account and go to the list's info page, but I guess that is the first place you'd go to debug when you get an email that your delivery was disabled?
https://gitlab.com/mailman/postorius/-/issues/470
I don't know if there are any downsides to letting users re-enable their delivery on their own.
Further, even after the upgrade, the moderators still cannot access the list memberships even though all the lists are set to allow that. I would have asked the moderators to do this if this access bug had been fixed, but they can't get there.
You've already reported this at <https://gitlab.com/mailman/postorius/-/issues/462>, and it's been previously reported at <https://gitlab.com/mailman/postorius/-/issues/369>.
As a result of these bugs, after consulting with Brian, who helped with the upgrade, I spent many hours re-enabling the several hundred accounts that had been disabled. I had to go through each email notification to find the address of a disabled account, then find the list, then the member, in Postorius, and finally enable the account (at which time Postorius DID show the enabled status).
I'm sorry you had to go through this. The potential issue and the avoidances should be better documented. Unfortunately, they aren't.
Please, can the next upgrade include these very basic fixes/enhancements, which I requested a long time ago:
a. The ability of moderators to see the list membership (a bug).
As I note above, this is a known issue. We are a small project with very feew core developers, all of whom are volunteers. There is a merge request at <https://gitlab.com/mailman/postorius/-/merge_requests/423> which purports to fix <https://gitlab.com/mailman/postorius/-/issues/369>, but as you can see from the comment thread, it is not complete and the author has apparently disappeared.
If you would like to take it over and address the deficiencies, we would welcome that.
b. The ability of members to change their addresses for all lists they are subscribed to.
Users can add addresses to their account and can then change their subscribed address at (again, e.g. for this list) <https://lists.mailman3.org/mailman3/accounts/list-options/mailman-users.mail...> (Get there via the
Manage Subscriptionbutton on the list's Info page.)If one is subscribed to lists via their
primaryaddress, one can go toE-mail Addressesin their account settings and make a new addressprimaryand that will change all their subscriptions.and further, now:
c. That when members go to look at their subscription info, they can actually see the settings.
They can if they go to
Mailman settingsin the dropdown or theManage Subscriptionbutton on the list's Info page and look at all the tabs.-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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)
On 2/12/21 5:55 PM, Abhilash Raj wrote:
I don't know if there are any downsides to letting users re-enable their delivery on their own.
It's been that way in MM 2.1 forever and doesn't seem to be an issue.
Also, although I haven't checked, even though the users delivery disabled by bounce doesn't show as disabled, I suspect that setting it to enabled would work.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2/12/21 8:55 PM, Abhilash Raj wrote:
IIUC, I think what Allan is trying to point out is that if your account was disabled due to bounces, there is no real visual indication about that if you go to any of the Preferences pages (either, Global preferences, List based preferences of address based preferences).
Even if you login as an admin and go to Member Option's view, you won't see any visual indication about the delivery being disabled.
The is definitely a bug, caused due to the fact that "Delivery Status" field only has two options, "Enabled" and "Disabled". Internally, this field can have 4 values, "enabled", "by_user" (maps to "Disabled" in Postorius), "by_admin" (means disabled by admin) and "by_bounces" (means disabled due to bounces). So, when the value of the field is among the last two options, it appears as "unset" with no options selected, which unfortunately is also how it looks by default since all options are "unset" from start.
The "fix" for this issue would be simply adding a new choice to the delivery_status field with a caveat that it is only a Readonly option to see that delivery is disabled due to bounces and not choosable as a valid delivery_status value by user or admin when submitting the form.
I really wish you guys rework that List Member's page for the sake of List Owners. With Affinity our List Owners can:
See the delivery status for every list members (enabled or disabled). If Disabled, there is a little icon (u=user, b=bounce, m=moderator) that lets the List Owner know the reason for the disable setting.
Sort members by delivery status (enable/disable). So a List Owner can choose a certain delivery status and only those members that have that status are shown.
Informs a List Owner whether a list member is registered with the UI.
See the moderation action set for every member.
You have plenty of real estate on that member page to vastly improve it and to be honest the MM2 member management page is superior to Postorius's member page. Personally instead of trying to get a reskin of Postorius that makes it look like Mailman 2 from the GSOC folks, I would push for a revamp of certain sections of Postorius that brings it into the modern UI era. That Member page is seriously lacking.
I am not trying to be mean here but I really felt Allan's pain yesterday. No List Owner should be that handicap to manage their own list members.
-- Brian Carpenter Harmonylists.com Emwd.com
Brian Carpenter writes:
I really wish you guys rework that List Member's page for the sake of List Owners. With Affinity our List Owners can:
How different is this from Mailman 2? (Just "not really different" is fine, I'll be looking at your specific desiderata for more details later, including potential GSoC tasks.) It seems to me it's basically the same, except maybe for some Web 2.0 features like sorting on fields. (I'm not deprecating those features: obviously sorting would have helped Allan a lot, for example. It's just that Mailman 2 is very much a Web 1.0, maybe even Web 0.9, application.) Am I missing something big?
That's my whole post, I'm leaving the rest of your desiderata for convenience in reference.
See the delivery status for every list members (enabled or disabled). If Disabled, there is a little icon (u=user, b=bounce, m=moderator) that lets the List Owner know the reason for the disable setting.
Sort members by delivery status (enable/disable). So a List Owner can choose a certain delivery status and only those members that have that status are shown.
Informs a List Owner whether a list member is registered with the UI.
See the moderation action set for every member.
On 2/13/21 3:03 AM, Stephen J. Turnbull wrote:
How different is this from Mailman 2? (Just "not really different" is fine, I'll be looking at your specific desiderata for more details later, including potential GSoC tasks.) It seems to me it's basically the same, except maybe for some Web 2.0 features like sorting on fields. (I'm not deprecating those features: obviously sorting would have helped Allan a lot, for example. It's just that Mailman 2 is very much a Web 1.0, maybe even Web 0.9, application.) Am I missing something big?
I actually took at lot of ideas from the MM 2 Membership List page simply due to the fact that Postorius' was not helpful in inspiring anything. The one thing that I did do is take MM2's approach and modernized it. So here are more tasks a List Owner can do that MM2 could never offer (and Postorius doesn't even come close):
-- Sort Members by Delivery mode (regular vs digest). (MM2 has no sorting abilities at all except by alphabet, Postorius doesn't even have that)
-- Reveal which Members are registered with the UI (MM2, everyone was registered, in Postorius nothing is revealed about registration)
-- Show in one List Member Management panel List Members, Non-Members, Moderators, and Owners (MM2 and Postorius requires this data to be seen via multiple pages)
-- View Member's List Subscriptions to other Mailing Lists on the server and, if that List Owner is List Owner of those other lists, can even access the List Owner board (Affinity terminology) for those other Lists.
-- Ban a member
-- Promote a member to List Owner and/or Moderator
-- Add a new List Member, List Owner, Moderator, and Non-Member from a Single List Member Membership panel. (Again both Postorius and MM2 requires multiple pages. Postorius is an improvement in this regard over MM2. The funny thing with Postorius is you can add a single Non-member, Moderator, and List Owner, but you cannot add a single List Member except through *Bulk* adding.)
Features are not the only thing about a modern UI, UX design plays a MAJOR role in the modern UI. Postorius should have at least matched MM2 in features in regards to something as important as Member management but instead it took a step back into the dark ages.
-- Brian Carpenter Harmonylists.com Emwd.com
On Sat, 2021-02-13 at 08:01 -0500, Brian Carpenter wrote:
Features are not the only thing about a modern UI, UX design plays a MAJOR role in the modern UI. Postorius should have at least matched MM2 in features in regards to something as important as Member management but instead it took a step back into the dark ages.
I'm gonna be a dick and remind you that less than 1 year ago you were trying to convince me that MM3 was a gift from god and that it was time for me to jump from MM2 to MM3 because it was sooo easy and such a time saver.. or something like that. The point being, you yourself just still aren't happy with MM3. Welcome to the club.
-Jim P.
On 2/13/21 10:37 AM, Jim Popovitch via Mailman-users wrote:
Features are not the only thing about a modern UI, UX design plays a MAJOR role in the modern UI. Postorius should have at least matched MM2 in features in regards to something as important as Member management but instead it took a step back into the dark ages. I'm gonna be a dick and remind you that less than 1 year ago you were
On Sat, 2021-02-13 at 08:01 -0500, Brian Carpenter wrote: trying to convince me that MM3 was a gift from god and that it was time for me to jump from MM2 to MM3 because it was sooo easy and such a time saver.. or something like that. The point being, you yourself just still aren't happy with MM3. Welcome to the club.
I am very happy with MM3 just not with Postorius. MM3 allowed me to come up with my own admin interface. Mailman 2 would never allowed me to do that. So please leave your Mailman 2 bondage and come over to Mailman 3. We have cookies!
-- Brian Carpenter Harmonylists.com Emwd.com
On Sat, 2021-02-13 at 10:40 -0500, Brian Carpenter wrote:
On 2/13/21 10:37 AM, Jim Popovitch via Mailman-users wrote:
Features are not the only thing about a modern UI, UX design plays a MAJOR role in the modern UI. Postorius should have at least matched MM2 in features in regards to something as important as Member management but instead it took a step back into the dark ages. I'm gonna be a dick and remind you that less than 1 year ago you were
On Sat, 2021-02-13 at 08:01 -0500, Brian Carpenter wrote: trying to convince me that MM3 was a gift from god and that it was time for me to jump from MM2 to MM3 because it was sooo easy and such a time saver.. or something like that. The point being, you yourself just still aren't happy with MM3. Welcome to the club.
I am very happy with MM3 just not with Postorius. MM3 allowed me to come up with my own admin interface. Mailman 2 would never allowed me to do that. So please leave your Mailman 2 bondage and come over to Mailman 3. We have cookies!
But how do you display a "Membership List page" for admins in MM3 (choice of wording is specific to other emails you've posted today) without third-party application(s), and isn't that too a shortcoming in MM3 due to that functionality being present in MM2? Look, without a doubt the REST API of MM3 Core is cool, but let's be honest, all the 3rd party wrapping and baggage is, well, not so cool. But, again being honest, you can't have a MM3 system without all of those things. With MM2 we have all those things, and we are happy with them. :)
-Jim P.
On 2/13/21 10:53 AM, Jim Popovitch via Mailman-users wrote:
But how do you display a "Membership List page" for admins in MM3 (choice of wording is specific to other emails you've posted today) without third-party application(s), and isn't that too a shortcoming in MM3 due to that functionality being present in MM2? Look, without a doubt the REST API of MM3 Core is cool, but let's be honest, all the 3rd party wrapping and baggage is, well, not so cool. But, again being honest, you can't have a MM3 system without all of those things. With MM2 we have all those things, and we are happy with them.:)
Affinity is just a UI that sits on top of Mailman 3 core. Most of its functions and displays come from Mailman 3 core. Everything I mentioned about how Affinity displays List Member Management to List Owners uses MM3's REST api to do so. In my opinion, Postorius is nowhere near in taking advantage of all that Mailman 3 core offers along with free tools such as Bootstrap 4. The only thing that is holding Postorius back is time to improve it and that is not the fault of MM3 or the developers. The thing to take away from this however is Postorius still has the potential (because the foundation is there) to be a great modern UI for Mailman 3 core. MM2 does not have that potential and never will. Sure it works until it doesn't.
I am pretty sure Pipermail is a wrapper and not an inherit part of MM2.
-- Brian Carpenter Harmonylists.com Emwd.com
Brian Carpenter writes:
I am pretty sure Pipermail is a wrapper and not an inherit part of MM2.
As I understand it, Pipermail was originally a third-party add-on called HyperMail. It was sufficiently capable, and the author was amenable, so it was bundled with the Mailman 2 distribution. It can be disabled easily, and it's not hard to get Mailman 2 to use an alternative archiver if you have one (or more). However, the source of Pipermail is contained within the Mailman 2 source tree, and the configuration of Pipermail is integrated (as much as that term makes sense for a series of Python assignment statements) into Mailman 2 configuration (Defaults.py and mm_cfg.py), so it's more integrated into Mailman 2 than HyperKitty is to Mailman 3.
Thing is, there's no particular reason ever for an archiver to be integrated, with the single exception of determining the archived message's URL so it can be added to the message being distributed. And Mailman 3 shows how that can be done without knowing anything else about the archiver. So the question of whether it is a wrapper (all archivers are just wrappers) or not (containment of source code and configuration files) is kinda moot.
Abhilash Raj writes:
The is definitely a bug, caused due to the fact that "Delivery Status" field only has two options, "Enabled" and "Disabled". Internally, this field can have 4 values, "enabled", "by_user" (maps to "Disabled" in Postorius), "by_admin" (means disabled by admin) and "by_bounces" (means disabled due to bounces). So, when the value of the field is among the last two options, it appears as "unset" with no options selected, which unfortunately is also how it looks by default since all options are "unset" from start.
The "fix" for this issue would be simply adding a new choice to the delivery_status field with a caveat that it is only a Readonly option to
I don't see why most users would care (there will always be somebody who cares "just because", of course). For those who don't care, I expect it will be confusing. I think it's better just to treat all of the disabled settings as just "disabled" in the UI for members.
We could also go a step further and show it on the List's info page when their delivery is disabled due to excessive bounce and allow the them to re-enable it themselves without admin intervention.
This is probably a good idea, but in a situation where we know the problem is excessive bouncing we should caution them that there is almost certainly a probably with delivery *to their specific address* and that Mailman and the admins *can do nothing about that*, so if that isn't fixed they'll just get disabled again. I suppose it would be good to add that frequently these are due to occasional problems like disk full that "management" at their site normally takes care of, so there's little if any harm to just reenabling.
to the list's info page, but I guess that is the first place you'd go to debug when you get an email that your delivery was disabled?
Surely we can help them go directly there?
https://gitlab.com/mailman/postorius/-/issues/470
I don't know if there are any downsides to letting users re-enable their delivery on their own.
I don't see any myself. Maybe if the list is planning a surprise party for them? ;-)
There is a specific downside, which is that if you only allow them to reenable if they disabled it themselves, you have to show them the other cases.
On Fri, Feb 12, 2021, at 8:52 PM, Stephen J. Turnbull wrote:
Abhilash Raj writes:
The is definitely a bug, caused due to the fact that "Delivery Status" field only has two options, "Enabled" and "Disabled". Internally, this field can have 4 values, "enabled", "by_user" (maps to "Disabled" in Postorius), "by_admin" (means disabled by admin) and "by_bounces" (means disabled due to bounces). So, when the value of the field is among the last two options, it appears as "unset" with no options selected, which unfortunately is also how it looks by default since all options are "unset" from start.
The "fix" for this issue would be simply adding a new choice to the delivery_status field with a caveat that it is only a Readonly option to
I don't see why most users would care (there will always be somebody who cares "just because", of course). For those who don't care, I expect it will be confusing. I think it's better just to treat all of the disabled settings as just "disabled" in the UI for members.
I don't have any strong opinions on treating all disabled options as just disabled for the user. Would List admins be interested in knowing more details about that or should it be the same for them? I feel they might be interested in such details. Brian mentioned that Affinity actually details explicit value of the delivery_status, so maybe it is useful for them?
We could also go a step further and show it on the List's info page when their delivery is disabled due to excessive bounce and allow the them to re-enable it themselves without admin intervention.
This is probably a good idea, but in a situation where we know the problem is excessive bouncing we should caution them that there is almost certainly a probably with delivery *to their specific address* and that Mailman and the admins *can do nothing about that*, so if that isn't fixed they'll just get disabled again. I suppose it would be good to add that frequently these are due to occasional problems like disk full that "management" at their site normally takes care of, so there's little if any harm to just reenabling.
Yeah, a link to an FAQ entry in documentation perhaps?
I am thinking that most addresses disabled due to bounces would really either be spam subscriptions or abandoned/invalid email addresses that once were working. There would be few with problems with delivery which would want to re-enable as soon as they can, but definitely letting them know that there is an issue with delivery is a good idea.
to the list's info page, but I guess that is the first place you'd go to debug when you get an email that your delivery was disabled?
Surely we can help them go directly there?
I guess yes, but that brings up the whole discussion about how does Core know about the URLs. Custom templates can help get there easily, but that will not solve the problem, only put the onus on list/server admins to set that on a per-installation basis.
Although, we can add "Goto your list subscriptions to re-enable" your subscription. Maybe even a new email command that allows re-enabling subscription without logging into P?
https://gitlab.com/mailman/postorius/-/issues/470
I don't know if there are any downsides to letting users re-enable their delivery on their own.
I don't see any myself. Maybe if the list is planning a surprise party for them? ;-)
Oh just Ban them in that case ;-)
There is a specific downside, which is that if you only allow them to reenable if they disabled it themselves, you have to show them the other cases.
I was initially thinking that maybe we can disable changing the delivery status if it was disabled by an admin ("by_admin" value), but AFAIK, there is really no way to even set that right now and no real use case for that has come up, so I am going to punt on that idea until someone really asks for it with a valid use case ;-)
-- thanks, Abhilash Raj (maxking)
Abhilash Raj writes:
I don't have any strong opinions on treating all disabled options as just disabled for the user.
Good.
Would List admins be interested in knowing more details about that or should it be the same for them? I feel they might be interested in such details. Brian mentioned that Affinity actually details explicit value of the delivery_status, so maybe it is useful for them?
I think they definitely are interested in the disabled by bounce case. If you get one complaint, sort the page by en-/dis-abled status, and the whole first page is "disabled by bounce", I bet you react strongly. :-) The distinction between disabled by admin and disabled by user is pretty small -- I suppose most "disabled by admin" are either cranky or technically innocent user requests.
This is probably a good idea, but in a situation where we know the problem is excessive bouncing we should caution [...].
Yeah, a link to an FAQ entry in documentation perhaps?
Maybe that would be enough. I'll think about it.
I am thinking that most addresses disabled due to bounces would really either be spam subscriptions or abandoned/invalid email addresses that once were working.
Normally, yes, but situations like DMARC April 2014 and upgrade from old Mailman 3 do happen. I think we should focus on the situations that cause users and admins pain.
Surely we can help them go directly there?
I guess yes, but that brings up the whole discussion about how does Core know about the URLs.
I was afraid of that. Users will complain if they have to go from login to user page to list page to options (I don't think it's that bad, though), but they will be able to get themselves re-enabled. Making it a more friendly experience can wait if the solution isn't obvious.
Although, we can add "Goto your list subscriptions to re-enable" your subscription.
This sounds good.
Maybe even a new email command that allows re-enabling subscription without logging into P?
I don't like that much, as to be useful it would have to bypass authentication or require plain-text credentials, and even the latter would be beyond many users. Bypassing auth would allow annoying attacks where you enable all of a person's post-only addresses for mail delivery.
On 2/13/21 12:54 AM, Abhilash Raj wrote:
I don't have any strong opinions on treating all disabled options as just disabled for the user. Would List admins be interested in knowing more details about that or should it be the same for them? I feel they might be interested in such details. Brian mentioned that Affinity actually details explicit value of the delivery_status, so maybe it is useful for them?
I think treating all disabled options the same is short-sighted. They are all not the same.
-- Some list members will disable their subscription for good reasons and will be really upset if a List Owner renables it through ignorance. So it is important to know a disable member is done by the member itself.
-- Some mailing lists will have multiple list owners managing them. So it is important for one List Owner to know when a subscription has been disabled by the actions of another List Owner.
-- A List Owner may not know that some of his List Members are bouncing messages for various reasons, so reviewing their Membership roster, they see that they have some list members disabled due to bounces and can then address those particular problematic members.
@Abhilash, I highly recommend that you contact me off list about getting access to Affinity so you can see what I am talking about. I would love to show you what I have done for Member Management. I offered the same to Steve but he never was interested in taking a look.
-- Brian Carpenter Harmonylists.com Emwd.com
- Brian Carpenter (brian_carpenter@emwd.com) [210213 13:42]:
On 2/13/21 12:54 AM, Abhilash Raj wrote:
I don't have any strong opinions on treating all disabled options as just disabled for the user. Would List admins be interested in knowing more details about that or should it be the same for them? I feel they might be interested in such details. Brian mentioned that Affinity actually details explicit value of the delivery_status, so maybe it is useful for them?
I think treating all disabled options the same is short-sighted. They are all not the same.
-- Some list members will disable their subscription for good reasons and will be really upset if a List Owner renables it through ignorance. So it is important to know a disable member is done by the member itself.
I'd even say: these are different flags.
So basically I'd consider it rather (as seperate boolean ones):
"disabled by member" (could be set by an admin as well of course)
"disabled for administrative reasons" (only by admin but user should be able to see it)
"bounced" (user and admin could reset it but not set it)
Or is this too complex for normal admins and users?
Regards, Andi
Andreas Barth writes:
I'd even say: these are different flags.
They already effectively are, as Abhilash explained earlier (more precisely, four values for one variable).
So basically I'd consider it rather (as seperate boolean ones):
I don't think separate booleans is a good idea, since they're basically mutually exclusive states, and in most scenarios you want the user to be able to reenable from any of the disabled states, so having both "member disabled" and "admin disabled" would have no special semantics.
- "disabled by member" (could be set by an admin as well of course)
Currently this is determined by whether the logged in user is the subscriber or not. It's an interesting idea to allow it to be set by an admin. Then we could have the semantics that the only transition allowed from this state would be to enabled, so that admins would know the user had intentionally disabled and know not to enable without permission.
- "disabled for administrative reasons" (only by admin but user should be able to see it)
I don't see why a user would need to see the difference. Unless you're suggesting that the user would not be able to reenable without asking the admin? What is the use case for this?
- "bounced" (user and admin could reset it but not set it)
Reenable but not set "bounced" is the current situation.
Or is this too complex for normal admins and users?
I don't really understand the use case for administrative disable, except at the request of the user. (The only thing I can think of offhand is the "surprise party" scenario, which seems like a stretch. In Mailman 2, you could do it with a topic that only the planners were subscribed to, and I would think that more likely to pass without notice by the guest of honor.)
In the current situation, where the state is determined by who is logged in, not by what the user wants, I think it would be confusing for some users to see "disabled by admin" if they requested it. I think that's the overwhelmingly common case for administrative disable. So I'm against showing the user the difference.
In your scheme, the question is whether admins would properly distinguish between user requests and the case where the admin disables for some reason. If they do, it's harmless, but it seems like a small burden on the admins.
Steve
- Stephen J. Turnbull (turnbull.stephen.fw@u.tsukuba.ac.jp) [210213 17:35]:
Andreas Barth writes:
I'd even say: these are different flags.
They already effectively are, as Abhilash explained earlier (more precisely, four values for one variable).
Well, currently these are exclusive-states, I'd rather see them as or-able-states.
So basically I'd consider it rather (as seperate boolean ones):
I don't think separate booleans is a good idea, since they're basically mutually exclusive states, and in most scenarios you want the user to be able to reenable from any of the disabled states, so having both "member disabled" and "admin disabled" would have no special semantics.
That's where I disagree :)
- "disabled by member" (could be set by an admin as well of course)
Currently this is determined by whether the logged in user is the subscriber or not. It's an interesting idea to allow it to be set by an admin. Then we could have the semantics that the only transition allowed from this state would be to enabled, so that admins would know the user had intentionally disabled and know not to enable without permission.
Exactly. Or while importing from another server, and there are people who have receiving mails disabled, this is the state that could be used for it.
I expect that state to be the most-often used when setting a state manually.
For "who set that", I would consider having some kind of history as useful (and displaying "last set by user / $person" to the admin but not the user).
- "disabled for administrative reasons" (only by admin but user should be able to see it)
I don't see why a user would need to see the difference. Unless you're suggesting that the user would not be able to reenable without asking the admin? What is the use case for this?
I'm suggesting exactly that, yes. Why? Well, worked with user for too long. ;)
E.g. consider that seeing archives works only for subscribers. And the subscriber in question complains about too many mails but still re-enables getting mails. This is basically "an admin has blocked you from more mails but not unsubscribed you". Might be an corner case, but still. Might also be too unimportant.
- "bounced" (user and admin could reset it but not set it)
Reenable but not set "bounced" is the current situation.
Except if someone sets the state to "disabled" and then undo this, the state is automatically cleared. Which might be the right thing to do, but perhaps not.
Anyways, that's just what I'd prefer. Doesn't mean that everyone needs to agree to it. :)
Andi
No answer required, I think I understand the situation pretty well now. But if I'm missing something, I would very much appreciate criticism.
Andreas Barth writes:
Well, currently these are exclusive-states, I'd rather see them as or-able-states.
Right, I understand that. I don't understand *why*.
There are real costs to making them or-able. There are constraints: 'enabled' shouldn't (mustn't?) be or-able with any 'disabled-by-foo' state. Such invariants are finicky to code and tricky to maintain, compared to a simple "mutually exclusive".
I guess you want to allow the or of any subset of disabled states, but presumably then they need to individually resettable in order for the admin to clear their disable without overriding a subscriber's preference or a bounce record. That set of controls is more complex, and requires additional mental effort on the part of anyone using them. If there are restrictions on which states can be or-ed, that's more coding and maintenance cost.
Then there's the question whether the subscriber can override the admin's setting. If they can, why does the admin have this power in the first place?
- "disabled by member" (could be set by an admin as well of course)
Currently this is determined by whether the logged in user is the subscriber or not. It's an interesting idea to allow it to be set by an admin. Then we could have the semantics that the only transition allowed from this state would be to enabled, so that admins would know the user had intentionally disabled and know not to enable without permission.
Exactly.
But if the admin should respect the DBS (disabled by subscriber) setting, DBS|DBA (disabled by admin) is logically equivalent to DBS. Are there use cases where the admin does not want to repect the subscriber's choice, and enables it anyway? What are they?
Or while importing from another server, and there are people who have receiving mails disabled, this is the state that could be used for it.
Why wouldn't they get the exact state from the original server? Or do you mean from a non-Mailman server?
I expect that state to be the most-often used when setting a state manually.
For "who set that", I would consider having some kind of history as useful (and displaying "last set by user / $person" to the admin but not the user).
Why not to the subscriber? As I explain below, the subscriber at least needs to be able to distinguish between DBA and DBB (disabled by bounce).
Keeping history of who is additional complexity, consumes a minor amount of resources, and is insufficient to the purpose. Assuming that there are reasons for admins to disable/enable other than as a courtesy to a subscriber, that reason is presumably important. Not only will the subscriber not know, but one admin may forget, and there may be multiple admins.[1]
I still don't see any reason for an admin to disable delivery other than as a courtesy to the subscriber or to the bounce processor.
- "disabled for administrative reasons" (only by admin but user should be able to see it)
I don't see why a user would need to see the difference. Unless you're suggesting that the user would not be able to reenable without asking the admin? What is the use case for this?
I'm suggesting exactly that, yes. Why? Well, worked with user for too long. ;)
E.g. consider that seeing archives works only for subscribers. And the subscriber in question complains about too many mails but still re-enables getting mails. This is basically "an admin has blocked you from more mails but not unsubscribed you". Might be an corner case, but still. Might also be too unimportant.
This is possible. If it occurs less than once in a million years, it's "too unimportant" to even think about.[2] Have you actually done this, or know anybody who has?
Is it really different from "at request of subscriber"? Practically, the only difference I can see is if such a subscriber should be prevented from overriding DBA. Are you suggesting that?
- "bounced" (user and admin could reset it but not set it)
Reenable but not set "bounced" is the current situation.
Except if someone sets the state to "disabled" and then undo this, the state is automatically cleared.
This is possible, but it's not clear what harm would be done. In most cases, bounces are intermittent and clear themselves up, in which case this is the right thing. But if the subscriber bounces again, they'll get disabled again, only cost is a slight waste of resources.
Here's how I would assess the issues. In the descriptions below, I am assuming that each state is the only "active" state.
- DBS is probably a "vacation" or "post-only" setting. For that reason it should be re-enabled only by the subscriber (or by an admin at the request of the subscriber).
- DBB is a "warning" and a minor convenience to the email system (slightly reducing traffic to mailboxes that are expected to fail, and perhaps avoiding some reputational damage to the list). Re-enabling much of the time causes no damage, as bounce disables are typically due to things like out of disk space, and are likely fixed by the time the subscription is reenabled. Most of the rest will be zombie mailboxes, which will rarely be reenabled, will quickly be redisabled by bounce, and at worst cause mild inconvenience. Finally, events like a Mailman upgrade and the April 2014 DMARC fiasco will be pretty evident, and the damage there has already been done, reenabling actually fixes it (although it may not be effective if the systemic problem hasn't been resolved).
- DBA is interesting mostly to *subscribers*, who need to distinguish DBA (which the subscriber can reenable freely) from DBB (which warns the subscriber to get in touch with their postmaster). It's comforting to subscribers who may be sure they never disabled their subscription; otherwise, it's semantically identical to DBS as far as I can see.
Am I missing something?
It seems to me that given 1-3, assuming a 4-state design:
- It's never unreasonable to re-enable, except DBS.
- In the DBA state, changing to either DBS or DBB causes no problems. (Changing to DBB is unlikely, since no mail is being sent. However, it's possible, due to the race between Postorius and mail in transit, and due to spam and other spoofing of the list domain.)
- In either of the other two states, we should never change to DBA.
- In either of the other two states, if the other event occurs, you would want the state to be DBS|DBB. I contend that if we substitute DBS, little harm is done. If the subscriber reenables, it's on them to fix the bounce problem if it reoccurs in any case. Since the subscriber has deliberately set DBS, the admin should not reenable without permission of the subscriber (I think we're mostly in agreement on that).
I think this 4-state design is much easier to design, validate, and maintain than the 16-state design you propose. If you're really worried about DBS|DBB, then we could have a 5-state design where enabling from DBS|DBB generates a warning that there may still be a bounce problem on the subscription. Instead, it could leave the subscription in state DBB, but that seems to me to be obnoxious, since there's little likelihood of harm from reenabling, and in many cases the bounce problem will have resolved itself in the meantime.
Regards, Steve
Footnotes: [1] There's also the question of GDPR obligations if personal reasons (such as "violated code of conduct") are in the history.
[2] I'm not sure where we'd actually draw the line, probably on the order of "once a year per thousand subscribers", that being every week for say a campus-wide list at Ohio State University with 55,000 students.
- Stephen J. Turnbull (turnbull.stephen.fw@u.tsukuba.ac.jp) [210216 16:24]:
But if the admin should respect the DBS (disabled by subscriber) setting, DBS|DBA (disabled by admin) is logically equivalent to DBS. Are there use cases where the admin does not want to repect the subscriber's choice, and enables it anyway? What are they?
To support a user saying "I have disabled myself and can't re-enable it, can you help me please". So basically when acting on-behalf of the user.
Or while importing from another server, and there are people who have receiving mails disabled, this is the state that could be used for it.
Why wouldn't they get the exact state from the original server? Or do you mean from a non-Mailman server?
For example, however there are no more imports from yahoogroups (that's why I started using mm3).
This is possible. If it occurs less than once in a million years, it's "too unimportant" to even think about.[2] Have you actually done this, or know anybody who has?
I'm happy to have forgotten much of my past experience, and for "my" archives I hope to be soon able to switch from subscriber-only to authorized-user-only, so doesn't matter too much for me anymore.
Otherwise, I think the good thing of this discussion is that we have now clearly written up the current state machine.
Otherwise, I just wrote up my favourite but if it stays the current way, well, that's ok of course as well. :) Thanks for your answers and time.
Andi
I am trying to distill some information from this discussion to be used for the implementation in Postorius. I'll maybe reiterate a bit of what Steve was saying just to confirm I am on the same page.
On Tue, Feb 16, 2021, at 7:23 AM, Stephen J. Turnbull wrote:
No answer required, I think I understand the situation pretty well now. But if I'm missing something, I would very much appreciate criticism.
Andreas Barth writes:
Well, currently these are exclusive-states, I'd rather see them as or-able-states.
Right, I understand that. I don't understand *why*.
There are real costs to making them or-able. There are constraints: 'enabled' shouldn't (mustn't?) be or-able with any 'disabled-by-foo' state. Such invariants are finicky to code and tricky to maintain, compared to a simple "mutually exclusive".
I guess you want to allow the or of any subset of disabled states, but presumably then they need to individually resettable in order for the admin to clear their disable without overriding a subscriber's preference or a bounce record. That set of controls is more complex, and requires additional mental effort on the part of anyone using them. If there are restrictions on which states can be or-ed, that's more coding and maintenance cost.
Then there's the question whether the subscriber can override the admin's setting. If they can, why does the admin have this power in the first place?
- "disabled by member" (could be set by an admin as well of course)
Currently this is determined by whether the logged in user is the subscriber or not. It's an interesting idea to allow it to be set by an admin. Then we could have the semantics that the only transition allowed from this state would be to enabled, so that admins would know the user had intentionally disabled and know not to enable without permission.
Exactly.
But if the admin should respect the DBS (disabled by subscriber) setting, DBS|DBA (disabled by admin) is logically equivalent to DBS. Are there use cases where the admin does not want to repect the subscriber's choice, and enables it anyway? What are they?
Or while importing from another server, and there are people who have receiving mails disabled, this is the state that could be used for it.
Why wouldn't they get the exact state from the original server? Or do you mean from a non-Mailman server?
I expect that state to be the most-often used when setting a state manually.
For "who set that", I would consider having some kind of history as useful (and displaying "last set by user / $person" to the admin but not the user).
Why not to the subscriber? As I explain below, the subscriber at least needs to be able to distinguish between DBA and DBB (disabled by bounce).
Keeping history of who is additional complexity, consumes a minor amount of resources, and is insufficient to the purpose. Assuming that there are reasons for admins to disable/enable other than as a courtesy to a subscriber, that reason is presumably important. Not only will the subscriber not know, but one admin may forget, and there may be multiple admins.[1]
I still don't see any reason for an admin to disable delivery other than as a courtesy to the subscriber or to the bounce processor.
- "disabled for administrative reasons" (only by admin but user should be able to see it)
I don't see why a user would need to see the difference. Unless you're suggesting that the user would not be able to reenable without asking the admin? What is the use case for this?
I'm suggesting exactly that, yes. Why? Well, worked with user for too long. ;)
E.g. consider that seeing archives works only for subscribers. And the subscriber in question complains about too many mails but still re-enables getting mails. This is basically "an admin has blocked you from more mails but not unsubscribed you". Might be an corner case, but still. Might also be too unimportant.
This is possible. If it occurs less than once in a million years, it's "too unimportant" to even think about.[2] Have you actually done this, or know anybody who has?
Is it really different from "at request of subscriber"? Practically, the only difference I can see is if such a subscriber should be prevented from overriding DBA. Are you suggesting that?
- "bounced" (user and admin could reset it but not set it)
Reenable but not set "bounced" is the current situation.
Except if someone sets the state to "disabled" and then undo this, the state is automatically cleared.
This is possible, but it's not clear what harm would be done. In most cases, bounces are intermittent and clear themselves up, in which case this is the right thing. But if the subscriber bounces again, they'll get disabled again, only cost is a slight waste of resources.
Here's how I would assess the issues. In the descriptions below, I am assuming that each state is the only "active" state.
- DBS is probably a "vacation" or "post-only" setting. For that reason it should be re-enabled only by the subscriber (or by an admin at the request of the subscriber).
- DBB is a "warning" and a minor convenience to the email system (slightly reducing traffic to mailboxes that are expected to fail, and perhaps avoiding some reputational damage to the list). Re-enabling much of the time causes no damage, as bounce disables are typically due to things like out of disk space, and are likely fixed by the time the subscription is reenabled. Most of the rest will be zombie mailboxes, which will rarely be reenabled, will quickly be redisabled by bounce, and at worst cause mild inconvenience. Finally, events like a Mailman upgrade and the April 2014 DMARC fiasco will be pretty evident, and the damage there has already been done, reenabling actually fixes it (although it may not be effective if the systemic problem hasn't been resolved).
- DBA is interesting mostly to *subscribers*, who need to distinguish DBA (which the subscriber can reenable freely) from DBB (which warns the subscriber to get in touch with their postmaster). It's comforting to subscribers who may be sure they never disabled their subscription; otherwise, it's semantically identical to DBS as far as I can see.
Am I missing something?
It seems to me that given 1-3, assuming a 4-state design:
- It's never unreasonable to re-enable, except DBS.
- In the DBA state, changing to either DBS or DBB causes no problems. (Changing to DBB is unlikely, since no mail is being sent. However, it's possible, due to the race between Postorius and mail in transit, and due to spam and other spoofing of the list domain.)
- In either of the other two states, we should never change to DBA.
- In either of the other two states, if the other event occurs, you would want the state to be DBS|DBB. I contend that if we substitute DBS, little harm is done. If the subscriber reenables, it's on them to fix the bounce problem if it reoccurs in any case. Since the subscriber has deliberately set DBS, the admin should not reenable without permission of the subscriber (I think we're mostly in agreement on that).
I think this 4-state design is much easier to design, validate, and maintain than the 16-state design you propose. If you're really worried about DBS|DBB, then we could have a 5-state design where enabling from DBS|DBB generates a warning that there may still be a bounce problem on the subscription. Instead, it could leave the subscription in state DBB, but that seems to me to be obnoxious, since there's little likelihood of harm from reenabling, and in many cases the bounce problem will have resolved itself in the meantime.
So it seems like we have some sort of agreement that we need all the roles to be able to see all the 4 states. Roles here are basically Admin( i.e. list owner/moderator/site admin) and Subscriber.
There is no access control to transition "from" any state but each value of non-enabled states is sort of a role's way to disable the delivery. Not all states are settable by all roles.
- A subscriber can only transition from any to "enabled" or "by_user" state but can see if delivery was disabled "by_admin" or "by_bounces" as separate state in the Options page.
- An admin can transition to "enabled", "by_user" and "by_moderator". They should use "by_user" when acting on behalf of the user and other when there are any administrative reason to disable delivery, whatever that may be. I expect "by_admin" to be used sparingly, and I don't see any use cases for it.
- Mailman itself will use the "by_bounces" to disable delivery due to bounces.
Is that an accurate description?
-- thanks, Abhilash Raj (maxking)
Abhilash Raj writes:
So it seems like we have some sort of agreement that we need all the roles to be able to see all the 4 states.
I think it's more like there's disagreement about which roles need to see which states, but for each role and each state, somebody thinks that role needs to see that state. I think there's agreement that it's harmless to allow everybody to see all states.
Roles here are basically Admin( i.e. list owner/moderator/site admin) and Subscriber.
In this discussion, yes. However, if we're going to take the discussion seriously, we should be more general than just this case. I think we need to consider five roles. Starting with Brian's list of List Owner, Moderator, List Member, and adding Anonymous (so that a pre-login connection has a named role) and Site Owner for completeness.
There is no access control to transition "from" any state but each value of non-enabled states is sort of a role's way to disable the delivery. Not all states are settable by all roles.
Off-list, Ruth Ivey-Cook informs me that in "who sets what" both "who" and "what" need to be considered is what she had in mind. So I think that's exactly right and there's agreement.
- A subscriber can only transition from any to "enabled" or "by_user" state but can see if delivery was disabled "by_admin" or "by_bounces" as separate state in the Options page.
- An admin can transition to "enabled", "by_user" and "by_moderator".
I assume you mean "by_admin" instead of "by_moderator"?
They should use "by_user" when acting on behalf of the user and other when there are any administrative reason to disable delivery, whatever that may be. I expect "by_admin" to be used sparingly, and I don't see any use cases for it.
- Mailman itself will use the "by_bounces" to disable delivery due to bounces.
Is that an accurate description?
+1 for 1 -- 3 as written. Others' mileage may vary.
Steve
On Wed, Feb 17, 2021, at 10:24 PM, Stephen J. Turnbull wrote:
Abhilash Raj writes:
So it seems like we have some sort of agreement that we need all the roles to be able to see all the 4 states.
I think it's more like there's disagreement about which roles need to see which states, but for each role and each state, somebody thinks that role needs to see that state. I think there's agreement that it's harmless to allow everybody to see all states.
Roles here are basically Admin( i.e. list owner/moderator/site admin) and Subscriber.
In this discussion, yes. However, if we're going to take the discussion seriously, we should be more general than just this case. I think we need to consider five roles. Starting with Brian's list of List Owner, Moderator, List Member, and adding Anonymous (so that a pre-login connection has a named role) and Site Owner for completeness.
Yep, those are all the roles that even we recognize in Postorius. We also have the concept of Domain Owner, though that isn't really implemented yet.
So, from this list, List Owner and above all will use the "by_admin" state to disable if they need to and they are the only ones who can set that state.
There is no access control to transition "from" any state but each value of non-enabled states is sort of a role's way to disable the delivery. Not all states are settable by all roles.
Off-list, Ruth Ivey-Cook informs me that in "who sets what" both "who" and "what" need to be considered is what she had in mind. So I think that's exactly right and there's agreement.
Nice.
- A subscriber can only transition from any to "enabled" or "by_user" state but can see if delivery was disabled "by_admin" or "by_bounces" as separate state in the Options page.
- An admin can transition to "enabled", "by_user" and "by_moderator".
I assume you mean "by_admin" instead of "by_moderator"?
Ok, I've made a mess of it in my responses, the Core actually calls this value "by_moderator" but I have used them interchangeably in my emails. Sorry about that.
https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/interfaces/memb...
They should use "by_user" when acting on behalf of the user and other when there are any administrative reason to disable delivery, whatever that may be. I expect "by_admin" to be used sparingly, and I don't see any use cases for it.
- Mailman itself will use the "by_bounces" to disable delivery due to bounces.
Is that an accurate description?
+1 for 1 -- 3 as written. Others' mileage may vary.
Cool, thanks!
Steve
-- thanks, Abhilash Raj (maxking)
Brian Carpenter writes:
I think treating all disabled options the same is short-sighted. They are all not the same.
-- Some list members will disable their subscription for good reasons and will be really upset if a List Owner renables it through ignorance. So it is important to know a disable member is done by the member itself.
This is true in principle, but (1) I don't think that the user cares; if they're looking at it, they know whether they want enabled or disabled, how it got that way doesn't matter to them, and (2) I can't see why an admin would disable delivery except on request from a user, so I can't see why an admin would reenable except on request from a user. The only case I can see would be a mass reenabling, but that's not going to happen in the future (I hope).
-- Some mailing lists will have multiple list owners managing them. So it is important for one List Owner to know when a subscription has been disabled by the actions of another List Owner.
I don't see why, see above.
-- A List Owner may not know that some of his List Members are bouncing messages for various reasons, so reviewing their Membership roster, they see that they have some list members disabled due to bounces and can then address those particular problematic members.
This query is an important use case. But it's the only one, I think, unless you really have List Owners arbitrarily disabling members' subscriptions. And if you're thinking about reenabling from that page, I think you need a lot more information. For example, if the admin disabled, you need to know if that was a user request or something else (what?). If bounce disabled, you want to know what the bounce was ("no such mailbox"? probably not a good candidate for reenabling), and when (5 minutes ago? ditto). I guess you could just reenable and see what happens, but that could be risky (eg, sending mail to non-existent users is frowned upon by some providers).
@Abhilash, I highly recommend that you contact me off list about getting access to Affinity so you can see what I am talking about. I would love to show you what I have done for Member Management. I offered the same to Steve but he never was interested in taking a look.
It's not that I lack interest, it's that life got in the way. Unfortunately, until I get enough time (man-weeks, I've never worked on Postorius and very little in Django) to work on Postorius, or somebody else starts to do it, a look at Affinity is low priority. Also, it's pretty clear that a quick look isn't going to be very helpful. The Mailman developers know what Mailman 2 looks like. I think the benefits to a hands-on admin are pretty obvious vs the current Postorius, as are Web 2.0 improvments like sorting on the options. The more subtle improvements you've made are going to require a guided tour and/or some study to identify and understand.
Aside: I have to assume that Postorius is aimed at the kind of subscriber that most of us are, and that list administration was something of an afterthought, and assumed to be mostly hands-off. That's the only rationale I can come up with for the design where list admins need to go to the individual pages to see user options -- it was easier to reuse the user option page and just give the admin permission to access and change it, than to provide a (sortable) list with user details.
Steve
On 2/13/21 11:39 AM, Stephen J. Turnbull wrote:
Brian Carpenter writes:
I think treating all disabled options the same is short-sighted. They are all not the same.
-- Some list members will disable their subscription for good reasons and will be really upset if a List Owner renables it through ignorance. So it is important to know a disable member is done by the member itself.
This is true in principle, but (1) I don't think that the user cares; if they're looking at it, they know whether they want enabled or disabled, how it got that way doesn't matter to them, and (2) I can't see why an admin would disable delivery except on request from a user, so I can't see why an admin would reenable except on request from a user. The only case I can see would be a mass reenabling, but that's not going to happen in the future (I hope).
-- Some mailing lists will have multiple list owners managing them. So it is important for one List Owner to know when a subscription has been disabled by the actions of another List Owner.
I don't see why, see above.
-- A List Owner may not know that some of his List Members are bouncing messages for various reasons, so reviewing their Membership roster, they see that they have some list members disabled due to bounces and can then address those particular problematic members.
This query is an important use case. But it's the only one, I think, unless you really have List Owners arbitrarily disabling members' subscriptions. And if you're thinking about reenabling from that page, I think you need a lot more information. For example, if the admin disabled, you need to know if that was a user request or something else (what?). If bounce disabled, you want to know what the bounce was ("no such mailbox"? probably not a good candidate for reenabling), and when (5 minutes ago? ditto). I guess you could just reenable and see what happens, but that could be risky (eg, sending mail to non-existent users is frowned upon by some providers).
@Abhilash, I highly recommend that you contact me off list about getting access to Affinity so you can see what I am talking about. I would love to show you what I have done for Member Management. I offered the same to Steve but he never was interested in taking a look.
It's not that I lack interest, it's that life got in the way. Unfortunately, until I get enough time (man-weeks, I've never worked on Postorius and very little in Django) to work on Postorius, or somebody else starts to do it, a look at Affinity is low priority. Also, it's pretty clear that a quick look isn't going to be very helpful. The Mailman developers know what Mailman 2 looks like. I think the benefits to a hands-on admin are pretty obvious vs the current Postorius, as are Web 2.0 improvments like sorting on the options. The more subtle improvements you've made are going to require a guided tour and/or some study to identify and understand.
Aside: I have to assume that Postorius is aimed at the kind of subscriber that most of us are, and that list administration was something of an afterthought, and assumed to be mostly hands-off. That's the only rationale I can come up with for the design where list admins need to go to the individual pages to see user options -- it was easier to reuse the user option page and just give the admin permission to access and change it, than to provide a (sortable) list with user details.
Steve
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/
I was going to respond in detail but it will be an effort in futility. My opinions are DEFINITELY not valued by you and that is your right as it my right to leave Postorius behind, permanently. Moving to my own interface was one of the best decisions I made and that decision continues to be shown to be a great one when I read threads like this.
-- Brian Carpenter Harmonylists.com Emwd.com
Brian Carpenter writes:
I was going to respond in detail but it will be an effort in futility. My opinions are DEFINITELY not valued by you
But they are. I 100% buy the part about providing full option data and controls in the list format (as in Mailman 2). Isn't that the most important aspect of your proposal for Postorius?
In the rest of the discussion, all I did was ask what are the use cases for distinguishing admin-disabled from user-disabled. I don't know anybody better to ask than you! IMO, these use cases matter, because as I explained in another post, it seems it would be useful to provide the admin with *more* information than just the disabling agent in cases where an admin is considering reenabling a disabled subscription. I could be wrong, that's why I ask. I apologize for not ending with a question mark, I should have done so.
I ask again, please, if you know, explain when admins are reenabling disabled subscriptions (other than the OP's mass disable case, which I think we understand pretty well). I personally have never reenabled a subscription except at user request. I understand my experience is extremely limited AND biased, but it is what it is, and it's all I have right now. I wouldn't be surprised if Mark's and Abhilash's are similar (although Mark does have his bicycle club list, and they're mostly not power users). So, please share yours.
As for the abandoning Postorius part, do you think that hurts my feelings? On the contrary, if you can do that, I feel pride. Affinity being proprietary hurts my feelings (even though I understand perfectly well why it's necessary), but list admins and subscribers benefitting from Affinity is vindication of Barry's decision to split out the UIs from the core, despite the pain that causes some site admins. I had nothing to do with that decision, but I'm happy to be associated with a project that cares enough for users to enable such progress.
Sincere regards, Steve
Mark,
Thank you for this reminder, but it’s not really sufficient for most. The ‘Mailman Settings’ dialog does, indeed show the other preferences tags, and yes, as you say, the dialog for ‘List-based preferences’ only shows values that are not inherited and when you set a value there, it shows.
There a two problems with this:
a. Once a value is overridden on the ‘List-based preferences’ dialog, you cannot go back to it being inherited by removing the override. b. You cannot see, on this dialog, what the inherited value is.
This is not user-friendly.
May I suggest the following:
That each option shows the following:
o Value 1 o Value 2 (or the equivalent for pull-down menus)
A box showing inheritance status: [ ] Use inherited value from address-based preference: Value2
If the ‘Use inherited value’ is chosen, then the inherited value shows. but the value radio buttons become non-selectable. If not, then whatever value the value radio box has become the value for the list,
From what I see, the ‘Use inherited value’ is the default for new lists/addresses. To change a value, the user would uncheck this box, making the radio buttons selectable, and then set the desired value.
Yours,
AllanOn Feb 12, 2021, at 11:52 , Mark Sapiro <mark@msapiro.net> wrote:
I then looked at several of the disabled accounts, but the subscription info page in Postorius had no information about whether an account was enabled or disabled. Why is this not displayed???. The members can't see if their account is enabled. Is this another example of the disconnect between Mailman and Postorius?
If the user has a Django account, she can see all that info at (e.g. for this list) <https://lists.mailman3.org/mailman3/accounts/subscriptions/ <https://lists.mailman3.org/mailman3/accounts/subscriptions/>> She gets there from
Mailman settingsin the dropdown under her user name. She can also get there via theManage Subscriptionbutton on the list's Info page. That takes her toList-based preferencesfor the list. Any setting not selected there is inherited from the Address-based preferences or Global Mailman preferences
On Sun, Feb 14, 2021, at 8:59 AM, Allan Hansen wrote:
Mark,
Thank you for this reminder, but it’s not really sufficient for most. The ‘Mailman Settings’ dialog does, indeed show the other preferences tags, and yes, as you say, the dialog for ‘List-based preferences’ only shows values that are not inherited and when you set a value there, it shows.
There a two problems with this:
a. Once a value is overridden on the ‘List-based preferences’ dialog, you cannot go back to it being inherited by removing the override.
Yes! This is something we've known for a while and haven't been able to fix properly.
https://gitlab.com/mailman/postorius/-/issues/414 https://gitlab.com/mailman/postorius/-/issues/195
There more than one open issue for this. And one of the reasons it hasn't been fixed yet is that it is larger problem than most low hanging fruits that gets fixed in the available time window for the us to work on issue.
This is a long weekend for me, so I'll start some work on this, but not sure if that would be enough to finish.
b. You cannot see, on this dialog, what the inherited value is.
https://gitlab.com/mailman/postorius/-/issues/476
I opened an issue for this too, but this might be a little bit longer of a task because the whole inheritance and calculation of effective preference/setting happens in Core. It would require that Core expose the effective values.
We do have some calculation of preferences in Postorius to display the "Global Mailman preferences" page for a User.
This is not user-friendly.
May I suggest the following:
That each option shows the following:
o Value 1 o Value 2 (or the equivalent for pull-down menus)
A box showing inheritance status: [ ] Use inherited value from address-based preference: Value2
If the ‘Use inherited value’ is chosen, then the inherited value shows. but the value radio buttons become non-selectable.
It is a good idea, might need Javascript skills that I don't have ;-) I'll still try to take a stab at implementing such a view.
If not, then whatever value the value radio box has become the value for the list,
From what I see, the ‘Use inherited value’ is the default for new lists/addresses. To change a value, the user would uncheck this box, making the radio buttons selectable, and then set the desired value.
Yours,
Allan
On Feb 12, 2021, at 11:52 , Mark Sapiro <mark@msapiro.net> wrote:
I then looked at several of the disabled accounts, but the subscription info page in Postorius had no information about whether an account was enabled or disabled. Why is this not displayed???. The members can't see if their account is enabled. Is this another example of the disconnect between Mailman and Postorius?
If the user has a Django account, she can see all that info at (e.g. for this list) <https://lists.mailman3.org/mailman3/accounts/subscriptions/ <https://lists.mailman3.org/mailman3/accounts/subscriptions/>> She gets there from
Mailman settingsin the dropdown under her user name. She can also get there via theManage Subscriptionbutton on the list's Info page. That takes her toList-based preferencesfor the list. Any setting not selected there is inherited from the Address-based preferences or Global Mailman preferences
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)
participants (8)
-
Abhilash Raj -
Allan Hansen -
Andreas Barth -
Brian Carpenter -
hansen＠rc.org
-
Jim Popovitch -
Mark Sapiro -
Stephen J. Turnbull