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

Harshit Bansal harshitbansal2015 at gmail.com
Sat Mar 12 15:31:17 EST 2016


Hi,

On 3/12/16, Stephen J. Turnbull <stephen at 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.


More information about the Mailman-Developers mailing list