From t.glaser at tarent.de Tue Jun 1 16:03:23 2010 From: t.glaser at tarent.de (Thorsten Glaser) Date: Tue, 01 Jun 2010 14:03:23 -0000 Subject: [Bug 266465] Re: teach firefox that different lists may have different passwo References: <20080905193221.27052.75535.launchpad@forster.canonical.com> Message-ID: <20100601140323.27549.87787.malone@potassium.ubuntu.com> Would something like this work? (For the lenny version of the package though, and we?re only about to test it.) In the long term, I?d prefer upstream to simply rename the field and not add another hidden one though. ** Patch added: "debdiff (experimental) against lenny version" http://launchpadlibrarian.net/49501050/mailman_2.1.11-11ff1.debdiff -- teach firefox that different lists may have different passwo https://bugs.launchpad.net/bugs/266465 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Tue Jun 1 18:39:58 2010 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 01 Jun 2010 16:39:58 -0000 Subject: [Bug 266465] Re: teach firefox that different lists may have different passwo References: <20080905193221.27052.75535.launchpad@forster.canonical.com> Message-ID: <20100601163958.1683.12171.malone@palladium.canonical.com> The patch looks like what I suggested in comment #1 based on the suggestion in the original. Whether it works or not is up to Firefox. For the long term, the entire GUI is being redone. See . Also, any specific admin (or list member) will have a single Mailman login which will work for all that person's defined roles, thus rendering this whole issue moot for MM 3. Note also that for MM 2.1 there are password management plugins for Firefox that may do a better job and render this unnecessary. -- teach firefox that different lists may have different passwo https://bugs.launchpad.net/bugs/266465 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From vagazzi at gvsig.com Wed Jun 2 14:49:27 2010 From: vagazzi at gvsig.com (Victoria Agazzi) Date: Wed, 02 Jun 2010 12:49:27 -0000 Subject: [Bug 588692] [NEW] Bad brasilian translation for the word "delay" on the admin interface. References: <20100602124928.334.14372.malonedeb@wampee.canonical.com> Message-ID: <20100602124928.334.14372.malonedeb@wampee.canonical.com> Public bug reported: The problem is that "DELAY" is translated as "DEFERIR" but this word in brasilian means "ACCEPT", so the first 2 options means the same. The word "DELAY" must be translated into "ADIAR". This was detected on the admin page: Outras Atividades Administrativas/Supervisionar requisi??es administrativas de modera??o pendentes . Thanks for your work! ** Affects: mailman Importance: Undecided Status: New -- Bad brasilian translation for the word "delay" on the admin interface. https://bugs.launchpad.net/bugs/588692 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From stevehulet at gmail.com Thu Jun 3 09:13:22 2010 From: stevehulet at gmail.com (Steve Hulet) Date: Thu, 03 Jun 2010 07:13:22 -0000 Subject: [Bug 266205] Re: URL-error on admin help-page References: <20080905192938.27052.29455.launchpad@forster.canonical.com> Message-ID: <20100603071322.14807.3919.malone@wampee.canonical.com> This also affects mailman-3.0.0a5. All instances of the string http://www.metasystema.org/essays/reply-to-useful.mhtml should be replaced with http://www.metasystema.net/essays/reply-to.html. -- URL-error on admin help-page https://bugs.launchpad.net/bugs/266205 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Thu Jun 3 16:59:34 2010 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 03 Jun 2010 14:59:34 -0000 Subject: [Bug 266205] Re: URL-error on admin help-page References: <20080905192938.27052.29455.launchpad@forster.canonical.com> Message-ID: <20100603145934.24539.26302.malone@gandwana.canonical.com> The original bug was fixed in Mailman 2.1.6. The only occurrences of the bad link in mailman-3.0.0a5 are in the message catalogs which are not really relevant as they are strings which don't exist anywhere it the code. There was still one occurrence of the old URL in the Mailman 2.1 list admin manual, which I have just fixed. ** Changed in: mailman Importance: Medium => Low ** Changed in: mailman Status: New => Fix Committed ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- URL-error on admin help-page https://bugs.launchpad.net/bugs/266205 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From erica.wolfe at gmail.com Sat Jun 5 19:01:48 2010 From: erica.wolfe at gmail.com (Erica Wolfe) Date: Sat, 05 Jun 2010 17:01:48 -0000 Subject: [Bug 590155] [NEW] extraneous line of code References: <20100605170148.4522.48380.malonedeb@soybean.canonical.com> Message-ID: <20100605170148.4522.48380.malonedeb@soybean.canonical.com> Public bug reported: Mailman 2.1.12-2 In Mailman/Handlers/Decorate.py line 237 is unnecessary. 'what' is created for use in the log message. The log message is generated in the previous line (236). 'what' has fulfilled its function and is not used again, there is no need to uppercase it. ** Affects: mailman Importance: Undecided Status: New -- extraneous line of code https://bugs.launchpad.net/bugs/590155 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From erica.wolfe at gmail.com Sat Jun 5 19:01:48 2010 From: erica.wolfe at gmail.com (Erica Wolfe) Date: Sat, 05 Jun 2010 17:01:48 -0000 Subject: [Bug 590155] Re: extraneous line of code References: <20100605170148.4522.48380.malonedeb@soybean.canonical.com> Message-ID: <20100605170149.4522.63858.malone@soybean.canonical.com> ** Patch added: "This is a patch to fix the defect" http://launchpadlibrarian.net/49731512/MailmanDecorateExtraLinePatch -- extraneous line of code https://bugs.launchpad.net/bugs/590155 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Sat Jun 5 19:52:22 2010 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 05 Jun 2010 17:52:22 -0000 Subject: [Bug 590155] Re: extraneous line of code References: <20100605170148.4522.48380.malonedeb@soybean.canonical.com> Message-ID: <20100605175223.22440.61254.launchpad@wampee.canonical.com> ** Changed in: mailman Importance: Undecided => Low ** Changed in: mailman Status: New => Fix Committed ** Changed in: mailman Milestone: None => 2.1.14 ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- extraneous line of code https://bugs.launchpad.net/bugs/590155 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Sat Jun 5 20:20:18 2010 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 05 Jun 2010 18:20:18 -0000 Subject: [Bug 588692] Re: Bad brasilian translation for the word "delay" on the admin interface. References: <20100602124928.334.14372.malonedeb@wampee.canonical.com> Message-ID: <20100605182018.22440.67358.malone@wampee.canonical.com> In Mailman 2.1.10, the pt-BR translation of "Defer" (not "Delay") was "Deferir", and the translation of "Discard all messages marked Defer" was "Descartar todas as mensagens marcadas como Deferidas". In Mailman 2.1.11, these were changed to "Adiar" and "Descartar todas as mensagens marcadas como Adiar" respectively, so it seems this issue was fixed in Mailman 2.1.11. ** Changed in: mailman Status: New => Fix Released ** Changed in: mailman Milestone: None => 2.1-stable -- Bad brasilian translation for the word "delay" on the admin interface. https://bugs.launchpad.net/bugs/588692 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From freqmod at gmail.com Sat Jun 12 14:58:38 2010 From: freqmod at gmail.com (FreqMod) Date: Sat, 12 Jun 2010 12:58:38 -0000 Subject: [Bug 593029] [NEW] Mailman package in pypi won't install References: <20100612125838.11704.21505.malonedeb@gandwana.canonical.com> Message-ID: <20100612125838.11704.21505.malonedeb@gandwana.canonical.com> Public bug reported: Mailman in pypi depends on munepy, but munepy has been renamed to flufl.enum. Therefore no munepy-package exists in pypi, and the mailman installation fails because of the dependency. ** Affects: mailman Importance: Undecided Status: New -- Mailman package in pypi won't install https://bugs.launchpad.net/bugs/593029 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From barry at canonical.com Wed Jun 16 04:38:27 2010 From: barry at canonical.com (Barry Warsaw) Date: Wed, 16 Jun 2010 02:38:27 -0000 Subject: [Bug 552917] Re: Subscribing an already subscribed member via REST should 409 References: <20100331225426.1307.60979.malonedeb@palladium.canonical.com> Message-ID: <20100616023829.15640.46173.launchpad@potassium.ubuntu.com> ** Changed in: mailman/3.0 Importance: Undecided => Medium ** Changed in: mailman/3.0 Status: Confirmed => In Progress -- Subscribing an already subscribed member via REST should 409 https://bugs.launchpad.net/bugs/552917 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From 552917 at bugs.launchpad.net Wed Jun 16 04:40:48 2010 From: 552917 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Wed, 16 Jun 2010 02:40:48 -0000 Subject: [Bug 552917] Re: Subscribing an already subscribed member via REST should 409 References: <20100331225426.1307.60979.malonedeb@palladium.canonical.com> Message-ID: <20100616024051.17806.41810.launchpad@loganberry.canonical.com> ** Branch linked: lp:mailman -- Subscribing an already subscribed member via REST should 409 https://bugs.launchpad.net/bugs/552917 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From barry at canonical.com Wed Jun 16 04:40:56 2010 From: barry at canonical.com (Barry Warsaw) Date: Wed, 16 Jun 2010 02:40:56 -0000 Subject: [Bug 552917] Re: Subscribing an already subscribed member via REST should 409 References: <20100331225426.1307.60979.malonedeb@palladium.canonical.com> Message-ID: <20100616024057.23012.3210.launchpad@palladium.canonical.com> ** Changed in: mailman/3.0 Status: In Progress => Fix Committed -- Subscribing an already subscribed member via REST should 409 https://bugs.launchpad.net/bugs/552917 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From barry at canonical.com Wed Jun 16 05:07:34 2010 From: barry at canonical.com (Barry Warsaw) Date: Wed, 16 Jun 2010 03:07:34 -0000 Subject: [Bug 593029] Re: Mailman package in pypi won't install References: <20100612125838.11704.21505.malonedeb@gandwana.canonical.com> Message-ID: <20100616030734.16436.40891.malone@gandwana.canonical.com> I'm marking this fix committed because the bzr head has already been fixed. If you can't grab that, I hope to be releasing alpha6 within a week or so, so stay tuned. ** Tags added: mailman3 ** Changed in: mailman Status: New => Fix Committed ** Changed in: mailman Importance: Undecided => High ** Changed in: mailman Assignee: (unassigned) => Barry Warsaw (barry) ** Changed in: mailman Milestone: None => 3.0.0a6 -- Mailman package in pypi won't install https://bugs.launchpad.net/bugs/593029 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From deuce135 at gmail.com Fri Jun 18 05:15:30 2010 From: deuce135 at gmail.com (NC) Date: Fri, 18 Jun 2010 03:15:30 -0000 Subject: [Bug 595766] [NEW] delete archives from web admin pages References: <20100618031530.15164.15301.malonedeb@potassium.ubuntu.com> Message-ID: <20100618031530.15164.15301.malonedeb@potassium.ubuntu.com> Public bug reported: To Whom It May Concern: This is not really a bug but didn't know where to place it. I would like a web interface for the admin pages to delete the HTML and List Archives. having to go through 50 different command line scripts to delete an archive is a pain. ** Affects: mailman Importance: Undecided Status: New -- delete archives from web admin pages https://bugs.launchpad.net/bugs/595766 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Fri Jun 18 05:33:07 2010 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 18 Jun 2010 03:33:07 -0000 Subject: [Bug 595766] Re: delete archives from web admin pages References: <20100618031530.15164.15301.malonedeb@potassium.ubuntu.com> Message-ID: <20100618033307.20849.57776.malone@wampee.canonical.com> This is the right place for a feature request such as this, but for clarification, do you want to be able to delete a list's entire archive or do you want to be able to delete individual messages from a list's archive or both? -- delete archives from web admin pages https://bugs.launchpad.net/bugs/595766 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From deuce135 at gmail.com Fri Jun 18 18:10:16 2010 From: deuce135 at gmail.com (NC) Date: Fri, 18 Jun 2010 16:10:16 -0000 Subject: [Bug 595766] Re: delete archives from web admin pages References: <20100618031530.15164.15301.malonedeb@potassium.ubuntu.com> Message-ID: <20100618161016.15164.82533.malone@potassium.ubuntu.com> It would actually be a great idea to be able to delete both individual archive items as sometimes we have duplicate or even triplicate messages with in the archive and as well as delete whole archives so that the archive is not wasting valuable disk space. currently in my server i delete the HTML archives but it still shows a list of archives from 2008 in the HTML archive list. -- delete archives from web admin pages https://bugs.launchpad.net/bugs/595766 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Fri Jun 18 20:28:18 2010 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 18 Jun 2010 18:28:18 -0000 Subject: [Bug 595766] Re: delete archives from web admin pages References: <20100618031530.15164.15301.malonedeb@potassium.ubuntu.com> Message-ID: <20100618182818.20805.13884.malone@wampee.canonical.com> > currently in my server i delete the HTML archives but it still shows > a list of archives from 2008 in the HTML archive list. Are you trying to delete just older messages leaving the most recent ones and continuing to archive? If so, and if you don't mind the message numbers and hence URLs of the recent messages changing, you can do the following: If you have say 5000 total messages in the cumulative archives/private/listname.mbox/listname.mbox file, and you want to keep only the most recent 500 for the HTML archive, just do bin/arch --wipe --start=4500 listname This will recreate the table of contents with only the current messages. If you want to empty the archive completely, you can do bin/arch --wipe listname /dev/null And this will give you the "no messages have been posted" table of contents until a new post is archived. -- delete archives from web admin pages https://bugs.launchpad.net/bugs/595766 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From fdgwjames at gmail.com Fri Jun 18 22:37:23 2010 From: fdgwjames at gmail.com (james) Date: Fri, 18 Jun 2010 20:37:23 -0000 Subject: [Bug 595766] Re: delete archives from web admin pages References: <20100618031530.15164.15301.malonedeb@potassium.ubuntu.com> <20100618182818.20805.13884.malone@wampee.canonical.com> Message-ID: <4C1BD903.3030308@gmail.com> Hi, This has nothing to do with me! I never mentioned deleting messages! Must be someone else... What I was trying to make out was why my mouse responds when I boot, and then stops responding for 3 minutes after launching 10.04 in the dual boot menu. The desk with all the applications is there, but the mouse remains inoperational for three minutes...Any idea? Is it a bug I reinstalled 10.04 several times. When I boot Win7, the mouse responds perfectly normally... If I should not post here, let me know where I should. I found nothing on the forums. Thanks a lot On 06/18/2010 08:28 PM, Mark Sapiro wrote: >> currently in my server i delete the HTML archives but it still shows >> a list of archives from 2008 in the HTML archive list. >> > Are you trying to delete just older messages leaving the most recent > ones and continuing to archive? If so, and if you don't mind the message > numbers and hence URLs of the recent messages changing, you can do the > following: > > If you have say 5000 total messages in the cumulative > archives/private/listname.mbox/listname.mbox file, and you want to keep > only the most recent 500 for the HTML archive, just do > > bin/arch --wipe --start=4500 listname > > This will recreate the table of contents with only the current messages. > > If you want to empty the archive completely, you can do > > bin/arch --wipe listname /dev/null > > And this will give you the "no messages have been posted" table of > contents until a new post is archived. > > -- ** Attachment added: "Signature MyNameIs.gif" http://launchpadlibrarian.net/50559446/Signature%20MyNameIs.gif ** Attachment added: "Signature MyNameIs.gif" http://launchpadlibrarian.net/50559447/Signature%20MyNameIs.gif -- delete archives from web admin pages https://bugs.launchpad.net/bugs/595766 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From su at tospeirs.net Sat Jun 19 06:24:59 2010 From: su at tospeirs.net (Terry Speirs) Date: Sat, 19 Jun 2010 04:24:59 -0000 Subject: [Bug 596169] [NEW] max_num_recipients is out by 1 References: <20100619042459.24319.76875.malonedeb@palladium.canonical.com> Message-ID: <20100619042459.24319.76875.malonedeb@palladium.canonical.com> Public bug reported: I'm using mailman 2.1.12.cp3 and I notice that if I set max_num_recipients to say "2", then send an email to the list and one other address, then it bounces with a message which includes "Too many recipients to the message", and the moderator needs to release it, even though there were only 2 recipients. If I send the message in the same way, with max_num_recipients set to "3", then the message goes through fine. It seems to me that, instead of max_num_recipients being the "Ceiling on acceptable number of recipients for a posting", it is more like the "point at which messages will not be accepted", and (max_num_recipients + 1) is the ceiling. I recommend the calculation be changed. Failing that, the variable name and its description should be changed. Thanks for your excellent software! ** Affects: mailman Importance: Undecided Status: New ** Tags: max-num-recipients -- max_num_recipients is out by 1 https://bugs.launchpad.net/bugs/596169 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Sat Jun 19 17:41:32 2010 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 19 Jun 2010 15:41:32 -0000 Subject: [Bug 596169] Re: max_num_recipients is out by 1 References: <20100619042459.24319.76875.malonedeb@palladium.canonical.com> Message-ID: <20100619154133.15537.2673.malone@gandwana.canonical.com> Did you read the documentation at the "(Details for max_num_recipients)" link where it says "If a posting has this number, or more, of recipients, it is held for admin approval. Use 0 for no ceiling."? Granted it's probably a bad design, but the documentation correctly describes how it works. ** Changed in: mailman Status: New => Invalid -- max_num_recipients is out by 1 https://bugs.launchpad.net/bugs/596169 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From barry at canonical.com Sat Jun 19 22:49:41 2010 From: barry at canonical.com (Barry Warsaw) Date: Sat, 19 Jun 2010 20:49:41 -0000 Subject: [Bug 497968] Re: Need a 'no-daemonize' option for '/bin/mailman start' References: <20091217213007.23975.78442.malonedeb@wampee.canonical.com> Message-ID: <20100619204942.21562.14357.launchpad@palladium.canonical.com> ** Changed in: mailman Status: Triaged => Won't Fix -- Need a 'no-daemonize' option for '/bin/mailman start' https://bugs.launchpad.net/bugs/497968 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From giecrilj at stegny.2a.pl Mon Jun 21 09:03:22 2010 From: giecrilj at stegny.2a.pl (Christopher Yeleighton) Date: Mon, 21 Jun 2010 07:03:22 -0000 Subject: [Bug 596764] [NEW] malformed digest archive References: <20100621070322.1442.18955.malonedeb@soybean.canonical.com> Message-ID: <20100621070322.1442.18955.malonedeb@soybean.canonical.com> Public bug reported: == Steps to reproduce == 1. Download the xslt Archives of Aug. 2002 . 2. gunzip '-l' '2002-August.txt.gz' Is: compressed uncompressed ratio uncompressed_name 145767 2831 -5048.0% 2002-August.txt Should be: compressed uncompressed ratio uncompressed_name 145767 380598 (whatever) 2002-August.txt == Workaround == The workaround is to gunzip the archive without listing. == See also == Ark reads only the first message of a gzipped digest ** Affects: mailman Importance: Undecided Status: New -- malformed digest archive https://bugs.launchpad.net/bugs/596764 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Mon Jun 21 17:22:04 2010 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 21 Jun 2010 15:22:04 -0000 Subject: [Bug 596764] Re: malformed digest archive References: <20100621070322.1442.18955.malonedeb@soybean.canonical.com> Message-ID: <20100621152204.26574.54246.malone@wampee.canonical.com> This does not appear to be a Mailman bug per se. I can see the problem with the .txt.gz files in the http://mail.gnome.org/archives/xslt/ archive, but I see this is a MHonArc archive, not a pipermail archive, and I don't know how the .txt.gz files are made in this environment. As noted, I am able to gunzip the .txt.gz file into a .txt file which is the full length, and if I then gzip that file with the Python 2.6.5 gzip module (which is the what standard GNU Mailman does) I get a result as follows: $ gunzip -l 2002-August.txt.gz compressed uncompressed ratio uncompressed_name 82840 380598 78.2% 2002-August.txt I get the same result with the gzip modules from Python 2.5.2 and 2.4.3. So, this appears to be a problem with whatever process produces the .txt.gz files from the .txt files in this particular installation's archive. I have also looked at some .txt.gz files in some other installation's archives, and they don't have this problem. ** Changed in: mailman Status: New => Invalid -- malformed digest archive https://bugs.launchpad.net/bugs/596764 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Wed Jun 23 17:21:17 2010 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 23 Jun 2010 15:21:17 -0000 Subject: [Bug 597741] [NEW] Lists missing from listinfo and admin overviews if host contains :port. References: <20100623152117.26310.89982.malonedeb@wampee.canonical.com> Message-ID: <20100623152117.26310.89982.malonedeb@wampee.canonical.com> Public bug reported: The fix for Bug #342162 failed to account for a possible :port in the URL used to visit the listinfo or admin overview pages. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: In Progress ** Changed in: mailman Importance: Undecided => Medium ** Changed in: mailman Status: New => In Progress ** Changed in: mailman Milestone: None => 2.1.14 ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- Lists missing from listinfo and admin overviews if host contains :port. https://bugs.launchpad.net/bugs/597741 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From unmobile+ubuntu at gmail.com Wed Jun 23 17:44:20 2010 From: unmobile+ubuntu at gmail.com (Phil M) Date: Wed, 23 Jun 2010 15:44:20 -0000 Subject: [Bug 597746] [NEW] UI inconsistency in administrative requests - actions in different orders References: <20100623154420.26310.8797.malonedeb@wampee.canonical.com> Message-ID: <20100623154420.26310.8797.malonedeb@wampee.canonical.com> Public bug reported: When moderating messages, I'm offered the opportunity to automatically set the disposition of all future messages from a given sender. I expect that the common case for this is "dispose of all future messages as I did this one". However, the corresponding options are listed in different orders for these two related actions. The attached picture highlights what I'm talking about. ** Affects: mailman Importance: Undecided Status: New -- UI inconsistency in administrative requests - actions in different orders https://bugs.launchpad.net/bugs/597746 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From unmobile+ubuntu at gmail.com Wed Jun 23 17:44:20 2010 From: unmobile+ubuntu at gmail.com (Phil M) Date: Wed, 23 Jun 2010 15:44:20 -0000 Subject: [Bug 597746] Re: UI inconsistency in administrative requests - actions in different orders References: <20100623154420.26310.8797.malonedeb@wampee.canonical.com> Message-ID: <20100623154421.26310.79516.malone@wampee.canonical.com> ** Attachment added: "An illustration of my concern" http://launchpadlibrarian.net/50806606/mailman.png -- UI inconsistency in administrative requests - actions in different orders https://bugs.launchpad.net/bugs/597746 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Thu Jun 24 04:33:42 2010 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 24 Jun 2010 02:33:42 -0000 Subject: [Bug 597746] Re: UI inconsistency in administrative requests - actions in different orders References: <20100623154420.26310.8797.malonedeb@wampee.canonical.com> Message-ID: <20100624023343.24319.11623.malone@palladium.canonical.com> I am moving this as a feature suggestion to the project for the Mailman 3.0 web UI. It will not be changed for Mailman 2.1. ** Project changed: mailman => mailmanweb -- UI inconsistency in administrative requests - actions in different orders https://bugs.launchpad.net/bugs/597746 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Thu Jun 24 06:17:20 2010 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 24 Jun 2010 04:17:20 -0000 Subject: [Bug 597741] Re: Lists missing from listinfo and admin overviews if host contains :port. References: <20100623152117.26310.89982.malonedeb@wampee.canonical.com> Message-ID: <20100624041721.15581.15512.launchpad@gandwana.canonical.com> ** Changed in: mailman Status: In Progress => Fix Committed ** Branch linked: lp:mailman/2.1 -- Lists missing from listinfo and admin overviews if host contains :port. https://bugs.launchpad.net/bugs/597741 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From flo.fuchs at gmail.com Fri Jun 25 18:50:43 2010 From: flo.fuchs at gmail.com (florianfuchs) Date: Fri, 25 Jun 2010 16:50:43 -0000 Subject: [Merge] lp:~flo-fuchs/mailman/restclient into lp:mailman Message-ID: <20100625165042.6066.5358.launchpad@loganberry.canonical.com> florianfuchs has proposed merging lp:~flo-fuchs/mailman/restclient into lp:mailman. Requested reviews: Mailman Coders (mailman-coders) I added a rest client in src/mailmanclient as well as a doctest in src/mailman/rest/docs/restclient.txt. -- https://code.launchpad.net/~flo-fuchs/mailman/restclient/+merge/28522 Your team Mailman Coders is requested to review the proposed merge of lp:~flo-fuchs/mailman/restclient into lp:mailman. -------------- next part -------------- A non-text attachment was scrubbed... Name: review-diff.txt Type: text/x-diff Size: 12200 bytes Desc: not available URL: From mark at msapiro.net Sat Jun 26 00:30:40 2010 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 25 Jun 2010 22:30:40 -0000 Subject: [Bug 598671] [NEW] KeyError in admindb when acting on a previously handled post. References: <20100625223040.15581.20464.malonedeb@gandwana.canonical.com> Message-ID: <20100625223040.15581.20464.malonedeb@gandwana.canonical.com> Public bug reported: If one moderator gets the admindb detail page for a post, and after retrieving the page but before acting on the post, another moderator or the poster acts on the post, submission of the detail page with action by the first moderator will throw a KeyError and produce the "we hit a bug" response. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: In Progress ** Changed in: mailman Importance: Undecided => Medium ** Changed in: mailman Status: New => In Progress ** Changed in: mailman Milestone: None => 2.1.14 ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- KeyError in admindb when acting on a previously handled post. https://bugs.launchpad.net/bugs/598671 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mark at msapiro.net Sat Jun 26 00:41:58 2010 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 25 Jun 2010 22:41:58 -0000 Subject: [Bug 598671] Re: KeyError in admindb when acting on a previously handled post. References: <20100625223040.15581.20464.malonedeb@gandwana.canonical.com> Message-ID: <20100625224159.31982.4310.launchpad@soybean.canonical.com> ** Changed in: mailman Status: In Progress => Fix Committed ** Branch linked: lp:mailman/2.1 -- KeyError in admindb when acting on a previously handled post. https://bugs.launchpad.net/bugs/598671 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mss at msquadrat.de Tue Jun 29 18:27:36 2010 From: mss at msquadrat.de (Malte S. Stretz) Date: Tue, 29 Jun 2010 16:27:36 -0000 Subject: [Bug 266824] Re: Add option to remove Sender header References: <20080905194257.1806.1335.launchpad@forster.canonical.com> Message-ID: <20100629162737.16079.21814.launchpad@soybean.canonical.com> ** Branch linked: lp:~mss/mailman/2.1-sender-header -- Add option to remove Sender header https://bugs.launchpad.net/bugs/266824 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From barry at canonical.com Tue Jun 29 20:45:40 2010 From: barry at canonical.com (Barry Warsaw) Date: Tue, 29 Jun 2010 18:45:40 -0000 Subject: [Merge] lp:~flo-fuchs/mailman/restclient into lp:mailman In-Reply-To: <20100625165042.6066.5358.launchpad@loganberry.canonical.com> Message-ID: <20100629144254.3f4e87d9@heresy> Thanks for getting this client library started, Florian! Here are some thoughts on your merge proposal. As we discussed on IRC, I now think the best place for this code is in src/mailmanclient. Don't worry about that though; I'll fix that up when I merge to trunk. I know for now it's difficult getting the test suite to run with that layout, so I'll take that on. I don't think it will be too difficult, but there will also be some other useful helpers to share. Omitting the non-controversial stuff. === added file 'src/mailman/rest/docs/restclient.txt' --- src/mailman/rest/docs/restclient.txt 1970-01-01 00:00:00 +0000 +++ src/mailman/rest/docs/restclient.txt 2010-06-25 16:50:42 +0000 > @@ -0,0 +1,89 @@ > +=================== > +Mailman REST Client > +=================== > + > +Domains > +======= > + > + # The test framework starts out with an example domain, so let's delete > + # that first. > + >>> from mailman.interfaces.domain import IDomainManager > + >>> from zope.component import getUtility > + >>> domain_manager = getUtility(IDomainManager) > + > + >>> domain_manager.remove('example.com') > + > + >>> transaction.commit() The test infrastructure currently sets up this sample domain. I wonder whether the REST client tests will more often want to start from a clean slate, or want this example domain. I think perhaps the former, so I should probably add a layer that is just like the ConfigLayer, but has an empty testSetUp(). (You don't have to worry about that for now. :) > +In order to add new lists first a new domain has to be added. > + > + >>> from mailmanclient.rest import MailmanRESTClient, MailmanRESTClientError > + >>> c = MailmanRESTClient('localhost:8001') > + >>> c.create_domain('example.com') > + True What do you think about having proxy objects for Domains, Lists, etc.? Launchpadlib works like this and it provides more of a natural, object oriented API to clients, rather than an XMLRPC style seen here. So for example, .create_domain() would return a Domain surrogate, and you'd call things like .get_lists() and .create_list() on that object. How much harder do you think it would be to do something like that, and do you think it would be worth it? > + > + > +Mailing lists > +============= > + > +You can get a lists of all lists by calling get_lists(). If no lists have been created yet, MailmanRESTClientError is raised. Please wrap narrative to 78 characters. > + > + >>> lists = c.get_lists() > + Traceback (most recent call last): > + ... > + MailmanRESTClientError: No mailing lists found I think it might be better to return an empty list instead of raising an exception here. Think about application code like so: # Display all the current lists. try: lists = c.get_lists() except MailmanRESTClientError: # Are we sure we got "No mailing lists found" or did some other # generic client error occur? lists = [] for mailing_list in lists: # ... The thing is, having no mailing lists isn't an error condition, so this should probably return an empty (Python) list rather than raise an exception. > + > +Lists can be created by calling create_list('listname at domain.tld'). > + > + >>> c.create_list('test-one at example.com') > + True > + >>> c.create_list('test-two at example.com') > + True > + > +If there are any mailing lists a list of dicts is returned. > + > + >>> lists = c.get_lists() > + >>> lists > + [{u'real_name': u'Test-one', u'self_link': u'http://localhost:8001/3.0/lists/test-one at example.com', u'http_etag': u'"5e99519ef1b823a52254b77e89bec54fbd17bef0"', u'host_name': u'example.com', u'fqdn_listname': u'test-one at example.com', u'list_name': u'test-one'}, {u'real_name': u'Test-two', u'self_link': u'http://localhost:8001/3.0/lists/test-two at example.com', u'http_etag': u'"a05542c9faa07cbe2b8fdf8a1655a2361ab365f2"', u'host_name': u'example.com', u'fqdn_listname': u'test-two at example.com', u'list_name': u'test-two'}] Unfortunately, this is too fragile because it depends on dictionary sort order, which isn't defined in Python, and has definitely changed between Python versions! This is why I added the dump_json() helper in src/mailman/tests/test_documentation.py. That helper isn't entirely appropriate for your tests because you don't explicitly pass in a url; that's basically embedded in .get_lists and the client. But there's enough commonality that dump_json() should be refactored into something that can be shared. Do you want to take a crack at that? > + > +Information about a specific list can be read (returns a single dict). > + > + >>> list = c.read_list('test-one at example.com') > + >>> list > + {u'real_name': u'Test-one', u'self_link': u'http://localhost:8001/3.0/lists/test-one at example.com', u'http_etag': u'"5e99519ef1b823a52254b77e89bec54fbd17bef0"', u'host_name': u'example.com', u'fqdn_listname': u'test-one at example.com', u'list_name': u'test-one'} I'm not sure 'reading' a list is the right phrase here. "Reading" a list implies to me reading its archive. Maybe .get_list() here? > + > + > +Membership > +========== > + > +Users can subscribe to a mailing list using the list's name, their email address, as well as their name. > + > + >>> c.subscribe_list('test-one at example.com', 'aperson at example.com', 'Garp') > + True > + >>> c.subscribe_list('test-one at example.com', 'bperson at example.com', 'Jenny') > + True > + >>> c.subscribe_list('test-two at example.com', 'bperson at example.com', 'Jenny') > + True Here's a place where a more object-oriented client might work better. For example, if we had both a List and User object, then depending on which one you had, you could do a simpler subscription. E.g. if .read_list/.get_list returned a List object, you'd do something like this: >>> test_one = c.get_list('test-one at example.com') >>> member = test_one.subscribe('aperson at example.com', 'Garp') Conversely, if you had a User object, you could do: >>> aperson = c.get_user('aperson at example.com') >>> aperson.subscribe('test-one at example.com') > +Members of all mailings list can be listed (returns a list of dicts). > + > + >>> all_members = c.get_members() > + >>> all_members > + [{u'self_link': u'http://localhost:8001/3.0/lists/test-one at example.com/member/aperson at example.com', u'http_etag': u'"925a22dc585a1c713d79912bd951f4cbb358dae2"'}, {u'self_link': u'http://localhost:8001/3.0/lists/test-one at example.com/member/bperson at example.com', u'http_etag': u'"344ef9f37f59cce14a81b688dd1fa3d39112e6b5"'}, {u'self_link': u'http://localhost:8001/3.0/lists/test-two at example.com/member/bperson at example.com', u'http_etag': u'"a5c962186200af483f6508dfbabca7a4a78ef309"'}] Here's that dict ordering problem again. > + > +As well as the members of a specific lists: > + > + >>> list_members = c.get_members('test-one at example.com') > + >>> list_members > + [{u'self_link': u'http://localhost:8001/3.0/lists/test-one at example.com/member/aperson at example.com', u'http_etag': u'"925a22dc585a1c713d79912bd951f4cbb358dae2"'}, {u'self_link': u'http://localhost:8001/3.0/lists/test-one at example.com/member/bperson at example.com', u'http_etag': u'"344ef9f37f59cce14a81b688dd1fa3d39112e6b5"'}] > + > +Lists can be unsubscribed by using list name and the member's email address > + > + >>> c.leave_list('test-one at example.com', 'bperson at example.com') > + True > + > +After leaving the list only the remaining members are shown: > + > + >>> new_members = c.get_members('test-one at example.com') > + >>> new_members > + [{u'self_link': u'http://localhost:8001/3.0/lists/test-one at example.com/member/aperson at example.com', u'http_etag': u'"925a22dc585a1c713d79912bd951f4cbb358dae2"'}] The same API principles apply here too. === added directory 'src/mailmanclient' === added file 'src/mailmanclient/__init__.py' === added file 'src/mailmanclient/rest.py' --- src/mailmanclient/rest.py 1970-01-01 00:00:00 +0000 +++ src/mailmanclient/rest.py 2010-06-25 16:50:42 +0000 > @@ -0,0 +1,248 @@ > +# Copyright (C) 2009-2010 by the Free Software Foundation, Inc. > +# > +# This file is part of GNU Mailman. > +# > +# GNU Mailman is free software: you can redistribute it and/or modify it under > +# the terms of the GNU General Public License as published by the Free > +# Software Foundation, either version 3 of the License, or (at your option) > +# any later version. > +# > +# GNU Mailman is distributed in the hope that it will be useful, but WITHOUT > +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for > +# more details. > +# > +# You should have received a copy of the GNU General Public License along with > +# GNU Mailman. If not, see . I hate to be so nitpicky on style, but I'm gonna anyway. :) A few things will help consistency with other code, so I'll be kind of anal about it for now. template.py in the top level directory is a good place to start with a new Python file. It contains the license header, a template module docstring, and some important __future__ imports. It also forces all unadorned classes to be new style (through the __metaclass__ assignment), and adds an empty __all__ for publicly exported symbols. > + > +import json > +from httplib import HTTPConnection, HTTPException > +from urllib import urlencode See src/mailman/docs/STYLEGUIDE.txt -----snip snip----- import json from httplib import HTTPConnection, HTTPException from urllib import urlencode -----snip snip----- (two blank lines between top level constructs) > + > +class MailmanRESTClientError(Exception): > + """An exception thrown by the Mailman REST API client.""" > + pass > + (blank line needed) > +class MailmanRESTClient(object): > + """A thin client wrapper for the Mailman REST API.""" > + > + def __init__(self, host): > + self.host = host > + if self.host[-1] == '/': > + self.host = self.host[:-1] > + > + # general header information This should be a complete sentence, e.g.: # Include general header information. > + self.headers = { > + "User-Agent": "MailmanRESTClient", > + "Accept": "text/plain", > + } I usually prefer single quotes when possible (one less shift key to hold down :), and the closing brace should be indented 4 spaces. > + > + try: > + self.c = HTTPConnection(self.host) > + except: > + raise MailmanRESTClientError('Could not connect to server') The bare except is problematic; it's generally not a good idea to use them. In this case, it's probably better to just let the HTTPConnection exception flow up uncaught. > + > + def __repr__(self): > + return '' % self.host > + > + def _get_url(self, path): > + try: > + self.c.request('GET', path, None, self.headers) > + except: > + raise MailmanRESTClientError('Error sending request') Similarly here. I don't think we need to turn all exceptions into MailmanRESTClientErrors. Let's reserve that exception hierarchy for exceptions specifically in our library. > + > + try: > + r = self.c.getresponse() > + raw_data = r.read() > + if len(raw_data) == 0: > + raise None You're actually not allowed to raise None (I had to try it myself to see :). This might be another case of just letting the original exception percolate up: >>> json.loads('') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.6/json/__init__.py", line 307, in loads return _default_decoder.decode(s) File "/usr/lib/python2.6/json/decoder.py", line 319, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/usr/lib/python2.6/json/decoder.py", line 338, in raw_decode raise ValueError("No JSON object could be decoded") ValueError: No JSON object could be decoded I'm a little less sure about this one, but that probably calls for just letting the json.loads() fail until there's an overriding reason to mutate it. > + data = json.loads(raw_data) > + except: > + raise MailmanRESTClientError('Error sending request') > + finally: > + self.c.close() > + > + return data > + > + def _post_url(self, path, data): > + self.headers['Content-type'] = "application/x-www-form-urlencoded" > + > + try: > + self.c.request('POST', path, urlencode(data), self.headers) > + except: > + raise MailmanRESTClientError('Could not send request') Again, probably don't need to try/except this. > + > + try: > + r = self.c.getresponse() > + > + if r.status == 201: > + return True > + else: > + return r.status Interesting. Why not always just return the status code? It seems like it would be better to always return an integer and let the client decide what to do with the status code, rather than transform just 201 into True. > + finally: > + self.c.close() > + > + def _delete_url(self, path): > + try: > + self.c.request('DELETE', path, None, self.headers) > + except: > + raise MailmanRESTClientError('Could not send request') > + finally: > + self.c.close() Similar. > + > + def _put_url(self, path): > + """To be implemented... > + """ You can use an XXX comment like so: """XXX 2010-06-29 florian: to be implemented.""" That slightly suggestive XXX is an old Guido tradition, but there are lots of good tools that search for them and remind you about them. E.g. pylint. Including the date and your Launchpad id is a good idea to identify who wrote the comment and how old it is, without having to reconstruct it from the vcs history. > + pass > + > + def get_lists(self): > + """Get a list of mail lists. > + > + returns a list of dicts You can use epydoc rest markup for describing the parameters and return values for a method. http://epydoc.sourceforge.net/manual-fields.html#epydoc-fields There are lots of examples sprinkled about in the current Mailman code. > + """ > + try: > + r = self._get_url('/3.0/lists') > + except: > + raise MailmanRESTClientError('Could not send request') > + > + if 'entries' not in r: > + raise MailmanRESTClientError('No mailing lists found') > + > + return r['entries'] > + > + def read_list(self, list_name): > + """Get information about list. > + > + :param list_name: name of the list to get information about > + :type list_name: string > + :rtype: dict Yep, like that! > + """ > + try: > + r = self._get_url('/3.0/lists/' + list_name) > + except: > + raise MailmanRESTClientError('Unable to get info about list') > + > + return r > + > + def create_list(self, fqdn_listname, **kwargs): > + """Create a new list. > + > + :param fqdn_listname: the name of the list including the @ and the domain name. eg. test at example.com This needs to be line wrapped to 78 characters. You can indent continuation lines. > + :type fqdn_listname: string > + :rtype: None > + """ > + data = { > + 'fqdn_listname': fqdn_listname Dedent 4 spaces and end in a comma. > + } Indent 4 spaces. > + data.update(**kwargs) > + try: > + return self._post_url('/3.0/lists', data) > + except MailmanRESTClientError, e: > + raise MailmanRESTClientError(e) Similar, no need to catch this exception. > + > + > + def subscribe_list(self, fqdn_listname, address, real_name, **kwargs): > + """Add an address to a list. > + > + :param fqdn_listname: the name of the list . > + :type fqdn_listname: string > + :param address: email address to add to the list. > + :type address: string > + :param real_name: the "real" name for the address to be addded > + :type real_name: string > + """ > + > + data = { > + 'fqdn_listname': fqdn_listname, > + 'address': address, > + 'real_name': real_name Dedent all lines 4 spaces and end the last one in a comma. > + } Indent 4 spaces. > + data.update(**kwargs) > + try: > + r = self._post_url('/3.0/members', data) > + except: > + raise MailmanRESTClientError('unable to join list') Don't catch. > + > + return r > + > + def leave_list(self, fqdn_listname, address): > + """Remove an address from a list. > + > + :param fqdn_listname: the name of the list. > + :type fqdn_listname: string > + :param address: email address that is leaving the list > + :type address: string > + :rtype: None > + """ > + try: > + r = self._delete_url('/3.0/lists/' + fqdn_listname + '/member/' + address ) Line length. You can probably just write this like: return self._delete_url( '/3.0/lists/' + fqdn_listname + '/member/' + address) (Note, no space before the close paren.) > + except: > + raise MailmanRESTClientError('unable to leave list') > + > + return True > + > + def get_members(self, fqdn_listname = None): No spaces around the = sign. > + """Get a list of all members for all lists. > + > + :rtype: list of dicts > + :type fqdn_listname: string > + """ > + > + if fqdn_listname != None: > + url = '/3.0/lists/' + fqdn_listname + '/roster/members' > + else: > + url = '/3.0/members' > + try: > + r = self._get_url(url) > + except: > + raise MailmanRESTClientError('Could not complete request') > + > + if 'entries' not in r: > + raise MailmanRESTClientError('Could not find any members') Maybe just return the empty list here? > + > + return r['entries'] > + > + def get_domains(self): > + """Get a list of domains. > + > + :rtype: list of dicts > + """ > + try: > + r = self._get_url('/3.0/domains') > + except: > + raise MailmanRESTClientError('Could not complete request') > + if 'entries' not in r: > + raise MailmanRESTClientError('Could not find any domains') And here, an empty list would be fine. > + > + return r['entries'] > + > + def read_domain(self, domain_name): > + """Get information about a specific domain. > + > + :param domain_name: the name of the domain. > + :rtype: dict > + """ > + try: > + r = self._get_url('/3.0/domains/' + domain_name) > + except: > + raise MailmanRESTClientError('Unable to read domain') > + > + return r > + > + def create_domain(self, email_host, **kwargs): > + """Create a new domain name. > + > + :param email_host: domain name to create > + :type email_host: string > + """ > + data = { > + 'email_host': email_host, > + } > + data.update(**kwargs) > + try: > + r = self._post_url('/3.0/domains', data) > + except: > + raise MailmanRESTClientError('Unable to create domain') > + > + return r > + Similar comments here. This is a great first draft. Please let me know if any of my comments don't make sense or you have questions about them. Thanks! -Barry -- https://code.launchpad.net/~flo-fuchs/mailman/restclient/+merge/28522 Your team Mailman Coders is requested to review the proposed merge of lp:~flo-fuchs/mailman/restclient into lp:mailman. From mss at msquadrat.de Wed Jun 30 16:02:55 2010 From: mss at msquadrat.de (Malte S. Stretz) Date: Wed, 30 Jun 2010 14:02:55 -0000 Subject: [Bug 266824] Re: Add option to remove Sender header References: <20080905194257.1806.1335.launchpad@forster.canonical.com> Message-ID: <20100630140255.6052.24415.malone@potassium.ubuntu.com> Sender header rewriting will be gone in 3.0: http://bazaar.launchpad.net /~mailman-coders/mailman/3.0/revision/6915 ** Changed in: mailman Status: New => Fix Committed -- Add option to remove Sender header https://bugs.launchpad.net/bugs/266824 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From barry at canonical.com Wed Jun 30 16:19:30 2010 From: barry at canonical.com (Barry Warsaw) Date: Wed, 30 Jun 2010 14:19:30 -0000 Subject: [Bug 266824] Re: Add option to remove Sender header References: <20080905194257.1806.1335.launchpad@forster.canonical.com> Message-ID: <20100630141932.2363.91279.launchpad@palladium.canonical.com> ** Also affects: mailman/3.0 Importance: Medium Status: Fix Committed ** Changed in: mailman/3.0 Assignee: (unassigned) => Barry Warsaw (barry) ** Changed in: mailman/3.0 Milestone: None => 3.0.0a6 -- Add option to remove Sender header https://bugs.launchpad.net/bugs/266824 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mss at msquadrat.de Wed Jun 30 16:40:46 2010 From: mss at msquadrat.de (Malte S. Stretz) Date: Wed, 30 Jun 2010 14:40:46 -0000 Subject: [Bug 266824] Re: Add option to remove Sender header References: <20080905194257.1806.1335.launchpad@forster.canonical.com> Message-ID: <20100630144047.16137.81521.launchpad@soybean.canonical.com> ** Branch linked: lp:~mss/mailman/2.2-sender-header -- Add option to remove Sender header https://bugs.launchpad.net/bugs/266824 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. From mss at msquadrat.de Wed Jun 30 17:01:29 2010 From: mss at msquadrat.de (Malte S. Stretz) Date: Wed, 30 Jun 2010 15:01:29 -0000 Subject: [Merge] lp:~mss/mailman/2.1-sender-header into lp:mailman/2.1 Message-ID: <20100630150129.24567.83474.launchpad@loganberry.canonical.com> Malte S. Stretz has proposed merging lp:~mss/mailman/2.1-sender-header into lp:mailman/2.1. Requested reviews: Mailman Coders (mailman-coders) Related bugs: #266824 Add option to remove Sender header https://bugs.launchpad.net/bugs/266824 Adds the long due option to disable the generation of the Sender header. The patch is quite simple, the changes in behaviour essentially being what some people already use for ages. But I don't know if I made an error in the GUI integration. Already prediscussed here . -- https://code.launchpad.net/~mss/mailman/2.1-sender-header/+merge/28901 Your team Mailman Coders is requested to review the proposed merge of lp:~mss/mailman/2.1-sender-header into lp:mailman/2.1. -------------- next part -------------- A non-text attachment was scrubbed... Name: review-diff.txt Type: text/x-diff Size: 5372 bytes Desc: not available URL: From mss at msquadrat.de Wed Jun 30 17:03:30 2010 From: mss at msquadrat.de (Malte S. Stretz) Date: Wed, 30 Jun 2010 15:03:30 -0000 Subject: [Merge] lp:~mss/mailman/2.2-sender-header into lp:mailman/2.2 Message-ID: <20100630150330.24751.29925.launchpad@loganberry.canonical.com> Malte S. Stretz has proposed merging lp:~mss/mailman/2.2-sender-header into lp:mailman/2.2. Requested reviews: Mailman Coders (mailman-coders) Related bugs: #266824 Add option to remove Sender header https://bugs.launchpad.net/bugs/266824 This is essentially the same change as proposed here for 2.1. -- https://code.launchpad.net/~mss/mailman/2.2-sender-header/+merge/28902 Your team Mailman Coders is requested to review the proposed merge of lp:~mss/mailman/2.2-sender-header into lp:mailman/2.2. -------------- next part -------------- A non-text attachment was scrubbed... Name: review-diff.txt Type: text/x-diff Size: 5372 bytes Desc: not available URL: