Harshit Bansal writes:
Basically, a style will be having three levels of viewability: 1: System wide : A style having this level of viewability will be visible to all the domains as well as the lists. It will be available to all the list owners for copying however the site owners will have the option to make it either read-only or editable.
I don't see a real advantage to having this editable by list owners, since it's copyable. On the other hand, "styles" are not just display, but also include security/privacy features. Eg, a rogue editor could DoS the whole site by adding .* as a ban or discard expression in spam filtering. I think probably it's OK to have styles editable only by owner. However, the owner might be a group of users.
How about inheritability? The difference between inheritance and copying is that if the template changes, with inheritance the derived configurations change too, with copying they don't.
2: Domain Wide : A style having this level of viewability will be visible to all the lists within a specific domain. However, the domain owners would have the option to make it read-only or editable.
Same as above.
3: List Specific : A style having this level of viewability will be visible to a specific list.
Not only this, all stylable attributes will be divided into three categories: 1: Site owner level attributes : Only site owners will have the permissions to edit these attributes.
As above, "owner" should be allowed to be a group.
2: Domain owner level : Site owners as well as domain owners can edit these attributes.
Ditto.
3: List owner level : Site owners as well as domain owners as well as list administrators will have the permissions to edit these attributes.
@Steve I think this system also addresses the issues that you pointed as now all the permissions will be enforced in the mailman core instead of Postorius.
Yes.
Also while working out the implementation details, I came across a new problem which is as follows: Suppose, we have three style A, B and C. B inherits from A and C inherits from B. Now, suppose someone decides to delete style B then how can we deal with this situation.
Persistence across Mailman restarts of course needs to be carefully dealt with, but we deal with the basic issue in the usual Unix way: a style which is "deleted" just loses its entry in the admin-visible directory of styles, but it is not actually deleted from the database until all references are gone.