Hi Steve, On 1/27/16, Stephen J. Turnbull <step...@xemacs.org> wrote: > Harshit Bansal writes: > > > Figure out how to store and access the styles as some of them are > > defined in the source code and the ones created by the by users would > > have to be stored in databases? > > You also need a read/print repr. A Python dict may be a reasonable > one, but JSON, YAML, init, etc could all be considered. >
I am planning to use dictionary. > > Styles will be stored in database in a dedicated table. > > You may want more than one table. Or you may be able to store them in > the same table as currently used for list configs, with that table > updated to allow "unstyled" as a value for its columns. (List id, > for example, would be "unstyled", since it is supposed to be globally > unique. Probably list name should be too, but domain would very > likely be styled.) > > > The style manager will update all the styles 'predefined in the > > source code' as well as the styles 'defined by users(by > > implementing the IStyle interface)' to the database. Currently we > > define a list of python import paths which are used for styles. > > Do you mean "configs"? > > > These will be collected in the style manager and then updated in > > the database. These styles will be publicly viewable but the users > > wouldn't be able to modify/change them(using Postorius) otherwise > > we would have to update those changes in the files as well. > > I don't understand why you wouldn't be able to modify them. The > presets probably should be read-only, and you might want to have a > permissions system such that only the owner of the style can change > it. Others would need to copy the style, modify the copy, and then > apply it to their own lists. > Here, I meant to say that the 'predefined-styles' would be read-only(not modifiable) while the style defined by the user(using Postorius) would be readable/editable as per the permissions system. > > Should we even allow changing list styles after lists have been > > created? > > Certainly. Consider the case where a dramatic improvement in MUAs > commonly used by a subscriber base makes it possible to use Wrap > Message instead of Munge From as DMARC mitigation. You want to change > all your lists in one go if they all have the same subscriber base > (consider an enterprise setting where the subscribers are mostly using > enterprise webmail). > > > Does changing a list style in database/source code changes > > the settings for list? > > IMO, yes. But source code changes by the Mailman Project would not be > allowed, except with a looong deprecation/obsoletion cycle, and source > code changes should be documented as an operation with potential (bad) > surprises for users. > > > I think there is no valid reason to not to allow changing list styles > > after they have been created but there are two attributes about which > > I am not sure these are: > > 1: default_member_action > > 2: default_nonmember_action > > The value of these style attributes are first copied to > > 'member.moderation_action'(moderation_action column of member table) > > and then this saved value is used to decide the correct moderation > > action. So changing the value of 'default_member_action' and > > 'default_nonmember_action' have no effect on the saved values and > > these will not change. This will have an undesired effect. > > I think that this is not a problem. We need to initialize all > attributes to valid values, and this will probably be hard-coded in > the source. Then we overlay this with site styles, domain styles, > list styles, and user attributes, and do the lookup in the opposite > order. In principle, for each attribute you would drill down as long > as the value at the current level is "unstyled". In practice, you'd > keep a cache of the current results of such lookups for users and > lists to avoid slamming the database, and some way of identifying when > the cache is out of date (such as a change "generation counter"). > Note that this explains some of the reason why source code changes > need to be treated with care -- in some sense they are always > "generation 0" because it's impossible to know in advance what > generation the installlation is at. > > > So I think whenever a user changes these two attributes then we > > will have to ask the user if he wants to change the saved values or > > not. Another approach could be to leave these values unchanged and > > bring this behavior to the knowledge of the user and if he wants > > then he can manually change the moderation action of some selected > > members but new members will automatically have their > > moderation_action set to new the values. > > This is the current behavior for default_* actions; I don't see why it > would change with the introduction of styles. > I wanted to ask that what should be the behavior when a user changes the 'default_member_action' and 'default_nonmember_action' attributes. Since, the values of these attributes are copied to the 'member.moderation_action' at the time of the creation of a new member. So, any changes made to the 'default_member_action' and 'default_nonmember_action' attributes will not be reflected in the already created members which I think may not be the desirable behavior. Please do correct me if am wrong somewhere. > > How to apply styles to lists after they have been created? I will > > expose the styles via REST API. Whenever the user(admin) will > > change a mailing list's style in Postorius, it will automatically > > call 'new_style.apply()' function which will update the mailinglist > > table with the new values. This will change the list style. > > Be careful here. Since some styles percolate up to user level, a site > with hundreds of thousands of lists and millions of users (they > exist!) could really slam the database. The whole system would grind > to a halt. > > > After implementing all these things, there will be two ways to create > > and update styles : > > 1: Using Postorius > > 2: By defining a class implementing the IStyle interface and saving it > > to a file. > > I don't see why you would allow 2 at all. IStyle is an internal > thing, which would be used to provide a Python interface to the > database backend. Unless you're thinking of dynamic styles (eg, > theming the list page according to day of week or server load :-)? > Earlier, I was thinking to implement a way to add new styles using Postorius as well as by adding a file to the source code containing a class implementing the 'IStyle' interface to define the new style. But now I have dropped this idea as I think that it would not be that useful. > Steve > Thanks, Harshit Bansal. IRC Nick : _Harshit_ _______________________________________________ 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
