<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Following on from my prior post, I've noticed a comment in RT's
    RT::EmailParse::ParseEmailAddress that I'm struggling to find more
    information about.<br>
    <br>
    It reads:<br>
    <br>
    <blockquote type="cite">Returns a list of Email::Address objects<br>
      Works around the bug that Email::Address 1.889 and earlier<br>
      doesn't handle local-only email addresses (when users pass<br>
      in just usernames on the RT system in fields that expect<br>
      Email Addresses)<br>
    </blockquote>
    <blockquote type="cite">We don't handle the case of <br>
      bob, <a class="moz-txt-link-abbreviated" href="mailto:fred@bestpractical.com">fred@bestpractical.com</a> <br>
      because we don't want to fail parsing<br>
      bob, "Falcone, Fred" <a class="moz-txt-link-rfc2396E" href="mailto:fred@bestpractical.com"><fred@bestpractical.com></a><br>
      The next release of Email::Address will have a new method<br>
      we can use that removes the bandaid<br>
    </blockquote>
    <br>
    This matches the behaviour observed in
    RT::EmailParse::ParseEmailAddress where only a single standalone
    username is successfully parsed; mixes of email addresses and
    usernames or lists of more than one user name are not successfully
    parsed, with the user names just ignored.<br>
    <br>
    This comment implies that a revision to Email::Address would fix the
    limitation causing this. Presumably the idea was to return text
    segments that weren't matched as email addresses, so you'd get a
    list of Email::Address objects and plain strings back from the parse
    method? If so, it doesn't seem to have made it into Email::Address,
    since the current release is 1.898 and it doesn't appear to contain
    a method matching that description or any optional params to parse
    that might let you retain unmatched strings.<br>
    <br>
    I'd really like to enable RT to accept lists of *usernames* (or
    group names) in requestor fields not just email addresses,
    particularly when accepting new tickets via the web UI. This is the
    main barrier to doing so.<br>
    <br>
    Would you consider using
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a
href="http://search.cpan.org/%7Eruz/Email-Address-List/lib/Email/Address/List.pm">http://search.cpan.org/~ruz/Email-Address-List/lib/Email/Address/List.pm</a>
    ? It appears to be designed to solve just this problem and is based
    on Email::Address.<br>
    <br>
    <pre class="moz-signature" cols="72">-- 
 Craig Ringer                   <a class="moz-txt-link-freetext" href="http://www.2ndQuadrant.com/">http://www.2ndQuadrant.com/</a>
 PostgreSQL Development, 24x7 Support, Training & Services</pre>
  </body>
</html>