<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>