Re: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" .
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.
Hi,
On 3/12/16, Stephen J. Turnbull <stephen@xemacs.org> wrote:
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.
Yes I also agree with you. I am refining this system as follows: Suppose there is a style A having a domain level viewability. Then only site owners and domain owners would be allowed to edit it. The list owners would have the option to either apply as it is or copy and modify it. Basically, a user at the same or upper level would be able to edit the style. The users at the lower level would have to copy the style if they want to change it.
However, the owner might be a group of users.
Yeah, I am actually assuming them to 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.
Sorry, I think I have used wrong terminology here. By 'copying' I actually meant 'inheriting'.
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.
Indeed a great idea. The unused styles will garbage collected at regular intervals.
Also, the way in which we now store and categorise styles has made them very much analogous to the members of a list. So, should a "roster" like functionality for searching and retrieving the styles be implemented just like it is implemented for members?
Thanks, Harshit Bansal.
participants (2)
-
Harshit Bansal -
Stephen J. Turnbull