Re: [Mailman-Developers] MM3 - preventing command summary by email
Hi I'm working with Robert on a newsletter project where we want to use Mailman 3 Therefore we'll use a moderated list to send out content to the subscribers.
In my opinion or at least for our usecase it doesn't make much sense to send 2 mails to the subscriber, one that tells the user "Confirmation email sent" and sending a mail to the user that he should confirm his email address. If the command is successful, at least when there is only one command executed, it should be enough to send the actual result of the command.
Would that be reasonable to make that configurable? Where would be the right place to hook in and at least prevent such "double" send outs?
One other thing, I think it would be nice to have the actual list name in the subject of the action mails, for example "MyMailinglist confirm 66c0886...." instead of confirm 66c0886...." and it wouldn't interfere with the actual commands being executed as far as i could test it. How about adding this to mailman3 core and where to add it?
Peter
agitator - weblösungen Peter Holzer Sumatrastrasse 25 CH-8006 Zürich Tel. +41 43 544 08 85 http://www.agitator.com
Fri, 03 Aug 2012 10:48:46 -0700
On Aug 03, 2012, at 04:55 PM, Robert Niederreiter wrote:
Is there a way to disable command summary sent by mail? e.g. after subscription and subscription confirmation.
Not currently. Why do you want to suppress the results?
-Barry
On Aug 19, 2012, at 04:50 PM, Peter Holzer wrote:
In my opinion or at least for our usecase it doesn't make much sense to send 2 mails to the subscriber, one that tells the user "Confirmation email sent" and sending a mail to the user that he should confirm his email address. If the command is successful, at least when there is only one command executed, it should be enough to send the actual result of the command.
Would that be reasonable to make that configurable?
Yes, I think so.
Where would be the right place to hook in and at least prevent such "double" send outs?
The place to hook this in would be in the CommandRunner src/mailman/runners/command.py
If you look down near the bottom of _dispose(), you'll see where the reply is created from a UserNotification(), then at the very bottom, it's sent. The hypothetical flag controlling this would just skip all that to prevent the results from being sent.
The question is how controllable would this need to be? Presumably, the
IMailingList itself would have a flag turning this off,
e.g. send_command_results.
If you do end up taking a crack at this, please open a bug and attach a branch. Ideally, it would have a unittest or doctest, and it will have to go through a schema migration, but I can help with that.
One other thing, I think it would be nice to have the actual list name in the subject of the action mails, for example "MyMailinglist confirm 66c0886...." instead of confirm 66c0886...." and it wouldn't interfere with the actual commands being executed as far as i could test it. How about adding this to mailman3 core and where to add it?
This will also take some more elaborate processing in the eml_confirm.py command. I think there are enough hints in the confirmation message to know which mailing list it's coming from, but if not, please submit a separate bug on this (and a separate branch if you work on a fix).
Cheers, -Barry
Hi,
On 19.08.2012 23:08, Barry Warsaw wrote:
The question is how controllable would this need to be? Presumably, the IMailingList itself would have a flag turning this off, e.g.
send_command_results.
It sounds reasonable to configure this per list.
If you do end up taking a crack at this, please open a bug and attach a branch. Ideally, it would have a unittest or doctest, and it will have to go through a schema migration, but I can help with that.
are tests passing right now in trunk? last time i tried running the tests there were errors:
Running mailman.testing.layers.ConfigLayer tests: Set up mailman.testing.layers.MockAndMonkeyLayer in 0.000 seconds. Set up mailman.testing.layers.ConfigLayer Traceback (most recent call last):
.../mailman.buildout/eggs/storm-0.19-py2.6-linux-x86_64.egg/storm/databases/postgres.py", line 312, in __init__ % (REQUIRED_PSYCOPG2_VERSION, PSYCOPG2_VERSION)) DatabaseModuleError: 'psycopg2' >= 2.0.7 not found. Found None.
Running mailman.testing.layers.RESTLayer tests: Set up mailman.testing.layers.ConfigLayer Traceback (most recent call last): .../mailman.buildout/devsrc/mailman/src/mailman/core/switchboard.py", line 268, in handle_ConfigurationUpdatedEvent 'Duplicate runner name: {0}'.format(name)) AssertionError: Duplicate runner name: in
-Robert
One other thing, ... How about adding this to mailman3 core and where to add it?
This will also take some more elaborate processing in the eml_confirm.py command. I think there are enough hints in the confirmation message to know which mailing list it's coming from, but if not, please submit a separate bug on this (and a separate branch if you work on a fix).
Cheers, -Barry _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/rnix%40squarewave....
Security Policy: http://wiki.list.org/x/QIA9
On Aug 20, 2012, at 08:29 AM, Robert Niederreiter wrote:
are tests passing right now in trunk? last time i tried running the tests there were errors:
This was just a section in testing.cfg that was left uncommented. I'd done a bunch of PostgreSQL clean up work and accidentally checked in the stanza that makes testing use PG. That's now fixed in the trunk.
-Barry
Thanx for the explanation, we'll look into that. Peter
On 19.08.2012, at 23:08, Barry Warsaw barry@list.org wrote:
On Aug 19, 2012, at 04:50 PM, Peter Holzer wrote:
In my opinion or at least for our usecase it doesn't make much sense to send 2 mails to the subscriber, one that tells the user "Confirmation email sent" and sending a mail to the user that he should confirm his email address. If the command is successful, at least when there is only one command executed, it should be enough to send the actual result of the command.
Would that be reasonable to make that configurable?
Yes, I think so.
Where would be the right place to hook in and at least prevent such "double" send outs?
The place to hook this in would be in the CommandRunner src/mailman/runners/command.py
If you look down near the bottom of _dispose(), you'll see where the reply is created from a UserNotification(), then at the very bottom, it's sent. The hypothetical flag controlling this would just skip all that to prevent the results from being sent.
The question is how controllable would this need to be? Presumably, the IMailingList itself would have a flag turning this off, e.g.
send_command_results.If you do end up taking a crack at this, please open a bug and attach a branch. Ideally, it would have a unittest or doctest, and it will have to go through a schema migration, but I can help with that.
One other thing, I think it would be nice to have the actual list name in the subject of the action mails, for example "MyMailinglist confirm 66c0886...." instead of confirm 66c0886...." and it wouldn't interfere with the actual commands being executed as far as i could test it. How about adding this to mailman3 core and where to add it?
This will also take some more elaborate processing in the eml_confirm.py command. I think there are enough hints in the confirmation message to know which mailing list it's coming from, but if not, please submit a separate bug on this (and a separate branch if you work on a fix).
Cheers, -Barry _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/devlists%40irrtum....
Security Policy: http://wiki.list.org/x/QIA9
participants (3)
-
Barry Warsaw -
Peter Holzer -
Robert Niederreiter