Is there an Emergency Moderation function (similar to the one that Mailman 2 had) with Mailman 3 core/Postorius?
Thanks, Brian
On 5/21/20 3:23 PM, Brian Carpenter wrote:
Is there an Emergency Moderation function (similar to the one that Mailman 2 had) with Mailman 3 core/Postorius?
It's in core and it's just recently been exposed in REST https://gitlab.com/mailman/mailman/-/merge_requests/643 but it's not in Postorius yet.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 5/21/20 6:30 PM, Mark Sapiro wrote:
On 5/21/20 3:23 PM, Brian Carpenter wrote:
Is there an Emergency Moderation function (similar to the one that Mailman 2 had) with Mailman 3 core/Postorius?
It's in core and it's just recently been exposed in REST https://gitlab.com/mailman/mailman/-/merge_requests/643 but it's not in Postorius yet.
Can I add this through a mailman core update via pip?
Thank you for the information. It is very helpful.
-- Please let me know if you need further assistance.
Thank you for your business. We appreciate our clients. Brian Carpenter EMWD.com
-- EMWD's Knowledgebase: https://clientarea.emwd.com/index.php/knowledgebase
EMWD's Community Forums http://discourse.emwd.com/
Brian Carpenter writes:
Can I add this through a mailman core update via pip?
Eventually .... This depends on when Abhilash gets enough content and a little bit of time to do a new release.
Getting meta: You've been asking for very recent features fairly frequently. I understand that everybody feels better with released code, but to be honest, we do not have a deep quality assurance process. The test suite is voluminous and quite comprehensive, but that's not the same as having a proper beta process, mandatory reviewing, etc etc. It's not obvious to me that we can do a better QA for you than you can do for yourself.
With that in mind, have you considered building your own from source, on a branch from a moderately recent tag, and cherry-picking only commits for features you really want right now?
I admit I don't know how appropriate that is in our tree (I just build from master all the time), but I think that Abhilash is probably pretty careful to pull complete branches so that this should work. If it looks to you like the patches are a little "ragged around the edges", we can work on the process and try to make it more amenable to such cherry-picking for people like you who need some of the most recent commits ASAP, but don't want to accept the whole "bleeding edge".
This also would be useful for your Affinity etc development, I think. (Of course maybe that's what you're talking about, but "emergency moderation" is a pretty common need in production.)
Steve
In the MM3 settings there is an option to ‘Hold for moderation’ when members or non-members post to the list. I use that for the same cases where in MM2 I switched a list to ‘Emergency Moderation.’
My own current top-of-the-list issues:
A bug: Moderators can’t see/edit the list of members even when allowed to by list setting. A feature request: Member changing email address on all lists he/she belongs to, without involving moderators.
Otherwise things appear to be running smoothly (I’m currently knocking very hard on an actual piece of wood - not my head). :-)
Yours,
Allan Hansen hansen@rc.org
On May 24, 2020, at 7:27 , Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Brian Carpenter writes:
Can I add this through a mailman core update via pip?
Eventually .... This depends on when Abhilash gets enough content and a little bit of time to do a new release.
Getting meta: You've been asking for very recent features fairly frequently. I understand that everybody feels better with released code, but to be honest, we do not have a deep quality assurance process. The test suite is voluminous and quite comprehensive, but that's not the same as having a proper beta process, mandatory reviewing, etc etc. It's not obvious to me that we can do a better QA for you than you can do for yourself.
With that in mind, have you considered building your own from source, on a branch from a moderately recent tag, and cherry-picking only commits for features you really want right now?
I admit I don't know how appropriate that is in our tree (I just build from master all the time), but I think that Abhilash is probably pretty careful to pull complete branches so that this should work. If it looks to you like the patches are a little "ragged around the edges", we can work on the process and try to make it more amenable to such cherry-picking for people like you who need some of the most recent commits ASAP, but don't want to accept the whole "bleeding edge".
This also would be useful for your Affinity etc development, I think. (Of course maybe that's what you're talking about, but "emergency moderation" is a pretty common need in production.)
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/
On 5/24/20 10:59 AM, Allan Hansen wrote:
In the MM3 settings there is an option to ‘Hold for moderation’ when members or non-members post to the list. I use that for the same cases where in MM2 I switched a list to ‘Emergency Moderation.’
If you imported your MM 2.1 lists with mailman import21, emergency
was set appropriately for the imported list and should be working to
hold posts regardless of other settings.
My own current top-of-the-list issues:
A bug: Moderators can’t see/edit the list of members even when allowed to by list setting.
The visibility issue is <https://gitlab.com/mailman/postorius/-/issues/369>.
Editing membership beyond what could be done via the admindb interface (i.e. clearing a moderated poster's mod flag) was never allowed for a moderator in MM 2.1.
In MM 3, a moderator can set a member's moderation when handling a held post. Do you think a non-owner moderator should be able to make other changes to a member?
A feature request: Member changing email address on all lists he/she belongs to, without involving moderators.
This is <https://gitlab.com/mailman/postorius/-/issues/399> and we're working on it.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Sun, May 24, 2020, at 11:34 AM, Mark Sapiro wrote:
On 5/24/20 10:59 AM, Allan Hansen wrote:
In the MM3 settings there is an option to ‘Hold for moderation’ when members or non-members post to the list. I use that for the same cases where in MM2 I switched a list to ‘Emergency Moderation.’
If you imported your MM 2.1 lists with
mailman import21,emergencywas set appropriately for the imported list and should be working to hold posts regardless of other settings.My own current top-of-the-list issues:
A bug: Moderators can’t see/edit the list of members even when allowed to by list setting.
The visibility issue is <https://gitlab.com/mailman/postorius/-/issues/369>.
Editing membership beyond what could be done via the admindb interface (i.e. clearing a moderated poster's mod flag) was never allowed for a moderator in MM 2.1.
In MM 3, a moderator can set a member's moderation when handling a held post. Do you think a non-owner moderator should be able to make other changes to a member?
A feature request: Member changing email address on all lists he/she belongs to, without involving moderators.
This is <https://gitlab.com/mailman/postorius/-/issues/399> and we're working on it.
Another way to achieve this request, without needing the Preferred Address route is to simply Patch the Member resource with the new address, which wouldn't trigger the full subscription workflow and would have the extra advantage of having the same delivery_mode and preferences.
I created: https://gitlab.com/mailman/postorius/-/issues/425 to track this issue.
-- 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 May 24, 2020, at 11:34 , Mark Sapiro <mark@msapiro.net> wrote:
On 5/24/20 10:59 AM, Allan Hansen wrote:
In the MM3 settings there is an option to ‘Hold for moderation’ when members or non-members post to the list. I use that for the same cases where in MM2 I switched a list to ‘Emergency Moderation.’
If you imported your MM 2.1 lists with
mailman import21,emergencywas set appropriately for the imported list and should be working to hold posts regardless of other settings.
Not sure what is the difference between ‘emergency moderation’ and ‘Hold for moderation.’ It appears redundant.
My own current top-of-the-list issues:
A bug: Moderators can’t see/edit the list of members even when allowed to by list setting.
The visibility issue is <https://gitlab.com/mailman/postorius/-/issues/369>.
Editing membership beyond what could be done via the admindb interface (i.e. clearing a moderated poster's mod flag) was never allowed for a moderator in MM 2.1.
In MM 3, a moderator can set a member's moderation when handling a held post. Do you think a non-owner moderator should be able to make other changes to a member?
I can only speak for my own application of MM3:
Desiring consistency between the lists, I don’t want to turn all the moderators into owners who can change list settings. Many of my moderators keep asking me to see the list of members and to subscribe and remove members. I end up servicing those requests. So...
a. Moderators should be able to unsubscribe and subscribe members. b. Moderators should be able to set the member’s moderation status. c. Moderators should not be able to see/modify any other member settings.
A feature request: Member changing email address on all lists he/she belongs to, without involving moderators.
This is <https://gitlab.com/mailman/postorius/-/issues/399> and we're working on it.
Awesome!!!!
Thank you,
Allan-- 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 5/25/20 8:21 PM, Allan Hansen wrote:
Not sure what is the difference between ‘emergency moderation’ and ‘Hold for moderation.’ It appears redundant.
emergency moderation is meant for emergencies such as flame wars on
and otherwise open list. It trumps essentially everything else except
pre-approval with and Approved: <password> header. It is not really
intended as a "normal" list setting, although it can be used that way if
you want to hold all posts.
The default action "Hold for moderation" for members and non-members only applies to those whose individual moderation is set to "List default".
To fully understand the difference, you have to know the order in which the various checks are applied. This is defined at <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/chains/builtin.py#L40>. You will see for example that emergency with a hold action comes before banned-address with a discard action. This means that if emergency is True, a post from a banned address will be held and not discarded, at least initially.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Allan Hansen writes:
Not sure what is the difference between ‘emergency moderation’ and ‘Hold for moderation.’ It appears redundant.
It is redundant. But conceptually, "emergency moderation" is a flag set on the list, for situations where a flamewar (or spam via spoofed users) is getting out of hand. "Hold for moderation" is set on individual users. Of course the latter can be used to implement the former, but from the moderator's point of view they're used in rather different situations.
Desiring consistency between the lists, I don’t want to turn all the moderators into owners who can change list settings.
Reasonable. This is why Mailman restricts the operations moderators can perform in the first place.
Many of my moderators keep asking me to see the list of members and to subscribe and remove members. I end up servicing those requests. So...
a. Moderators should be able to unsubscribe and subscribe members.
Reasonable, but traditionally (ie, in Mailman 2) they can't, and this might be inappropriate for some lists. So for backward compatiblity, we probably need to make this a list owner option (or maybe domain owner, but if a list owner wants it I don't see why they shouldn't have it, and denying it creates some perverse incentive to give list owner credentials or permissions to moderators).
I could see defaulting it on eventually, though.
b. Moderators should be able to set the member’s moderation status. c. Moderators should not be able to see/modify any other member settings.
Not sure if there are other settings "somebody" might want to give to moderators, but we should remember you definitely don't want moderators to have them, and make them owner options.
Steve
On May 25, 2020, at 23:18 , Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Allan Hansen writes:
Not sure what is the difference between ‘emergency moderation’ and ‘Hold for moderation.’ It appears redundant.
It is redundant. But conceptually, "emergency moderation" is a flag set on the list, for situations where a flamewar (or spam via spoofed users) is getting out of hand. "Hold for moderation" is set on individual users. Of course the latter can be used to implement the former, but from the moderator's point of view they're used in rather different situations.
Makes sense now. I have all users set to default list moderation, so setting the list to ‘Hold for moderation’ for me is the same. But yes, individual users have other options, then emergency moderation is stronger.
Desiring consistency between the lists, I don’t want to turn all the moderators into owners who can change list settings.
Reasonable. This is why Mailman restricts the operations moderators can perform in the first place.
I appreciate that.
Many of my moderators keep asking me to see the list of members and to subscribe and remove members. I end up servicing those requests. So...
a. Moderators should be able to unsubscribe and subscribe members.
Reasonable, but traditionally (ie, in Mailman 2) they can't, and this might be inappropriate for some lists. So for backward compatiblity, we probably need to make this a list owner option (or maybe domain owner, but if a list owner wants it I don't see why they shouldn't have it, and denying it creates some perverse incentive to give list owner credentials or permissions to moderators).
I’m willing to do the work now, but would rather it be done by moderators, as these list maintenance things (listing, sub/unsub) seem to be moderator level activities.
I could see defaulting it on eventually, though.
Correct. It could be a domain default, overridden by list owner.
b. Moderators should be able to set the member’s moderation status. c. Moderators should not be able to see/modify any other member settings.
Not sure if there are other settings "somebody" might want to give to moderators, but we should remember you definitely don't want moderators to have them, and make them owner options.
Excellent!
Thank you, Steve and Mark!
Allan
On Sun, May 24, 2020, at 7:27 AM, Stephen J. Turnbull wrote:
Brian Carpenter writes:
Can I add this through a mailman core update via pip?
Eventually .... This depends on when Abhilash gets enough content and a little bit of time to do a new release.
FWIW, you can also install from Gitlab directly simply using pip:
$ pip install git+https://gitlab.com/mailman/mailman@masterYou can use @ to specify a git reference, like a branch name or tag name or a commit hash would also work.
Getting meta: You've been asking for very recent features fairly frequently. I understand that everybody feels better with released code, but to be honest, we do not have a deep quality assurance process. The test suite is voluminous and quite comprehensive, but that's not the same as having a proper beta process, mandatory reviewing, etc etc. It's not obvious to me that we can do a better QA for you than you can do for yourself.
Our QA process is basically mail.python.org (m.p.o) and lists.mailman3.org and couple of other server Mark runs for his personal stuff. We get notified about the major breaking changes pretty fast (m.p.o is pretty important to keep up) but some small changes do get piled up until I get to them.
I have a decent number of errors from Sentry that I should look at, many of which are triggered by weird inputs. It needs a bit more work and balance between bugfixing and new features, which I haven't been very good at :(
I can however do more rc and beta releases if there are people out there willing to get/test out new features faster. With the current releases, I am first time releasing some rc versions, but I think I might keep up the 1-2 week rc period for upcoming releases.
With that in mind, have you considered building your own from source, on a branch from a moderately recent tag, and cherry-picking only commits for features you really want right now?
I admit I don't know how appropriate that is in our tree (I just build from master all the time), but I think that Abhilash is probably pretty careful to pull complete branches so that this should work. If it looks to you like the patches are a little "ragged around the edges", we can work on the process and try to make it more amenable to such cherry-picking for people like you who need some of the most recent commits ASAP, but don't want to accept the whole "bleeding edge".
The one huge issue with "clean" cherry-picking is NEWS.rst in each repo. There is a little bit of manual intervention involved always to update the changelog. We could adopt a different more specialized tool like Blurb1 that CPython uses, but I find it a little too cumbersome for a small project like us. It might just end up making contributing to Mailman a bit harder too (extra tool to install and create NEWS files vs adding a new line in NEWS.rst, pretty small change but things add up!).
This also would be useful for your Affinity etc development, I think. (Of course maybe that's what you're talking about, but "emergency moderation" is a pretty common need in production.)
I am "trying" to do more frequent releases. There are a lot of bugfixes and REST API enhancements coming up in the next version of Core, including like Mark said, emergency flag being exposed.
I **think** emergency was the last one pending to be exposed via API, I did a whole bunch of them in previous version but missed out on emergency. There are a bunch of un-used attributes of MailingList (like topics, expire_subscriptions_after etc) which don't *need* to be exposed and they get mixed with some other useful ones.
If anyone finds something useful that isn't exposed, please open a ticket or even better submit a MR (it is really quite easy).
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/
-- thanks, Abhilash Raj (maxking)
participants (5)
-
Abhilash Raj -
Allan Hansen -
Brian Carpenter -
Mark Sapiro -
Stephen J. Turnbull