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

Stephen J. Turnbull stephen at xemacs.org
Sat Mar 21 04:33:09 CET 2015


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
 > `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).

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



More information about the Mailman-Developers mailing list