[Mailman-Developers] GSOC'15: Improving styles for lists

[prakhar joshi]

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 at 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
>
>