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

[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 <raj.abhilash1 at gmail.com> 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 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
>
>