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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
