[Mailman-Developers] GSOC:Populating two default styles
Hi,
I was trying to populate the two default styles in the database. For
this purpose, I was trying to use ConfigurationUpdatedEvent as used in
the earlier style manager but I am recieving following error:
Traceback (most recent call last):
File "/home/harshit/Drive1/dev/Mailman/mailman/src/mailman/testing/layers.py",
line 87, in setUp
initialize.initialize_1(INHIBIT_CONFIG_FILE)
File
"/home/harshit/Drive1/dev/Mailman/mailman/src/mailman/core/initialize.py",
line 118, in initialize_1
mailman.config.config.load(config_path)
File "/home/harshit/Drive1/dev/Mailman/mailman/src/mailman/config/config.py",
line 102, in load
self._post_process()
File "/home/harshit/Drive1/dev/Mailman/mailman/src/mailman/config/config.py",
line 125, in _post_process
notify(ConfigurationUpdatedEvent(self))
File
"/home/harshit/Drive1/dev/Mailman/env/lib/python3.4/site-packages/zope.event-4.1.0-py3.4.egg/zope/event/__init__.py",
line 31, in notify
subscriber(event)
File
"/home/harshit/Drive1/dev/Mailman/mailman/src/mailman/model/styletmanager.py",
line 105, in handle_ConfigurationUpdatedEvent
getUtility(IStyletManager).populate()
File
"/home/harshit/Drive1/dev/Mailman/mailman/src/mailman/database/transaction.py",
line 85, in wrapper
return function(args[0], config.db.store, *args[1:], **kws)
File "/home/harshit/Drive1/dev/Mailman/mailman/src/mailman/config/config.py",
line 87, in __getattr__
return getattr(self._config, name)
File
"/home/harshit/Drive1/dev/Mailman/env/lib/python3.4/site-packages/lazr.config-2.1-py3.4.egg/lazr/config/_config.py",
line 513, in __getattr__
raise AttributeError("No section or category named %s." % name)
AttributeError: No section or category named db.
It seems that the database layer hasn't got initialized by the time
this event was fired. Is there any way of fixing this or any other way
using which I can populate the database when mailman starts?
Thanks,
Harshit Bansal
___
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
Re: [Mailman-Developers] New Interface
Hi, On 04-Jun-2016 1:11 am, "Barry Warsaw" wrote: >I've always wanted styles to be composable, by which I mean that a style can >describe just a partial set of attributes. For now I'll call these stylets. >One stylet might define how autoresponses work, while another might describe >how digests work. In a sense, this is analogous to how the composition was >broken down in MM2.1, but without all the ugly mixin stuff. How can this composability be achieved in a model? I mean that the size of a table is fixed in a model and if a style describes just a partial set of attributes then what would be stored in other attributes? Also how would this partial style be applied to a mailing list? Problems that are blocking me for past two-three days: Solved: 1: Getting a list of all styleable attributes. Since you have approved the new interface this problem is solved. Unsolved: 1: How to trigger the fallback mechanism? 2: Current 'IStyle' interface allows us to define either a partial style(stylet, describing just a partial set of attributes) or a complete style. But is that possible with a model? 3: If I go for style composabiltiy as described by you then how would I represent that idea in REST and Postorius? Thanks, Harshit Bansal ___ 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
Re: [Mailman-Developers] New Interface
Hi, Thanks for replying in spite of being busy! > As you've noticed, some of the attributes in the model class aren't > described > in the interface. Those are mostly the legacy attributes which should > eventually go away (because they are unused or represent features we don't > want to support), or converted to better database types (see the PickleType > for accept_these_nonmembers). It's gotten a lot better, but there are > still > some holdovers from the old MM2.1 code, so more opportunities to clean up > and > modernize. Would you like to keep these attributes(those which are unused and we don't want to support) or should these be removed? > I've always wanted styles to be composable, by which I mean that a style > can > describe just a partial set of attributes. For now I'll call these > stylets. > One stylet might define how autoresponses work, while another might > describe > how digests work. In a sense, this is analogous to how the composition was > broken down in MM2.1, but without all the ugly mixin stuff. > > The current IStyles support this, but of course they are only applied to > mailing lists when they are created, and changing a style does not change > any > list to which the style was applied. >From core's point of view this idea seems to be fine but I am unable to think of any way of representing this idea in Postorius(since new styles would be created there)? Earlier while discussing we decided to make style composable in terms of other styles(inheritance and fallback mechanism). For example, if a user wants to modify only the the autoresponses attributes of Style1, then, he may create a child style of Style1 and change only the attributes related to the autoresponses and rest of the attributes will take their values from the parent style(Style1). Also is there any advantage of making styles composable in terms of stylets? >>I am thinking of adding a new interface named 'IStyleable' to the >>mailman core. All the styleable attributes from the current >>'IMailingList' interface will be moved to this new interface. The >>current 'IMailingList' interface does not provide documentation for >>all the styleable attributes. This new interface will contain all >>styleable interfaces arranged in an orderly way with proper >>documentation. This new interface then can be extended by the existing >>'IMailingList' interface and the new 'IStyle' interface that I am >>writing. > > I think this makes sense. You're refactoring out the interface for the > attributes of a mailing list apart from the functionality that a list > provides. There may be some attributes which aren't style related, > e.g. created_at, and perhaps some that shouldn't get refactored because > they > identify the list (e.g. list_name and list_id), but we can discuss that. The new interface will contain only styleable attributes and not any immutable attributes like created_at. All the immutable attributes will reside in the existing 'IMailingList' interface. New interface(WIP): https://gitlab.com/_Harshit_/mailman/commit/6c94e220cd5f5ba857fa003bdc17919ca6f9217b > Then it may be possible to do a lot of cool things on stylets, such as > impose > permissions on changing or using one; recording the stylets used with a > particular mailing list, so if you change the stylet, the mailing list > automatically changes, etc. How will be the permissions enforced without authorization system? > Let me see if I understand: you want to query the IStyleable interface to > know > what attributes are allowed in a style. It makes sense in that case to use > a > separate interface just for that purpose, without cluttering it up with all > the other interface bits specifically for mailing list operation > (e.g. get_roster(), subscribe(), and immutable attributes like created_at > and > list_id). As I mentioned above that the new interface is going to have only styleable attributes. > The only other comment on the above paragraph has to do with requiring a > style > to contain *all* the attributes. How would you handle the composability in > that case? All attributes will be required only in case the style doesn't inherit from any other base style. In case the style inherits from some other base style then the dictionary(argument to the constructor) will contain only those attributes which the user wants to change and rest of the attributes would be taken from the parent style. Also could you suggest some default value(such as 'DEFER') for styleable attributes that would trigger the fall back mechanism to take values from the parent style. Thanks, Harshit Bansal. ___
[Mailman-Developers] New Interface
Hi, I am thinking of adding a new interface named 'IStyleable' to the mailman core. All the styleable attributes from the current 'IMailingList' interface will be moved to this new interface. The current 'IMailingList' interface does not provide documentation for all the styleable attributes. This new interface will contain all styleable interfaces arranged in an orderly way with proper documentation. This new interface then can be extended by the existing 'IMailingList' interface and the new 'IStyle' interface that I am writing. Why I felt the need of a new interface? For constructing a new style I am taking a dictionary as an input to the constructor which is supposed to contain all the necessary styleable attributes and their corresponding values as key value pairs and to check whether the dictionary contains all the styleable attributes or not I will need to have a list of all the styleable attributes and that can be done very easily if I have an interface containning all the styleable attributes. I know there are other methods of getting a list of all the attributes but they are neither pythonic nor stable as all of them depend on python internals which are liable to change with the version of python. I had asked Barry for his comments but as he is busy in PyCon so he asked me to redirect my query to mailing list. As this was blocking so I in the meantime I wrote the new interface which can be found here: https://gitlab.com/_Harshit_/mailman/commit/6c94e220cd5f5ba857fa003bdc17919ca6f9217b Please provide your comments/suggestions on whether should I continue with this or not. Thanks, Harshit Bansal. ___ 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
[Mailman-Developers] Some Doubtful Attributes
Hi,
While categorising the styleable attributes I have come across some
attributes which are defined but never used in the code. Some of these
attributes are:
forward_auto_discard
non_member_rejection_notice
member_rejection_notice
bounce_score_threshold
bounce_notify_owner_on_disable
bounce_notify_owner_on_removal
forward_auto_discards
max_days_to_hold
digest_is_default
mime_is_default_digest
scrub_nondigest
obscure_addresses
Some of the attributes are present only in
src/utilities/tests/test_import.py. A list of such attributes is as follows:
bounce_you_are_disabled_warnings
bounce_info_stale_after
accept_these_nonmembers
discard_these_nonmembers
reject_these_nonmembers
What should be done to these attributes? For now, I have included them in
the model.
Also in src/mailman/styles/base.py line no. 129, we are setting up an
non-existing attribute as follows:
mlist.topics_userinterest = {}
But the IMailinglist doesn't contain any such attribute.
Thanks,
Harshit Bansal
___
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
[Mailman-Developers] Code Duplicacy
Hi, I was writing the new 'IStyle' interface and after completing some part of it I realised that the code has become a bit repetitive as all the styleable attributes which are present in src/interfaces/mailinglist.py are to be copied to src/interfaces/styles.py in IStyle interface. For example, advertised = Attribute( """Advertise this mailing list when people ask for an overview of the available mailing lists.""") This piece of code is now present in both src/interfaces/mailinglist.py and src/interfaces/styles.py. Is there any way to correct it or is it fine? One approach that I am able to think of is to write one seperate interface containning all the styleable attributes and implement that interface both in src/model/mailinglist.py and src/model/styles.py. Thanks, Harshit Bansal. ___ 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
Re: [Mailman-Developers] Authorization System in Core
Hi Simon, This is the discussion that I was referring to: Harshit Bansal writes: > I think the "Permissions Systems" would have nothing to do with the > core. It would be related to Postorius. We will have to create a style > model separately in Postorius which would store the style name and the > user who created it. Then only the user who has created the style > would be granted the permission to edit it. Stephen J. Turnbull wrote: Then there is no *permissions* system! For example, one project last year created a Javascript client -- that would completely bypass the "permissions" system as you describe it. You could imagine that style changes are a "friendly users" feature, and so the "style owner" system would be a *safety* feature of the Postorius UI rather than an *authorization* feature of styles. But in an enterprise context (eg, a virtual hosting service), I'm sure that users will think of it as an authorization system. While at present it seems unlikely that there would be multiple interfaces on one hosting service, you never know what users will do[1]. Also, it would not be obvious to somebody who installed the node.js Mailman client that they are likely bypassing "security" as documented in the typical Mailman manuals and tutorials that you would find on the web. Thanks, Harshit Bansal >Hi, >Earlier, while discussing the permission system for manging styles, it >was >decided that the permissions system should be enforced in the core >rather >than in the postorius since otherwise it can be bypassed(deliberately >or >undeliberately). But one thing that I think I forgot to discuss was >that >currently there is no authorisation system in the core and now I am >unable >to figure out that how could the permissions be enforced in the core >without an authorisation system. >Should I workout an authorisation system for the core first or enforce >permissions in postorius only? Can you elaborate a little more? What do you want to use the authorization for? Why isn't doing it in postorius safe enough? -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ 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/harshitbansal2015%40gmail.com Security Policy: http://wiki.list.org/x/QIA9 ___ 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
[Mailman-Developers] Authorization System in Core
Hi, Earlier, while discussing the permission system for manging styles, it was decided that the permissions system should be enforced in the core rather than in the postorius since otherwise it can be bypassed(deliberately or undeliberately). But one thing that I think I forgot to discuss was that currently there is no authorisation system in the core and now I am unable to figure out that how could the permissions be enforced in the core without an authorisation system. Should I workout an authorisation system for the core first or enforce permissions in postorius only? Thanks, Harshit Bansal ___ 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
[Mailman-Developers] Blog
Hi, I have been a little bit inactive these days as I am stuck in my end semester exams. However, I have been able to take out some time and update my blog with a few posts explaining my proposal and my experiences of GSOC. I invite all of you to have a look at my blog here: https://contributingtofoss.blogspot.com/ Comments/suggestions are most welcomed. Thanks, Harshit Bansal ___ 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
[Mailman-Developers] Rosters not using 'ISubscriptionService' Interface.
Hi, I was looking at the 'rosters.py' and I am unable to understand that why are rosters not using 'ISubscriptionService' interface instead of making raw queries for finding members? Is there any reason for doing so and if no then should it be changed? Thanks, Harshit Bansal. ___ 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
Re: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" .
Hi Barry, >The point of this break down is because some things (and it's not a perfect >separation) really won't be shared between mailing lists. OTOH, you might >want site-wide bounce settings that all lists will inherit and shouldn't be >able to change. Other sub-styles give the list its "flavor", i.e. an open >discussion list where anyone can join just by confirming their email, or a >one-way announcement list that can't be unsubscribed from because it's an >"all-employees" roster. I already had this idea in my mind and that's why I have divided all the styleable attributes into three categories: 1: Site owner level attributes. 2: Domain owner level attributes. 3: List owner level attributes. Suppose attributes related to bounce-settings come into site owner level attributes(I have not yet decided which attribute will fall in which category) then only site-owners would be able to set them and once these are set, the list owners would be having only two options. Either apply the existing style as it is or create a sub-style and adjust the list owner level(not site-owner level) attributes(to give their list "flavor") and then apply it. This way they would be able to make their list an "open discussion list" or an "one-way announcement list" without being able to edit the bounce-settings. Regards, Harshit Bansal. ___ 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
Re: [Mailman-Developers] Pushing branch to origin
Hi Vinay, On 3/19/16, Vinay Mundada wrote: > git remote -v gives me this: > origin g...@gitlab.com:mailman/postorius.git (fetch) > origin g...@gitlab.com:mailman/postorius.git (push) > > But I have followed the exact steps while doing the setup. Instead of cloning from your fork(as mentioned in the guide), you seem to have cloned from Mailman project's master branch. > So now to what do I change my remote name to? You can perform these steps: 1: Rename origin to upstream.(git rename origin upstream) 2: Add new remote origin.(git remote add origin g...@gitlab.com:/mailmam.git)(If you want then you can copy exact SSH url from your fork's GitLab page.) 3: Push your branch to origin.(git push origin 4: Create a Merge Request. Hope it helps. Regards, Harshit Bansal. > On Sat, Mar 19, 2016 at 12:24 PM, Harshit Bansal < > harshitbansal2...@gmail.com> wrote: > >> Hi vinay, >> Have you setup your remotes correctly as mentioned in: >> http://wiki.list.org/DEV/HowToContributeGit >> >> You can check your remote by this command: >> git remote -v >> >> It must show your fork as origin. If it doesn't show your fork as origin >> then you must setup remotes correctly as mentioned in the guide. You can >> use git remote rename command to rename your remotes. >> You should always push to your fork and then create a merge request. >> >> Regards, >> Harshit Bansal. >> > ___ 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
Re: [Mailman-Developers] Pushing branch to origin
Hi vinay, Have you setup your remotes correctly as mentioned in: http://wiki.list.org/DEV/HowToContributeGit You can check your remote by this command: git remote -v It must show your fork as origin. If it doesn't show your fork as origin then you must setup remotes correctly as mentioned in the guide. You can use git remote rename command to rename your remotes. You should always push to your fork and then create a merge request. Regards, Harshit Bansal. ___ 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
Re: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" .
Hi, On 3/12/16, Stephen J. Turnbull wrote: > > Basically, a style will be having three levels of viewability: > > 1: System wide : A style having this level of viewability will be > > visible to all the domains as well as the lists. It will be available > > to all the list owners for copying however the site owners will have > > the option to make it either read-only or editable. > > I don't see a real advantage to having this editable by list owners, > since it's copyable. On the other hand, "styles" are not just > display, but also include security/privacy features. Eg, a rogue > editor could DoS the whole site by adding .* as a ban or discard > expression in spam filtering. I think probably it's OK to have styles > editable only by owner. > Yes I also agree with you. I am refining this system as follows: Suppose there is a style A having a domain level viewability. Then only site owners and domain owners would be allowed to edit it. The list owners would have the option to either apply as it is or copy and modify it. Basically, a user at the same or upper level would be able to edit the style. The users at the lower level would have to copy the style if they want to change it. > However, the owner might be a group of users. Yeah, I am actually assuming them to be a group of users. > How about inheritability? The difference between inheritance and > copying is that if the template changes, with inheritance the derived > configurations change too, with copying they don't. > Sorry, I think I have used wrong terminology here. By 'copying' I actually meant 'inheriting'. > > Also while working out the implementation details, I came across a new > > problem which is as follows: > > Suppose, we have three style A, B and C. B inherits from A and C > > inherits from B. Now, suppose someone decides to delete style B then > > how can we deal with this situation. > > Persistence across Mailman restarts of course needs to be carefully > dealt with, but we deal with the basic issue in the usual Unix way: a > style which is "deleted" just loses its entry in the admin-visible > directory of styles, but it is not actually deleted from the database > until all references are gone. > Indeed a great idea. The unused styles will garbage collected at regular intervals. Also, the way in which we now store and categorise styles has made them very much analogous to the members of a list. So, should a "roster" like functionality for searching and retrieving the styles be implemented just like it is implemented for members? Thanks, Harshit Bansal. ___ 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
Re: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" .
Hi everyone, First of all, I would like to thank Barry and Steve for giving their valuable comments due to which I have been able to workout the "Permission model" from the very scratch, the details of which are as follows: Basically, a style will be having three levels of viewability: 1: System wide : A style having this level of viewability will be visible to all the domains as well as the lists. It will be available to all the list owners for copying however the site owners will have the option to make it either read-only or editable. 2: Domain Wide : A style having this level of viewability will be visible to all the lists within a specific domain. However, the domain owners would have the option to make it read-only or editable. 3: List Specific : A style having this level of viewability will be visible to a specific list. Not only this, all stylable attributes will be divided into three categories: 1: Site owner level attributes : Only site owners will have the permissions to edit these attributes. 2: Domain owner level : Site owners as well as domain owners can edit these attributes. 3: List owner level : Site owners as well as domain owners as well as list administrators will have the permissions to edit these attributes. Let us consider a domain example.com with a list te...@example.com with ow...@example.com as site owner. Now, suppose the site owner(ow...@example.com) creates a style named 'foo'. Now the domain owner of example.com will have two options, either he can edit(if the style is editable) domain owner and list owner level attributes and then can delegate to list owners or if the style is read-only then they can copy the style to have a new style 'foo1', make necessary changes and then delegate to the list owners. Now the list owners can either apply 'foo' or foo1' or create their own customizations and apply them. @Steve I think this system also addresses the issues that you pointed as now all the permissions will be enforced in the mailman core instead of Postorius. Also while working out the implementation details, I came across a new problem which is as follows: Suppose, we have three style A, B and C. B inherits from A and C inherits from B. Now, suppose someone decides to delete style B then how can we deal with this situation. Further comments/suggestions are welcomed. Thanks, Harshit Bansal. On 3/10/16, Stephen J. Turnbull wrote: > Barry Warsaw writes: > > > It's likely that the permissions would only be enforced in > > Postorius, although we can think about how the core would enforce > > the permissions. > > I don't insist on core enforcement, though I think it desirable. I do > ask that this functionality not be called "permission" if core doesn't > enforce it. (Details in earlier reply to Harshit.) > > > One other thing to think about is whether some styles will be > > allowed or disallowed for various domains or mailing lists. > > I think this would be very convenient, but could be handled purely as > visibility control (after all, you can reconstruct any style attribute > by attribute unless prohibited in mm_cfg.py, but that's instance-wide > anyway). Eg, a dotted name would be used as a str.endswidth filter, > and the convention would be to name styles according to List-Id, with > multiple styles or versions being "subdomains" of List-Id. The > domains example.net (season to taste) and distribution.list.org would > be special, corresponding to anonymous styles and the GNU Mailman > distribution, respectively. So typical names of styles would be > > xemacs-beta.xemacs.org = style used for xemacs-b...@xemacs.org > v2.honeypot.xemacs.org = rev 2 of style used for honey...@xemacs.org > spam-fierce.example.net = a style containing spam filter > configuration, but the admin doesn't want the name to give > away which lists use it > anonymous.distribution.list.org = Mark's recommendation for > anonymous list configuration > announce.distribution.list.org = Mark's recommendation for > anouncement list configuration > > and typical filters would be > > .xemacs.org > .example.net > .distribution.list.org > > with the default being empty. Both style naming UI and available > style lists could suppress the filter, and the convention would make > it easy to copy a list's style. > > The special treatment of example.net is pretty clearly > over-engineering, but the information leakage that motivates it > represents the only reason I can think of for worrying about > availability of styles. > > Since endswidth would be used to filter, you wouldn't have to break at > dots, but I think that would be intuitive to users. > >
Re: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" .
Hi, As per previous discussions, it would be nice to support style hierarchies such that the list owners can compose them and defer settings to values higher up, that would allow the core to define some basic styles and then list owners can just tweak a few settings to modify one of those base styles but in this case should the changes in base-styles be propagated to all the styles that inherit it or not. If we allow the propagation of changes to inheriting styles, some list owners might be uncomfortable with this feature as then if any of the base-style changes their inheriting styles will change without any kind of prior notification. >> In the back-end, we will be using tables for storing style attributes >> and permission level(read only or editable). This table will basically >> contain all the "stylable" attributes with "default or predefined" >> values as contained in the mailing list table and one extra column for >> permissions. I think the "Permissions Systems" would have nothing to do with the core. It would be related to Postorius. We will have to create a style model separately in Postorius which would store the style name and the user who created it. Then only the user who has created the style would be granted the permission to edit it. >From UI point of view, there is one more feature that comes to my mind: When the users are presented with an interface to customize the style, we could provide them with two views, one 'simple' and another 'advanced'. The 'simple' one would show only the *frequently* (or most commonly) changed attributes while the 'advanced' one will show all the attributes. This will help them in customizing the styles. I would like to hear some of your comments on it as well. Thanks, Harshit Bansal. On 2/11/16, Abhilash Raj wrote: > On 02/10/2016 10:03 AM, Harshit Bansal wrote: >> Hi Abhilash, >> In our previous discussion you mentioned that : >> >>> Permissions should also consider if the user wants to make his new style >>> public or keep it private. And should public styles be editable by >>> anyone or just read-only? >> >> I am unable to think of a use case in which it will be useful to have >> private styles.. Can you please suggest a suitable use case? > > Well, i agree there is nothing "private" in list styles. We could just > make all styles read-only for everyone. But if someone wants to use the > style created by other users, it would be better idea to first make them > copy the style so that the behavior or their list doesn't change when > the owner changes the style. > > > Barry: If you have some time, I would like to hear some of your thoughts > on this thread? I believe you have some ideas of your own on how this is > supposed to work. > >> >> Thanks, >> Harshit Bansal. >> > > -- > thanks, > Abhilash Raj > > ___ 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
Re: [Mailman-Developers] Accessing the members of a list
Hi Aditya,
Since a lot of Postorius code involves calls to Mailman's REST API and
running these tests against a real instance would be painfully slow,
hence ''vcrpy'' cassettess are used. These files contain pre-recorded
HTTP responses. If you write new tests, it's advisable to add a
separate fixture file for each test case. Considering your test, the
fixture file that your test uses contains the following pre-recorded
responses for the following POST requests :
request:
body: mail_host=example.com
headers:
accept-encoding: ['gzip, deflate']
!!python/unicode content-type: [!!python/unicode
application/x-www-form-urlencoded]
method: !!python/unicode POST
uri: http://localhost:9001/3.0/domains
request:
body: fqdn_listname=foo%40example.com
headers:
accept-encoding: ['gzip, deflate']
!!python/unicode content-type: [!!python/unicode
application/x-www-form-urlencoded]
method: !!python/unicode POST
uri: http://localhost:9001/3.0/lists
request:
body:
display_name=None&list_id=foo.example.com&pre_approved=True&pre_confirmed=True&pre_verified=True&subscriber=member-1%40example.com
headers:
accept-encoding: ['gzip, deflate']
!!python/unicode content-type: [!!python/unicode
application/x-www-form-urlencoded]
method: !!python/unicode POST
uri: http://localhost:9001/3.0/members
request:
body:
display_name=None&list_id=foo.example.com&pre_approved=True&pre_confirmed=True&pre_verified=True&subscriber=member-2%40example.com
headers:
accept-encoding: ['gzip, deflate']
!!python/unicode content-type: [!!python/unicode
application/x-www-form-urlencoded]
method: !!python/unicode POST
uri: http://localhost:9001/3.0/members
So only these request formats can be used in your test. If you want to
use other request formats then probably you have to record them in the
following fixture file:
src/postorius/tests/fixtures/vcr_cassettes/ListMembersTest.test_search_members_1.yaml
You can also refer to ''vcrpy'' documentation for more information.
Hope this helps.
Regards,
Harshit Bansal.
On 2/24/16, Aditya Divekar wrote:
> Thanks for the help Harshit!
> But I realized that I framed my question improperly. I used the above
> command before too, but it raises an error -
>
> CannotOverwriteExistingCassetteException: No match for the request
> ( http://localhost:9001/3.0/members/find?subscriber=%2Aexample.com%2A&list_id=foo.example.com&role=member>)
> was found. Can't overwrite existing cassette
> ('/home/hp/postorius_aditya/src/postorius/tests/fixtures/vcr_cassettes/ListMembersTest.test_search_members_1.yaml')
> in your current record mode ('once').
>
> Is this error because the request is not present in test cases or is it
> some other error?
> Also, if it is a test case problem, can anyone suggest me how to change the
> test case (or where I could read about how to go about it) to make the
> build pass?
>
> Thanks,
> Aditya.
>
___
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
Re: [Mailman-Developers] Accessing the members of a list
> Hi, > > This is in regard to postorius. Is there a way by which I can access all > the members of a list using its 'list_id' in the list.py file with/without > creating a new client? > > The approach I tried was creating a client in the list.py file for this > purpose and calling on the 'members()' function from the Client class > defined in client.py. The doubt I had here is that the members() function > uses the self parameter to decide which list is being referred to. For > this, I think I need to pass the exact url to the list I wish to search for > as a parameter while creating the client and then call on the members() > function on it. Here, how do I figure out the url for this purpose? > > Thanks! > > Aditya > I think this approach can be used for getting all members without creating a new client : m_list = List.objects.get_or_404(fqdn_listname=list_id) Then mlist.members can be used to access all the members of the mailing list. If you want to use the client then the exact url of the list would be lists/fqdn_listname. Hope this helps. Thanks and regards, Harshit Bansal HBTI, KANPUR ___ 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
Re: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" .
Hi Abhilash, In our previous discussion you mentioned that : > Permissions should also consider if the user wants to make his new style > public or keep it private. And should public styles be editable by > anyone or just read-only? I am unable to think of a use case in which it will be useful to have private styles.. Can you please suggest a suitable use case? Thanks, Harshit Bansal. ___ 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
Re: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" .
Hi Steve, On 1/27/16, Stephen J. Turnbull 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
Re: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" .
Hi Abhilash, I liked your idea of providing the users the capability to copy and customize the existing styles very much. Additionally, when the users are presented with an interface to customize the style, we could provide them with two views, one 'simple' and another 'advanced'. The 'simple' one would show only the *frequently*(or most commonly) changed attributes while the 'advanced' one will show all the attributes. This will help them in customizing the style. I think the major challenges that you pointed out in the last email can be addressed as follows: 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? Styles will be stored in database in a dedicated table. 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. 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. However, as per your suggestion they will have the option to copy and customize them as per their needs. This way of implementation would make the database a centralized place to store the styles and to access them and would be faster and safer than the file based approach. Should we even allow changing list styles after lists have been created? Does changing a list style in database/source code changes the settings for list? 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. 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. Currently, changing a style in source code doesn't changes the settings for list that inherits it. See what happens when a style is changed now? Is it propagated down to the list or only the new list inherits that? Presently when a style is changed, only the new list that inherits it is affected and the change is not propagated down to the old lists that inherits it. As of now there is no way to change a style without changing the source code. Also the styles are applied to a mailing list only during the creation time and after this there is no way to change the style of a list. After this project, the users will be able to change the styles without modifying the source code(using Postorius) and the lists that inherit those changes will automatically be updated to reflect those changes. 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. If a style is changed by a user using Postorius, then the Postrius will forward the request to the style manager via the REST API which apart from updating the 'style' table will also update the 'mailinglist' table such that the old mailing lists which inherited the changed style will also reflect the changes. 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. Here, I am unable to figure out that if an user creates or modifies a style using method 2 then how the mailman can be notified of the change? Thanks, Harshit Bansal IRC NICK : _Harshit_ On 1/18/16, Abhilash Raj wrote: > Hi Harshit, > > On 01/17/2016 09:22 AM, Harshit Bansal wrote: >> Hi everybody, >> I was looking at GSOC 2016 wiki page and I found "Preset List Settings >> Templates" project quite interesting. >> >> Af
[Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" .
Hi everybody, I was looking at GSOC 2016 wiki page and I found "Preset List Settings Templates" project quite interesting. After reading out the project description and the discussion on the project from the mail archives I have been able to reach out the following conclusion : I will be required to develop a Web Interface that will allow the admins to set the different attributes to the different mailing lists using some fixed templates(also known as styles). Not only this they will be able to define their own styles and use them. This will serve as our front-end. In the back-end, we will be using tables for storing style attributes and permission level(read only or editable). This table will basically contain all the "stylable" attributes with "default or predefined" values as contained in the mailing list table and one extra column for permissions. There will also be some back-end python code whose key function would be to read the attribute values from the styles table and when the user applies a style on a mailing list it will copy the attribute values from the style table to that particular mailing list's table. Please do correct me if I am wrong somewhere. Also,I wish to seek your views on this approach. Also tell me if I would need to develop a Command Line Interface(which I will love to develop) as well or only Web Interface would suffice? Thanks, Harshit Bansal. ___ 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
[Mailman-Developers] Introductory Mail
Hello everybody, I am Harshit Bansal, a first year undergraduate student from Harcourt Butler Technological Institute, Kanpur, looking to contribute to the GNU Mailman project for the upcoming Google Summer of Code program. I am very proficient in C and python. I also have a good grasp over the concepts of cryptography. I also have an intermediate level of experience in JavaScript. Currently, I am going through the codebase, the mail archives and documentation of GNU Mailman and trying to set up the development environment for the GNU Mailman and finding some simple bugs to work on. Looking forward to contributing to GNU Mailman through this year's GSOC program. Thanks, Harshit Bansal, B.Tech.(IT), HBTI, Kanpur. ___ 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
