Membership List letter links could be incorrectly rendered as Unicode.

2 files changed, 30 insertions, 24 deletions

diff --git a/Mailman/Cgi/admin.py b/Mailman/Cgi/admin.py
index 9ae661a8..41dc5cf1 100644
--- a/Mailman/Cgi/admin.py
+++ b/Mailman/Cgi/admin.py
@@ -1010,6 +1010,9 @@ def membership_options(mlist, subcat, cgidata, doc, form):
             if regexp:
                 findfrag = '&findmember=' + urllib.quote(regexp)
             url = adminurl + '/members?letter=' + letter + findfrag
+            if isinstance(url, unicode):
+                url = url.encode(Utils.GetCharSet(mlist.preferred_language),
+                                 errors='ignore')
             if letter == bucket:
                 show = Bold('[%s]' % letter.upper()).Format()
             else:
diff --git a/NEWS b/NEWS
index 2ca87cac..7d8df3ae 100644
--- a/NEWS
+++ b/NEWS
@@ -9,30 +9,30 @@ Here is a history of user visible changes to Mailman.
  
   New Features
 
-    - For header_filter_rules matching, both RFC 2047 encoded headers and
-      header_filter_rules patterns are now decoded to unicode as are.  Both
-      XML character references of the form &#nnnn; and unicode escapes of the
-      form \Uxxxx in patterns are converted to unicodes as well.  Both headers
-      and patterns are normalized to 'NFKC' normal form before matching, but
-      the normalization form can be set via a new NORMALIZE_FORM mm_cfg
-      setting.  Also, the web UI has been updated to encode characters in text
-      fields that are invalid in the character set of the page's language as
-      XML character references instead of '?'.  This should help with entering
-      header_filter_rules patterns to match 'odd' characters.  This feature is
-      experimental and is problematic for some cases where it is desired to
-      have a header_filter_rules pattern with characters not in the character
-      set of the list's preferred language.  For patterns without such
-      characters, the only change in behavior should be because of unicode
-      normalization which should improve matching.  For other situations such
-      as trying to match a Subject: with CJK characters (range U+4E00..U+9FFF)
-      on an English language (ascii) list, one can enter a pattern like
-      '^subject:.*[一-鿿]' or '^subject:.*[\u4e00;-\u9fff;]' to
-      match a Subject with any character in the range, and it will work, but
-      depending on the actual characters and the browser, submitting another,
-      even unrelated change can garble the original entry although this
-      usually occurs only with ascii pages and characters in the range
-      \u0080-\u00ff.  The \Uxxxx unicode escapes must have exactly 4 hex
-      digits, but they are case insensitive.  (LP: #558155)
+    - For header_filter_rules matching, RFC 2047 encoded headers, non-encoded
+      headers and header_filter_rules patterns are now all decoded to unicode.
+      Both XML character references of the form &#nnnn; and unicode escapes
+      of the form \Uxxxx in patterns are converted to unicodes as well.  Both
+      headers and patterns are normalized to 'NFKC' normal form before
+      matching, but the normalization form can be set via a new NORMALIZE_FORM
+      mm_cfg setting.  Also, the web UI has been updated to encode characters
+      in text fields that are invalid in the character set of the page's
+      language as XML character references instead of '?'.  This should help
+      with entering header_filter_rules patterns to match 'odd' characters.
+      This feature is experimental and is problematic for some cases where it
+      is desired to have a header_filter_rules pattern with characters not in
+      the character set of the list's preferred language.  For patterns
+      without such characters, the only change in behavior should be because
+      of unicode normalization which should improve matching.  For other
+      situations such as trying to match a Subject: with CJK characters (range
+      U+4E00..U+9FFF) on an English language (ascii) list, one can enter a
+      pattern like '^subject:.*[一-鿿]' or
+      '^subject:.*[\u4e00;-\u9fff;]' to match a Subject with any character in
+      the range, and it will work, but depending on the actual characters and
+      the browser, submitting another, even unrelated change can garble the
+      original entry although this usually occurs only with ascii pages and
+      characters in the range \u0080-\u00ff.  The \Uxxxx unicode escapes must
+      have exactly 4 hex digits, but they are case insensitive.  (LP: #558155)
 
     - Thanks to Jim Popovitch REMOVE_DKIM_HEADERS can now be set to 3 to
       preserve the original headers as X-Mailman-Original-... before removing
@@ -65,6 +65,9 @@ Here is a history of user visible changes to Mailman.
 
   Bug fixes and other patches
 
+    - The admin Membership List letter links could be incorrectly rendered as
+      Unicode strings following a search.  (LP: #1604544)
+
     - We no longer throw an uncaught TypeError with certain defective crafted
       POST requests to Mailman's CGIs.  (LP: #1602608)