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, [email protected] > because we don't want to fail parsing > bob, "Falcone, Fred" <[email protected]> > 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 <http://search.cpan.org/%7Eruz/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
