Re: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" .
Thanks for following up here Harshit. Here are some of my thoughts/ramblings.
On Mar 09, 2016, at 10:51 PM, Harshit Bansal wrote:
I think the "Permissions Systems" would have nothing to do with the core. It would be related to Postorius. We will have to create a style model separately in Postorius which would store the style name and the user who created it. Then only the user who has created the style would be granted the permission to edit it.
Mailing lists have a clear ownership chain.
At the top is the system administrator who has access to the shell. They get to do things no one else can, such as create Python files. Ultimately, they should be able to create immutable styles which serve as the baseline for all other style options. These are immutable because they are defined in Python code.
The sysadmin can delegate style customizations to the server/site owner, which
is a defined role in the core's model. The IUser interface defines a flag
is_server_owner to define this permission.
The server owners can delegate to domain owners. The IDomain interface has a
owners attribute which can contain users that have this permission.
Domain owners can then delegate to list owners, and of course there is an
owners attribute on the IMailingList interface. Mailing lists also have
moderators but those users wouldn't have permission to change list styles.
Here's where it gets complicated. At each level, it should be possible to say "I delegate settings X, Y, and Z to the level below and they can change it to anything they want." But they should also be able to say, "I do not allow the level below to change settings A, B, and C." For example, a domain owner might say, "you list owners can change your welcome messages to anything you want, but you cannot change the footers because for legal reasons this text must appear on every message."
So you have several things you want to be able to specify about each attribute in a style. You want to be able to delegate permission to change a style attribute going down the hierarchy, but you also want to be able to have any particular style attribute delegate its value up the hierarchy. E.g. a list owners could say "I don't really care about the filter_types, just use whatever is in the parent style."
It's likely that the permissions would only be enforced in Postorius, although we can think about how the core would enforce the permissions. The core would definitely support the deferring of style values back up to parent styles.
One other thing to think about is whether some styles will be allowed or disallowed for various domains or mailing lists. E.g. should some styles only be allowed for example.com and others for example.org, or can all of them be allowed for any mailing list on the system? I think at the very least, some segregation based on domain would be useful.
Cheers, -Barry
Barry Warsaw writes:
It's likely that the permissions would only be enforced in Postorius, although we can think about how the core would enforce the permissions.
I don't insist on core enforcement, though I think it desirable. I do ask that this functionality not be called "permission" if core doesn't enforce it. (Details in earlier reply to Harshit.)
One other thing to think about is whether some styles will be allowed or disallowed for various domains or mailing lists.
I think this would be very convenient, but could be handled purely as visibility control (after all, you can reconstruct any style attribute by attribute unless prohibited in mm_cfg.py, but that's instance-wide anyway). Eg, a dotted name would be used as a str.endswidth filter, and the convention would be to name styles according to List-Id, with multiple styles or versions being "subdomains" of List-Id. The domains example.net (season to taste) and distribution.list.org would be special, corresponding to anonymous styles and the GNU Mailman distribution, respectively. So typical names of styles would be
xemacs-beta.xemacs.org = style used for xemacs-beta@xemacs.org
v2.honeypot.xemacs.org = rev 2 of style used for honeypot@xemacs.org
spam-fierce.example.net = a style containing spam filter
configuration, but the admin doesn't want the name to give
away which lists use it
anonymous.distribution.list.org = Mark's recommendation for
anonymous list configuration
announce.distribution.list.org = Mark's recommendation for
anouncement list configurationand typical filters would be
.xemacs.org
.example.net
.distribution.list.orgwith the default being empty. Both style naming UI and available style lists could suppress the filter, and the convention would make it easy to copy a list's style.
The special treatment of example.net is pretty clearly over-engineering, but the information leakage that motivates it represents the only reason I can think of for worrying about availability of styles.
Since endswidth would be used to filter, you wouldn't have to break at dots, but I think that would be intuitive to users.
The whole scheme is probably over-engineered, but maybe somebody can bend it into something that's not too horrible. :-) The main advantage to it is that each list would implicitly name its own configuration. You would only need to explicitly choose a name when you want something more generally descriptive, but hopefully most generic styles will be in the Mailman distribution.
I think at the very least, some segregation based on domain would be useful.
I do agree with that.
Steve
Hi everyone, First of all, I would like to thank Barry and Steve for giving their valuable comments due to which I have been able to workout the "Permission model" from the very scratch, the details of which are as follows: 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. 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. 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. 2: Domain owner level : Site owners as well as domain owners can edit these attributes. 3: List owner level : Site owners as well as domain owners as well as list administrators will have the permissions to edit these attributes.
Let us consider a domain example.com with a list test1@example.com with owner@example.com as site owner. Now, suppose the site owner(owner@example.com) creates a style named 'foo'. Now the domain owner of example.com will have two options, either he can edit(if the style is editable) domain owner and list owner level attributes and then can delegate to list owners or if the style is read-only then they can copy the style to have a new style 'foo1', make necessary changes and then delegate to the list owners. Now the list owners can either apply 'foo' or foo1' or create their own customizations and apply them.
@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.
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.
Further comments/suggestions are welcomed.
Thanks, Harshit Bansal.
On 3/10/16, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Barry Warsaw writes:
It's likely that the permissions would only be enforced in Postorius, although we can think about how the core would enforce the permissions.
I don't insist on core enforcement, though I think it desirable. I do ask that this functionality not be called "permission" if core doesn't enforce it. (Details in earlier reply to Harshit.)
One other thing to think about is whether some styles will be allowed or disallowed for various domains or mailing lists.
I think this would be very convenient, but could be handled purely as visibility control (after all, you can reconstruct any style attribute by attribute unless prohibited in mm_cfg.py, but that's instance-wide anyway). Eg, a dotted name would be used as a str.endswidth filter, and the convention would be to name styles according to List-Id, with multiple styles or versions being "subdomains" of List-Id. The domains example.net (season to taste) and distribution.list.org would be special, corresponding to anonymous styles and the GNU Mailman distribution, respectively. So typical names of styles would be
xemacs-beta.xemacs.org = style used for xemacs-beta@xemacs.org v2.honeypot.xemacs.org = rev 2 of style used for honeypot@xemacs.org spam-fierce.example.net = a style containing spam filter configuration, but the admin doesn't want the name to give away which lists use it anonymous.distribution.list.org = Mark's recommendation for anonymous list configuration announce.distribution.list.org = Mark's recommendation for anouncement list configurationand typical filters would be
.xemacs.org .example.net .distribution.list.orgwith the default being empty. Both style naming UI and available style lists could suppress the filter, and the convention would make it easy to copy a list's style.
The special treatment of example.net is pretty clearly over-engineering, but the information leakage that motivates it represents the only reason I can think of for worrying about availability of styles.
Since endswidth would be used to filter, you wouldn't have to break at dots, but I think that would be intuitive to users.
The whole scheme is probably over-engineered, but maybe somebody can bend it into something that's not too horrible. :-) The main advantage to it is that each list would implicitly name its own configuration. You would only need to explicitly choose a name when you want something more generally descriptive, but hopefully most generic styles will be in the Mailman distribution.
I think at the very least, some segregation based on domain would be useful.
I do agree with that.
Steve
participants (3)
-
Barry Warsaw -
Harshit Bansal -
Stephen J. Turnbull