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

2016-03-23 Thread Harshit Bansal 
Hi Barry,

>The point of this break down is because some things (and it's not a perfect
>separation) really won't be shared between mailing lists.  OTOH, you might
>want site-wide bounce settings that all lists will inherit and shouldn't be
>able to change.  Other sub-styles give the list its "flavor", i.e. an open
>discussion list where anyone can join just by confirming their email, or a
>one-way announcement list that can't be unsubscribed from because it's an
>"all-employees" roster.

I already had this idea in my mind and that's why I have divided all
the styleable attributes into three categories:
1: Site owner level attributes.
2: Domain owner level attributes.
3: List owner level attributes.

Suppose attributes related to bounce-settings come into site owner
level attributes(I have not yet decided which attribute will fall in
which category) then only site-owners would be able to set them and
once these are set, the list owners would be having only two options.
Either apply the existing style as it is or create a sub-style and
adjust the list owner level(not site-owner level) attributes(to give
their list "flavor") and then apply it. This way they would be able to
make their list an "open discussion list" or an "one-way announcement
list" without being able to edit the bounce-settings.

Regards,
Harshit Bansal.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

2016-03-22 Thread Barry Warsaw 
On Mar 13, 2016, at 03:01 AM, Harshit Bansal wrote:

>Sorry, I think I have used wrong terminology here. By 'copying' I
>actually meant 'inheriting'.

Just a quick follow up to my previous comment about multiple inheritance.  I
was thinking about the way it's done in the Python code now, but even there, a
specific ordering is imposed (see LegacyDefaultStyle.apply() and
LegacyAnnounceOnly.apply()).

The point of this break down is because some things (and it's not a perfect
separation) really won't be shared between mailing lists.  OTOH, you might
want site-wide bounce settings that all lists will inherit and shouldn't be
able to change.  Other sub-styles give the list its "flavor", i.e. an open
discussion list where anyone can join just by confirming their email, or a
one-way announcement list that can't be unsubscribed from because it's an
"all-employees" roster.

I know this gets complicated quickly and I don't mean to throw a wrench into
things.  Harshit, I think you're essentially on the right track and Steve is
right that we should be careful not to overengineer the whole thing.  I think
you've got enough ideas, input, feedback, and comments to have plenty of fun
with it, and no doubt you'll discover a lot as you work out the details and
implementation.

Cheers,
-Barry


pgpxxLhBNXtH3.pgp
Description: OpenPGP digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

2016-03-12 Thread Harshit Bansal 
Hi,

On 3/12/16, Stephen J. Turnbull  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.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

2016-03-12 Thread Stephen J. Turnbull 
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.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

2016-03-11 Thread 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 te...@example.com
with ow...@example.com as site owner. Now, suppose the site
owner(ow...@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  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-b...@xemacs.org
> v2.honeypot.xemacs.org = rev 2 of style used for honey...@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

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

2016-03-09 Thread Stephen J. Turnbull 
Harshit Bansal writes:

 > 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.

Then there is no *permissions* system!  For example, one project last
year created a Javascript client -- that would completely bypass the
"permissions" system as you describe it.  You could imagine that style
changes are a "friendly users" feature, and so the "style owner"
system would be a *safety* feature of the Postorius UI rather than an
*authorization* feature of styles.  But in an enterprise context (eg,
a virtual hosting service), I'm sure that users will think of it as an
authorization system.  While at present it seems unlikely that there
would be multiple interfaces on one hosting service, you never know
what users will do[1].  Also, it would not be obvious to somebody who
installed the node.js Mailman client that they are likely bypassing
"security" as documented in the typical Mailman manuals and tutorials
that you would find on the web.

 > From UI point of view, there is one more feature that comes to my mind:
 > When the users are presented with an interface to customize the style,
 > we could provide them with two views, one 'simple' and another
 > 'advanced'. The 'simple' one would show only the *frequently* (or most
 > commonly) changed attributes while the 'advanced' one will show all
 > the attributes. This will help them in customizing the styles.
 > I would like to hear some of your comments on it as well.

Doing this well is a hard problem.  It seems to me that it is likely
that the "frequently changed attributes" will differ depending on the
base style.  Also, there's a "self-fulfilling prophecy" aspect: the
attributes that don't make it to the "simple" view will be less
discoverable, and of course they will be less frequently tweaked.

How about a "pluggable" page?  Ie, where site or domain admins can set
a list of items, which can be either a string (explanatory comment) or
a widget (a UI object permitting customization of one attribute or
perhaps a container for customizing several related attributes).  I
suspect you'll find that the current pages are already factored so
that it won't be too hard to accomplish this.  Of course we would
provide some initial lists that we think are good.

I think the time has come to think about adding feedback on our UI to
the UI.  Of course we won't do it behind the admin's back, nor default
it on, and we would allow admins to configure the information to be
sent.  But I think our user base would be pretty enthusiastic about
contributing things like customized UIs and list styles.

Footnotes:
[1] The Harvard Law: Under the most rigorously controlled conditions
of pressure, temperature, volume, humidity, and other variables,
the organism will do as it damn well pleases.
http://scienceblogs.com/clock/2007/05/15/and-now-the-scientists-will-do/
I think I've seen this attached to a person's name, and it would have
been in the early '70s, so predating the Usenet post.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

2016-03-09 Thread Barry Warsaw 
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


pgpun_XS3O1MK.pgp
Description: OpenPGP digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

2016-03-09 Thread Harshit Bansal 
Hi,
As per previous discussions, it would be nice to support style
hierarchies such that the list owners can compose them and defer
settings to values higher up, that would allow the core to define some
basic styles and then list owners can just tweak a few settings to
modify one of those base styles but in this case should the changes in
base-styles be propagated to all the styles that inherit it or not.
If we allow the propagation of changes to inheriting styles, some list
owners might be uncomfortable with this feature as then if any of the
base-style changes their inheriting styles will change without any
kind of prior notification.

>> In the back-end, we will be using tables for storing style attributes
>> and permission level(read only or editable). This table will basically
>> contain all the "stylable" attributes with "default or predefined"
>> values as contained in the mailing list table and one extra column for
>> permissions.

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.

>From UI point of view, there is one more feature that comes to my mind:
When the users are presented with an interface to customize the style,
we could provide them with two views, one 'simple' and another
'advanced'. The 'simple' one would show only the *frequently* (or most
commonly) changed attributes while the 'advanced' one will show all
the attributes. This will help them in customizing the styles.
I would like to hear some of your comments on it as well.

Thanks,
Harshit Bansal.


On 2/11/16, Abhilash Raj  wrote:
> On 02/10/2016 10:03 AM, Harshit Bansal wrote:
>> Hi Abhilash,
>> In our previous discussion you mentioned that :
>>
>>> Permissions should also consider if the user wants to make his new style
>>> public or keep it private. And should public styles be editable by
>>> anyone or just read-only?
>>
>> I am unable to think of a use case in which it will be useful to have
>> private styles.. Can you please suggest a suitable use case?
>
> Well, i agree there is nothing "private" in list styles. We could just
> make all styles read-only for everyone. But if someone wants to use the
> style created by other users, it would be better idea to first make them
> copy the style so that the behavior or their list doesn't change when
> the owner changes the style.
>
>
> Barry: If you have some time, I would like to hear some of your thoughts
> on this thread? I believe you have some ideas of your own on how this is
> supposed to work.
>
>>
>> Thanks,
>> Harshit Bansal.
>>
>
> --
> thanks,
> Abhilash Raj
>
>
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

2016-02-10 Thread Harshit Bansal 
Hi Abhilash,
In our previous discussion you mentioned that :

> Permissions should also consider if the user wants to make his new style
> public or keep it private. And should public styles be editable by
> anyone or just read-only?

I am unable to think of a use case in which it will be useful to have
private styles.. Can you please suggest a suitable use case?

Thanks,
Harshit Bansal.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

2016-02-10 Thread Abhilash Raj 
On 02/10/2016 10:03 AM, Harshit Bansal wrote:
> Hi Abhilash,
> In our previous discussion you mentioned that :
> 
>> Permissions should also consider if the user wants to make his new style
>> public or keep it private. And should public styles be editable by
>> anyone or just read-only?
> 
> I am unable to think of a use case in which it will be useful to have
> private styles.. Can you please suggest a suitable use case?

Well, i agree there is nothing "private" in list styles. We could just
make all styles read-only for everyone. But if someone wants to use the
style created by other users, it would be better idea to first make them
copy the style so that the behavior or their list doesn't change when
the owner changes the style.


Barry: If you have some time, I would like to hear some of your thoughts
on this thread? I believe you have some ideas of your own on how this is
supposed to work.

> 
> Thanks,
> Harshit Bansal.
> 

-- 
thanks,
Abhilash Raj



signature.asc
Description: OpenPGP digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

2016-01-30 Thread Harshit Bansal 
Hi Steve,

On 1/27/16, Stephen J. Turnbull  wrote:
> Harshit Bansal writes:
>
>  > Figure out how to store and access the styles as some of them are
>  > defined in the source code and the ones created by the by users would
>  > have to be stored in databases?
>
> You also need a read/print repr.  A Python dict may be a reasonable
> one, but JSON, YAML, init, etc could all be considered.
>

I am planning to use dictionary.

>  > Styles will be stored in database in a dedicated table.
>
> You may want more than one table.  Or you may be able to store them in
> the same table as currently used for list configs, with that table
> updated to allow "unstyled" as a value for its columns.  (List id,
> for example, would be "unstyled", since it is supposed to be globally
> unique.  Probably list name should be too, but domain would very
> likely be styled.)
>
>  > The style manager will update all the styles 'predefined in the
>  > source code' as well as the styles 'defined by users(by
>  > implementing the IStyle interface)' to the database. Currently we
>  > define a list of python import paths which are used for styles.
>
> Do you mean "configs"?
>
>  > These will be collected in the style manager and then updated in
>  > the database. These styles will be publicly viewable but the users
>  > wouldn't be able to modify/change them(using Postorius) otherwise
>  > we would have to update those changes in the files as well.
>
> I don't understand why you wouldn't be able to modify them.  The
> presets probably should be read-only, and you might want to have a
> permissions system such that only the owner of the style can change
> it.  Others would need to copy the style, modify the copy, and then
> apply it to their own lists.
>

Here, I meant to say that the 'predefined-styles' would be
read-only(not modifiable) while the style defined by the user(using
Postorius) would be readable/editable as per the permissions system.

>  > Should we even allow changing list styles after lists have been
>  > created?
>
> Certainly.  Consider the case where a dramatic improvement in MUAs
> commonly used by a subscriber base makes it possible to use Wrap
> Message instead of Munge From as DMARC mitigation.  You want to change
> all your lists in one go if they all have the same subscriber base
> (consider an enterprise setting where the subscribers are mostly using
> enterprise webmail).
>
>  > Does changing a list style in database/source code changes
>  > the settings for list?
>
> IMO, yes.  But source code changes by the Mailman Project would not be
> allowed, except with a looong deprecation/obsoletion cycle, and source
> code changes should be documented as an operation with potential (bad)
> surprises for users.
>
>  > I think there is no valid reason to not to allow changing list styles
>  > after they have been created but there are two attributes about which
>  > I am not sure these are:
>  > 1: default_member_action
>  > 2: default_nonmember_action
>  > The value of these style attributes are first copied to
>  > 'member.moderation_action'(moderation_action column of member table)
>  > and then this saved value is used to decide the correct moderation
>  > action. So changing the value of 'default_member_action' and
>  > 'default_nonmember_action' have no effect on the saved values and
>  > these will not change. This will have an undesired effect.
>
> I think that this is not a problem.  We need to initialize all
> attributes to valid values, and this will probably be hard-coded in
> the source.  Then we overlay this with site styles, domain styles,
> list styles, and user attributes, and do the lookup in the opposite
> order.  In principle, for each attribute you would drill down as long
> as the value at the current level is "unstyled".  In practice, you'd
> keep a cache of the current results of such lookups for users and
> lists to avoid slamming the database, and some way of identifying when
> the cache is out of date (such as a change "generation counter").
> Note that this explains some of the reason why source code changes
> need to be treated with care -- in some sense they are always
> "generation 0" because it's impossible to know in advance what
> generation the installlation is at.
>
>  > So I think whenever a user changes these two attributes then we
>  > will have to ask the user if he wants to change the saved values or
>  > not. Another approach could be to leave these values unchanged and
>  > bring this behavior to the knowledge of the user and if he wants
>  > then he can manually change the moderation action of some selected
>  > members but new members will automatically have their
>  > moderation_action set to new the values.
>
> This is the current behavior for default_* actions; I don't see why it
> would change with the introduction of styles.
>

I wanted to ask that what should be the behavior when a user changes
the 'default_member_action' and

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

2016-01-30 Thread Abhilash Raj 


On 01/30/2016 11:11 AM, Harshit Bansal wrote:
> Hi Steve,
> 
> On 1/27/16, Stephen J. Turnbull  wrote:
>> Harshit Bansal writes:
>>
>>  > Figure out how to store and access the styles as some of them are
>>  > defined in the source code and the ones created by the by users would
>>  > have to be stored in databases?
>>
>> You also need a read/print repr.  A Python dict may be a reasonable
>> one, but JSON, YAML, init, etc could all be considered.
>>
> 
> I am planning to use dictionary.

What exactly I meant here was not a data structure but *how*? The data
structure could simply be dictionary, but how would you populate the
existing styles in the code? Notice that there is already an existing
IStyle interface in the mailman right now, can you modify it somehow to
dynamically update/fetch/store styles from the database instead of
creating a new structure altogether?

Barry: Is there a reason the styles in the src/styles/base.py are not an
implementation of IStyle interface?

If I am not wrong, you can define the styles in configuration too apart
from the source code, so how do you pull those and update the database
during the initialization?

This is not a difficult question I want an answer to right now, just
that the application should have implementation details too, even if
they are a rough sketch.
> 
>>  > Styles will be stored in database in a dedicated table.
>>
>> You may want more than one table.  Or you may be able to store them in
>> the same table as currently used for list configs, with that table
>> updated to allow "unstyled" as a value for its columns.  (List id,
>> for example, would be "unstyled", since it is supposed to be globally
>> unique.  Probably list name should be too, but domain would very
>> likely be styled.)
>>
>>  > The style manager will update all the styles 'predefined in the
>>  > source code' as well as the styles 'defined by users(by
>>  > implementing the IStyle interface)' to the database. Currently we
>>  > define a list of python import paths which are used for styles.
>>
>> Do you mean "configs"?
>>
>>  > These will be collected in the style manager and then updated in
>>  > the database. These styles will be publicly viewable but the users
>>  > wouldn't be able to modify/change them(using Postorius) otherwise
>>  > we would have to update those changes in the files as well.
>>
>> I don't understand why you wouldn't be able to modify them.  The
>> presets probably should be read-only, and you might want to have a
>> permissions system such that only the owner of the style can change
>> it.  Others would need to copy the style, modify the copy, and then
>> apply it to their own lists.
>>
> 
> Here, I meant to say that the 'predefined-styles' would be
> read-only(not modifiable) while the style defined by the user(using
> Postorius) would be readable/editable as per the permissions system.

You may want to expand more on the *permissions system* in you
application as that is an important part of this. Also, how are you
going to propagate that to the Postorius via the API.

> 
>>  > Should we even allow changing list styles after lists have been
>>  > created?
>>
>> Certainly.  Consider the case where a dramatic improvement in MUAs
>> commonly used by a subscriber base makes it possible to use Wrap
>> Message instead of Munge From as DMARC mitigation.  You want to change
>> all your lists in one go if they all have the same subscriber base
>> (consider an enterprise setting where the subscribers are mostly using
>> enterprise webmail).
>>
>>  > Does changing a list style in database/source code changes
>>  > the settings for list?
>>
>> IMO, yes.  But source code changes by the Mailman Project would not be
>> allowed, except with a looong deprecation/obsoletion cycle, and source
>> code changes should be documented as an operation with potential (bad)
>> surprises for users.
>>
>>  > I think there is no valid reason to not to allow changing list styles
>>  > after they have been created but there are two attributes about which
>>  > I am not sure these are:
>>  > 1: default_member_action
>>  > 2: default_nonmember_action
>>  > The value of these style attributes are first copied to
>>  > 'member.moderation_action'(moderation_action column of member table)
>>  > and then this saved value is used to decide the correct moderation
>>  > action. So changing the value of 'default_member_action' and
>>  > 'default_nonmember_action' have no effect on the saved values and
>>  > these will not change. This will have an undesired effect.
>>
>> I think that this is not a problem.  We need to initialize all
>> attributes to valid values, and this will probably be hard-coded in
>> the source.  Then we overlay this with site styles, domain styles,
>> list styles, and user attributes, and do the lookup in the opposite
>> order.  In principle, for each attribute you would drill down as long
>> as the value at the current level is "unstyled".  In practice,

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

2016-01-30 Thread Stephen J. Turnbull 
Abhilash Raj writes:

 > I *think* we have had a discussion before about what should be a better
 > default value for member.moderation_action and
 > nonmeember.moderation_action. Instead of just copying them to the field,
 > we could set it to defer in which it case the lookup automatically picks
 > up the value of the list's default_(non)member_action.
 > 
 > Or we could *always* copy the default styles to a new style that the
 > list owner owns and can use for his other lists.

These somewhat analogous to "deep binding" and "shallow binding"
(actually they should be called "deep lookup" and "shallow lookup") in
Lisp implementation.  They can have the same semantics (Mailman can
choose, the point of using Lisp as an example is that the semantics
are defined by the language definition and the implementation must
match that definition), but shallow binding requires more care in
implementation (the binding is basically a cache).  I think probably
shallow binding is the way to go because changing these values is much
less frequent than referencing them.

 > > I wanted to ask that what should be the behavior when a user changes
 > > the 'default_member_action' and 'default_nonmember_action' attributes.
 > > Since, the values of these attributes are copied to the
 > > 'member.moderation_action' at the time of the creation of a new
 > > member. So, any changes made to the 'default_member_action' and
 > > 'default_nonmember_action' attributes will not be reflected in the
 > > already created members which I think may not be the desirable
 > > behavior.

This is easy.  Just think about what happens if you change the
creation default from unmoderated to moderated, and automatically copy
that to an existing list.  Would you want to be that list owner?

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

2016-01-26 Thread Harshit Bansal 
Hi Abhilash,

I liked your idea of providing the users the capability to copy and
customize the existing styles very much. Additionally, when the users
are presented with an interface to customize the style, we could
provide them with two views, one 'simple' and another 'advanced'. The
'simple' one would show only the *frequently*(or most commonly)
changed attributes while the 'advanced' one will show all the
attributes. This will help them in customizing the style.

I think the major challenges that you pointed out in the last email
can be addressed as follows:

Figure out how to store and access the styles as some of them are
defined in the source code and the ones created by the by users would
have to be stored in databases?
Styles will be stored in database in a dedicated table. The style
manager will update all the styles 'predefined in the source code' as
well as the styles 'defined by users(by implementing the IStyle
interface)' to the database. Currently we define a list of python
import paths which are used for styles. These will be collected in the
style manager and then updated in the database. These styles will be
publicly viewable but the users wouldn't be able to modify/change
them(using Postorius) otherwise we would have to update those changes
in the files as well. However, as per your suggestion they will have
the option to copy and customize them as per their needs.
This way of implementation would make the database a centralized place
to store the styles and to access them and would be faster and safer
than the file based approach.

Should we even allow changing list styles after lists have been
created? Does changing a list style in database/source code changes
the settings for list?
I think there is no valid reason to not to allow changing list styles
after they have been created but there are two attributes about which
I am not sure these are:
1: default_member_action
2: default_nonmember_action
The value of these style attributes are first copied to
'member.moderation_action'(moderation_action column of member table)
and then this saved value is used to decide the correct moderation
action. So changing the value of 'default_member_action' and
'default_nonmember_action' have no effect on the saved values and
these will not change. This will have an undesired effect. So I think
whenever a user changes these two attributes then we will have to ask
the user if he wants to change the saved values or not. Another
approach could be to leave these values unchanged and bring this
behavior to the knowledge of the user and if he wants then he can
manually change the moderation action of some selected members but new
members will automatically have their moderation_action set to new the
values.
Currently, changing a style in source code doesn't changes the
settings for list that inherits it.

See what happens when a style is changed now? Is it propagated down to
the list or only the new list inherits that?
Presently when a style is changed, only the new list that inherits it
is affected and the change is not propagated down to the old lists
that inherits it.
As of now there is no way to change a style without changing the
source code. Also the styles are applied to a mailing list only during
the creation time and after this there is no way to change the style
of a list. After this project, the users will be able to change the
styles without modifying the source code(using Postorius) and the
lists that inherit those changes will automatically be updated to
reflect those changes.

How to apply styles to lists after they have been created?
I will expose the styles via REST API. Whenever the user(admin) will
change a mailing list's style in Postorius, it will automatically call
'new_style.apply()' function which will update the mailinglist table
with the new values. This will change the list style.
If a style is changed by a user using Postorius, then the Postrius
will forward the request to the style manager via the REST API which
apart from updating the 'style' table will also update the
'mailinglist' table such that the old mailing lists which inherited
the changed style will also reflect the changes.


After implementing all these things, there will be two ways to create
and update styles :
1: Using Postorius
2: By defining a class implementing the IStyle interface and saving it
to a file.

Here, I am unable to figure out that if an user creates or modifies a
style using method 2 then how the mailman can be notified of the
change?

Thanks,
Harshit Bansal
IRC NICK : _Harshit_

On 1/18/16, Abhilash Raj  wrote:
> Hi Harshit,
>
> On 01/17/2016 09:22 AM, Harshit Bansal wrote:
>> Hi everybody,
>> I was looking at GSOC 2016 wiki page and I found "Preset List Settings
>> Templates" project quite interesting.
>>
>> After reading out the project description and the discussion on the
>> project from the mail archives I have been able to reach out the
>> following conclusion :
>> I

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

2016-01-26 Thread Stephen J. Turnbull 
Harshit Bansal writes:

 > Figure out how to store and access the styles as some of them are
 > defined in the source code and the ones created by the by users would
 > have to be stored in databases?

You also need a read/print repr.  A Python dict may be a reasonable
one, but JSON, YAML, init, etc could all be considered.

 > Styles will be stored in database in a dedicated table.

You may want more than one table.  Or you may be able to store them in
the same table as currently used for list configs, with that table
updated to allow "unstyled" as a value for its columns.  (List id,
for example, would be "unstyled", since it is supposed to be globally
unique.  Probably list name should be too, but domain would very
likely be styled.)

 > The style manager will update all the styles 'predefined in the
 > source code' as well as the styles 'defined by users(by
 > implementing the IStyle interface)' to the database. Currently we
 > define a list of python import paths which are used for styles.

Do you mean "configs"?

 > These will be collected in the style manager and then updated in
 > the database. These styles will be publicly viewable but the users
 > wouldn't be able to modify/change them(using Postorius) otherwise
 > we would have to update those changes in the files as well.

I don't understand why you wouldn't be able to modify them.  The
presets probably should be read-only, and you might want to have a
permissions system such that only the owner of the style can change
it.  Others would need to copy the style, modify the copy, and then
apply it to their own lists.

 > Should we even allow changing list styles after lists have been
 > created?

Certainly.  Consider the case where a dramatic improvement in MUAs
commonly used by a subscriber base makes it possible to use Wrap
Message instead of Munge From as DMARC mitigation.  You want to change
all your lists in one go if they all have the same subscriber base
(consider an enterprise setting where the subscribers are mostly using
enterprise webmail).

 > Does changing a list style in database/source code changes
 > the settings for list?

IMO, yes.  But source code changes by the Mailman Project would not be
allowed, except with a looong deprecation/obsoletion cycle, and source
code changes should be documented as an operation with potential (bad)
surprises for users.

 > I think there is no valid reason to not to allow changing list styles
 > after they have been created but there are two attributes about which
 > I am not sure these are:
 > 1: default_member_action
 > 2: default_nonmember_action
 > The value of these style attributes are first copied to
 > 'member.moderation_action'(moderation_action column of member table)
 > and then this saved value is used to decide the correct moderation
 > action. So changing the value of 'default_member_action' and
 > 'default_nonmember_action' have no effect on the saved values and
 > these will not change. This will have an undesired effect.

I think that this is not a problem.  We need to initialize all
attributes to valid values, and this will probably be hard-coded in
the source.  Then we overlay this with site styles, domain styles, 
list styles, and user attributes, and do the lookup in the opposite
order.  In principle, for each attribute you would drill down as long
as the value at the current level is "unstyled".  In practice, you'd
keep a cache of the current results of such lookups for users and
lists to avoid slamming the database, and some way of identifying when
the cache is out of date (such as a change "generation counter").
Note that this explains some of the reason why source code changes
need to be treated with care -- in some sense they are always
"generation 0" because it's impossible to know in advance what
generation the installlation is at.

 > So I think whenever a user changes these two attributes then we
 > will have to ask the user if he wants to change the saved values or
 > not. Another approach could be to leave these values unchanged and
 > bring this behavior to the knowledge of the user and if he wants
 > then he can manually change the moderation action of some selected
 > members but new members will automatically have their
 > moderation_action set to new the values.

This is the current behavior for default_* actions; I don't see why it
would change with the introduction of styles.

 > How to apply styles to lists after they have been created?  I will
 > expose the styles via REST API. Whenever the user(admin) will
 > change a mailing list's style in Postorius, it will automatically
 > call 'new_style.apply()' function which will update the mailinglist
 > table with the new values. This will change the list style.

Be careful here.  Since some styles percolate up to user level, a site
with hundreds of thousands of lists and millions of users (they
exist!) could really slam the database.  The whole system would grind
to a halt.

 > After implementing all these

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

2016-01-17 Thread Abhilash Raj 
Hi Harshit,

On 01/17/2016 09:22 AM, Harshit Bansal wrote:
> Hi everybody,
> I was looking at GSOC 2016 wiki page and I found "Preset List Settings
> Templates" project quite interesting.
> 
> After reading out the project description and the discussion on the
> project from the mail archives I have been able to reach out the
> following conclusion :
> I will be required to develop a Web Interface that will allow the
> admins to set the different attributes to the different mailing lists
> using some fixed templates(also known as styles). Not only this they
> will be able to define their own styles and use them. This will serve
> as our front-end.

Your understanding is actually good, but more generic as of now. Styles
are the term used in Mailman to accumulate a certain list of
list-settings that change the behavior of the list. There are some
pre-defined styles like "Announce", "General", "Moderation" etc that you
can find in src/mailman/styles/base.py in the mailman-core source code[1].

Right now, styles can only be applied to a mailing list when they are
created. And there is no way right now to create new styles without
modifying the source code. The official Web UI for Mailman is called
Postorius and talks to the mailman-core via HTTP REST API. So you'd have
to expose the styles via REST API and then implement it in the Postorius
(which is a Django application).

Some major challenges for your project (not exhaustive) that I would
like to see addressed in the application are:

1) Figure out how to store and access the styles as some of them are
defined in the source code and the ones created by users would have to
be stored in database.

2) How to apply styles to lists after they have been created?

3) Should we even allow changing list styles after lists have been
created? Does changing a style in database/source code change the
settings for list?

4) See what happens when a style is changed now? Is it propagated down
to the lists or only the new lists inherit that?

> In the back-end, we will be using tables for storing style attributes
> and permission level(read only or editable). This table will basically
> contain all the "stylable" attributes with "default or predefined"
> values as contained in the mailing list table and one extra column for
> permissions.

Permissions should also consider if the user wants to make his new style
public or keep it private. And should public styles be editable by
anyone or just read-only?

One useful feature I can think of from the UI point of view is to be
able to copy an existing style to create a new style and then present
with the interface to customize the new style.

> There will also be some back-end python code whose key function would
> be to read the attribute values from the styles table and when the
> user applies a style on a mailing list it will copy the attribute
> values from the style table to that particular mailing list's table.

This "back-end" code is usually a part of Mailman-Core which takes care
of all the actual logic and mail processing.

> 
> Please do correct me if I am wrong somewhere. Also,I wish to seek your
> views on this approach.
> 
> Also tell me if I would need to develop a Command Line Interface(which
> I will love to develop) as well or only Web Interface would suffice?

I think an integration with Postorius would be sufficiently big for a
Summer. We already have a command line interface for mailman that can be
extended to add this functionality.


[1]: https://gitlab.com/mailman/mailman


-- 
thanks,
Abhilash Raj



signature.asc
Description: OpenPGP digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9