- Stephen J. Turnbull (turnbull.stephen.fw@u.tsukuba.ac.jp) [210522 14:33]:
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.
Thanks, I'll give it a try.
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
Perhaps I expressed it badly.
Currently it is "list public" vs "subscribers only". I need something inbetween, so that some (i.e. most) people have access to the restricted audience lists but not just everybody.
, 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).
That would be working for me as well.
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.
Just as an idea, how about always one "custom attributes" field. So that from a database pov this field is always there. In that field, the attributes could then be stored as e.g. json (which is of course a bit worse from performance than multiple entries, but well). Rest would give access to this field, but anything else is really up to the local implementation?
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?
It could be done in postorius - the restriction that subscribing by mail needs moderators action would be ok (or if it annoys me, this part be move to a cron job).
Andi