hi Abhilash, Thanks for all these corrections.
Prakhar Joshi DA-IICT,Gandhinagar On Fri, Mar 20, 2015 at 7:03 PM, Abhilash Raj <raj.abhila...@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. > 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'. > 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 > `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. > 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_id` would be better option to use as a > ForeignKey instead of `user_name` which is an optional argument for `User`. > Yeah, basically we need to relate each style with its owner so user_id will be more appropriate. > -- > thanks, > Abhilash > > _______________________________________________ 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