Andreas Barth writes:
I need to add custom attributes to the mailing lists:
It's a rather different use case, but Systers Mailman contains extensive modifications including Systers-specific attributes. Might be a useful example (although I don't know how recently they've merged from mainline. ISTR the last time this came up the Systers repo had moved and it wasn't clear where. Try a quick Google and if no joy, I can probably put you in touch with somebody who has a clone.
Enhance the boolean public to a tri-state: public, restricted audience and private (restricted audience means: some people could subscribe themself
I'm not sure tri-state is a good idea. The boolean public controls visibility of the list in listinfo pages. I'm not sure if combining that with who-can-subscribe logic is safe, and there are pending RFEs to change the visibility logic, which might cause you annoyance at upgrade. I also am not sure it's a *bad* idea :-), although I suspect if we were to add the feature to our distribution, we'd probably implement as a per-list check for permission (this could be a list of Users, a list of Addresses, or a function to be called with one or the other).
- of course this could also be implemented as a second boolean that e.g. splits "not public" into "restricted audience" and "private" (means: nothing goes wrong for code that doesn't know this difference).
Exactly my concern.
Any hints how to do that best? Is it possible to store custom attributes, or should that be stored elsewhere?
No, I don't think there's provision for custom attributes in core. Of course you could change the database schema, but you'd have to provide a migration for that. Migrations for somebody else's custom attributes being a hard thing to automate on our side, we don't provide for them.
Does this need to be implemented in core (eg, because restricted audience users would subscribe by mail), or could you get away with a modification to Postorius only?