On Jul 11, 2011, at 12:22 AM, Paul Wise wrote:
For the Indymedia Mailman 2 install, we have a patch that allowed list
disabling (and later re-enabling). Disabled lists had their
settings/archives saved, did not accept mail and were listed on a
separate page to listinfo. For a long-lived large mailman server
serving local groups in many locations, management of the complete
list life cycle was and still is essential for us.
AFAICT Mailman 3 doesn't yet support such a concept, is that the case?
I've thought about this on and off over the years and still think it's a good
idea. No, MM3 does not have such a thing yet.
If not, would it be acceptable to add that?
Yep, but I'd like to understand the semantics first. Do messages to the list
get bounced, and if so, by Mailman or the MTA? Currently, deleting a list
does remove its configuration, but (by default) retains its archives, which
can be deleted later. A disabled list would always have its archives
available I think.
Any pointers if I were to try and add that?
I think the core feature would not be too hard to implement, but some
specifics would depend on answering the main question above. Here's an
outline of what you'd probably need to touch:
- IMailingList interface to add a `enabled` flag, along with (possibly)
methods to disable and re-enable a list. It's possible that the flag would
be a property and just setting `mlist.enabled = False` would be enough.
- mailman.sql to add that flag to the schema.
- MailingList model to plumb the flag through and implement the switching
- Add a new command class, probably in cli_lists.py to expose disable/enable
to `bin/mailman`. Perhaps implement this as options on the existing
- Plumb this through to the REST API, either by extended the AList class in
src/mailman/rest/lists.py, or by exposing the flag in the ListConfiguration
class in src/mailman/rest/configuration.py.
- Tests and documentation!
It sounds like a lot, but I'd think it's only a day or two of work, and I'm
happy to answer questions, review code, etc.