[Mailman-Developers] MM3: list disabling/enabling?

[Barry Warsaw]

On Jul 13, 2011, at 04:51 PM, Paul Wise wrote:

>By bounce I meant SMTP-time rejection, sounds like the LMTP stuff
>provides that (and mailman 2 doesn't use that IIRC).

Correct.

>Temporarily failing lists were not an objective.

Cool, I think we're agreed on that.

>The design of list objects seems to be heavily similar to how the UI
>is in mailman 2, I think it should be much more generic.
>
>For example:
>
>In the web UI turning on emergency moderation should set the first
>item in the receive pipeline to a hold() function.
>
>Disabling a list would set the first item in the receive pipeline to
>reject_disabled, set the first item in the subscription pipeline to
>reject_disabled, set the first item in the settings pipeline to
>admin_read_only etc.

This isn't exactly how MM3 works.  In MM3, the incoming queue sends the
message through a chain, where each link has a rule and an action.  An action
can be something like "jump to the `hold` chain", which is in fact exactly
what happens in the default built-in chain:

src/mailman/chains/builtin.py:

    _link_descriptions = (
        ('approved', LinkAction.jump, 'accept'),
        ('emergency', LinkAction.jump, 'hold'),
        ...

There really aren't "subscription" or "settings" pipelines, and I'm not sure
they're the right way to implement what you have in mind.

>List objects should be flexible to support different kinds of lists,
>but the UI should hide most of that behind simple labels like "retired
>list", "public list", "private list" and the "emergency moderation"
>button.

MM3 has list styles, which are composeable and extensible.  A style is only
applied at list creation time though.

>PS: Is there a Mailman UI yet? The link on the Mailman branches wiki
>page points to one with only one commit in it and no working code.

I think we're still waiting for Florian and the GSoC students to propose
branch merges into lp:mailmanweb.

>PPS: It seems Mailman 3 will be quite different to Mailman 2 so I'm
>thinking configuration filenames, data directories etc should be named
>mailman3 instead of mailman.

Maybe.  I'd really like to not do that if it can be avoided.  For example, the
configuration system is so different I can't see how there would be much
collision.  The data directories, possibly, but I also think there are enough
knobs to allow site admins or vendor packagers to set things up with the
proper defaults.  I don't think there will be any collisions on command line
program names.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110715/cf4679f0/attachment.pgp>