From adam at amyl.org.uk Sat Jan 2 10:03:13 2016 From: adam at amyl.org.uk (Adam McGreggor) Date: Sat, 2 Jan 2016 15:03:13 +0000 Subject: [Mailman-Developers] Student looking to contribute towards GNU Mailman In-Reply-To: <22149.26711.154500.875095@turnbull.sk.tsukuba.ac.jp> References: <56841146.5070306@gmail.com> <22149.26711.154500.875095@turnbull.sk.tsukuba.ac.jp> Message-ID: <20160102150313.GE21217@hendricks.amyl.org.uk> On Fri, Jan 01, 2016 at 02:39:35AM +0900, Stephen J. Turnbull wrote: > https://gitlab.com/mailman/mailman/issues/62 > https://gitlab.com/mailman/postorius/issues/5 > > Neither seems to suggest that anybody is actually working on this > project. Note that the issues are titled "User Profile Pages" rather > than "Subscriber Profile Pages" -- searching for appropriate issues is > an art. Don't kill yourself trying to do an exhaustive search or > coming up with the perfect keywords. > > If you decide to work on this, come up with a summary of what *you* > want to do (it may help to refer to the existing issue descriptions), > and post it as an RFE (request for enhancement), most likely on the > Postorius tracker. That will allow others interested in the project > (both potential users and developers) to find you. Mention that you > are working on the project, and link to the existing issues. For something as common (in principle, at least) as these, I think it might be useful in these posts *as RFEs), to commit an outline/spec (so others can PR against it), which also considers the merits of Things Already Written, and what (if any) enhancements etc they might need (and I suspect they will, as noted, things are scattered about with separate components, rather than a collexion of microservices that plugin). It strikes me that something like this already exists, and may be even as far as 70% there (i.e. general functionality that works well, is well maintained & documented). It also feels (in my mind) a more open-source way of working, and could benefit from receiving updates etc from 'upstream'. > A bit of advice: I tend to disagree with Our Fearless Leader: I think > there's more of a role for "core" in this. Specifically, > discoverability of resources. Resources are spread across the three > main components, and the list archives at least will have multiple > implementations in common use. "Under which project do I raise this bug report?" "oh look, duplication of issues?" "I just want it all working to best practice". -- "The English people are like the English beer-- froth on top, dregs at the bottom; the middle, excellent." -- Voltaire From terri at toybox.ca Tue Jan 5 05:33:04 2016 From: terri at toybox.ca (Terri Oda) Date: Tue, 5 Jan 2016 02:33:04 -0800 Subject: [Mailman-Developers] GSoC 2016 wiki page now up! Message-ID: <568B9BE0.3060900@toybox.ca> I set up an initial page for GSoC 2016 with Mailman: http://wiki.list.org/DEV/Google_Summer_of_Code_2016 Students: Please take a look at the page and let us know if it has the information you're looking for, other than project ideas (those are coming!) Mentors: I put my name at the bottom so students know who to bug on IRC or expect to hear from on the mailing lists, feel free to add your own! Mentors and community members: Is anyone interested in doing a brainstorming session for project ideas this weekend? I'm thinking around 10-11am Pacific US on Sunday, which would be early evening for the Europeans (7pm in Germany) and early afternoon (1pm) for the US Eastern folk. It's terrible for Japan and India, but we can do two brainstorming sessions or you can try to get me to wake up earlier. ;) Terri From rishab.jaju97 at gmail.com Tue Jan 5 06:35:18 2016 From: rishab.jaju97 at gmail.com (Rishab Jaju) Date: Tue, 5 Jan 2016 17:05:18 +0530 Subject: [Mailman-Developers] GSoC 2016 wiki page now up! In-Reply-To: <568B9BE0.3060900@toybox.ca> References: <568B9BE0.3060900@toybox.ca> Message-ID: Won't the ideas page for previous years be valid? Some projects from previous years must still be incomplete, right? On Tue, Jan 5, 2016 at 4:03 PM, Terri Oda wrote: > I set up an initial page for GSoC 2016 with Mailman: > > http://wiki.list.org/DEV/Google_Summer_of_Code_2016 > > Students: Please take a look at the page and let us know if it has the > information you're looking for, other than project ideas (those are coming!) > > Mentors: I put my name at the bottom so students know who to bug on IRC or > expect to hear from on the mailing lists, feel free to add your own! > > Mentors and community members: Is anyone interested in doing a > brainstorming session for project ideas this weekend? > > I'm thinking around 10-11am Pacific US on Sunday, which would be early > evening for the Europeans (7pm in Germany) and early afternoon (1pm) for > the US Eastern folk. It's terrible for Japan and India, but we can do two > brainstorming sessions or you can try to get me to wake up earlier. ;) > > Terri > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/rishab.jaju97%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 > From terri at toybox.ca Wed Jan 6 00:20:29 2016 From: terri at toybox.ca (Terri Oda) Date: Tue, 5 Jan 2016 21:20:29 -0800 Subject: [Mailman-Developers] GSoC 2016 wiki page now up! In-Reply-To: References: <568B9BE0.3060900@toybox.ca> Message-ID: <568CA41D.8030208@toybox.ca> Some of last year's page will totally be valid, for sure! But there have definitely been changes, and some old ideas that no one's gotten excited about will likely be rotated out. One big change is the switch to gitlab, which means some of our instructions have to change and it even affects some of the projects (there's one up there now for GitLab integration that used to be described as primarily about GitHub integration!) Terri On 2016-01-05 3:35 AM, Rishab Jaju wrote: > Won't the ideas page for previous years be valid? Some projects from > previous years must still be incomplete, right? > > On Tue, Jan 5, 2016 at 4:03 PM, Terri Oda wrote: > >> I set up an initial page for GSoC 2016 with Mailman: >> >> http://wiki.list.org/DEV/Google_Summer_of_Code_2016 >> >> Students: Please take a look at the page and let us know if it has the >> information you're looking for, other than project ideas (those are coming!) >> >> Mentors: I put my name at the bottom so students know who to bug on IRC or >> expect to hear from on the mailing lists, feel free to add your own! >> >> Mentors and community members: Is anyone interested in doing a >> brainstorming session for project ideas this weekend? >> >> I'm thinking around 10-11am Pacific US on Sunday, which would be early >> evening for the Europeans (7pm in Germany) and early afternoon (1pm) for >> the US Eastern folk. It's terrible for Japan and India, but we can do two >> brainstorming sessions or you can try to get me to wake up earlier. ;) >> >> Terri >> >> _______________________________________________ >> Mailman-Developers mailing list >> Mailman-Developers at 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/rishab.jaju97%40gmail.com >> >> Security Policy: http://wiki.list.org/x/QIA9 >> > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/terri%40toybox.ca > > Security Policy: http://wiki.list.org/x/QIA9 > From barry at list.org Wed Jan 6 11:27:48 2016 From: barry at list.org (Barry Warsaw) Date: Wed, 6 Jan 2016 11:27:48 -0500 Subject: [Mailman-Developers] GSoC 2016 wiki page now up! In-Reply-To: <568B9BE0.3060900@toybox.ca> References: <568B9BE0.3060900@toybox.ca> Message-ID: <20160106112748.351f33a7@limelight.wooz.org> On Jan 05, 2016, at 02:33 AM, Terri Oda wrote: >Mentors and community members: Is anyone interested in doing a brainstorming >session for project ideas this weekend? > >I'm thinking around 10-11am Pacific US on Sunday, which would be early >evening for the Europeans (7pm in Germany) and early afternoon (1pm) for the >US Eastern folk. It's terrible for Japan and India, but we can do two >brainstorming sessions or you can try to get me to wake up earlier. ;) I'd be up for that, as long as we're done by about 4pm US/Eastern. I have a date with a TV, a pigskin, a burgundy and gold painted belly, and a sore throat from cheering very loudly. -Barry From etienne.loks at iggdrasil.net Wed Jan 6 10:12:55 2016 From: etienne.loks at iggdrasil.net (=?UTF-8?Q?=c3=89tienne_Loks?=) Date: Wed, 6 Jan 2016 16:12:55 +0100 Subject: [Mailman-Developers] Mailman 3: some non member allowed to post on a mailing list Message-ID: <568D2EF7.3010603@iggdrasil.net> Hi, I'm beginning to use mailman 3. One of the nice feature in mailman 2 was the ability to allow specific non-member of a list to post in it. I don't find a way to do this in mailman 3 and as far as I understand this page http://www.pythonhosted.org/mailman/src/mailman/model/docs/membership.html it seems that there is no automatic way of dealing with this. Am I wrong? -- ?tienne Loks From barry at list.org Wed Jan 6 18:20:33 2016 From: barry at list.org (Barry Warsaw) Date: Wed, 6 Jan 2016 18:20:33 -0500 Subject: [Mailman-Developers] Mailman 3: some non member allowed to post on a mailing list In-Reply-To: <568D2EF7.3010603@iggdrasil.net> References: <568D2EF7.3010603@iggdrasil.net> Message-ID: <20160106182033.6df66f95@anarchist.wooz.org> On Jan 06, 2016, at 04:12 PM, ?tienne Loks via Mailman-Developers wrote: >I'm beginning to use mailman 3. One of the nice feature in mailman 2 was the >ability to allow specific non-member of a list to post in it. > >I don't find a way to do this in mailman 3 and as far as I understand this >page >http://www.pythonhosted.org/mailman/src/mailman/model/docs/membership.html it >seems that there is no automatic way of dealing with this. This is really what you want to read. There's a new 'nonmember' rule that checks for posting conditions described here: http://mailman.readthedocs.org/en/release-3.0/src/mailman/chains/docs/moderation.html#nonmembers "Members" are users or addresses subscribed to mailing lists, and every member has a role and a moderation_action. "Non-member" is a valid role. So the idea is that you "subscribe" a non-member to a mailing list and give them a moderation_action of 'accept'. Then their postings won't be held for approval. Mailman 3 also supports the legacy *_these_nonmember fields, e.g. accept_these_nonmembers, which must contain email addresses or, if the string starts with a ^ it's interpreted as a regular express, just as with Mailman 2.1. Cheers, -Barry From stephen at xemacs.org Wed Jan 6 23:11:30 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 7 Jan 2016 13:11:30 +0900 Subject: [Mailman-Developers] GSoC 2016 wiki page now up! In-Reply-To: <568B9BE0.3060900@toybox.ca> References: <568B9BE0.3060900@toybox.ca> Message-ID: <22157.58738.27134.666524@turnbull.sk.tsukuba.ac.jp> Terri Oda writes: > Mentors and community members: Is anyone interested in doing a > brainstorming session for project ideas this weekend? I'll think about it and if I have any ideas I'll send email. > I'm thinking around 10-11am Pacific US on Sunday, which would be > early evening for the Europeans (7pm in Germany) and early > afternoon (1pm) for the US Eastern folk. It's terrible for Japan > and India, but we can do two brainstorming sessions or you can try > to get me to wake up earlier. ;) Don't worry about me. I'm up to my ass in alligators, trying to find my way through a maze of twisty little theses, all alike. So I won't really be able to break free at this time anyway. Steve From stephen at xemacs.org Wed Jan 6 23:11:51 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 7 Jan 2016 13:11:51 +0900 Subject: [Mailman-Developers] GSoC 2016 wiki page now up! In-Reply-To: <568CA41D.8030208@toybox.ca> References: <568B9BE0.3060900@toybox.ca> <568CA41D.8030208@toybox.ca> Message-ID: <22157.58759.879586.561460@turnbull.sk.tsukuba.ac.jp> Terri Oda writes: > One big change is the switch to gitlab, which means some of our > instructions have to change and it even affects some of the projects > (there's one up there now for GitLab integration that used to be > described as primarily about GitHub integration!) And I'll update HOWTO SPAM and move it to the Wiki. Does anybody care about changing the title (ie, the word "spam", which I thought appropriate since we're Python-based, but ...)? If so, suggestions welcome. From cnulk at scu.edu Thu Jan 7 12:30:47 2016 From: cnulk at scu.edu (Chris Nulk) Date: Thu, 7 Jan 2016 09:30:47 -0800 Subject: [Mailman-Developers] Mailman 3: some non member allowed to post on a mailing list In-Reply-To: <20160106182033.6df66f95@anarchist.wooz.org> References: <568D2EF7.3010603@iggdrasil.net> <20160106182033.6df66f95@anarchist.wooz.org> Message-ID: <568EA0C7.8060809@scu.edu> On 1/6/2016 3:20 PM, Barry Warsaw wrote: > On Jan 06, 2016, at 04:12 PM, ?tienne Loks via Mailman-Developers wrote: > >> I'm beginning to use mailman 3. One of the nice feature in mailman 2 was the >> ability to allow specific non-member of a list to post in it. >> >> I don't find a way to do this in mailman 3 and as far as I understand this >> page >> http://www.pythonhosted.org/mailman/src/mailman/model/docs/membership.html it >> seems that there is no automatic way of dealing with this. > This is really what you want to read. There's a new 'nonmember' rule that > checks for posting conditions described here: > > http://mailman.readthedocs.org/en/release-3.0/src/mailman/chains/docs/moderation.html#nonmembers > > "Members" are users or addresses subscribed to mailing lists, and every member > has a role and a moderation_action. "Non-member" is a valid role. So the > idea is that you "subscribe" a non-member to a mailing list and give them a > moderation_action of 'accept'. Then their postings won't be held for > approval. > > Mailman 3 also supports the legacy *_these_nonmember fields, > e.g. accept_these_nonmembers, which must contain email addresses or, if the > string starts with a ^ it's interpreted as a regular express, just as with > Mailman 2.1. Will Mailman 3 also accept a string starting with @ to be interpreted as a list to be used, just as with later versions of Mailman 2.1? Thanks, Chris From barry at list.org Thu Jan 7 14:29:07 2016 From: barry at list.org (Barry Warsaw) Date: Thu, 7 Jan 2016 14:29:07 -0500 Subject: [Mailman-Developers] Mailman 3: some non member allowed to post on a mailing list In-Reply-To: <568EA0C7.8060809@scu.edu> References: <568D2EF7.3010603@iggdrasil.net> <20160106182033.6df66f95@anarchist.wooz.org> <568EA0C7.8060809@scu.edu> Message-ID: <20160107142907.7d52c1fa@limelight.wooz.org> On Jan 07, 2016, at 09:30 AM, Chris Nulk wrote: >Will Mailman 3 also accept a string starting with @ to be interpreted as >a list to be used, just as with later versions of Mailman 2.1? Not currently, because that landed in MM2.1 after the split. Merge requests welcome, of course. Cheers, -Barry From rishab.jaju97 at gmail.com Sun Jan 10 00:33:00 2016 From: rishab.jaju97 at gmail.com (Rishab Jaju) Date: Sun, 10 Jan 2016 11:03:00 +0530 Subject: [Mailman-Developers] Building mailman Message-ID: Hi all, I am trying to build mailman. I assume these are the instructions: http://wiki.list.org/HyperKitty/DevelopmentSetupGuide Although the page is for Hyperkitty, I assume that others will be built in the same way since that is the only page I could find. I can't clone the repositories from gitlab. It gives me the following error: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. How do I solve that error? Also, am I following the correct build instructions? Thanks, Rishab. From etienne.loks at iggdrasil.net Sun Jan 10 07:37:39 2016 From: etienne.loks at iggdrasil.net (=?UTF-8?Q?=c3=89tienne_Loks?=) Date: Sun, 10 Jan 2016 13:37:39 +0100 Subject: [Mailman-Developers] Mailman 3: some non member allowed to post on a mailing list In-Reply-To: <20160106182033.6df66f95@anarchist.wooz.org> References: <568D2EF7.3010603@iggdrasil.net> <20160106182033.6df66f95@anarchist.wooz.org> Message-ID: <56925093.5090609@iggdrasil.net> Le 07/01/2016 00:20, Barry Warsaw a ?crit : > This is really what you want to read. There's a new 'nonmember' rule that > checks for posting conditions described here: > > http://mailman.readthedocs.org/en/release-3.0/src/mailman/chains/docs/moderation.html#nonmembers > > "Members" are users or addresses subscribed to mailing lists, and every member > has a role and a moderation_action. "Non-member" is a valid role. So the > idea is that you "subscribe" a non-member to a mailing list and give them a > moderation_action of 'accept'. Then their postings won't be held for > approval. Thanks for the explanation! I have tried different things with the python client to achieve this but with no results. I don't know if there are missing features in the client or if I have misunderstood something. For instance for known email: ======================================================================== client = Client('http://localhost:8001/3.0', 'restadmin', 'restpass') my_list = client.get_list(ml_id) # my_list.nonmembers is a list no "get_member" method for nm in my_list.nonmembers: if nm.email == email_to_add: pass # no moderation_action ======================================================================== Or to "subscribe" an unknown email: ======================================================================== my_list.add_role('non-member', email_to_add) # non-member / nonmember / etc. are not considered as valid roles ======================================================================== As a fallback I have tried to edit directly the database: ======================================================================== conn = sqlite3.connect(DB) c = conn.cursor() sql = """ UPDATE member set moderation_action=? WHERE member.list_id=? and member.address_id = ( SELECT id from address where email=?)""" c.execute(sql, [Action.accept.value, ml_id, email_to_add]) conn.commit() ======================================================================== But with no result. Thanks for any help! -- ?tienne Loks From mark at msapiro.net Sun Jan 10 12:29:26 2016 From: mark at msapiro.net (Mark Sapiro) Date: Sun, 10 Jan 2016 09:29:26 -0800 Subject: [Mailman-Developers] Building mailman In-Reply-To: References: Message-ID: <569294F6.6080907@msapiro.net> On 01/09/2016 09:33 PM, Rishab Jaju wrote: > Hi all, > > I am trying to build mailman. I assume these are the instructions: > http://wiki.list.org/HyperKitty/DevelopmentSetupGuide > > Although the page is for Hyperkitty, I assume that others will be built in > the same way since that is the only page I could find. You should see and . > I can't clone the repositories from gitlab. It gives me the following error: > Permission denied (publickey). > fatal: Could not read from remote repository. > Please make sure you have the correct access rights > and the repository exists. The above error indicates you are using ssh to clone the repository from gitlab but you haven't registered and provided an ssh public key on gitlab. The easiest way around this is to use http instead. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From gauravmittal1995 at gmail.com Sun Jan 10 18:11:47 2016 From: gauravmittal1995 at gmail.com (Gaurav Mittal) Date: Mon, 11 Jan 2016 04:41:47 +0530 Subject: [Mailman-Developers] Getting Started Message-ID: Hi, I want to introduce myself. I am a 3rd year student pursuing my B.Tech in CSE from International Institute of Information Technology, Hyderabad. I want to start contributing to Mailman and also hoping to do GSOC'16 with mailman. How do i begin? Thanks From raj.abhilash1 at gmail.com Sun Jan 10 22:10:45 2016 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Sun, 10 Jan 2016 19:10:45 -0800 Subject: [Mailman-Developers] Getting Started In-Reply-To: References: Message-ID: <56931D35.9080100@gmail.com> Hi Gaurav, On 01/10/2016 03:11 PM, Gaurav Mittal wrote: > Hi, > I want to introduce myself. I am a 3rd year student pursuing my B.Tech in > CSE from International Institute of Information Technology, Hyderabad. Welcome and thanks for your interest in Mailman. > I want to start contributing to Mailman and also hoping to do GSOC'16 with > mailman. How do i begin? You can start by reading a bit about mailman from the website (list.org) and digging out getting started guide. I could give you the direct links, but it isn't really very hard to find them I guess. Let me know if you really don't really find the Getting Started Guide on http://wiki.list.org or http://list.org. Make sure that you look for Mailman Suite 3.0 and not mailman 2.0 which is not actively developed now. After you think you know enough about Mailman, you can then try to fix some small easy bugs in Mailman core or any of its sister projects (Postorius - the Web UI, Hyperkitty - the Archiver, Client - Python bindings). There might be less number or bugs actually tagged "easy" or "beginner friendly", but you can explore other bugs too. If you have any problems/questions, ask questions here or on #mailman on Freenode(IRC). -- thanks, Abhilash Raj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From anirudhdahiya9 at gmail.com Mon Jan 11 06:48:08 2016 From: anirudhdahiya9 at gmail.com (Anirudh Dahiya) Date: Mon, 11 Jan 2016 17:18:08 +0530 Subject: [Mailman-Developers] Facing error while building mailman Message-ID: Hello I have built mailman but upon running the server and opening the interface i am facing a 403 Forbidden error. I am behind a proxy. Please guide. Link to trace - http://dpaste.com/074YZZK Thanks From raj.abhilash1 at gmail.com Mon Jan 11 13:48:01 2016 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Mon, 11 Jan 2016 10:48:01 -0800 Subject: [Mailman-Developers] Facing error while building mailman In-Reply-To: References: Message-ID: <5693F8E1.3020307@gmail.com> Hi Anirudh, Can you tell us a few other things too? Which version of Mailman are you using? (From the django output in the trace I am guessing it is 3.0, but just to confirm). What do you mean by behind a proxy? Is the server behind a proxy and the client/Postorius trying to access the server through proxy? I *think* Postorius/HK is not Django 1.9+ compatible for some reason, can you try out with django version <=1.8? On 01/11/2016 03:48 AM, Anirudh Dahiya wrote: > Hello > I have built mailman but upon running the server and opening the interface > i am facing a 403 Forbidden error. I am behind a proxy. Please guide. > Link to trace - http://dpaste.com/074YZZK > Thanks > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/raj.abhilash1%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 > -- thanks, Abhilash Raj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From stephen at xemacs.org Mon Jan 11 21:06:16 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 12 Jan 2016 11:06:16 +0900 Subject: [Mailman-Developers] Facing error while building mailman In-Reply-To: <5693F8E1.3020307@gmail.com> References: <5693F8E1.3020307@gmail.com> Message-ID: <22164.24472.190869.126112@turnbull.sk.tsukuba.ac.jp> This -- "Python Version: 2.7.9" is also a problem for recent Mailman 3 (since 3.1 IIRC) -- Mailman 3 is only supported on Python 3. I guess this is Postorius and it's still OK for 2.7 (upgrading to the most recent Python 2 version, which I believe is 2.7.11, is probably a good idea, as there were security issues in 2.7.9 and 2.7.10). I would guess that your proxy simply isn't permitted to access the REST port by the server. Check firewall settings and try a simple client such as wget or curl from the Mailman host. If you get the same result (ie, 403 Forbidden) with those clients, then you're going to need to talk to your local administrators about how to configure the firewall to permit Postorius to talk to Mailman. Steve From terri at toybox.ca Tue Jan 12 01:11:34 2016 From: terri at toybox.ca (Terri Oda) Date: Mon, 11 Jan 2016 22:11:34 -0800 Subject: [Mailman-Developers] Getting Started In-Reply-To: <56931D35.9080100@gmail.com> References: <56931D35.9080100@gmail.com> Message-ID: <56949916.2060004@toybox.ca> On 2016-01-10 7:10 PM, Abhilash Raj wrote: > After you think you know enough about > Mailman, you can then try to fix some small easy bugs in Mailman core or > any of its sister projects (Postorius - the Web UI, Hyperkitty - the > Archiver, Client - Python bindings). There might be less number or bugs > actually tagged "easy" or "beginner friendly", but you can explore other > bugs too. If you have any problems/questions, ask questions here or on > #mailman on Freenode(IRC). Also, if you aren't finding bugs that suit you, you might want to consider adding tests. Since our test suites are relatively young, there's definitely some common use-cases missing that you could write. For example, the postorius tests can be found here: https://gitlab.com/mailman/postorius/tree/master/src/postorius/tests And here's a scenario without a test: What happens if the address you're trying to subscribe is on the banned list? Answer, it should fail to subscribe you, and give an appropriate error message. But if you look in ListSubscribeTest under https://gitlab.com/mailman/postorius/blob/master/src/postorius/tests/test_forms.py you'll see that we test invalid emails but not banned ones. I've filed an issue for this here: https://gitlab.com/mailman/postorius/issues/80 So if anyone wants to write this test case, you can claim that bug so everyone knows you're working on it! Making test cases that would catch recent bugs is a good way to get started if you can't think of any missing test cases on your own, too: Here's one that recently came up in a Postorius bug: what happens if you log in as a moderator using an alternative email address? The user *should* still see the moderation interface, but due to the bug you didn't -- a test case could have caught this! I leave checking to see if we have a test case for this and filing an issue if we don't as an exercise to the reader. ;) Terri From anirudhdahiya9 at gmail.com Tue Jan 12 12:36:46 2016 From: anirudhdahiya9 at gmail.com (Anirudh Dahiya) Date: Tue, 12 Jan 2016 23:06:46 +0530 Subject: [Mailman-Developers] Facing error while building mailman In-Reply-To: <22164.24472.190869.126112@turnbull.sk.tsukuba.ac.jp> References: <5693F8E1.3020307@gmail.com> <22164.24472.190869.126112@turnbull.sk.tsukuba.ac.jp> Message-ID: Hello I was building Mailman 3. The server is behind a proxy. I was using Django 1.9.1 . After fixing my /etc/environment file to set the correct proxy thing the 403 Forbidden error was resolved well. Another thing I faced was the unsuported keyword used in django render_to_string(template,context_instance=final_context) method. I manually changed it to replace just the context_instance part with context=final_context(checked django docs for that) and things worked out fine after that. Its finally working now. I hope I can start contributing soon! Thanks for the guidance Anirudh On Tue, Jan 12, 2016 at 7:36 AM, Stephen J. Turnbull wrote: > This -- "Python Version: 2.7.9" is also a problem for recent Mailman 3 > (since 3.1 IIRC) -- Mailman 3 is only supported on Python 3. I guess > this is Postorius and it's still OK for 2.7 (upgrading to the most > recent Python 2 version, which I believe is 2.7.11, is probably a good > idea, as there were security issues in 2.7.9 and 2.7.10). > > I would guess that your proxy simply isn't permitted to access the > REST port by the server. Check firewall settings and try a simple > client such as wget or curl from the Mailman host. If you get the > same result (ie, 403 Forbidden) with those clients, then you're going > to need to talk to your local administrators about how to configure > the firewall to permit Postorius to talk to Mailman. > > Steve > > From stephen at xemacs.org Thu Jan 14 22:14:38 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 15 Jan 2016 12:14:38 +0900 Subject: [Mailman-Developers] Facing error while building mailman In-Reply-To: References: <5693F8E1.3020307@gmail.com> <22164.24472.190869.126112@turnbull.sk.tsukuba.ac.jp> Message-ID: <22168.25630.312122.208793@turnbull.sk.tsukuba.ac.jp> Glad to hear that! Keep us informed about what you're doing, and also any problems you have even if you can resolve them yourself. We want the experience for non-developer users to be as smooth as possible. Steve Anirudh Dahiya writes: > Hello > I was building Mailman 3. > The server is behind a proxy. > I was using Django 1.9.1 . > After fixing my /etc/environment file to set the correct proxy thing the > 403 Forbidden error was resolved well. > Another thing I faced was the unsuported keyword used in django > render_to_string(template,context_instance=final_context) method. I > manually changed it to replace just the context_instance part with > context=final_context(checked django docs for that) and things worked out > fine after that. Its finally working now. I hope I can start contributing > soon! > Thanks for the guidance > Anirudh > > > > On Tue, Jan 12, 2016 at 7:36 AM, Stephen J. Turnbull > wrote: > > > This -- "Python Version: 2.7.9" is also a problem for recent Mailman 3 > > (since 3.1 IIRC) -- Mailman 3 is only supported on Python 3. I guess > > this is Postorius and it's still OK for 2.7 (upgrading to the most > > recent Python 2 version, which I believe is 2.7.11, is probably a good > > idea, as there were security issues in 2.7.9 and 2.7.10). > > > > I would guess that your proxy simply isn't permitted to access the > > REST port by the server. Check firewall settings and try a simple > > client such as wget or curl from the Mailman host. If you get the > > same result (ie, 403 Forbidden) with those clients, then you're going > > to need to talk to your local administrators about how to configure > > the firewall to permit Postorius to talk to Mailman. > > > > Steve > > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/stephen%40xemacs.org > > Security Policy: http://wiki.list.org/x/QIA9 > From harshitbansal2015 at gmail.com Fri Jan 15 12:33:21 2016 From: harshitbansal2015 at gmail.com (Harshit Bansal) Date: Fri, 15 Jan 2016 23:03:21 +0530 Subject: [Mailman-Developers] Introductory Mail Message-ID: 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. From raj.abhilash1 at gmail.com Fri Jan 15 15:07:00 2016 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Fri, 15 Jan 2016 12:07:00 -0800 Subject: [Mailman-Developers] Introductory Mail In-Reply-To: References: Message-ID: <56995164.7080205@gmail.com> Hi Harshit, On 01/15/2016 09:33 AM, Harshit Bansal wrote: > 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. Thanks for choosing Mailman and welcome! Do not hesitate to ask questions here or on IRC channel #mailman at freenode. > 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 at 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/raj.abhilash1%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 > -- thanks, Abhilash Raj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From simon.hanna at serve-me.info Fri Jan 15 21:17:38 2016 From: simon.hanna at serve-me.info (Simon Hanna) Date: Sat, 16 Jan 2016 03:17:38 +0100 Subject: [Mailman-Developers] Availability as a mentor Message-ID: <5699A842.9060201@serve-me.info> Hi, (mainly for Florian, but it's not secret) Since I'm a student, I was thinking about applying for a GSoC spot this summer, but I'll probably not have the time for it, so I won't do that. I would however have enough time to be a mentor. (Google says about 5h a week per student, I could manage up to 10h I guess) The code of the mailman-suite I know best is postorius, so if a mentor is needed for that, I'm available. I could of course still manage mentoring other projects. A little bio: I'm a 24 year old computer science student, currently pursuing my master degree. I'm studying in Stuttgart, Germany. I'm fluent in English, German and Arabic (but I really don't like typing Arabic ^^) I was a tutor for about 8 different computing courses at my University. I was always responsible for a group of up to 20 students. My job was to help them with their assignments, grade them and explain stuff they didn't understand in the lectures. The courses included practical programming courses, programming languages, distributed computing and computer networks, algorithms and data structures, ... If you want to look at my code, you'll find most of it in postorius where my username is 'thelinuxguy'. So, if a mentor is needed, I'm available :-) Feel free to ask any questions... Simon From ankush.rawat95 at gmail.com Sat Jan 16 16:37:18 2016 From: ankush.rawat95 at gmail.com (Ankush Khandelwal) Date: Sun, 17 Jan 2016 03:07:18 +0530 Subject: [Mailman-Developers] Newbie to the "Mailman" Message-ID: Hello, I am an undergraduate student pursuing Computer Science from IIIT Hyderabad ( India ), currently in 3rd year and I'm newbie to this organization. I am familiar with python and Git. Can somebody tell me about the bugs which I can solve so that I can start contributing. Thanks Ankush khandelwal From stephen at xemacs.org Sat Jan 16 18:48:06 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sun, 17 Jan 2016 08:48:06 +0900 Subject: [Mailman-Developers] Newbie to the "Mailman" In-Reply-To: References: Message-ID: <22170.54966.167748.265842@turnbull.sk.tsukuba.ac.jp> Ankush Khandelwal writes: > I am an undergraduate student pursuing Computer Science from IIIT > Hyderabad ( India ), currently in 3rd year and I'm newbie to this > organization. I am familiar with python and Git. Can somebody tell > me about the bugs which I can solve so that I can start > contributing. Any of the ones listed at https://gitlab.com/mailman/mailman/issues/? That's a joke, of course, but unfortunately the list if you select label "beginner-friendly" is rather sparse (currently 1 issue is listed). So at this point nobody really has a handle on this. One *really* useful task you could do is go through a handful of issues (say 10-25) and label the ones you think you *could* do as "beginner-friendly" (and grab any you *like* by adding a comment that you're working on them :-). Then post the list of issues you evaluated (with the results) so somebody can (a) check your evaluations for you, (b) we get a better idea of what new developers *think* they can do (as opposed to our idea of what we think they should be able to do), and (c) change any that are actually far deeper than they look. Such "triage"[1] is a more or less neglected task for all the projects I know of. Of course coding is more fun, but (at least at Mailman's current state of 1 open "beginner-friendly" issue) triage is more productive. Steve Footnotes: [1] https://docs.python.org/devguide/triaging.html This page is for Python, but the basic principles apply to any project. From harshitbansal2015 at gmail.com Sun Jan 17 12:22:36 2016 From: harshitbansal2015 at gmail.com (Harshit Bansal) Date: Sun, 17 Jan 2016 22:52:36 +0530 Subject: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" . Message-ID: 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. From raj.abhilash1 at gmail.com Sun Jan 17 15:14:42 2016 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Sun, 17 Jan 2016 12:14:42 -0800 Subject: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" . In-Reply-To: References: Message-ID: <569BF632.3010906@gmail.com> 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. > > 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. Your understanding is actually good, but more generic as of now. Styles are the term used in Mailman to accumulate a certain list of list-settings that change the behavior of the list. There are some pre-defined styles like "Announce", "General", "Moderation" etc that you can find in src/mailman/styles/base.py in the mailman-core source code[1]. Right now, styles can only be applied to a mailing list when they are created. And there is no way right now to create new styles without modifying the source code. The official Web UI for Mailman is called Postorius and talks to the mailman-core via HTTP REST API. So you'd have to expose the styles via REST API and then implement it in the Postorius (which is a Django application). Some major challenges for your project (not exhaustive) that I would like to see addressed in the application are: 1) Figure out how to store and access the styles as some of them are defined in the source code and the ones created by users would have to be stored in database. 2) How to apply styles to lists after they have been created? 3) Should we even allow changing list styles after lists have been created? Does changing a style in database/source code change the settings for list? 4) See what happens when a style is changed now? Is it propagated down to the lists or only the new lists inherit that? > 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. 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? One useful feature I can think of from the UI point of view is to be able to copy an existing style to create a new style and then present with the interface to customize the new style. > 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. This "back-end" code is usually a part of Mailman-Core which takes care of all the actual logic and mail processing. > > 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? I think an integration with Postorius would be sufficiently big for a Summer. We already have a command line interface for mailman that can be extended to add this functionality. [1]: https://gitlab.com/mailman/mailman -- thanks, Abhilash Raj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From siddhartha.gairola18 at gmail.com Sun Jan 17 16:20:26 2016 From: siddhartha.gairola18 at gmail.com (Siddhartha Gairola) Date: Mon, 18 Jan 2016 02:50:26 +0530 Subject: [Mailman-Developers] Need Assistance Message-ID: Dear Developers, I am new to this community and have set up the dev environment. If you could assist me as to how I should proceed now. it would be helpful if I could get started with some beginner level bug fixes. Thanking you. Regards, Siddhartha Gairola From stephen at xemacs.org Sun Jan 17 20:34:06 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 18 Jan 2016 10:34:06 +0900 Subject: [Mailman-Developers] Need Assistance In-Reply-To: References: Message-ID: <22172.16654.442826.680251@turnbull.sk.tsukuba.ac.jp> Siddhartha Gairola writes: > If you could assist me as to how I should proceed now. Start at https://www.mail-archive.com/mailman-developers at python.org/. A couple of months' worth at first, then the last year or two. First, this question, and several other relevant questions, have been answered recently. Second, the archives provide background for understanding the current focus of development. Then, it's important that you test any changes you make, both with unit tests and with a "live" installation. It doesn't need to go over the Internet -- just localhost is enough in most cases -- but you do need a real MTA (Postfix and Exim are supported and recommended) and later, for the Postorius and HyperKitty components, a WGSI-capable webserver (all the usual suspects will work; the Django internal testing server is not good enough). Finally, for more hints on developing, you should look at http://wiki.list.org/DEV/Google_Summer_of_Code_2015 (the 2016 version is still under construction, but the generic hints you want are fully developed in last year's version). Happy hacking! Steve From jefsey at jefsey.com Thu Jan 21 04:47:00 2016 From: jefsey at jefsey.com (JFC Morfin) Date: Thu, 21 Jan 2016 10:47:00 +0100 Subject: [Mailman-Developers] an impossible need to address ? Message-ID: <3pmKfG065RzFr4K@mail.python.org> Hi! I am a new comer on this list. I am an old cyberactivist and an administrator of more than 100 mailman lists and I would need to operate much more for a budled project trough a user/feature database. It means a way (1) to set-up scores of same style mailing lists and (2) for a person being a member of my directory to easiliy select the lists she wants to attend or quit. My idea is to get it simple, non interfering and robust by having an independent database used to generate an update script on a cron basis and that scri^pt being run to create/update the necessary mailman instances. 1) would such a system already exist? 2) considered your experience of mailman do you think such a system could realisticly be feasible and work? 3) I never looked at the mailman code yet : where in it should I have a look? 4) would this be a big work? 5) where could I get some help to develop it? Thank you for attention and response. Best jfcm From terri at toybox.ca Fri Jan 22 00:17:36 2016 From: terri at toybox.ca (Terri Oda) Date: Thu, 21 Jan 2016 21:17:36 -0800 Subject: [Mailman-Developers] an impossible need to address ? In-Reply-To: <3pmKfG065RzFr4K@mail.python.org> References: <3pmKfG065RzFr4K@mail.python.org> Message-ID: <56A1BB70.7030708@toybox.ca> On 2016-01-21 1:47 AM, JFC Morfin wrote: > Hi! > > I am a new comer on this list. I am an old cyberactivist and an > administrator of more than 100 mailman lists and I would need to operate > much more for a budled project trough a user/feature database. It means > a way (1) to set-up scores of same style mailing lists and (2) for a > person being a member of my directory to easiliy select the lists she > wants to attend or quit. My idea is to get it simple, non interfering > and robust by having an independent database used to generate an update > script on a cron basis and that scri^pt being run to create/update the > necessary mailman instances. You could add this pretty easily in Mailman 3, which uses data structures that can handle that. Basically, take a look at the postorius "subscription based preferences" page under "my settings", and all you'd need to do is add a column that allowed people to choose to subscribe or unsubscribe. (you can right now turn mail delivery on/off and edit the other preferences, but not actually unsubscribe from that page.) In Mailman 2, it's much harder, because the data structures are such that there's not really a concept of a user, so you'd have to fake it by going through each list, seeing if a given email address was in it, and collating all that information. If you look at the code that runs when you click "list my other subscriptions" in the user options page, and that would give you a good idea of how it can be done. Terri From stephen at xemacs.org Fri Jan 22 00:27:13 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 22 Jan 2016 14:27:13 +0900 Subject: [Mailman-Developers] an impossible need to address ? In-Reply-To: <3pmKfG065RzFr4K@mail.python.org> References: <3pmKfG065RzFr4K@mail.python.org> Message-ID: <22177.48561.235115.72604@turnbull.sk.tsukuba.ac.jp> I see I'm duplicating much of what Terri wrote but there's some new information here. With that caveat (must run, no time to edit), here we go: JFC Morfin writes: > database. It means a way (1) to set-up scores of same style mailing > lists and (2) for a person being a member of my directory to easiliy > select the lists she wants to attend or quit. For (1), Mailman 3 lists are database-backed (currently PostgreSQL, MySQL, and SQLite are supported, either of the first two should easily scale to your requirements). Setting up list styles easily is not yet well-supported, but we hope to have a Google Summer of Code student work on that feature this summer. The Postorius web interface supports (2) quite well. > My idea is to get it simple, non interfering and robust by having > an independent database used to generate an update script on a cron > basis and that scri^pt being run to create/update the necessary > mailman instances. This turns out to work but it's not as easy as you would hope. Mailman 3 should soon include the necessary features, but on the other hand it is already working with Mailman 2. AFAIK systems like cPanel don't really support (1) or (2) all that well. But I know that there are lots of homebrew systems out there at universities and corporations. From mark at msapiro.net Fri Jan 22 00:51:46 2016 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 21 Jan 2016 21:51:46 -0800 Subject: [Mailman-Developers] an impossible need to address ? In-Reply-To: <3pmKfG065RzFr4K@mail.python.org> References: <3pmKfG065RzFr4K@mail.python.org> Message-ID: <56A1C372.5060807@msapiro.net> On 01/21/2016 01:47 AM, JFC Morfin wrote: > > It means > a way (1) to set-up scores of same style mailing lists and (2) for a > person being a member of my directory to easiliy select the lists she > wants to attend or quit. Just to add a bit to what Terri and Steve have already said. For MM 2.1, for (1) you can setup a list in the style you want, export its config with Mailman's bin/config_list, delete a few list specific things from that output like real_name, owner and subject_prefix, and then for a new list, create it with bin/newlist and update the config with bin/config_list with the prior style as input. for (2) if you can export from your directory a flat file of Display Name entries that represent who should be on a list, then you can use bin/sync_members to sync the list membership with that file. I do that for the 'all members announce list' for my bike club. A cron runs nightly to export the member list from the member database and then runs sync_members to update the list membership. This could be done for any number of lists if you have a way to create the desired membership list for each list. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at list.org Fri Jan 22 15:04:26 2016 From: barry at list.org (Barry Warsaw) Date: Fri, 22 Jan 2016 15:04:26 -0500 Subject: [Mailman-Developers] an impossible need to address ? In-Reply-To: <22177.48561.235115.72604@turnbull.sk.tsukuba.ac.jp> References: <3pmKfG065RzFr4K@mail.python.org> <22177.48561.235115.72604@turnbull.sk.tsukuba.ac.jp> Message-ID: <20160122150426.5d6639c8@anarchist.wooz.org> On Jan 22, 2016, at 02:27 PM, Stephen J. Turnbull wrote: >> database. It means a way (1) to set-up scores of same style mailing >> lists and (2) for a person being a member of my directory to easiliy >> select the lists she wants to attend or quit. Just another bit of Mailman 3 obscurity: there is a handler called 'file-recipients' which can be used to populate a message's recipient list from a static file. It looks on the file system, inside the mailing list's data directory for a members.txt file. If found, this can contain one email address per line which is used as the recipient list for the message. Of course, you need file system access to edit this file because it's not currently available via REST, and thus not available to Postorius. A few things could make this nicer: * Expose the file to REST so that it can be updated via Postorius * Use 'parseaddr' style lines so that they can contain anything parseable by the email.utils.parseaddr() function * Allow it to augment any other recipient list already calculated, instead of short-circuiting when any other recipient list is already present * Add file-recipients to the default pipeline handler list Contributions welcome of course. Cheers, -Barry From raj.abhilash1 at gmail.com Sun Jan 24 16:20:12 2016 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Sun, 24 Jan 2016 13:20:12 -0800 Subject: [Mailman-Developers] Continuous Integration for Mailman Projects Message-ID: <56A5400C.7000903@gmail.com> Mailman Developers, Since you all know that a big reason why we moved to Gitlab from Launchpad was Continuous Integration. As of now, only the forks of core developers were automatically built by the Gitlab CI runners that we have added for Mailman Project. But now, thanks for Simon Hanna, anyone can enable Gitblab's Shared Runners and run their tests inside a Docker Container. Right now, this only works for Mailman Core, but very soon I am going to extend this to other project repositories too. How to: 1. Pull the latest commits from the Mailman's repo[1] or fork it if you haven't already. 2. Go to the project settings page of your fork and you will see an option called 'Runners' in the left hand side menu. 3. In the runners page, push the big green button that says "Enable Shared Runners". After this, each commit that you push to your fork should automatically be tested. If you don't see the CI running at all, make sure that you have enabled CI for your fork. Under the `Project Settings`, in the `Features` section, check the box that says "Build". AFAIK, this should be enabled by default, but just in case if it is not. Again I would like to Simon Hanna for this contribution. [1]: https://gitlab.com/mailman/mailman -- thanks, Abhilash Raj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From barry at list.org Sun Jan 24 19:52:46 2016 From: barry at list.org (Barry Warsaw) Date: Sun, 24 Jan 2016 19:52:46 -0500 Subject: [Mailman-Developers] Continuous Integration for Mailman Projects In-Reply-To: <56A5400C.7000903@gmail.com> References: <56A5400C.7000903@gmail.com> Message-ID: <20160124195246.755004fe@anarchist.wooz.org> On Jan 24, 2016, at 01:20 PM, Abhilash Raj wrote: >But now, thanks for Simon Hanna, anyone can enable Gitblab's Shared >Runners and run their tests inside a Docker Container. Right now, this >only works for Mailman Core, but very soon I am going to extend this to >other project repositories too. This is really awesome. Thanks so much Simon and Abhilash! I would highly recommend contributors to Mailman 3 enable their runners. It helps me quite a bit when reviewing merge requests to see if the test suite succeeds. I've also been looking at some enhancements to core's tox.ini to ensure things like 100% coverage in differences between new branches and master. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From tarunjit.singh.cs at gmail.com Sun Jan 24 23:38:01 2016 From: tarunjit.singh.cs at gmail.com (Tarunjit Singh) Date: Sun, 24 Jan 2016 23:38:01 -0500 Subject: [Mailman-Developers] Yet another newbie to the "Mailman" Message-ID: Hi Fellow Developers, I am a graduate student at University of Toronto, Canada who likes to code (mainly in python). I just started to get to know the Mailman product by studying its architecture available on Aosabook and I am looking forward to contribute to the organization. After reading some of the email chains, I am assuming the best place to start is by looking into issues available here once I have a better understanding on the product but any newbie advice/guidance is welcome. Thanks Tarunjit Singh From raj.abhilash1 at gmail.com Mon Jan 25 20:23:34 2016 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Mon, 25 Jan 2016 17:23:34 -0800 Subject: [Mailman-Developers] Yet another newbie to the "Mailman" In-Reply-To: References: Message-ID: <56A6CA96.50107@gmail.com> Hi Tarunjit, On 01/24/2016 08:38 PM, Tarunjit Singh wrote: > Hi Fellow Developers, > > I am a graduate student at University of Toronto, Canada who likes to code > (mainly in python). > I just started to get to know the Mailman product by studying its > architecture available on Aosabook Awesome! That particular article really sums up the architecture of Mailman. If you want to know more, look at Barry's talk/notes from PyCon 2012. > and I am looking forward to contribute to the organization. After reading > some of the email chains, I am assuming the best place to start is by > looking into issues available here > once I have a better > understanding on the product but any newbie advice/guidance is welcome. Yes, you are on the right track. Try looking for issues that are marked "easy" or "beginner-friendly", though there aren't many. You can look for bugs in Postorius[1] or Hyperkitty[2] too if you like. They feed upon the REST API from the core and are Django based front-end and archiver respectively. Also, instead of solving some random bugs, you can also find a particular project from the ideas page that interests you and try solving some easy but small "parts" of the project that you can submit as an independent patch. Even if you don't end up working on that project, it would help you to know the wiring[*] inside mailman a lot better. [1]: https://gitlab.com/mailman/postorius/issues [2]: https://gitlab.com/mailman/hyperkitty/issues [*]: There is a lot of wiring and moving parts in mailman. So feel free about asking about anything that don't understand, even if its very trivial. > Thanks > Tarunjit Singh > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/raj.abhilash1%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 > -- thanks, Abhilash Raj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mark at msapiro.net Mon Jan 25 20:56:46 2016 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 25 Jan 2016 17:56:46 -0800 Subject: [Mailman-Developers] Yet another newbie to the "Mailman" In-Reply-To: <56A6CA96.50107@gmail.com> References: <56A6CA96.50107@gmail.com> Message-ID: <56A6D25E.4010002@msapiro.net> On 01/25/2016 05:23 PM, Abhilash Raj wrote: > Hi Tarunjit, > > On 01/24/2016 08:38 PM, Tarunjit Singh wrote: >> Hi Fellow Developers, >> >> I am a graduate student at University of Toronto, Canada who likes to code >> (mainly in python). >> I just started to get to know the Mailman product by studying its >> architecture available on Aosabook > > Awesome! That particular article really sums up the architecture of > Mailman. If you want to know more, look at Barry's talk/notes from PyCon > 2012. Barry's talk from Pycon 2012 is at . Some additional notes are at . -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From harshitbansal2015 at gmail.com Tue Jan 26 12:51:56 2016 From: harshitbansal2015 at gmail.com (Harshit Bansal) Date: Tue, 26 Jan 2016 23:21:56 +0530 Subject: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" . In-Reply-To: <569BF632.3010906@gmail.com> References: <569BF632.3010906@gmail.com> Message-ID: 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. >> >> 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. > > Your understanding is actually good, but more generic as of now. Styles > are the term used in Mailman to accumulate a certain list of > list-settings that change the behavior of the list. There are some > pre-defined styles like "Announce", "General", "Moderation" etc that you > can find in src/mailman/styles/base.py in the mailman-core source code[1]. > > Right now, styles can only be applied to a mailing list when they are > created. And there is no way right now to create new styles without > modifying the source code. The official Web UI for Mailman is called > Postorius and talks to the mailman-core via HTTP REST API. So you'd have > to expose the styles via REST API and then implement it in the Postorius > (which is a Django application). > > Some major challenges for your project (not exhaustive) that I would > like to see addressed in the application are: > > 1) Figure out how to store and access the styles as some of them are > defined in the source code and the ones created by users would have to > be stored in database. > > 2) How to apply styles to lists after they have been created? > > 3) Should we even allow changing list styles after lists have been > created? Does changing a style in database/source code change the > settings for list? > > 4) See what happens when a style is changed now? Is it propagated down > to the lists or only the new lists inherit that? > >> 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. > > 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? > > One useful feature I can think of from the UI point of view is to be > able to copy an existing style to create a new style and then present > with the interface to customize the new style. > >> 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. > > This "back-end" code is usually a part of Mailman-Core which takes care > of all the actual logic and mail processing. > >> >> 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? > > I think an integration with Postorius would be sufficiently big for a > Summer. We already have a command line interface for mailman that can be > extended to add this functionality. > > > [1]: https://gitlab.com/mailman/mailman > > > -- > thanks, > Abhilash Raj > > From stephen at xemacs.org Tue Jan 26 19:43:19 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 27 Jan 2016 09:43:19 +0900 Subject: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" . In-Reply-To: References: <569BF632.3010906@gmail.com> Message-ID: <22184.4775.708220.823578@turnbull.sk.tsukuba.ac.jp> 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. > 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. > 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. > 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 :-)? Steve From manish.bisht490 at gmail.com Fri Jan 29 00:42:00 2016 From: manish.bisht490 at gmail.com (Manish Bisht) Date: Fri, 29 Jan 2016 11:12:00 +0530 Subject: [Mailman-Developers] GSOC-2016 Message-ID: Hello Devs, I am Manish Bisht. I am in second year of my engineering in information technology. I want to provide the code for Ubuntu. I have created many projects outside of my college projects. You can see all at https://github.com/manishbisht. I am familiar with many languages some of them are HTML, CSS, JavaScript, PHP, C/C++, Java, and I am currently learning Python also. Also apart from my college hours i have also started my own startup with Run4Offers (http://www.run4offers.com/) I have also interested in Graphics Designing also. I have the knowledge of AdobePhotoshop, Adobe Illustrator and Adobe In Design. I have created many images of various festivals for my College Entrepreneurship Cell(TOPAZ). This is all about about me. I am new to open source communities. I want to work on the GSOC-2016 projects of Mailman and want to start contributing to it. Can anyone please help me in contributing to Mailman. Hope to see you soon :) Thanks :) From simon.hanna at serve-me.info Fri Jan 29 06:56:32 2016 From: simon.hanna at serve-me.info (Simon Hanna) Date: Fri, 29 Jan 2016 12:56:32 +0100 Subject: [Mailman-Developers] Dropping Persona Message-ID: <56AB5370.3030205@serve-me.info> Hi, Mozilla is dropping Persona and shutting it down later this year [1]. Postorius and Hyperkitty will have to drop it, and use something else as a default login mechanism. I propose using the django authentication system by default and making it easy for people to add other authentication methods. If we go with django authentication we can either build everything ourselves (I did it for a couple of projects myself) or use some provided project. This is because django doesn't offer registration views and email confirmation. Also password changing and password resetting will have to be added. I know of two projects that do that already: django-user-accounts [2] It's part of the pinax platform, but can be used independently of the other components. It comes with everything we need and not much more. Note that the profiles of django-user-accounts can contain additional emails, which we probably don't want. It's officially supporting django 1.8 and 1.9. I'm not sure about our django dependency policy but since upstream has marked all pre 1.8 as being out of date, I think that we can move on as well... django-userena [3] Pretty much the same as django-user-accounts but it has additional "features" like messaging which we definitely don't need. It's not yet django 1.9 compatible but there is a merge request that adds support for it. Since we have two projects to maintain, I'd rather go with an external app. I guess it would be easiest to have exactly the same configurations for Postorius and Hyperkitty. In order to not duplicate any templates and other code, I'd propose to create a third project that has all the account functionality and put everything we need in there. In case we go with doing everything ourselves, I guess it's still better to create a separate app for that. My personal favorite is django-user-accounts for which I have some basic functionality in a merge request for Postorius so you can have a look at what needs to be changed. [4] Regardless of what approach we choose, we should also think of migrations. Existing internal django accounts can be easily migrated. We'll have to choose if we want to migrate the "social" accounts as well or just tell people to sign up again. We still have time for the transition, but I'd prefer dropping persona before the 3.1 release if that happens to come before the shutdown. What do you think? Simon [1]: https://wiki.mozilla.org/Identity/Persona_Shutdown_Guidelines_for_Reliers [2]: https://github.com/pinax/django-user-accounts [3]: https://github.com/bread-and-pepper/django-userena [4]: https://gitlab.com/mailman/postorius/merge_requests/73 From adam-mailman at amyl.org.uk Fri Jan 29 08:45:09 2016 From: adam-mailman at amyl.org.uk (Adam McGreggor) Date: Fri, 29 Jan 2016 13:45:09 +0000 Subject: [Mailman-Developers] Dropping Persona In-Reply-To: <56AB5370.3030205@serve-me.info> References: <56AB5370.3030205@serve-me.info> Message-ID: <20160129134509.GU21217@hendricks.amyl.org.uk> On Fri, Jan 29, 2016 at 12:56:32PM +0100, Simon Hanna wrote: > Mozilla is dropping Persona and shutting it down later this year [1]. > > Postorius and Hyperkitty will have to drop it, and use something else as a default login mechanism. > > I propose using the django authentication system by default and making it easy for people to add > other authentication methods. I think this makes sense. Reinventing the wheel is often quite wasteful, especially when there are decent existing solutions available already. > django-user-accounts [2] > It's part of the pinax platform, but can be used independently of the other components. It comes > with everything we need and not much more. Note that the profiles of django-user-accounts can > contain additional emails, which we probably don't want. I can think of several use-cases where managing multiple email addresses in the same place could be exceptionally useful and a good win for UX. -- "Youth cannot know how age thinks and feels. But old men are guilty if they forget what it was to be young" -- Ch37, Order of the Phoenix, JK Rowling From barry at list.org Fri Jan 29 10:00:31 2016 From: barry at list.org (Barry Warsaw) Date: Fri, 29 Jan 2016 10:00:31 -0500 Subject: [Mailman-Developers] Dropping Persona In-Reply-To: <56AB5370.3030205@serve-me.info> References: <56AB5370.3030205@serve-me.info> Message-ID: <20160129100031.305b6809@subdivisions.wooz.org> On Jan 29, 2016, at 12:56 PM, Simon Hanna wrote: >Postorius and Hyperkitty will have to drop it, and use something else as a >default login mechanism. > >I propose using the django authentication system by default and making it >easy for people to add other authentication methods. I don't have any sense about which technology to adopt, but I do agree it probably makes sense for Postorius and HK to be compatible here. So I'll leave technology choices and migration schedules up to Aurelien and Florian. From a UX perspective, I do want to allow people to log into their accounts using any of their registered and validated email addresses. People very often forget just which address is subscribed to which mailing list, so it really shouldn't matter which one they use to get into their account. Further, I have a strong personal preference for "no user names", or alternatively, using email addresses as their "user name". I think user names are essentially contrived extra information for which there's no need, when clearly your identity is your email address. I liked this about Persona. We've long debated, but never attempted, a "centralized user database" component, partly because we can't decide whether that should be a separate piece that the core, Postorius, and HK (and at some point, mailmania) talk to, or whether it should just live in the core. I've resisted putting it in the core because it would have little use for it, and I like to keep it as lean and narrowly focused as possible. But perhaps, if such a component makes sense for a better UX for the user facing bits, then we can open that discussion up again. >We still have time for the transition, but I'd prefer dropping persona before >the 3.1 release if that happens to come before the shutdown. The big feature for 3.1 from the core's perspective is reliable upgrades from MM2.1. I know that Aurelien has been working hard on that, and that there's still one MR to deal with (#32), but I am thinking out loud that if not before, the Pycon 2016 sprints would be a good time to release 3.1. Cheers, -Barry From stephen at xemacs.org Fri Jan 29 12:27:32 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 30 Jan 2016 02:27:32 +0900 Subject: [Mailman-Developers] Dropping Persona In-Reply-To: <20160129100031.305b6809@subdivisions.wooz.org> References: <56AB5370.3030205@serve-me.info> <20160129100031.305b6809@subdivisions.wooz.org> Message-ID: <22187.41220.235636.116629@turnbull.sk.tsukuba.ac.jp> Barry Warsaw writes: > Further, I have a strong personal preference for "no user names", > or alternatively, using email addresses as their "user name". I > think user names are essentially contrived extra information for > which there's no need, when clearly your identity is your email > address. Clearly that's *an* identity, yes, and for social and volunteer sites it's one of the few things that is operationally verifiable for most users (except for those wonderfully expressive and mnemonic, not to mention easy-to-type, PGP keys!), so some email address should be the "main" user identifier. OTOH I don't see why a person having an (optional, additional) nickname is bad. > We've long debated, but never attempted, a "centralized user > database" component, partly because we can't decide whether that > should be a separate piece that the core, Postorius, and HK (and at > some point, mailmania) talk to, or whether it should just live in > the core. Another problem is Mailman in the enterprise, which probably has its own database already. From stephen at xemacs.org Fri Jan 29 12:50:06 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 30 Jan 2016 02:50:06 +0900 Subject: [Mailman-Developers] Dropping Persona In-Reply-To: <56AB5370.3030205@serve-me.info> References: <56AB5370.3030205@serve-me.info> Message-ID: <22187.42574.412907.797890@turnbull.sk.tsukuba.ac.jp> Simon Hanna writes: > I propose using the django authentication system by default and > making it easy for people to add other authentication methods. I think we should provide social auth (OAuth2 or whatever Google and Yahoo! do) by default. At least as I recall the discussion at the sprints a couple years ago, we picked Persona because a Mozilla person gave us a lot of help with the implementation, but we really wanted social auth because users demand it and because it allows us to get out of the business of storing and securing passwords. From f at florianfuchs.com Fri Jan 29 14:30:01 2016 From: f at florianfuchs.com (f at florianfuchs.com) Date: Fri, 29 Jan 2016 20:30:01 +0100 Subject: [Mailman-Developers] Dropping Persona In-Reply-To: <56AB5370.3030205@serve-me.info> References: <56AB5370.3030205@serve-me.info> Message-ID: <63c88f6c30e04a9010b13d5d995b96a9@florianfuchs.com> On 2016-01-29 12:56, Simon Hanna wrote: > Hi, > > Mozilla is dropping Persona and shutting it down later this year [1]. Yeah, that's such a shame. > Postorius and Hyperkitty will have to drop it, and use something else > as a default login mechanism. > > I propose using the django authentication system by default and making > it easy for people to add > other authentication methods. In fact, technically, the django auth system is what we were using all along, since our browserid integration was a layer on top of that. I agree we should still have something in place for site admins to allow using others methods like OAuth. But we can keep python-socialauth for that I think. It's a bit more hassle for admins to configure than Persona though. > If we go with django authentication we can either build everything > ourselves (I did it for a couple > of projects myself) or use some provided project. This is because > django doesn't offer registration > views and email confirmation. Also password changing and password > resetting will have to be added. > > I know of two projects that do that already: Thanks for investigating! > django-user-accounts [2] > It's part of the pinax platform, but can be used independently of the > other components. It comes > with everything we need and not much more. Note that the profiles of > django-user-accounts can > contain additional emails, which we probably don't want. It's > officially supporting django 1.8 and > 1.9. I'm not sure about our django dependency policy but since > upstream has marked all pre 1.8 as > being out of date, I think that we can move on as well... Oh, I think we *do* want additional emails. On a Mailman core level there can be multiple email addresses associated with one account. Being able to keep these tied to one Django record would be very good. > django-userena [3] > Pretty much the same as django-user-accounts but it has additional > "features" like messaging which > we definitely don't need. It's not yet django 1.9 compatible but there > is a merge request that adds > support for it. Some kind of messaging would be good, so we can hook into new registrations and, for instance, create new accounts on the core level. Although we already do that using Django signals. So I agree, another messaging system is probably not needed. > Since we have two projects to maintain, I'd rather go with an external > app. I guess it would be > easiest to have exactly the same configurations for Postorius and > Hyperkitty. In order to not > duplicate any templates and other code, I'd propose to create a third > project that has all the > account functionality and put everything we need in there. > In case we go with doing everything ourselves, I guess it's still > better to create a separate app > for that. > > My personal favorite is django-user-accounts for which I have some > basic functionality in a merge > request for Postorius so you can have a look at what needs to be > changed. [4] > > > Regardless of what approach we choose, we should also think of > migrations. > Existing internal django accounts can be easily migrated. We'll have > to choose if we want to migrate > the "social" accounts as well or just tell people to sign up again. The existing social accounts do already exist locally, since for each new Persona login a new user record is created. Only there's no usable password (since they used persona to authenticate). But if a new app also sits on top of the default django auth system *and* can create new passwords for existing records, we might not even have to do a lot to give folks access to their accounts. Florian From f at florianfuchs.com Fri Jan 29 14:59:09 2016 From: f at florianfuchs.com (f at florianfuchs.com) Date: Fri, 29 Jan 2016 20:59:09 +0100 Subject: [Mailman-Developers] Dropping Persona In-Reply-To: <20160129100031.305b6809@subdivisions.wooz.org> References: <56AB5370.3030205@serve-me.info> <20160129100031.305b6809@subdivisions.wooz.org> Message-ID: <62a8d6f2d4e70d5401f7ef404f6e782f@florianfuchs.com> On 2016-01-29 16:00, Barry Warsaw wrote: > From a UX perspective, I do want to allow people to log into their > accounts > using any of their registered and validated email addresses. People > very > often forget just which address is subscribed to which mailing list, so > it > really shouldn't matter which one they use to get into their account. We should check out which external app allows for multiple emails to be set. Or which ones allows for easy customization to do so at least. > Further, I have a strong personal preference for "no user names", or > alternatively, using email addresses as their "user name". I think > user names > are essentially contrived extra information for which there's no need, > when > clearly your identity is your email address. I liked this about > Persona. I agree, especially since even though we now have HyperKitty, there will probably always be many folks whose interface of choice for Mailman is email, and who will not use the interface very often. Remembering usernames for sites you last visited 20 months ago is awful. >> We still have time for the transition, but I'd prefer dropping persona >> before >> the 3.1 release if that happens to come before the shutdown. > > The big feature for 3.1 from the core's perspective is reliable > upgrades from > MM2.1. I know that Aurelien has been working hard on that, and that > there's > still one MR to deal with (#32), but I am thinking out loud that if not > before, the Pycon 2016 sprints would be a good time to release 3.1. If we can't make the transition into 3.1, we're going to make another release before November, since that's when Persona is getting shut down for good. So I'd say it's a good idea to at least try to get it into 3.1. Cheers Florian From f at florianfuchs.com Fri Jan 29 15:06:27 2016 From: f at florianfuchs.com (f at florianfuchs.com) Date: Fri, 29 Jan 2016 21:06:27 +0100 Subject: [Mailman-Developers] Dropping Persona In-Reply-To: <22187.42574.412907.797890@turnbull.sk.tsukuba.ac.jp> References: <56AB5370.3030205@serve-me.info> <22187.42574.412907.797890@turnbull.sk.tsukuba.ac.jp> Message-ID: On 2016-01-29 18:50, Stephen J. Turnbull wrote: > Simon Hanna writes: > > > I propose using the django authentication system by default and > > making it easy for people to add other authentication methods. > > I think we should provide social auth (OAuth2 or whatever Google and > Yahoo! do) by default. At least as I recall the discussion at the > sprints a couple years ago, we picked Persona because a Mozilla person > gave us a lot of help with the implementation, but we really wanted > social auth because users demand it and because it allows us to get > out of the business of storing and securing passwords. I can only speak for me, but I liked Persona because it allowed people/email providers to implement their own backends, giving them a real possibility to handle the authentication themselves with Persona merely being a technology or a broker. Also the fact that Mozilla is a Non-Profit which doesn't aim at making money from user data. Which is why I would rather make the local option the default, but give site admins everything they need to integrate OAuth(2) using Gmail, Yahoo, Twitter or else. Florian From stephen at xemacs.org Sat Jan 30 00:42:30 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 30 Jan 2016 14:42:30 +0900 Subject: [Mailman-Developers] Dropping Persona In-Reply-To: References: <56AB5370.3030205@serve-me.info> <22187.42574.412907.797890@turnbull.sk.tsukuba.ac.jp> Message-ID: <22188.19782.371016.742748@turnbull.sk.tsukuba.ac.jp> I disagree, but this being a GNU project it's the party line to deprecate security and privacy in favor of freedom. I won't push the issue of defaults any further since we agree the OAuth option should be available. f at florianfuchs.com writes: > Non-Profit which doesn't aim at making money from user data. Which is > why I would rather make the local option the default, but give site > admins everything they need to integrate OAuth(2) using Gmail, Yahoo, > Twitter or else. From simon.hanna at serve-me.info Sat Jan 30 06:20:15 2016 From: simon.hanna at serve-me.info (Simon Hanna) Date: Sat, 30 Jan 2016 12:20:15 +0100 Subject: [Mailman-Developers] Dropping Persona In-Reply-To: <62a8d6f2d4e70d5401f7ef404f6e782f@florianfuchs.com> References: <56AB5370.3030205@serve-me.info> <20160129100031.305b6809@subdivisions.wooz.org> <62a8d6f2d4e70d5401f7ef404f6e782f@florianfuchs.com> Message-ID: <56AC9C6F.4080609@serve-me.info> On 01/29/2016 08:59 PM, f at florianfuchs.com wrote: > > > On 2016-01-29 16:00, Barry Warsaw wrote: >> From a UX perspective, I do want to allow people to log into their accounts >> using any of their registered and validated email addresses. People very >> often forget just which address is subscribed to which mailing list, so it >> really shouldn't matter which one they use to get into their account. > > We should check out which external app allows for multiple emails to be set. Or which ones allows > for easy customization to do so at least. > >> Further, I have a strong personal preference for "no user names", or >> alternatively, using email addresses as their "user name". I think user names >> are essentially contrived extra information for which there's no need, when >> clearly your identity is your email address. I liked this about Persona. > > I agree, especially since even though we now have HyperKitty, there will probably always be many > folks whose interface of choice for Mailman is email, and who will not use the interface very often. > Remembering usernames for sites you last visited 20 months ago is awful. I just found another solution: django-allauth http://www.intenct.nl/projects/django-allauth/ http://django-allauth.readthedocs.org/en/latest/overview.html https://github.com/pennersr/django-allauth It's a relatively large project. It has 2000+ stars and about 800 forks on github. The other two I introduced can't get these values when adding them together. About their functionalit quoting from their docs: * Signup of both local and social accounts * Connecting more than one social account to a local account * Disconnecting a social account ? requires setting a password if only the local account remains * Optional instant-signup for social accounts ? no questions asked * E-mail address management (multiple e-mail addresses, setting a primary) * Password forgotten flow * E-mail address verification flow They are basically supporting every OAuth provider out there They have more signals than the other two projects I introduced. Some of them are: * when a user signs up * when a user adds an email * when the user removes an email I didn't look at the code yet but I think they are only using emails and not usernames. I will try to integrate it in the next couple of weeks and see if we should create a sepparate app for that or do the work in both projects From adityadivekar03 at gmail.com Sat Jan 30 10:19:23 2016 From: adityadivekar03 at gmail.com (Aditya Divekar) Date: Sat, 30 Jan 2016 20:49:23 +0530 Subject: [Mailman-Developers] help in testing Message-ID: I have just started working on the mailman project. I am currently trying to solve Issue #186 and need help in testing, to check if my recommended fix is correct. any help would be appreciated. From harshitbansal2015 at gmail.com Sat Jan 30 14:11:29 2016 From: harshitbansal2015 at gmail.com (Harshit Bansal) Date: Sun, 31 Jan 2016 00:41:29 +0530 Subject: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" . In-Reply-To: <22184.4775.708220.823578@turnbull.sk.tsukuba.ac.jp> References: <569BF632.3010906@gmail.com> <22184.4775.708220.823578@turnbull.sk.tsukuba.ac.jp> Message-ID: 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 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_ From raj.abhilash1 at gmail.com Sat Jan 30 17:01:59 2016 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Sat, 30 Jan 2016 14:01:59 -0800 Subject: [Mailman-Developers] help in testing In-Reply-To: References: Message-ID: <56AD32D7.5040708@gmail.com> Hi Aditya, On 01/30/2016 07:19 AM, Aditya Divekar wrote: > I have just started working on the mailman project. I am currently trying > to solve Issue #186 and need help in testing, to check if my recommended > fix is correct. any help would be appreciated. I have added a comment on the Issue. > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/raj.abhilash1%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 > -- thanks, Abhilash Raj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From raj.abhilash1 at gmail.com Sat Jan 30 17:46:46 2016 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Sat, 30 Jan 2016 14:46:46 -0800 Subject: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" . In-Reply-To: References: <569BF632.3010906@gmail.com> <22184.4775.708220.823578@turnbull.sk.tsukuba.ac.jp> Message-ID: <56AD3D56.6020208@gmail.com> On 01/30/2016 11:11 AM, Harshit Bansal wrote: > 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. What exactly I meant here was not a data structure but *how*? The data structure could simply be dictionary, but how would you populate the existing styles in the code? Notice that there is already an existing IStyle interface in the mailman right now, can you modify it somehow to dynamically update/fetch/store styles from the database instead of creating a new structure altogether? Barry: Is there a reason the styles in the src/styles/base.py are not an implementation of IStyle interface? If I am not wrong, you can define the styles in configuration too apart from the source code, so how do you pull those and update the database during the initialization? This is not a difficult question I want an answer to right now, just that the application should have implementation details too, even if they are a rough sketch. > >> > 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. You may want to expand more on the *permissions system* in you application as that is an important part of this. Also, how are you going to propagate that to the Postorius via the API. > >> > 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. I *think* we have had a discussion before about what should be a better default value for member.moderation_action and nonmeember.moderation_action. Instead of just copying them to the field, we could set it to defer in which it case the lookup automatically picks up the value of the list's default_(non)member_action. Or we could *always* copy the default styles to a new style that the list owner owns and can use for his other lists. This way he can change values in the default styles too. This way, we don't have to deal with user's being affected by the change in the default styles. Along with that we could provide them with an option to update the styles automatically from the default (when it changes) to fetch any new values added/removed/updated. This however might introduce a *lot* of redundancy in the database. Just a possibility, not very sure if this is a good idea. >> >> > 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. See my comment above about the default behavior. >> > 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. You cannot let users add stuff in the source code, configurations are meant for the values that can be adjusted by users. AND you can add styles via configs. -- thanks, Abhilash Raj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From stephen at xemacs.org Sat Jan 30 19:59:44 2016 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sun, 31 Jan 2016 09:59:44 +0900 Subject: [Mailman-Developers] Discussion On Project Idea "Preset List Settings Templates" . In-Reply-To: <56AD3D56.6020208@gmail.com> References: <569BF632.3010906@gmail.com> <22184.4775.708220.823578@turnbull.sk.tsukuba.ac.jp> <56AD3D56.6020208@gmail.com> Message-ID: <22189.23680.282655.986781@turnbull.sk.tsukuba.ac.jp> Abhilash Raj writes: > I *think* we have had a discussion before about what should be a better > default value for member.moderation_action and > nonmeember.moderation_action. Instead of just copying them to the field, > we could set it to defer in which it case the lookup automatically picks > up the value of the list's default_(non)member_action. > > Or we could *always* copy the default styles to a new style that the > list owner owns and can use for his other lists. These somewhat analogous to "deep binding" and "shallow binding" (actually they should be called "deep lookup" and "shallow lookup") in Lisp implementation. They can have the same semantics (Mailman can choose, the point of using Lisp as an example is that the semantics are defined by the language definition and the implementation must match that definition), but shallow binding requires more care in implementation (the binding is basically a cache). I think probably shallow binding is the way to go because changing these values is much less frequent than referencing them. > > 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. This is easy. Just think about what happens if you change the creation default from unmoderated to moderated, and automatically copy that to an existing list. Would you want to be that list owner? From barry at list.org Sun Jan 31 17:46:49 2016 From: barry at list.org (Barry Warsaw) Date: Sun, 31 Jan 2016 17:46:49 -0500 Subject: [Mailman-Developers] help in testing In-Reply-To: References: Message-ID: <20160131174649.1ab73147@subdivisions.wooz.org> On Jan 30, 2016, at 08:49 PM, Aditya Divekar wrote: >I have just started working on the mailman project. I am currently trying >to solve Issue #186 and need help in testing, to check if my recommended >fix is correct. any help would be appreciated. There are some comments about manual testing in the issue, but for any branch to land, it needs to have a test case that covers the new code. There's lots and lots of examples of both doctests and unittests, and I will try to add some more useful information to the in-tree documentation. If you're unable to write a test for your branch, please indicate as such in your merge request, and I will take a crack at it. Note though that an MR without tests can mean a delay in merging. For now, see src/mailman/docs/START.rst and DEVELOP.rst. Cheers, -Barry