- Stephen J. Turnbull (turnbull.stephen.fw@u.tsukuba.ac.jp) [210523 02:41]:
Andreas Barth writes:
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.
That much is clear. The problem is that "access to list" can mean a lot of things: can subscribe, can post, can admin, can view archives, can view list in listinfo, can view subscriber list, and there are probably others. What permissions are needed for what general classes of users?
public: anyone can subscribe and read the archive. Think about an announcement mailing list of an organisation.
restricted: for employees (or members - or whatever) only. So they could subscribe themself. The archive and posting may be restricted to subscribers or to anyone in that group - both would be working for me. (How to know who is allowed to subscribe is another question - having an internal mailing list which contains all the members just for this purpose would be ok for me.)
private: hand-selected people, think about e.g. board or steering committees internal discussions. Of course, the archive (if there is any) should be restricted to the actual members. Posting to these lists is currently not restricted, so no derivation needed from the current set in postorius.
Just as an idea, how about always one "custom attributes" field. So that from a database pov this field is always there.
We could do that, but then we'd have to support it. I'm thinking of situations like admin A populates the field, then leaves the organization, and we add (some of) the supported features, and admin B wants to migrate that. I don't see any good coming of that for us. As Mark says, a separate table seems like the way to go for custom attributes.
Well, that problem will always exist. I don't think you would make it harder by having one "custom attributes" field.
I'm going to try the plugin route Mark suggested.
Andi