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

[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 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 :-)?

Steve