Prakhar Joshi
DA-IICT,Gandhinagar
On Sat, Mar 21, 2015 at 9:03 AM, Stephen J. Turnbull <step...@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
> > `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.
>
> 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,
_______________________________________________
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
