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

[Harshit Bansal]

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 at example.com
with owner at example.com as site owner. Now, suppose the site
owner(owner at 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 at 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 at xemacs.org
>     v2.honeypot.xemacs.org = rev 2 of style used for honeypot at 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 configuration
>
> and typical filters would be
>
>     .xemacs.org
>     .example.net
>     .distribution.list.org
>
> with 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
>