On Tue, Jan 16, 2018 at 10:59:28AM +0900, Stephen J. Turnbull wrote:
Colin Watson writes:
Ideally, I'd like mailing lists to have a "deactivated" state in addition to full deletion. In this state, the list would appear nonexistent for most purposes: incoming email would be rejected, Postorius would deny its existence, etc.
[...]
Has there been any discussion of this in the past, or any advice as to implementation strategy?
I don't recall anybody discussing this. Your use case is your use case, but I think if we were going to implement this I'd probably want "partial" deactivation where the archives remain available but no mail is delivered, can't subscribe, etc. I'm also not sure I'd want Postorius to deny it ever existed. That seems rather unfriendly (again, I don't understand your use case, so that is not a comment on your requirements).
I possibly should have explained our situation in a little more detail. The way we have things set up with Mailman 2.1 is that any team in Launchpad (teams are basically just a collection of people, with varying policies on who can join them etc.) can have a mailing list if its administrators want one, and they enable it in the Launchpad web UI. If you want to subscribe to one of these lists, you join the team in question and you press the "Subscribe to mailing list" button. Launchpad runs the show and tells Mailman exactly what to do. So in fact we have all of Mailman's user interface disabled except for the list archives, and Postorius wouldn't come into it in our case - I probably shouldn't have confused things by bringing it up hypothetically.
We'd probably want to do roughly the same kind of thing with Mailman 3, at least to start with, though we may well want to make some of HyperKitty's advanced features work with single-sign-on integration. I haven't looked into that in any detail yet.
I can definitely see that both "preserve archives" vs. "hide archives" are potentially useful things to do.
It seems to me that dump, delete, and restore may be the best approach for the HyperKitty side because HyperKitty maintains all that state. Of course this could be done inside the database. Also, perhaps you can (ab)use the ArchivePolicy enum by adding an "inactive" element, but core has no way to enforce those on the archiver (which can be a third party host like mail-archive.com), and I'm not sure HyperKitty ever consults core about that once the archive is created.
I'd been thinking more of a new enum in HyperKitty for the visibility state, since it does seem like quite an archiver-specific thing. (Dump/delete/restore would of course be possible, but it's somewhat cumbersome to do externally and it seems like an odd way to go about things internally given the ability to change the DB schema.) I agree that not all archiver implementations can support this.
I'm not sure what you mean about IArchiver; as far as I can see that interface is sort of half-duplex: it provides the information core needs *about* the archiver to do core's side of archiving, not for core to communicate *with* the archiver. In fact all of the concrete code is callbacks provided by the archiver, and once a message is archived the core forgets about it. So this isn't "just" an extension; it's a fundamental redesign of IArchiver.
Well, IArchiver.archive_message sends a message from core to the archiver. I'd been thinking of something like IArchiver.set_list_visibility(mlist, visibility) which would send a message from core to the archiver to instruct it to show/hide the archives. It doesn't seem too out of line, though I'm not wedded to it either.
I suppose that one alternative could be that we handle this in a Launchpad-specific add-on to HyperKitty, since at a minimum we'll need some of our own code there to deal with sign-in for private lists. So the same bit of custom code that determines whether a list's archives are private could hide them from everyone except their owner, or even deny their existence entirely. It sounds like maybe we'd be better off pursuing that?
I'm not sure that's not a good thing, but we do need to think about it. ISTM we're gradually converging back on the monolithic approach to MLM, with the distribution, administration, and archiving quite tightly interwoven, and I'm not sure I like that. OTOH, we do get a lot of requests for ever more bundling.
Given our requirements, the decreased coupling in Mailman 3 is a very good thing, and I'm definitely not looking for more bundling. I hope I've clarified that above.
Thanks,
-- Colin Watson [cjwatson@ubuntu.com]