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 settings
in the dropdown under her user name. She can also get there via theManage Subscription
button on the list's Info page. That takes her toList-based preferences
for 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 Subscription
button on the list's Info page.)If one is subscribed to lists via their
primary
address, one can go toE-mail Addresses
in their account settings and make a new addressprimary
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 theManage 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
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)