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

[Harshit Bansal]

Hi Steve,

On 1/27/16, Stephen J. Turnbull <stephen at xemacs.org> 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 '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.
Please do correct me if am wrong somewhere.

>  > 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 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.
>
> I don't see why you would allow 2 at all.  IStyle is an internal
> thing, which would be used to provide a Python interface to the
> database backend.  Unless you're thinking of dynamic styles (eg,
> theming the list page according to day of week or server load :-)?
>

Earlier, I was thinking to implement a way to add new styles using
Postorius as well as by adding a file to the source code containing a
class implementing the 'IStyle' interface to define the new style. But
now I have dropped this idea as I think that it would not be that
useful.

> Steve
>

Thanks,
Harshit Bansal.
IRC Nick : _Harshit_