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

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.

-- thanks, Abhilash Raj

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

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.

-- thanks, Abhilash Raj