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)