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.
It reads:
Returns a list of Email::Address objects
Works around the bug that Email::Address 1.889 and earlier
doesn’t handle local-only email addresses (when users pass
in just usernames on the RT system in fields that expect
Email Addresses)
We don’t handle the case of
bob, fred@bestpractical.com
because we don’t want to fail parsing
bob, “Falcone, Fred” fred@bestpractical.com
The next release of Email::Address will have a new method
we can use that removes the bandaid
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.
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.
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.
Would you consider using
http://search.cpan.org/~ruz/Email-Address-List/lib/Email/Address/List.pm
? It appears to be designed to solve just this problem and is based on
Email::Address.
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services