Mailman 3 April 2007 - Mailman-coders

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

Aug. 19, 2022

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-1710185 ] Add support for digest_size_threshold = 0
by SourceForge.net April 30, 2007

April 30, 2007

Patches item #1710185, was opened at 2007-04-30 13:00 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=1710185&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 Private: No Submitted By: Michael McGraw-Herdeg (mherdeg) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for digest_size_threshold = 0 Initial Comment: This patch results in no more than one digest being sent per day if digest_size_threshold is set to zero. This behavior is documented at http://www.gnu.org/software/mailman/mailman-admin/node19.html: "Set this variable to zero to specify that there is no size threshold, in which case no more than one digest will be sent out per day." ToDigest.py does not currently implement this behavior. Under the current code, a threshold of zero will always be exceeded, so digest mode will not result in any reduction of traffic for recipients (and will in fact increase message size.) This patch expands the test to check the zero case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1710185&group_…

1 0

[ mailman-Bugs-1696053 ] Hebrew Translation Attached!
by SourceForge.net April 26, 2007

April 26, 2007

Bugs item #1696053, was opened at 2007-04-07 17:24 Message generated for change (Comment added) made by dovzamir You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1696053&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: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dubi (dovzamir) Assigned to: Nobody/Anonymous (nobody) Summary: Hebrew Translation Attached! Initial Comment: Attached are the Hebrew files for Mailman 2.1.9 I added a parameter to the LC_DESCRIPTION function, and these are the files that are affected by the addition of 'direction' to the 'LC_DESCRIPTION' function. They have been changed, and diffs are attached... ./Mailman/Cgi/create.py ./Mailman/Defaults.py.in ./Mailman/Defaults.py ./Mailman/Utils.py ./messages/es/README.es ./messages/ja/README.ja ./messages/ja/doc/Defaults.py.in ./messages/eu/README.eu Likewise, all translation files are attached. There is still a problem displaying command line output in the correct direction. Still looking for a solution... ---------------------------------------------------------------------- >Comment By: Dubi (dovzamir) Date: 2007-04-26 21:33 Message: Logged In: YES user_id=1207589 Originator: YES File Added: Mailman_2.1.9_he.tar.gz ---------------------------------------------------------------------- Comment By: Dubi (dovzamir) Date: 2007-04-26 21:30 Message: Logged In: YES user_id=1207589 Originator: YES File Added: Mailman_2.1.9_he.tar.gz ---------------------------------------------------------------------- Comment By: Dubi (dovzamir) Date: 2007-04-26 21:27 Message: Logged In: YES user_id=1207589 Originator: YES File Added: Mailman_2.1.9_he.tar.gz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1696053&group_…

1 0

[ mailman-Bugs-1696053 ] Hebrew Translation Attached!
by SourceForge.net April 26, 2007

April 26, 2007

Bugs item #1696053, was opened at 2007-04-07 17:24 Message generated for change (Comment added) made by dovzamir You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1696053&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: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dubi (dovzamir) Assigned to: Nobody/Anonymous (nobody) Summary: Hebrew Translation Attached! Initial Comment: Attached are the Hebrew files for Mailman 2.1.9 I added a parameter to the LC_DESCRIPTION function, and these are the files that are affected by the addition of 'direction' to the 'LC_DESCRIPTION' function. They have been changed, and diffs are attached... ./Mailman/Cgi/create.py ./Mailman/Defaults.py.in ./Mailman/Defaults.py ./Mailman/Utils.py ./messages/es/README.es ./messages/ja/README.ja ./messages/ja/doc/Defaults.py.in ./messages/eu/README.eu Likewise, all translation files are attached. There is still a problem displaying command line output in the correct direction. Still looking for a solution... ---------------------------------------------------------------------- >Comment By: Dubi (dovzamir) Date: 2007-04-26 21:30 Message: Logged In: YES user_id=1207589 Originator: YES File Added: Mailman_2.1.9_he.tar.gz ---------------------------------------------------------------------- Comment By: Dubi (dovzamir) Date: 2007-04-26 21:27 Message: Logged In: YES user_id=1207589 Originator: YES File Added: Mailman_2.1.9_he.tar.gz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1696053&group_…

1 0

[ mailman-Bugs-1696053 ] Hebrew Translation Attached!
by SourceForge.net April 26, 2007

April 26, 2007

Bugs item #1696053, was opened at 2007-04-07 17:24 Message generated for change (Comment added) made by dovzamir You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1696053&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: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dubi (dovzamir) Assigned to: Nobody/Anonymous (nobody) Summary: Hebrew Translation Attached! Initial Comment: Attached are the Hebrew files for Mailman 2.1.9 I added a parameter to the LC_DESCRIPTION function, and these are the files that are affected by the addition of 'direction' to the 'LC_DESCRIPTION' function. They have been changed, and diffs are attached... ./Mailman/Cgi/create.py ./Mailman/Defaults.py.in ./Mailman/Defaults.py ./Mailman/Utils.py ./messages/es/README.es ./messages/ja/README.ja ./messages/ja/doc/Defaults.py.in ./messages/eu/README.eu Likewise, all translation files are attached. There is still a problem displaying command line output in the correct direction. Still looking for a solution... ---------------------------------------------------------------------- >Comment By: Dubi (dovzamir) Date: 2007-04-26 21:27 Message: Logged In: YES user_id=1207589 Originator: YES File Added: Mailman_2.1.9_he.tar.gz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1696053&group_…

1 0

[ mailman-Feature Requests-1707731 ] Don't munge reply-to if one already exists -- feature reques
by SourceForge.net April 26, 2007

April 26, 2007

Feature Requests item #1707731, was opened at 2007-04-25 15:13 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1707731&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Knut Auvor Grythe (auvor) Assigned to: Nobody/Anonymous (nobody) Summary: Don't munge reply-to if one already exists -- feature reques Initial Comment: As you all know, a few (loud) users still seem to think reply-to header munging is a good idea, and thus I and many others feel forced to enable it on certain lists. This causes problems every time people would like a reply off-list, since people tend to reply to the list by mistake, obeying the munged reply-to. Turning off first_strip_reply_to looks like it would help at first glance, but it still requires users to edit the headers manually to remove the added list address, and many forget this. A simple solution would be to simply allow leaving any existing reply-to-headers alone, and only add one if none are already defined. This way, the munging will act as a default, allowing the sender to override it by adding an explicit one. The change should be fairly simple, and something similar to the attached diff should suffice. Naturally, the setting "leave_existing_reply_to_alone" would also have to be added and documented. The diff is just to illustrate the idea (although I can create a complete diff if you wish). ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2007-04-25 18:50 Message: Logged In: YES user_id=1123998 Originator: NO Per your comment I am moving this to Feature Requests. I'm sorry for the confusion, but it's not my tracker either :-) ---------------------------------------------------------------------- Comment By: Knut Auvor Grythe (auvor) Date: 2007-04-25 15:28 Message: Logged In: YES user_id=1137196 Originator: YES Ooops. I didn't realize that the "Submit new" menu choice acted differently based on where one was in the tracker when clicking it, and expected to be able to mark the request as a feature request on the next page or something. I'm very sorry about that. I'd normally try to clean up after myself, but this time I expect I'd just worsen the mess :-| As you've probably guessed, I've never used the SourceForge bugtracker before ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1707731&group_…

1 0

[ mailman-Patches-1707731 ] Don't munge reply-to if one already exists -- feature reques
by SourceForge.net April 25, 2007

April 25, 2007

Patches item #1707731, was opened at 2007-04-26 00:13 Message generated for change (Comment added) made by auvor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1707731&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Knut Auvor Grythe (auvor) Assigned to: Nobody/Anonymous (nobody) Summary: Don't munge reply-to if one already exists -- feature reques Initial Comment: As you all know, a few (loud) users still seem to think reply-to header munging is a good idea, and thus I and many others feel forced to enable it on certain lists. This causes problems every time people would like a reply off-list, since people tend to reply to the list by mistake, obeying the munged reply-to. Turning off first_strip_reply_to looks like it would help at first glance, but it still requires users to edit the headers manually to remove the added list address, and many forget this. A simple solution would be to simply allow leaving any existing reply-to-headers alone, and only add one if none are already defined. This way, the munging will act as a default, allowing the sender to override it by adding an explicit one. The change should be fairly simple, and something similar to the attached diff should suffice. Naturally, the setting "leave_existing_reply_to_alone" would also have to be added and documented. The diff is just to illustrate the idea (although I can create a complete diff if you wish). ---------------------------------------------------------------------- >Comment By: Knut Auvor Grythe (auvor) Date: 2007-04-26 00:28 Message: Logged In: YES user_id=1137196 Originator: YES Ooops. I didn't realize that the "Submit new" menu choice acted differently based on where one was in the tracker when clicking it, and expected to be able to mark the request as a feature request on the next page or something. I'm very sorry about that. I'd normally try to clean up after myself, but this time I expect I'd just worsen the mess :-| As you've probably guessed, I've never used the SourceForge bugtracker before ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1707731&group_…

1 0

[ mailman-Patches-1707731 ] Don't munge reply-to if one already exists -- feature reques
by SourceForge.net April 25, 2007

April 25, 2007

Patches item #1707731, was opened at 2007-04-26 00:13 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=1707731&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Knut Auvor Grythe (auvor) Assigned to: Nobody/Anonymous (nobody) Summary: Don't munge reply-to if one already exists -- feature reques Initial Comment: As you all know, a few (loud) users still seem to think reply-to header munging is a good idea, and thus I and many others feel forced to enable it on certain lists. This causes problems every time people would like a reply off-list, since people tend to reply to the list by mistake, obeying the munged reply-to. Turning off first_strip_reply_to looks like it would help at first glance, but it still requires users to edit the headers manually to remove the added list address, and many forget this. A simple solution would be to simply allow leaving any existing reply-to-headers alone, and only add one if none are already defined. This way, the munging will act as a default, allowing the sender to override it by adding an explicit one. The change should be fairly simple, and something similar to the attached diff should suffice. Naturally, the setting "leave_existing_reply_to_alone" would also have to be added and documented. The diff is just to illustrate the idea (although I can create a complete diff if you wish). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1707731&group_…

1 0

[ mailman-Feature Requests-782436 ] members per page on admin page
by SourceForge.net April 18, 2007

April 18, 2007

Feature Requests item #782436, was opened at 2003-08-03 19:32 Message generated for change (Comment added) made by umardarmaji You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=782436&group_i… 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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: JC Dill (jcdill) Assigned to: Nobody/Anonymous (nobody) Summary: members per page on admin page Initial Comment: Put a radio button option on the membership page to allow list owners to change the number of members returned on each page. I suggest that the options include: 25 per page 50 per page 100 per page 200 per page 500 per page all subscribers on one page (use with caution if you have a big list!) ---------------------------------------------------------------------- Comment By: oemardarmaji (umardarmaji) Date: 2007-04-18 07:19 Message: Logged In: YES user_id=1772313 Originator: NO Test ---------------------------------------------------------------------- Comment By: John W. Baxter (jwbaxter) Date: 2006-06-11 17:55 Message: Logged In: YES user_id=664644 This seems like a quite reasonable proposal. Is the intent to return to the old method, where the pages (except last) were all full and there was on each page an index of links giving the first (first and last) address on each other page? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=782436&group_i…

1 0

[ mailman-Feature Requests-1387243 ] option to discard messages that lack explicit destination
by SourceForge.net April 17, 2007

April 17, 2007

Feature Requests item #1387243, was opened at 2005-12-22 03:01 Message generated for change (Comment added) made by tpv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1387243&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matt Swift (msswift) Assigned to: Nobody/Anonymous (nobody) Summary: option to discard messages that lack explicit destination Initial Comment: The configurable variable require_explicit_destination is a boolean that selects whether to hold a message for moderation if neither the list address nor any aliases appear in the To: or Cc: headers. On certain lists I manage, a lot of spam is sent to the lists via BCC:. Setting this variable keeps this spam off the list, which is great, but I spend a lot of time discarding the spam. I can't simply discard all messages held for moderation, because there are occasional legitimate messages held for another reason that I want to accept. So I have to trawl through it all. Therefore, please make the require_explicit_destination setting offer the familiar choices of allow, hold, reject, and discard. I'd be happy if you added just "discard" without adding "reject", but the full four choices would be consistent with the rest of Mailman. This will save me a lot of time, and I would think many other users are in the same situation. ---------------------------------------------------------------------- Comment By: Tim Vernum (tpv) Date: 2007-04-18 00:17 Message: Logged In: YES user_id=4727 Originator: NO This RFE is becoming a significant issue for some lists that I run. What can be done to get this fixed? Would a patch help, or is there some specific piece of work that you want to bundle it up with? I'm happy to put together a patch (although my python is a little rusty) but I don't want to waste everyone's time if you want it done a specific way. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-12-22 04:28 Message: Logged In: YES user_id=1123998 While we're at it, we probably should also add hold, reject and discard choices if max_num_recipients is > 0 ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-12-22 03:32 Message: Logged In: YES user_id=1123998 I think this is a good idea. In the mean time, see the post and reply at <http://mail.python.org/pipermail/mailman-users/2005-December/048078.html> and <http://mail.python.org/pipermail/mailman-users/2005-December/048086.html> for some interim patch ideas. Also see the post at <http://mail.python.org/pipermail/mailman-users/2005-February/042954.html> for a way to do this with spam filters that doesn't require patching. ---------------------------------------------------------------------- Comment By: Matt Swift (msswift) Date: 2005-12-22 03:29 Message: Logged In: YES user_id=1409646 P.S. I realize that I can accomplish what I want by an appropriate setting of header_filter_rules, but it's not very convenient, since I can't make use of acceptable_aliases. The introduction of header_filter_rules is great, but it creates confusion by making the existing sender and recipient filters redundant. I suggest renaming the section in which header_filter_rules from "spam filters" to "advanced filter" or something like that. All three sections can be used to filter spam, so it's misleading to distinguish a "spam filter" from sender and recipient filters. The documentation for header_filter_rules / "advanced filter" section should explain that this filter is a general mechanism which exists; the sender/recipient filters are special cases that are common enough to merit a convenient interface just for them. Even with this clarification of the header_filter_rules, I still think require_explicit_destination should be expanded to offer all four actions. If you're going to go to the trouble of setting up the special interface to filter a lack of explicit destination, it really ought to offer complete options. It won't complicate the interface (really, it will simplify it to have the familiar four actions offered), and it seems very awkward to have to recreate this nice interface in header_filter_rules (acceptable_aliases and so on) just because the manager wants an action other than "accept" or "hold". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1387243&group_…

1 0