[rt-users] EmailParser.pm:ParseEmailAddress - mixing usernames and email addresses

[Craig Ringer]

Hi folks

I have a basic module to convert individual users into "customer groups"
(customer entities modeled as RT groups) ready. It's going well with a
few limitations and is doing a good job of converting the requestor of
tickets into a customer group with a scrip. It's here:
https://github.com/2ndQuadrant/rt-extension-customergroups-perl but
hasn't been pushed to CPAN as it's not quite feature complete yet.

I'm hoping to enable users to enter customer group names as requestors
directly. This works when adding watchers after the ticket has been
created, though RT doesn't autocomplete them in the web ui, but it
doesn't seem to be possible for ticket creation via the web ui because
of the process RT goes through to turn the requestor field input into
user IDs which converts all inputs to email addresses and from there
into user IDs:

Create.html: Requestors is string like 'username1, "Freddy Bob
<email at hostname>'
-> calls
Display.html: passed through unchanged
-> to
RT::Interface::Web::CreateTicket: Passed through unchanged
-> to
RT::Ticket->Create, still as string or as arrayref containing a single
string entry, where single digit string is treated as username otherwise:
-> to
RT::EmailParser->ParseEmailAddress matches a single user name where
string has no @ symbols or:
-> to
Email::Address->parse returns array of email addresses parsed out and
discards the rest
-> returns to
RT::EmailParser->ParseEmailAddress which returns email address array
-> returns to
RT::Ticket->Create .. which *converts the email addresses to RT::User
objects and gets their IDs*

This flow means that RT can't handle requestor lists containing a mix of
email addresses and user names. There's no way to pass a list of
RT::User/RT::Group or RT::Principal objects into RT::Ticket->Create, nor
can you pass more than one RT user name. Presumably that's why RT's user
name autocomplete in Requestors converts the user into an email address
when it's autocompleted.

If I was to teach RT::Ticket->Create to accept a RequestorObj array
containing RT::User and RT::Group objects that can be passed to
Ticket::_AddWatcher, is that a chance the RT team would be willing to
accept this change into RT proper? What I want to do is factor out the
Requestors-string-to-list-of-users conversion from RT::Ticket->Create
into its own function that can be wrapped or replaced via the RT
SiteConfig, since right now there's no common point you can hook into
ticket creation from all paths (SelfService and normal web ui create,
email create, import, etc).

I'd also like to introduce callback sites in RT::Ticket->Create, one
before the ticket entity is created that allows transformation of the
%args array and one after that takes the %args array and the new $ticket
var. Unlike RT's existing callbacks these would be simple Perl functions
or modules, more like @MailPlugins than the Mason callbacks. That way
hooks for custom behaviour could be more easily added to things like the
ticket creation path without having to patch the main sources, easing
upgrades and making it easier to package changes as modules.

(I know you can wrap methods but this isn't very useful for things like
RT::Ticket->Create where it's one giant monolithic method).

In the mean time I'm living with a few limitations in the code posted above:

- Users can only be a member of one customer group if they submit
tickets via email; and
- Tickets created via the web ui are created with the requestor as the
individual user then immediately rewritten by a scrip to use the
customer group; this rewrite is visible in the logs.

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20130321/e567eb74/attachment.htm>