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?
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.
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).
OK. I'll think about this.
Steve