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

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

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 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@master

You 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)

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

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