Mailman 3 March 2015 - Mailman-Developers

Re: [Mailman-Developers] How do I turn on/off moderation of subscription requests?
by Barry Warsaw 21 Mar '15

21 Mar '15

On Mar 20, 2015, at 04:39 PM, Aurelien Bompard wrote: >Alright, I resurrected your branch to the best of my understanding. I hope >it's more Lazarus than Reanimator. > > https://code.launchpad.net/~abompard/mailman/subpolicy > >All tests pass, but there's still a missing part: the new attribute in the >MailingList table must still be actually written as a column, and an >Alembic migration script must be generated. I'm going to do that in the >next hours (or maybe on Monday), but in the meantime this branch only >contains your former code, with minor adaptations. Could you check it out? Wow, that's awesome Aurelien, thanks! I'll grab the branch and start taking a look. The question is, is this the right approach for implementing the subscription policy? Have a look at the workflow illustrated in my crappy Dia file, which I think is an accurate representation of how the policy should work. I have my uncertainties about the implementation. Maybe a fresh look would help. Cheers, -Barry

2 1

About writing proposals
by Stephen J. Turnbull 21 Mar '15

21 Mar '15

To the students and mentors, I've written the following on several students' proposals, but think it's useful to make them public, and I've learned some things since writing them. A couple of students have provided links to mockups of user interfaces and so on. I think it's useful to provide a mockup as a linked object, but you need to provide verifiable documentation of its content such as the commit ID in a git repo so that we can confirm you don't change it after the deadline date. Also, it's possible to inline images in the proposal (I couldn't access the source so I'm not sure how, but several students have figured out how :-). A major problem with all proposals is lack of good "milestones". A *milestone* is a precise description of the completion of a task which can be verified objectively. Exactly how to phrase milestones depends on many things. In many cases, something like "design document committed to repo, submitted to and approved by mentor" (ie, verification by another person) is appropriate. Or, in the case where a bunch of input functions have been coded, "valid input documented and validation functions implemented for all input fields" is something you can check yourself. Without "sharp" milestones, it's hard to determine whether you are keeping to your proposed schedule, or if you are leaving "10%" to be done later. Writing good milestones is hard. Many professionals can't (or don't bother). But you will find it very useful when making proposals in your work, or later when managing others in larger projects. Now is a good time to start. Steve

1 0

Re: [Mailman-Developers] GSOC'15: Improving styles for lists
by Abhilash Raj 21 Mar '15

21 Mar '15

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. 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'. > 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). > 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. >> 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`. -- thanks, Abhilash

3 3

GSoC 2015: Anonymous Users & Dashboards
by Stephen J. Turnbull 20 Mar '15

20 Mar '15

Sreyanth writes: > Hi Terri & others > > I am Sreyantha Chary (you can call me Sreyanth), a current MBA student at > IIM Ahmedabad. I have been a GSoC student for the past 2 years and would > like to hack on Mailman this year. > > I am interested in implementing the *anonymous *users feature and > dashboards for admins/owners/mods > > I have a few questions in mind about the anonymous users feature. > > 1. Lets say a user A sends an email and it gets disguised as > <foo>@<bar>. Should the user B who sends another anon email gets disguised > as <foo>@<bar>? No. Each user's "disguised address" (I think the term most used is "alias") needs to be different from other users. The real-id-to-alias mapping might be consistent for the whole site, only within a list or a thread, or even be regenerated per-post, depending on the use case. It might be an option, or you can pick one. There has been discussion of this on-list, see the archives. > 2. How do we store the email mapping? The email identifier mapped to the > user's email or list's subscriber id for that user? That's a requirements issue that you should think about and tell us what you decide and why. > Are we looking at implementing an encryption/decryption > algorithm here for additional security? Depends on the threat model, that is, whose anonymity you want to protect from whom.

2 1

Re: [Mailman-Developers] Regarding Subscriber profile pages project
by Barry Warsaw 20 Mar '15

20 Mar '15

On Mar 17, 2015, at 10:36 PM, Ashish Kumar wrote: >1. Use of different email addresses - so called aliases - for sending >emails Mailman 3's model is that users can have one or more addresses linked to their record, and can specific a preferred address. You can subscribe to a mailing list with any specific address, or with the generic preferred address. Thus if the user changes their preferred address, all the subscriptions tied to the preferred automatically get changed over, with no other action on their part. If you're a Launchpad user and have visited your +editemail page, you'll see this exact model played out, and we've been very happy with it. Note too that the subscribed email only defines the address to which your list deliveries will be sent. You can still post to the list with any address linked to your user record, as long as its been verified. Cheers, -Barry

1 0

GSOC'15: Improving styles for lists
by Stephen J. Turnbull 20 Mar '15

20 Mar '15

prakhar joshi writes: > I am thinking of storing the styles in the database by creating a > table for the styles in the db Mailman's databases are not relational dbs, they're object-oriented. Underneath the objects are stored in relational dbs and managed by an ORM (SQLAlchemy), of course, but the Mailman API is object-based. If you want to think of your schema in terms of tables, I don't think you'll have any trouble in design, but when you get to the implementation stage you'll have to shift gears to OODB style. > and this table will contain all the attributes of a style and these > entries can be null too. So a table which will contain a style name > with all its attributes. Now as we have table for mailing list > containing all the attributes in the mailing list table. So now the > style table will contain all these attributes and in the mailing > list table we will just store the mailing list name and the style > name and this way we can connect the two table by providing foreign > key of style_id to the mailing list table? I think this is probably not the best way to go. Some of the attributes change over time, some attributes flip back and forth, and so on. Some lists may have a unique combination not very useful for other lists/list owners. So I think a library of templates so that you can set many attributes at once by applying a template is a better way to go. Also, I suspect it would be useful to allow very incomplete templates so that you could apply template A to get the basic character, then apply template B (which is very incomplete and only changes two attributes) to get the effect you want. I haven't thought about it carefully, so don't just assume everything I wrote is right. Maybe it will be useful for refining your proposal.

3 2

Re: [Mailman-Developers] [Fwd: Re: Discussion about Mailman plugins(GSOC 2015)]
by Barry Warsaw 20 Mar '15

20 Mar '15

On Mar 20, 2015, at 12:35 PM, Aanand Shekhar Roy wrote: >I wonder if we could add our modules of plugin to the var/ext( which is built >for plug-ins), and then importing those modules(i.e. handlers ,rules etc) to >the config.py using python imports, by doing this we wont have to add our >modules to the sys.path and so we will avert the complexities of using >customized paths. Please correct me if I am wrong. Right now config.EXT_DIR (a.k.a. [paths.*]ext_dir or /etc/mailman.d) isn't added to sys.path so imports via dotted module names won't work. Perhaps it should be (or a subdirectory of ext_dir). This is a good directory to use because it's outside the Mailman source code. Cheers, -Barry

1 0

Re: [Mailman-Developers] [Bug 1418276] Re: Deleting a user via the REST API does not delete their user preferences
by Barry Warsaw 20 Mar '15

20 Mar '15

On Mar 20, 2015, at 05:41 PM, Abhishek wrote: >In rest/tests/test_users.py you have used >config.db.store.query(Preferences) inside with. But there is another >usage of it in line 221 and also in the file model/tests/test_user.py >which are not inside with block. Any specific reason for the >difference..? > >230 with transaction(): >231 preferences = config.db.store.query(Preferences).filter_by( >232 id=anne.preferences.id) >233 self.assertEqual(preferences.count(), 0) Yes. The ids don't get assigned until after the commit, so they have to be within the with-statement in order for the subsequent query to work. But after that, the delete does not require a commit for the query to succeed. I don't think this was the case with Storm, but it appears to be so with SQLAlchemy.

1 0

Re: [Mailman-Developers] GSoC 2015 Introduction
by Abhilash Raj 20 Mar '15

20 Mar '15

Hi Ana, On Friday 20 March 2015 09:52 AM, Ana Badescu wrote: > Hello, > > I'm Ana Badescu, and I'm a first year Artificial Intelligence graduate at > Polytechnic University of Bucharest, Faculty of Automatic Control and > Computer Science, looking to participate in GSOC 2015, hopefully with > Mailman! > > You might believe that I arrived late. However, I have just installed the > mailman client, mailman core and the Postorius and got them up and running > in their own env. Can't believe how straight-forward it was! Once I'm done > reading the contribution guides, I'll pick a few bugs to get a better idea > of how the codebase is structured. That is great! You can find some 'easy' tagged bugs on launchpad bug tracker for core as well as postorius. You can also write some non-trivial unit-tests for Postorius as a part of your appplication. > As this is my first GSoC try, I admit I was a bit at a loss facing the huge > diversity of organisations and projects. > > Honestly, there are three reasons that I chose Mailman over: > - it involves areas that I am familiar with and I enjoy working on (Python) > - I started looking at the organisation list and project list on day one. > At least in my opinion, Mailman has one of the most friendly > getting-started guides out there. > - I found the Javascript client project being interesting to me. I do have > quite a lot of experience with node.js, enough to say there is a love-hate > relationship when it comes down to using it in projects. I'm actually doing > my graduation thesis in node. I think it's great idea to get a Javascript > client going, it will be well received by the community as there are a lot > of devs that work solely with js and maybe a few frontend technologies. > Kind of sad but true. > I've also set up a number of RESTful interfaces before, specially in > hackathons where the team members are each using different technologies. There is already another student working on this idea and so there must be some previous discussion this topic in the mailing list archives. Although the idea is simple enough that we need a simple JS client for mailman REST API. But focus should be on good testing framework and better code quality. All the best! -- thanks, Abhilash

1 0

Re: [Mailman-Developers] How do I turn on/off moderation of subscription requests?
by Aurelien Bompard 20 Mar '15

20 Mar '15

> Do you think I can help you work on that? Or would you prefer doing the > initial branch resurrection? > Anything I need to know before I start? > Alright, I resurrected your branch to the best of my understanding. I hope it's more Lazarus than Reanimator. https://code.launchpad.net/~abompard/mailman/subpolicy All tests pass, but there's still a missing part: the new attribute in the MailingList table must still be actually written as a column, and an Alembic migration script must be generated. I'm going to do that in the next hours (or maybe on Monday), but in the meantime this branch only contains your former code, with minor adaptations. Could you check it out? Thanks! Aurélien

1 0