very few moderation capabilities for moderators
Hi all:
I need to provide the list moderators a way to change the moderation flag for users from whichever it is (normally "list default processing") to "hold for moderation" and viceversa (to "list default" or to "accept")
I understand that it could be done via console script (That's the way I did on mailman2: I made two commands using "withlist", one to hold, moderar.py, and other one to accept, desmoderar.py. I show you below)
But I think I'm not the only one that could use as an improvement a way to do this on postorius/web.
Before to trying implementing them on mailman3, I beg you to tell me if they could do that on mailman3.
Thanks in advance.
****************** (moderar.py)
#! /usr/local/bin/python # # script via withlist para moderar a pelo #
"""moderar un miembro.
Save as bin/moderar.py
Run via
bin/withlist -r moderar <listname> <member> """
from Mailman import mm_cfg
def moderar(mlist, member): if not mlist.Locked(): mlist.Lock() mlist.setMemberOption(member, mm_cfg.Moderate, True) mlist.Save() mlist.Unlock()
****************** (desmoderar.py)
#! /usr/local/bin/python # # script via withlist para desmoderar un miembro #
"""desmoderar un miembro.
Save as bin/desmoderar.py
Run via
bin/withlist -r desmoderar <listname> <member> """
from Mailman import mm_cfg
def desmoderar(mlist, member): if not mlist.Locked(): mlist.Lock() mlist.setMemberOption(member, mm_cfg.Moderate, False) mlist.Save() mlist.Unlock()
--
On 9/16/21 2:39 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
Hi all:
I need to provide the list moderators a way to change the moderation flag for users from whichever it is (normally "list default processing") to "hold for moderation" and viceversa (to "list default" or to "accept")
I understand that it could be done via console script (That's the way I did on mailman2: I made two commands using "withlist", one to hold, moderar.py, and other one to accept, desmoderar.py. I show you below)
Are you asking what the equivalent MM 3 scripts would be?
But I think I'm not the only one that could use as an improvement a way to do this on postorius/web.
Postorius allows a list owner or site admin to set Moderation for list members and non members at e.g. https://www.example.com/mailman3/lists/list.example.com/members/(non)member/. Currently, a list moderator who is not an owner cannot do this, but a moderator can set Moderation for the sender of a held post when handling the post.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 16/9/21 16:40, Mark Sapiro wrote:
On 9/16/21 2:39 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
Hi all:
I need to provide the list moderators a way to change the moderation flag for users from whichever it is (normally "list default processing") to "hold for moderation" and viceversa (to "list default" or to "accept")
I understand that it could be done via console script (That's the way I did on mailman2: I made two commands using "withlist", one to hold, moderar.py, and other one to accept, desmoderar.py. I show you below)
Are you asking what the equivalent MM 3 scripts would be?
More or less: I'm asking for a general direction here. I think I cannot use tthe "withlist" method as before, inside a python script, and I'm not sure how to do it. I've been reviewing all the command docs that I've found, but I have no clear way. I need a shell or a python script that I can pass the list and the mail address to put on hold/hold (that way the moderators can log in a special account thhat asks for the address to hold/unhold). I did it in mailman2 whith the bin/withlist command, but now whithlist seems to be an alias for shell and is interactive.Thats not my goal)
But I think I'm not the only one that could use as an improvement a way to do this on postorius/web.
Postorius allows a list owner or site admin to set Moderation for list members and non members at e.g. https://www.example.com/mailman3/lists/list.example.com/members/(non)member/.
Yes, I know that. But the owner cannot be 24/7 attending the lists (as we all know), and could need a help hand from moderators. Not just from accepting mails on hold, but to put on hold a member (and be capable of reversing it) when the netiquete dissapears completely and some thread becomes a flame and all goes south. I'ts the admin capability I miss the most for moderators in mailman.
Currently, a list moderator who is not an owner cannot do this, but a moderator can set Moderation for the sender of a held post when handling the post.
But I'm talking about a moderator can put a member mails in hold when it is marked to accept. To prevent putting more gas in the fire.
On 9/17/21 6:18 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
On 16/9/21 16:40, Mark Sapiro wrote:
Are you asking what the equivalent MM 3 scripts would be?
More or less: I'm asking for a general direction here. I think I cannot use tthe "withlist" method as before, inside a python script, and I'm not sure how to do it.
You can run scripts via withlist in Mailman 3 similarly to Mailman 2. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/commands/do...
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 17/9/21 17:24, Mark Sapiro wrote:
On 9/17/21 6:18 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
On 16/9/21 16:40, Mark Sapiro wrote:
Are you asking what the equivalent MM 3 scripts would be?
More or less: I'm asking for a general direction here. I think I cannot use tthe "withlist" method as before, inside a python script, and I'm not sure how to do it.
You can run scripts via withlist in Mailman 3 similarly to Mailman 2. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/commands/do...
First, thanks for the prompt response, Mark.
Maybe I'm a little bit ofuscated, but I readed this doc many times when I was searching how to do it... but I cannot imagine how to do a shell or a python script, using the needed parameters, that sets hold on a member of a list.
I'll try to do some tests tomorrow.
As said, thanks.
Guillermo Hernandez (Oldno7) via Mailman-users writes:
But� I'm talking about a moderator can put a member mails in hold when it is marked to accept. To prevent putting more gas in the fire.
Not sure what you want here. I don't see how this is supposed to work -- if a subscriber is set to accept, the moderator will never see the posts until they're distributed to the subscribers.
But that inspires a short rant ;-) a little about the implied feature request.
First let me point out that there are a lot of lists out there where the owner is relatively laissez faire, and some moderators are a lot more activist. In the modern environment, it turns out to be important for many lists to vet new subscribers' first posts, and moderators basically function to give prompt response to non-spam first posts. So I don't want to just give moderators the same privileges as owners here, because they'll impose restrictions that the owner doesn't want, and the current low-privilege moderators seem to work just fine for a lot of lists.
I don't object in principle to allowing *owners* to give moderators more privileges. On the one hand, it's often case that owners trust their colleagues with owner-level privileges. So that's an option we already have -- no moderators, all owners.
So maybe you *don't* like the all-owners strategy (and it's obvious why many owners won't, no need to bend my ear on that). The design problem is that there are a lot of capabilities, and it's not obvious to me that there's a specific collection of them that owners want to grant to their moderators. Maybe we can get rough consensus on that list, and then it's not hard to get to working code. I'm not going to start the conversation here (I don't personally have such a list), but I'm happy to listen, and provide advice to anyone who wants to submit a merge request.
If there isn't consensus, then we're going to need a framework for moderator capability management so that owners can pick and choose. That's something I'd be interested in working on myself if there's user demand for it. (There's a long list of things I'm interested in, and not a lot of work actually done recently, so no promises. But it could happen! ;-) It could also end up on the GSoC idea list for next year. :-)
Another capability I have an interest in is closing replies to specific posts and to whole threads. Again, that's going to require some thinking about the administration interface. It's easy enough to do the basics if there's an archive (allow the moderator to click on a post, and either disable replies to that post or replies to all thread descendents), but I can imagine lots of related capabilities (reenable replies for "sane" subthreads, automatic expiration of the restriction, ...).
And of course all of the above (except unconditionally granting moderators the capability to apply a HOLD to users) requires REST updates, I suspect.
As always: code contributions welcome.
Steve
On 18/9/21 7:10, Stephen J. Turnbull wrote:
Guillermo Hernandez (Oldno7) via Mailman-users writes:
But? I'm talking about a moderator can put a member mails in hold when it is marked to accept. To prevent putting more gas in the fire.
Not sure what you want here. I don't see how this is supposed to work -- if a subscriber is set to accept, the moderator will never see the posts until they're distributed to the subscribers.
I'll try to explain:
In my experience, the most useful tool to cool down a thread that has converted in a flame is to stop free distribution (hold) new mails coming from some suscribers (the most infuriated, or maybe the more infuriating -I don't know if this word, infuriating, makes sense in english-). You need to slow down the interchange of burning mails, and perhaps discard some of them. Make announcements to the rest of the suscribers and try to reconduce the waters. Yes: it can be done by the owner or the list or administrators. But this admin capability cannot be done by a so called "moderator". The moderators, in mailman, cannot moderate the flux of a overheated list.
I'm talking about lists that otherwise have a normal and pausated exchange of mails, but some subject becomes a battlefield, and in a period of minutes you have hundreds of mails...
And the admins are sleeping (because in their timezone are 03:00 am) and the moderators that are awake have their hands tied.
A moderator doesn't have to be capable of configuring lists, but they would have to be capable to moderate the flux of mails when it's necessary.
The rest of your post is very appreciated, as always.
Thanks a lot.
But that inspires a short rant ;-) a little about the implied feature request.
First let me point out that there are a lot of lists out there where the owner is relatively laissez faire, and some moderators are a lot more activist. In the modern environment, it turns out to be important for many lists to vet new subscribers' first posts, and moderators basically function to give prompt response to non-spam first posts. So I don't want to just give moderators the same privileges as owners here, because they'll impose restrictions that the owner doesn't want, and the current low-privilege moderators seem to work just fine for a lot of lists.
I don't object in principle to allowing *owners* to give moderators more privileges. On the one hand, it's often case that owners trust their colleagues with owner-level privileges. So that's an option we already have -- no moderators, all owners.
So maybe you *don't* like the all-owners strategy (and it's obvious why many owners won't, no need to bend my ear on that). The design problem is that there are a lot of capabilities, and it's not obvious to me that there's a specific collection of them that owners want to grant to their moderators. Maybe we can get rough consensus on that list, and then it's not hard to get to working code. I'm not going to start the conversation here (I don't personally have such a list), but I'm happy to listen, and provide advice to anyone who wants to submit a merge request.
If there isn't consensus, then we're going to need a framework for moderator capability management so that owners can pick and choose. That's something I'd be interested in working on myself if there's user demand for it. (There's a long list of things I'm interested in, and not a lot of work actually done recently, so no promises. But it could happen! ;-) It could also end up on the GSoC idea list for next year. :-)
Another capability I have an interest in is closing replies to specific posts and to whole threads. Again, that's going to require some thinking about the administration interface. It's easy enough to do the basics if there's an archive (allow the moderator to click on a post, and either disable replies to that post or replies to all thread descendents), but I can imagine lots of related capabilities (reenable replies for "sane" subthreads, automatic expiration of the restriction, ...).
And of course all of the above (except unconditionally granting moderators the capability to apply a HOLD to users) requires REST updates, I suspect.
As always: code contributions welcome.
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 17/9/21 19:58, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
On 17/9/21 17:24, Mark Sapiro wrote:
On 9/17/21 6:18 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
On 16/9/21 16:40, Mark Sapiro wrote:
Are you asking what the equivalent MM 3 scripts would be?
More or less: I'm asking for a general direction here. I think I cannot use tthe "withlist" method as before, inside a python script, and I'm not sure how to do it.
You can run scripts via withlist in Mailman 3 similarly to Mailman 2. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/commands/do...
First, thanks for the prompt response, Mark.
Maybe I'm a little bit ofuscated, but I readed this doc many times when I was searching how to do it... but I cannot imagine how to do a shell or a python script, using the needed parameters, that sets hold on a member of a list.
I'll try to do some tests tomorrow.
I've followed the indications of a
mailman -C /usr/local/mailman3/var/etc/mailman.cfg shell --details
I've been trying to "translate" the python script that I made for mailman2 to new mailman3, but obviously, I'm missing something. It seems that mailman cannot locate the "module" needed.
The script is named "moderar.py":
*-*-*-*-*-*-*-*-*-* (begin of /usr/local/mailman3/moderar.py)
/usr/local/mailman3 # cat moderar.py #! /usr/local/bin/python3 # # script via withlist para moderar a pelo en mailman3 #
import os import sys
sys.path.insert(0, '/usr/local/mailman3') os.environ['PYTHONPATH'] = '/usr/local/mailman3' os.environ['DJANGO_SETTINGS_MODULE'] = 'settings' os.environ['MAILMAN_CONFIG_FILE'] = '/usr/local/mailman3/var/etc/mailman.cfg'
import mm_cfg
def moderar(mlist, member): if not mlist.Locked(): mlist.Lock() mlist.setMemberOption(member, mm_cfg.Moderate, True) mlist.Save() mlist.Unlock()
*-*-*-*-*-*-*-*-*-* (end of /usr/local/mailman3/moderar.py)
When I execute a
mailman withlist -r moderar -l list_to_use@mydomain.com address@moderate.com
The system returns:
Traceback (most recent call last): File "/usr/local/bin/mailman", line 11, in <module> load_entry_point('mailman==3.3.4', 'console_scripts', 'mailman')() File "/usr/local/lib/python3.7/site-packages/click/core.py", line 829, in __call__ return self.main(*args, **kwargs) File "/usr/local/lib/python3.7/site-packages/click/core.py", line 782, in main rv = self.invoke(ctx) File "/usr/local/lib/python3.7/site-packages/mailman/bin/mailman.py", line 68, in invoke return super().invoke(ctx) File "/usr/local/lib/python3.7/site-packages/click/core.py", line 1259, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) File "/usr/local/lib/python3.7/site-packages/click/core.py", line 1066, in invoke return ctx.invoke(self.callback, **ctx.params) File "/usr/local/lib/python3.7/site-packages/click/core.py", line 610, in invoke return callback(*args, **kwargs) File "/usr/local/lib/python3.7/site-packages/click/decorators.py", line 21, in new_func return f(get_current_context(), *args, **kwargs) File "/usr/local/lib/python3.7/site-packages/mailman/commands/cli_withlist.py", line 293, in shell r = call_name(dotted_name, m, *run_args) File "/usr/local/lib/python3.7/site-packages/mailman/utilities/modules.py", line 69, in call_name named_callable = find_name(dotted_name) File "/usr/local/lib/python3.7/site-packages/mailman/utilities/modules.py", line 52, in find_name module = import_module(module_path) File "/usr/local/lib/python3.7/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1006, in _gcd_import File "<frozen importlib._bootstrap>", line 983, in _find_and_load File "<frozen importlib._bootstrap>", line 965, in _find_and_load_unlocked ModuleNotFoundError: No module named 'moderar'
I've done a
ln -s /usr/local/mailman3/moderar.py /usr/local/lib/python3.7/site-packages/mailman/bin/moderar.py
But with the same result.
And I'm not sure if I'm doing well importing "mm_cfg" in the script.
My enviroment is open wide installation of mailman, python, etc. in a FreeBSD 12.2-RELEASE-p10
Mailman Core Version GNU Mailman 3.3.4 (Tom Sawyer) Mailman Core API Version 3.1 Mailman Core Python Version 3.7.9 (default, Nov 6 2020, 21:14:59) [Clang 8.0.1 (tags/RELEASE_801/final 366581)]
Postorius version: 1.3.5
If someone can give a hint it will be much appreciated.
Guillermo Hernandez (Oldno7) via Mailman-users writes:
On 18/9/21 7:10, Stephen J. Turnbull wrote:
Guillermo Hernandez (Oldno7) via Mailman-users writes:
But? I'm talking about a moderator can put a member mails in hold when it is marked to accept. To prevent putting more gas in the fire.
Not sure what you want here. I don't see how this is supposed to work -- if a subscriber is set to accept, the moderator will never see the posts until they're distributed to the subscribers.
I'll try to explain:
In my experience, the most useful tool to cool down a thread that has converted in a flame is to stop free distribution (hold) new mails coming from some suscribers
That's what I was missing. You want moderators to be able to set the moderation flag on a particular member, or several members.
A moderator doesn't have to be capable of configuring lists, but they would have to be capable to moderate the flux of mails when it's necessary.
As I wrote before, I think this needs to be an option controlled by the owner, which makes implementation more complicated. But we'll see what the rest of the core thinks.
Steve
On 18/9/21 14:29, Stephen J. Turnbull wrote:
Guillermo Hernandez (Oldno7) via Mailman-users writes:
On 18/9/21 7:10, Stephen J. Turnbull wrote:
Guillermo Hernandez (Oldno7) via Mailman-users writes:
But? I'm talking about a moderator can put a member mails in hold when it is marked to accept. To prevent putting more gas in the fire.
Not sure what you want here. I don't see how this is supposed to work -- if a subscriber is set to accept, the moderator will never see the posts until they're distributed to the subscribers.
I'll try to explain:
In my experience, the most useful tool to cool down a thread that has converted in a flame is to stop free distribution (hold) new mails coming from some suscribers
That's what I was missing. You want moderators to be able to set the moderation flag on a particular member, or several members.
Yes. Exactly. That's the unique capability for moderators (that admins have) that I think mailman lacked ever.
From my perspective: there is two complementary "sides" when it comes to managing a list: the admin tasks, configuring, setting rules of suscribing, acceptation mails, etc. AND the management of the flux of messages. Thats what I call "moderation". Warning suscribers when a thread overheat, and being capable to set off a member when his behaviour makes it neccesary.
Good you have understand me despite muy poor explanations.
In mailman2 I have this second part covered via python scripts (and login via special account from moderators), and I will do in mailman3. If I cannot succeed via python, I'm planning doing it via DDBB. Let's see.
A moderator doesn't have to be capable of configuring lists, but they would have to be capable to moderate the flux of mails when it's necessary.
As I wrote before, I think this needs to be an option controlled by the owner, which makes implementation more complicated. But we'll see what the rest of the core thinks.
Steve
Guillermo Hernandez (Oldno7) via Mailman-users writes:
import mm_cfg
This should result in an error, there is no mm_cfg.py in Mailman3. Was there previously a Mailman 2 installation on this host?
mailman withlist -r moderar -l list_to_use@mydomain.com address@moderate.com
The system returns:
Traceback (most recent call last): ModuleNotFoundError: No module named 'moderar'
I've done a
ln -s� /usr/local/mailman3/moderar.py /usr/local/lib/python3.7/site-packages/mailman/bin/moderar.py
Note that "--detail" when gives an example for "-r", it says "listaddr.py" is installed in "the Mailman installation directory", which is either /usr/local/lib/python3.7/site-packages/mailman or /usr/local/mailman3, or maybe something under /usr/local/mailman3/var, I think.
If neither of those works, Mark or Abhilash will explain soon. In the meantime you could also try "mailman.bin.moderar" instead of "moderar". I don't think mailman/bin is on Python's sys.path for imports (it's set up as a package with __init__.py), and the qualified path is what is used in the scripts you invoke from from the OS shell like "mailman".
On 18/9/21 15:17, Stephen J. Turnbull wrote:
Guillermo Hernandez (Oldno7) via Mailman-users writes:
import mm_cfg
This should result in an error, there is no mm_cfg.py in Mailman3. Was there previously a Mailman 2 installation on this host? Yes, indeed. I'm trying to convert a mailman2 script to its equivalent in mailman3.
mailman withlist -r moderar -llist_to_use@mydomain.com address@moderate.com
The system returns:
Traceback (most recent call last): ModuleNotFoundError: No module named 'moderar'
I've done a
ln -s? /usr/local/mailman3/moderar.py /usr/local/lib/python3.7/site-packages/mailman/bin/moderar.py
Note that "--detail" when gives an example for "-r", it says "listaddr.py" is installed in "the Mailman installation directory", which is either /usr/local/lib/python3.7/site-packages/mailman or /usr/local/mailman3, or maybe something under /usr/local/mailman3/var, I think.
I've placed moderar.py via ln -s in all those paths. Same results
If neither of those works, Mark or Abhilash will explain soon. In the meantime you could also try "mailman.bin.moderar" instead of "moderar".
Tried, but same results. Tomorrow will be another day.
Thaks a lot for your hints.
I don't think mailman/bin is on Python's sys.path for imports (it's set up as a package with __init__.py), and the qualified path is what is used in the scripts you invoke from from the OS shell like "mailman".
Mailman-users mailing list --mailman-users@mailman3.org To unsubscribe send an email tomailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
I think you've missed one good option to do this - by sending an HTTP(s) request to your Mailman Core. You can do it from console via curl or even from a custom web page via Javascript (if your API is exposed to the public). The request would be quite simple - check docs at https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/m...
You can also retrieve a list of mailing lists (e.g. for a nice UI select element) using GET /lists request: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/l...
Best regards, Danil
On 18/9/21 17:22, Danil Smirnov wrote:
I think you've missed one good option to do this - by sending an HTTP(s) request to your Mailman Core. You can do it from console via curl or even from a custom web page via Javascript (if your API is exposed to the public).
Sound very interesting. Tomorrow I'll take a thorough look at this
Thanks a lot
The request would be quite simple - check docs at https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/m...
You can also retrieve a list of mailing lists (e.g. for a nice UI select element) using GET /lists request: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/l...
Best regards, Danil
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 9/18/21 1:41 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
I've been trying to "translate" the python script that I made for mailman2 to new mailman3, but obviously, I'm missing something. It seems that mailman cannot locate the "module" needed.
The script is named "moderar.py":
*-*-*-*-*-*-*-*-*-* (begin of /usr/local/mailman3/moderar.py)
/usr/local/mailman3 # cat moderar.py #! /usr/local/bin/python3 # # script via withlist para moderar a pelo en mailman3 #
import os import sys
sys.path.insert(0, '/usr/local/mailman3')
If /usr/local/mailman3 is not already in the path, this is too late.
The rest of your script is not relevant.
Here's what you need:
from mailman.interfaces.action import Action def moderar(mlist, member): memb = mlist.members.get_member(member) if not memb: print('{} is not a list member.'.format(member)) return memb.moderation_action = Action.hold print('{} moderation_action set to hold.'.format(member))
That should be put in a moderar.py file somewhere in Mailman's path. The
same directory that contains the mailman command is for sure good.
Possibly that's /usr/local/mailman3/bin/.
Then
mailman withlist -r moderar -l list_to_use@mydomain.com address@moderate.com
should work.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 18/9/21 20:27, Mark Sapiro wrote:
from mailman.interfaces.action import Action def moderar(mlist, member): memb = mlist.members.get_member(member) if not memb: print('{} is not a list member.'.format(member)) return memb.moderation_action = Action.hold print('{} moderation_action set to hold.'.format(member))
That completely did it. The problem about finding the module was completely gone when I made a soft link in the same directory where mailman command is (in /usr/local/bin, for your info).
Thank you very, very much.
On 18/9/21 20:42, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
On 18/9/21 20:27, Mark Sapiro wrote:
from mailman.interfaces.action import Action def moderar(mlist, member): memb = mlist.members.get_member(member) if not memb: print('{} is not a list member.'.format(member)) return memb.moderation_action = Action.hold print('{} moderation_action set to hold.'.format(member))
Just a one more silly question:
Where do I can find the diferent values that memb.moderation_action can take? (I want to prepare the "unhold" script too)
Thanks in advance.
That completely did it. The problem about finding the module was completely gone when I made a soft link in the same directory where mailman command is (in /usr/local/bin, for your info).
Thank you very, very much.
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 9/18/21 11:56 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
Just a one more silly question:
Where do I can find the diferent values that memb.moderation_action can take? (I want to prepare the "unhold" script too)
https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/interfaces/acti...
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 18/9/21 22:59, Mark Sapiro wrote:
On 9/18/21 11:56 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
Just a one more silly question:
Where do I can find the diferent values that memb.moderation_action can take? (I want to prepare the "unhold" script too)
https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/interfaces/acti...
Thanks: It's perfect
On 9/18/21 2:52 PM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
On 18/9/21 22:59, Mark Sapiro wrote:
On 9/18/21 11:56 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
Just a one more silly question:
Where do I can find the diferent values that memb.moderation_action can take? (I want to prepare the "unhold" script too)
https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/interfaces/acti...
Thanks: It's perfect
One more thing. It isn't obvious, but generally you want Action.defer rather than Action.accept. Action.defer will pass the moderation check, but still continue to check other rules such as administrivia, implicit-destination, max-recipients, max-size, no-subject and header filters whereas Action.accept will accept the message unconditionally and bypass those subsequent checks.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 19/9/21 3:03, Mark Sapiro wrote:
On 9/18/21 2:52 PM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
On 18/9/21 22:59, Mark Sapiro wrote:
On 9/18/21 11:56 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
Just a one more silly question:
Where do I can find the diferent values that memb.moderation_action can take? (I want to prepare the "unhold" script too)
https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/interfaces/acti...
Thanks: It's perfect
One more thing. It isn't obvious, but generally you want Action.defer rather than Action.accept. Action.defer will pass the moderation check, but still continue to check other rules such as administrivia, implicit-destination, max-recipients, max-size, no-subject and header filters whereas Action.accept will accept the message unconditionally and bypass those subsequent checks.
Thanks for the tip. I definitely use defer instead of accept now. At least for the use of moderators in a "unhold" stance.
--
participants (4)
-
Danil Smirnov -
Guillermo Hernandez (Oldno7) -
Mark Sapiro -
Stephen J. Turnbull