From noreply at sourceforge.net Wed May 2 21:54:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 May 2007 12:54:23 -0700 Subject: [ mailman-Bugs-1711470 ] Problem with accept_these_nonmembers Message-ID: Bugs item #1711470, was opened at 2007-05-02 14:54 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=1711470&group_id=103 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: Barry S. Finkel (barry_s_finkel) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with accept_these_nonmembers Initial Comment: I posted this to mailman-users May 01, 2007, and Mark Sapiro replied with a detailed diagnosis. I create new Mailman (2.1.9) lists via copying template files. One of my template files has: accept_these_nonmembers = ['user1 at example.com', 'user2 at example.com', 'user3 at example.com (Joe Bleaux)', 'user4 at example.com'] (I have split the line for easier readibility.) When I create a new list via /usr/sbin/newlist $listname config_list -i $1.config $listname I get no complaints, and the administrator web interface shows the four addresses with the parenthesized name after the third address. I have not tested whether any of these addresses can post to the new list. But when I want to add another address to the list (or remove an address) via the admin web interface, I get an error messsage about an incorrect address. When I remove the parenthesized name, the error message is not produced. If the parenthesized name is not valid, I would expect an error message during the config_list command execution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1711470&group_id=103 From noreply at sourceforge.net Thu May 3 16:39:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 May 2007 07:39:45 -0700 Subject: [ mailman-Bugs-1712034 ] Pipermail uses MIME CTEs in HTTP Message-ID: Bugs item #1712034, was opened at 2007-05-03 23:39 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=1712034&group_id=103 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: Pipermail Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen J. Turnbull (yaseppochi) Assigned to: Nobody/Anonymous (nobody) Summary: Pipermail uses MIME CTEs in HTTP Initial Comment: CTE = Content-Transfer-Encoding = BASE64 or QP John Papapanos writes: > Here is a URL where I created a list for testing > mailman. > > https://mail.bioacademy.gr/pipermail/testlist2/2007-May/thread.html Wow! That's amazingly broken. What's I'm pretty sure is happening is that the archive contains raw message content in a MIME QP or transfer-encoding, which cannot be decoded because the Content-Transfer-Encoding header has been stripped (AFAIK it's actually prohibited in HTTP, cf RFC 2616 section 19.5). (I'm not 100% sure because I don't have access to the physical archive, only via https.) The reason that the Greek text-only comes out OK is that your browser (John and I are both using Firefox) interprets the { notation in the message body as SGML entities, which are Unicode. Presumably the reason that such content is in there in the first place is that either pipermail doesn't parse the mail (unlikely) or it reencodes use flatten or something like that. I'll look more carefully at the code later, maybe provide a patch, but don't bet on it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1712034&group_id=103 From noreply at sourceforge.net Fri May 4 02:44:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 May 2007 17:44:32 -0700 Subject: [ mailman-Patches-1688957 ] fix concurrency problem in 2.2 Message-ID: Patches item #1688957, was opened at 2007-03-27 08:15 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1688957&group_id=103 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.2 / 3.0 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: fix concurrency problem in 2.2 Initial Comment: The problem is described in a mailman-dev post. http://www.mail-archive.com/mailman-developers at python.org/msg10203.html Fix this by introducing reload mechanism in the interface to SQLAlchemy. I use session.refresh() to do this but because this function looks like to break locks, attempt is made to save the lock status and lock again after refresh. I'm not sure this is the right way to fix the problem but it is working (for now). ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2007-05-04 00:44 Message: Logged In: YES user_id=67709 Originator: YES Fix in a different way by Barry, thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1688957&group_id=103 From noreply at sourceforge.net Fri May 4 02:52:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 May 2007 17:52:18 -0700 Subject: [ mailman-Patches-1415956 ] Sitewide headers/footers & XHTML Compliant Web UI Message-ID: Patches item #1415956, was opened at 2006-01-26 22:23 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1415956&group_id=103 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 Private: No 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: A.M. Kuchling (akuchling) Date: 2007-05-03 20:52 Message: Logged In: YES user_id=11375 Originator: NO The patch looks pretty good, though I'll suggest some refinements and some decisions need to be made. Net effects of the patch: Adds XHTML compliance. Adds site-header.html/site-footer.html to the templates/en directory and usage of CSS instead of tags. Still uses tables for page layout. Adds CSS_FILE to mm_cfg.py. Requires addition of a /css/ directory to the web tree. Possible issues: Many I18N strings change, but only by folding HTML markup to lowercase. A bunch of search-and-replacing should be able to update all the language-specific templates. Need to decide upon class naming scheme; the scheme used isn't consistent (mm_web_adminitem_color in one case, mmErrorBackground in another). Could retarget it to use the
suggestion and '#mailman error' selectors. Possible bug: AddSpanStyle, AddDivStyle: won't generate
, if no 'css_class' is provided. Presumably all current callers get this right; should the class work properly if there's an error, though? Compatibility issues: The patch removes the colour settings (WEB_HEADER_COLOR, WEB_ERROR_COLOR, WEB_ADMINITEM_COLOR, etc.) -- how to handle backward compatibility? That would require substituting into the .css file, or adding a 'style' attribute. WEB_HEADER_COLOR -- mmHeader WEB_ERROR_COLOR -- replaced by mmErrorBackground CSS class WEB_ADMINITEM_COLOR -- replaced by mmRight/mmLeft/mm_web_adminitem_color/ mmAdminItem Features not present that I thought of: * allow adding an embedded stylesheet * allow adding JavaScript links or text to the * adding an onLoad to the body (perhaps not necessary -- can it be done in a