Mailman 3 January 2006 - Mailman-coders

[ mailman-Patches-657951 ] Generate RSS summary in archives
by SourceForge.net 19 Aug '22

19 Aug '22

Patches item #657951, was opened at 2002-12-23 14:17 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i… Category: Pipermail Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 7 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Generate RSS summary in archives Initial Comment: Here's a first-draft patch. Things that need fixing: * The generated RSS feed needs to be validated. (It passed the W3C's RDF validator, but RSS validators still need to be checked.) * The date should be given in YYYY-MM-DD format, which requires parsing the .fromdate attribute. * How do I get the URL for an archived message? The generated RSS currently just uses the filename, which is wrong. How do I get at the PUBLIC_ARCHIVE_URL setting? * Getting the most recent N postings is inefficient; the code loops through all of the archived messages and takes the last N of them. We could add .last() and .prev() methods to the Database class, but that's more ambitious for 2.1beta than I like. (Would be nice to get this into 2.1final...) * The list index page should have a LINK element pointing to the RSS file. Please make any comments you have, and I'll rework the patch accordingly. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-18 18:43 Message: Logged In: YES user_id=12800 Andrew, to get the url for the archived message use mlist.GetBaseArchiveURL(), which knows about private vs. public archives, the host name and the list name. From there you should be able to tack on just the part of the path under "archives/private/listname". See Mailman/Handlers/Scrubber.py for an example. Only other minor comment: NUM_ARTICLES can probably go in Defaults.py.in ---------------------------------------------------------------------- Comment By: Justin Mason (jmason) Date: 2003-03-26 16:49 Message: Logged In: YES user_id=935 big thumbs up from me too. Much better solution than http://taint.org/mmrss/ ;) ---------------------------------------------------------------------- Comment By: Uche Ogbuji (uche) Date: 2003-03-17 20:09 Message: Logged In: YES user_id=38966 I'd like to add my vote to this item. This is a fantastic idea, Andrew. Thanks. --Uche ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 15:42 Message: Logged In: YES user_id=11375 Updated patch: * Dates are now rendered as ISO-8601 (date only, not the time of the message) * By hard-wiring 2002-December, I got the RSS to validate using Mark Pilgrim's validator. ---------------------------------------------------------------------- Comment By: captain larry (captainlarry) Date: 2002-12-23 14:36 Message: Logged In: YES user_id=147905 Just voting for support here. This is *great* thanks for the patch and I hope the maintainers include it as soon as it's appropriate :) Adam. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-23 14:27 Message: Logged In: YES user_id=12800 Deferring until post-2.1 ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 14:21 Message: Logged In: YES user_id=11375 Argh; SF choked on the file upload. Attaching the patch again... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i…

2 1

[ mailman-Patches-1419490 ] email.Utils.parsedate can return bogus date
by SourceForge.net 30 Jan '06

30 Jan '06

Patches item #1419490, was opened at 2006-01-31 01:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1419490&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Tokio Kikuchi (tkikuchi) Summary: email.Utils.parsedate can return bogus date Initial Comment: While the CVE entry of CVE-2005-4153 (see http://www.securityfocus.com/bid/16248/info) is not vulnerable for mailman-2.1.7 and newer, we should fix the date parsing bug in email package. In the meantime of the package renewal, this patch may be used to workaround the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1419490&group_…

1 0

[ mailman-Bugs-1000699 ] moderator page with details misses a submit button
by SourceForge.net 30 Jan '06

30 Jan '06

Bugs item #1000699, was opened at 2004-07-30 09:30 Message generated for change (Comment added) made by djast You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1000699&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web/CGI Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Stepan Kasal (kasal) Assigned to: Nobody/Anonymous (nobody) Summary: moderator page with details misses a submit button Initial Comment: Working with version 2.1.5. I moderate a few lists. When I go from summary page to "wiev the detail of individual postings", I get a page which has a submit button at the bottom. Similar button should be on the top, as with the Summary page. Besides being an inconvenience, this can also be confusing: I checked "Discard all msgs marked as deferred" on the top, then moved to the end and pressed the button there. Of course the upper checkbox had no influence. Btw: I hope that the "discard all deferred" checkbox discards only the messages from that dispayed page, not the messages that might have arrived while themoderator was staring at the page. That would be nasty if it weren't this way. ---------------------------------------------------------------------- Comment By: Dan Astoorian (djast) Date: 2006-01-30 10:54 Message: Logged In: YES user_id=1437943 Apologies for being unclear: the "details" page I was referring to in my followup is the "?details=all" page (following the "you can also view the details of all held postings" link at the top of the summary page), not the details page for an individual sender or message id. The "discard all deferred" checkbox still does appear (but fails to work) on the "?details=all" page, as of 2.1.7. The test for whether to supply the button is "if not (sender or msgid):"; if the button is not supposed to appear on the "?details=all" page, perhaps the test should be changed to something like "if not (details or sender or msgid)"? ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-01-30 10:21 Message: Logged In: YES user_id=1123998 I am marking this closed/fixed because the "discard all deferred" checkbox was intended to work only on the summary page. It's appearance on the detail pages was a mistake that was fixed in 2.1.6. So yes, in 2.1.5 neither "discard all deferred" checkbox works on the detail pages, and BTW, you can check the box at the top of the summary page and click the button at the bottom or vice versa and it works. In 2.1.6 and above, the checkboxes appear only on the summary page and they only cause messages on that page marked 'defer' to be discarded even if there are other messages not rendered on that page. Also, there are submit buttons at both the top and bottom of both the 'all messages from' detail and the individual message detail. If you really want a "discard all messages marked defer" box that works on the "view all messages from" page, that is now a feature request (RFE) and should be resubmitted as such. ---------------------------------------------------------------------- Comment By: Dan Astoorian (djast) Date: 2006-01-30 09:48 Message: Logged In: YES user_id=1437943 The scope of the problem is greater than that: "Discard all msgs marked as deferred" does not appear to work at all from the "details" page, as far as I can tell. In the summary page, each group of items on which an action is to be taken is identified with a set of radio buttons with 'INPUT name="senderaction-SENDER"' tags, and the "senderaction-" prefix is used by the code in Cgi/admindb.py which processes the "Discard all msgs marked as deferred" checkbox. However, the details page uses only the request-id in the field names, e.g., 'INPUT name="10112"', so they aren't processed by the same code. I can't find anywhere else in the code (Mailman 2.1.7) where the discardalldefersp field is processed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1000699&group_…

1 0

[ mailman-Bugs-1000699 ] moderator page with details misses a submit button
by SourceForge.net 30 Jan '06

30 Jan '06

Bugs item #1000699, was opened at 2004-07-30 06:30 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1000699&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web/CGI Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stepan Kasal (kasal) Assigned to: Nobody/Anonymous (nobody) Summary: moderator page with details misses a submit button Initial Comment: Working with version 2.1.5. I moderate a few lists. When I go from summary page to "wiev the detail of individual postings", I get a page which has a submit button at the bottom. Similar button should be on the top, as with the Summary page. Besides being an inconvenience, this can also be confusing: I checked "Discard all msgs marked as deferred" on the top, then moved to the end and pressed the button there. Of course the upper checkbox had no influence. Btw: I hope that the "discard all deferred" checkbox discards only the messages from that dispayed page, not the messages that might have arrived while themoderator was staring at the page. That would be nasty if it weren't this way. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-01-30 07:21 Message: Logged In: YES user_id=1123998 I am marking this closed/fixed because the "discard all deferred" checkbox was intended to work only on the summary page. It's appearance on the detail pages was a mistake that was fixed in 2.1.6. So yes, in 2.1.5 neither "discard all deferred" checkbox works on the detail pages, and BTW, you can check the box at the top of the summary page and click the button at the bottom or vice versa and it works. In 2.1.6 and above, the checkboxes appear only on the summary page and they only cause messages on that page marked 'defer' to be discarded even if there are other messages not rendered on that page. Also, there are submit buttons at both the top and bottom of both the 'all messages from' detail and the individual message detail. If you really want a "discard all messages marked defer" box that works on the "view all messages from" page, that is now a feature request (RFE) and should be resubmitted as such. ---------------------------------------------------------------------- Comment By: Dan Astoorian (djast) Date: 2006-01-30 06:48 Message: Logged In: YES user_id=1437943 The scope of the problem is greater than that: "Discard all msgs marked as deferred" does not appear to work at all from the "details" page, as far as I can tell. In the summary page, each group of items on which an action is to be taken is identified with a set of radio buttons with 'INPUT name="senderaction-SENDER"' tags, and the "senderaction-" prefix is used by the code in Cgi/admindb.py which processes the "Discard all msgs marked as deferred" checkbox. However, the details page uses only the request-id in the field names, e.g., 'INPUT name="10112"', so they aren't processed by the same code. I can't find anywhere else in the code (Mailman 2.1.7) where the discardalldefersp field is processed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1000699&group_…

1 0

[ mailman-Bugs-1418670 ] Problems with lists named like languages
by SourceForge.net 30 Jan '06

30 Jan '06

Bugs item #1418670, was opened at 2006-01-30 15:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1418670&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: configuring/installing Group: 2.1 (stable) Status: Open Resolution: None Priority: 6 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with lists named like languages Initial Comment: "update" has fatal problems with lists named like a language. Create some lists named "it" (Italian) or "de" (German) an update will crash: Updating mailing list: de Updating the held requests database. - updating old private mbox file looks like you have a really recent CVS installation... you're either one brave soul, or you already ran me - updating old public mbox file looks like you have a really recent CVS installation... you're either one brave soul, or you already ran me - This list looks like it might have <= b4 list templates around Traceback (most recent call last): File "bin/update", line 789, in ? errors = main() File "bin/update", line 679, in main errors = errors + dolist(listname) File "bin/update", line 357, in dolist os.rename(o_tmpl, n_tmpl) OSError: [Errno 2] No such file or directory make: *** [update] Error 1 (Btw: update crashs if there`s no pending.pck. That should not happen!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1418670&group_…

1 0

[ mailman-Bugs-1000699 ] moderator page with details misses a submit button
by SourceForge.net 30 Jan '06

30 Jan '06

Bugs item #1000699, was opened at 2004-07-30 09:30 Message generated for change (Comment added) made by djast You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1000699&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Stepan Kasal (kasal) Assigned to: Nobody/Anonymous (nobody) Summary: moderator page with details misses a submit button Initial Comment: Working with version 2.1.5. I moderate a few lists. When I go from summary page to "wiev the detail of individual postings", I get a page which has a submit button at the bottom. Similar button should be on the top, as with the Summary page. Besides being an inconvenience, this can also be confusing: I checked "Discard all msgs marked as deferred" on the top, then moved to the end and pressed the button there. Of course the upper checkbox had no influence. Btw: I hope that the "discard all deferred" checkbox discards only the messages from that dispayed page, not the messages that might have arrived while themoderator was staring at the page. That would be nasty if it weren't this way. ---------------------------------------------------------------------- Comment By: Dan Astoorian (djast) Date: 2006-01-30 09:48 Message: Logged In: YES user_id=1437943 The scope of the problem is greater than that: "Discard all msgs marked as deferred" does not appear to work at all from the "details" page, as far as I can tell. In the summary page, each group of items on which an action is to be taken is identified with a set of radio buttons with 'INPUT name="senderaction-SENDER"' tags, and the "senderaction-" prefix is used by the code in Cgi/admindb.py which processes the "Discard all msgs marked as deferred" checkbox. However, the details page uses only the request-id in the field names, e.g., 'INPUT name="10112"', so they aren't processed by the same code. I can't find anywhere else in the code (Mailman 2.1.7) where the discardalldefersp field is processed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1000699&group_…

1 0

[ mailman-Patches-1418016 ] Dutch translation update
by SourceForge.net 29 Jan '06

29 Jan '06

Patches item #1418016, was opened at 2006-01-29 17:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1418016&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Schoinobates Volans (schoinobates) Assigned to: Nobody/Anonymous (nobody) Summary: Dutch translation update Initial Comment: A Debian user, Luc Stroobant, has contributed this update to the Dutch translation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1418016&group_…

1 0

[ mailman-Patches-1415956 ] Sitewide headers/footers & XHTML Compliant Web UI
by SourceForge.net 28 Jan '06

28 Jan '06

Patches item #1415956, was opened at 2006-01-26 22:23 Message generated for change (Comment added) made by carbonnb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1415956&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Bryan Carbonnell (carbonnb) Assigned to: Nobody/Anonymous (nobody) Summary: Sitewide headers/footers & XHTML Compliant Web UI Initial Comment: This patch was borne out of a request I received to make the Mailman UI fit the look of the web site. This patch allows you to set a site wide header and footer. This allows you to pretty much make the MM UI look like any other site. While I was at it I also made the web UI XHTML compliant. Once you patch your source and install it, all you need to do is edit the html files in the templates/en directory. Most of the pages will get the header and footers from the site-header.html and site-footer.html files, but some of the HTML files already contain theor own header/footer so you will need ot edit some of these files as well. Since this also adds XHTML compliance, this superceeds patch #116035 ---------------------------------------------------------------------- >Comment By: Bryan Carbonnell (carbonnb) Date: 2006-01-28 23:07 Message: Logged In: YES user_id=449953 Updated both patches to remove some of my site specific HTML coding. ---------------------------------------------------------------------- Comment By: Bryan Carbonnell (carbonnb) Date: 2006-01-26 22:31 Message: Logged In: YES user_id=449953 I am also uploading a second version of this patch. This second version will add the sitewide headers/footer to source that has been patched with the ht://dig integration patches. At the time I posted this, the official ht://dig integration patches were not released, but the MM2.1.6 patches appear to work with MM 2.1.7, so they are what were used. to apply this patch use this command from your mailman source directory: patch -p1 <full/path/to/headfoot-htdig-2.1.7-0.1.patch ---------------------------------------------------------------------- Comment By: Bryan Carbonnell (carbonnb) Date: 2006-01-26 22:27 Message: Logged In: YES user_id=449953 I have only tested this with the english pages. I'm not sure how to deal with i18n yet, but I'm reading and I will update this patch as soon as I figure out how to deal with it. To apply this patch for MM2.1.7, you will need to apply patch #1405790 (Mailman 2.1.7 multiple patch) first. to apply this patch use this command from your mailman source directory: patch -p1 <full/path/to/headfoot-2.1.7-0.1.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1415956&group_…

1 0

[ mailman-Bugs-1417678 ] Dutch translation wrong
by SourceForge.net 28 Jan '06

28 Jan '06

Bugs item #1417678, was opened at 2006-01-28 23:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1417678&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: (un)subscribing Group: None Status: Open Resolution: None Priority: 5 Submitted By: Koen Martens (gmc2000) Assigned to: Nobody/Anonymous (nobody) Summary: Dutch translation wrong Initial Comment: On some versions i've seen 'Uw bent' in the dutch translation of certain messages, this should be 'U bent' (uw is possesive): # grep "Uw bent" * -r messages/nl/LC_MESSAGES/mailman.po:"Uw bent op deze lijst aangemeld met het adres met niet te wijzigen You are " messages/nl/LC_MESSAGES/mailman.po:msgstr "Uw bent afgemeld van de %(realname)s maillijst" Binary file messages/nl/LC_MESSAGES/mailman.mo matches Solution is simple: just s/Uw bent/U bent/g ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1417678&group_…

1 0

[ mailman-Bugs-1416853 ] Jan 14 change to Handlers/SpamDetect.py is incomplete
by SourceForge.net 27 Jan '06

27 Jan '06

Bugs item #1416853, was opened at 2006-01-27 15:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1416853&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: security/privacy Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Astoorian (djast) Assigned to: Nobody/Anonymous (nobody) Summary: Jan 14 change to Handlers/SpamDetect.py is incomplete Initial Comment: tkikuchi's patch to Handlers/SpamDetect.py to avoid an infinite loop when administrivia messages are caught by spam filters fails to fix a related problem; a different approach should perhaps be considered. Specifically: it is (IMHO) probably incorrect to apply the "Hold" action to messages which were not submitted to the list address. For example, a message sent to "listname-owner" and matched by a "Hold" header_filter_rule should not be held for approval (irrespective of whether the message was administrivia or not). (It is not clear to the end user whether approving such a held message would cause the message to be delivered to the original "listname-owner" address, or whether it would be sent to the list itself.) I suspect (but have not verified) that similar issues may exist for other mail paths (e.g., -request, -admin, -(un)subscribe). Probably the most sensible thing to do with messages that match a "Hold" rule would be to hold the message only if the "tolist" key is set; otherwise, do one of the following: a) continue on to the next rule, as though the "Hold" rule failed to match the message; b) accept the message; or c) discard the message. It's not clear to me which of these options makes the most sense. Discarding the message is probably unwise, as a "hold" rule in the first place suggests that the administrator does not consider all mail that matches the rule to be expendable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1416853&group_…

1 0