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

Harshit Bansal writes:
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.)
Do you mean "configs"?
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 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.
This is the current behavior for default_* actions; I don't see why it would change with the introduction of styles.
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.
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

Hi Steve,
On 1/27/16, Stephen J. Turnbull <stephen@xemacs.org> wrote:
I am planning to use dictionary.
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.
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.
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_

Hi Steve,
On 1/27/16, Stephen J. Turnbull <stephen@xemacs.org> wrote:
I am planning to use dictionary.
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.
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.
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_
participants (2)
-
Harshit Bansal
-
Stephen J. Turnbull