[Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" .

Stephen J. Turnbull stephen at xemacs.org
Sat Mar 12 11:19:24 EST 2016


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.



More information about the Mailman-Developers mailing list