Re: [Mailman-Developers] GSOC'15: Improving styles for lists
Hi Prakhar,
I see that you mentioned below the details of our conversation, but the language looks confusing to me. Please look out for simple mistakes in your English before sending the mail, not just here but anywhere.
On Friday 20 March 2015 12:37 PM, prakhar joshi wrote:
hi, For the storage of list we will have table for list styles and when the admin creates a new list he/she will edit some attributes of particular list. By attribute I mean the options under each mailing list style like announce list have "allow list post". Admin can change there values.
You meant 'their' here and not 'there'.
style table will have all the attributes(same attributes that are listed in mailing list table) in column but the values of attributes that user will change will be stored in the table and rest values will be null. With improving the "apply" method for styles we can over write the present settings of the mailing list. I hope this is making sense to you ?
What he means to say is we can create a generic Style class, another implementation of IStyle interface which instead of having static values of attributes like existing styles would have methods to dynamically fetch the stored styles from database. This new class would have all the attributes of a MailigList class that can be customized using list styles ( we can leave out attributes like list_name, list_id).
I will have table for style which will be having only changed attributes in it and rest of the attributes will be null. For example if admin has changed the attribute "send_welcome_message" under discussion and other attribute like "advertise" under public list then these two attributes with their values defined by admin will be stores under the list style name and rest all the attributes which have been there in the mailinglist table will be null for the list style table. Now by using apply function on list style table the values of attributes will be overwritten on the mailing list table when admin apply that list.
Only admin will be able to change the settings and by having user section I mean we have to specify the admin of each style so that at time of showing present styles for a particular admin we will fetch only styles with that admin name from the style table, as we don't want other (admins) to change saved styles for particular admin. That is why admin field is essential in the style table.
If we create styles for ease-of-implementation of Admins and Moderators,
it is required that we support some level of authorization to edit/use
those styles. So for that purpose each style create would belong to a
User and can only be viewed/edited by him. Ideally it would be nice if
we could set different access levels for styles, like public, read_only,
private.
prakhar joshi writes:
what if we create separate tables for each class in the mailman/src/mailman/styles/base.py and store the name and their attributes in it with user_name with it.
Who are these "users" (subscribers? admins?) and why do you want to associate styles with users? Please use more descriptive terms unless you really need to describe something generic. But here IIRC the styles are for lists, and therefore the relevant users are list admins. However, why would a style be associated with a list admin? The same admin might have announce lists and discussion lists as well as anonymous lists, and so on.
This is not the association of "users" with styles, it is just meant for
authorization purpose. Also user_id would be better option to use as a
ForeignKey instead of user_name which is an optional argument for User.
thanks, Abhilash
hi Abhilash,
Thanks for all these corrections.
Prakhar Joshi DA-IICT,Gandhinagar
On Fri, Mar 20, 2015 at 7:03 PM, Abhilash Raj <raj.abhilash1@gmail.com> wrote:
Hi Prakhar,
I see that you mentioned below the details of our conversation, but the language looks confusing to me. Please look out for simple mistakes in your English before sending the mail, not just here but anywhere.
I will definitely take care of it in future.
hi, For the storage of list we will have table for list styles and when the admin creates a new list he/she will edit some attributes of
On Friday 20 March 2015 12:37 PM, prakhar joshi wrote: particular
list. By attribute I mean the options under each mailing list style like announce list have "allow list post". Admin can change there values.
You meant 'their' here and not 'there'.
Yes.
style table will have all the attributes(same attributes that are listed in mailing list table) in column but the values of attributes that user will change will be stored in the table and rest values will be null. With improving the "apply" method for styles we can over write the present settings of the mailing list. I hope this is making sense to you ?
What he means to say is we can create a generic Style class, another implementation of IStyle interface which instead of having static values of attributes like existing styles would have methods to dynamically fetch the stored styles from database. This new class would have all the attributes of a MailigList class that can be customized using list styles ( we can leave out attributes like list_name, list_id).
yeah, that is what I want to say.
I will have table for style which will be having only changed attributes in it and rest of the attributes will be null. For example if admin has changed the attribute "send_welcome_message" under discussion and other attribute like "advertise" under public list then these two attributes with their values defined by admin will be stores under the list style name and rest all the attributes which have been there in the mailinglist table will be null for the list style table. Now by using apply function on list style table the values of attributes will be overwritten on the mailing list table when admin apply that list.
Only admin will be able to change the settings and by having user section I mean we have to specify the admin of each style so that at time of showing present styles for a particular admin we will fetch only styles with that admin name from the style table, as we don't want other (admins) to change saved styles for particular admin. That is why admin field is essential in the style table.
If we create styles for ease-of-implementation of Admins and Moderators, it is required that we support some level of authorization to edit/use those styles. So for that purpose each style create would belong to a
Userand can only be viewed/edited by him. Ideally it would be nice if we could set different access levels for styles, like public, read_only, private.
Yeah we can provide option these options to admin.
prakhar joshi writes:
what if we create separate tables for each class in the mailman/src/mailman/styles/base.py and store the name and their attributes in it with user_name with it.
Who are these "users" (subscribers? admins?) and why do you want to associate styles with users? Please use more descriptive terms unless you really need to describe something generic. But here IIRC the styles are for lists, and therefore the relevant users are list admins. However, why would a style be associated with a list admin? The same admin might have announce lists and discussion lists as well as anonymous lists, and so on.
This is not the association of "users" with styles, it is just meant for authorization purpose. Also
user_idwould be better option to use as a ForeignKey instead ofuser_namewhich is an optional argument forUser.
Yeah, basically we need to relate each style with its owner so user_id will be more appropriate.
-- thanks, Abhilash
Abhilash Raj writes:
Admin can change there values.
You meant 'their' here and not 'there'.
(-: Lighten up on the spelling stuff. *I* make that typo regularly (I think I mostly manage to correct it before posting, I hope :-).
You're right about reviewing the language, though. I had no idea what Prakhar (@prakhar126: is that your preferred form of address?) was talking about. Thanks for the "translation"!
I will have table for style which will be having only changed attributes in it and rest of the attributes will be null.
I'm not a fan of this API using nulls. I would prefer a special value of "inherit" or "defer" to indicate that omission of a value is deliberate. (This can be hidden from end users.)
It's possible that None (or NULL in the backing store) is an appropriate way to implement "inherit", but only if concrete styles (that is, styles that are actually part of a mailing list) have all attributes required. I don't see how this is possible if we want to allow for extensibility by users.
For example if admin has changed the attribute "send_welcome_message" under discussion and other attribute like "advertise" under public list then these two attributes with their values defined by admin will be stores under the list style name and rest all the attributes which have been there in the mailinglist table will be null for the list style table. Now by using apply function on list style table the values of attributes will be overwritten on the mailing list table when admin apply that list.
I don't understand when "apply" happens. I'm guessing that the proposal is to have a "stack" of styles in the configuration UI:
{ name: <list specific>, read-only: no, notmetoo_default: no } { name: anonymous_overlay, read-only: yes, redact_all_addresses: yes } { name: discussion, read-only: yes, <usual discussion list options ...> }
where unspecified attributes are "inherit", and when the admin is done, they hit an apply button, which searches the stack from top down and takes the first non-inherit value found. The constructed configuration is validated for all required options being set. Finally, the list configuration is instantiated in the list table.
Only admin will be able to change the settings and by having user section I mean we have to specify the admin of each style so that at time of showing present styles for a particular admin we will fetch only styles with that admin name from the style table, as we don't want other (admins) to change saved styles for particular admin. That is why admin field is essential in the style table.
Lists may have multiple admins AFAIK. I think the <list> field I propose above is a better construct.
If we create styles for ease-of-implementation of Admins and Moderators, it is required that we support some level of authorization to edit/use those styles. So for that purpose each style create would belong to a
Userand can only be viewed/edited by him. Ideally it would be nice if we could set different access levels for styles, like public, read_only, private.
I thought about this for a few minutes, and I think we need a concrete schema and some use cases. For example, I don't see why styles would need to be "private". And although I used "read-only" myself, I just meant "writing not authorized". One could also simply have all styles be read only once registered (unused locally-defined styles could be garbage-collected or explicitly deleted).
This is not the association of "users" with styles, it is just meant for authorization purpose.
Sure, users are always about authorization in this kind of application. My point is that there are too many kinds of "user" in the mailing list context, and that in Mailman 3, ordinary subscribers are included when we talk about "user" in the sense used in the code.
Prakhar Joshi DA-IICT,Gandhinagar
On Sat, Mar 21, 2015 at 9:03 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Abhilash Raj writes:
Admin can change there values.
You meant 'their' here and not 'there'.
(-: Lighten up on the spelling stuff. *I* make that typo regularly (I think I mostly manage to correct it before posting, I hope :-).
You're right about reviewing the language, though. I had no idea what Prakhar (@prakhar126: is that your preferred form of address?) was talking about. Thanks for the "translation"!
Prakhar is fine. yeah prakhar126 is my email address.
I will have table for style which will be having only changed attributes in it and rest of the attributes will be null.
I'm not a fan of this API using nulls. I would prefer a special value of "inherit" or "defer" to indicate that omission of a value is deliberate. (This can be hidden from end users.)
So you want to store only changed attributes under a specific list style in the table ? Isn't that make the table dynamic in width as sometimes only one attribute is stored and sometimes 3-4 attributes are stored ?
It's possible that None (or NULL in the backing store) is an appropriate way to implement "inherit", but only if concrete styles (that is, styles that are actually part of a mailing list) have all attributes required. I don't see how this is possible if we want to allow for extensibility by users.
By extensibility you mean to add new attributes ? or add new class as there are few classes in the mailman/src/mailma/styles/base.py (but that can't be possible through web interface, I guess? )
For example if admin has changed the attribute "send_welcome_message" under discussion and other attribute like "advertise" under public list then these two attributes with their values defined by admin will be stores under the list style name and rest all the attributes which have been there in the mailinglist table will be null for the list style table. Now by using apply function on list style table the values of attributes will be overwritten on the mailing list table when admin apply that list.
I don't understand when "apply" happens. I'm guessing that the proposal is to have a "stack" of styles in the configuration UI:
{ name: <list specific>, read-only: no, notmetoo_default: no } { name: anonymous_overlay, read-only: yes, redact_all_addresses: yes } { name: discussion, read-only: yes, <usual discussion list options ...> }
If there are more than 1 attributes in the last section of above list style configuration then the list table will not have the same width ?
where unspecified attributes are "inherit", and when the admin is done, they hit an apply button, which searches the stack from top down and takes the first non-inherit value found. The constructed configuration is validated for all required options being set. Finally, the list configuration is instantiated in the list table.
unspecified attributes ? You mean attributes other than that of mailing list table ?
Only admin will be able to change the settings and by having user section I mean we have to specify the admin of each style so that at time of showing present styles for a particular admin we will fetch only styles with that admin name from the style table, as we don't want other (admins) to change saved styles for particular admin. That is why admin field is essential in the style table.
Lists may have multiple admins AFAIK. I think the <list> field I propose above is a better construct.
Yeah that read only and editable thing will be better and no need to add user_id for each list style.
If we create styles for ease-of-implementation of Admins and Moderators, it is required that we support some level of authorization to edit/use those styles. So for that purpose each style create would belong to a
Userand can only be viewed/edited by him. Ideally it would be nice if we could set different access levels for styles, like public, read_only, private.I thought about this for a few minutes, and I think we need a concrete schema and some use cases. For example, I don't see why styles would need to be "private". And although I used "read-only" myself, I just meant "writing not authorized". One could also simply have all styles be read only once registered (unused locally-defined styles could be garbage-collected or explicitly deleted).
yeah that's the main objective.
This is not the association of "users" with styles, it is just meant for authorization purpose.
Sure, users are always about authorization in this kind of application. My point is that there are too many kinds of "user" in the mailing list context, and that in Mailman 3, ordinary subscribers are included when we talk about "user" in the sense used in the code.
Here by user I mean admins and I will take care of it in future to be specific.
I think we are still not on same page for list style storage as still there are few things that I have in my mind like admin can't create its own new attribute, he/she can just change the value of the attribute, right ?
And if that is true(admin can't add new attributes) than how can we just store only changed/modified attributes in the styles table as than the table will not have same width, lets assume for style A we will store one attributes and for style B we will store two/more attribute.
Let me summarize the whole thing what I have understood and what I want to implement for the list styles.
In the web interface the admin will have a option to apply styles or change settings of the list, then he/she will be redirected to new page with all the styles which are there in the database table for styles some with read only permissions and some which can be editable. Now when admin selects a style then there must be attributes in that style with values and these attribute values will be overwritten in the mailing list table(which have all the attributes listed down) and admin can change these attribute values if that particular style have permission for the same. This way style will be implemented to the list. (This is from the frontend's view)
Now lets get back to the backend, here we will be having a table for styles and this table will contain the style name type of permission and all the attributes that are listed in mailing list table (to maintain the width for a table) and as few attributes must have been edited by the user so these(few attributes) will have those edited values and rest will have default values(as you said Null will not be preferred). Now when a style will be applied to the mailing list then all the values of attributes from the style table( this will have new set values to few attributes and default values to rest attributes) will be copied to mailing list table. This way when any style which has been created by admin is applied to a mailing list then all the attributes from styles will be applied to mailing list attributes. Also when admin wants to change the settings of a style (which is not read_only) he/she will be listed down all the attributes(all means all attributes same as mailing list table) and he can edit their values and save them under some name(style name).
When admin create a new style he will be listed down with all the attributes (all means all attributes same as mailing list table) with their default values and now admin can change them and save them with style name.
Basically the style table will be copy of mailing list table and will have same number of column same as mailing list table with one more column about permission (read_only or editable). Now when style will be applied to a list there will be a generic class that will copy these attribute value (from style table) to the mailing list table. I guess this make sense, I am clear this time?
Thanks,
participants (3)
-
Abhilash Raj -
prakhar joshi -
Stephen J. Turnbull