<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi folks<br>
    <br>
    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:
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a
      href="https://github.com/2ndQuadrant/rt-extension-customergroups-perl">https://github.com/2ndQuadrant/rt-extension-customergroups-perl</a>
    but hasn't been pushed to CPAN as it's not quite feature complete
    yet.<br>
    <br>
    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:<br>
    <br>
    Create.html: Requestors is string like 'username1, "Freddy Bob
    <email@hostname>'<br>
    -> calls<br>
    Display.html: passed through unchanged<br>
    -> to<br>
    RT::Interface::Web::CreateTicket: Passed through unchanged<br>
    -> to<br>
    RT::Ticket->Create, still as string or as arrayref containing a
    single string entry, where single digit string is treated as
    username otherwise:<br>
    -> to<br>
    RT::EmailParser->ParseEmailAddress matches a single user name
    where string has no @ symbols or:<br>
    -> to <br>
    Email::Address->parse returns array of email addresses parsed out
    and discards the rest<br>
    -> returns to<br>
    RT::EmailParser->ParseEmailAddress which returns email address
    array<br>
    -> returns to<br>
    RT::Ticket->Create .. which *converts the email addresses to
    RT::User objects and gets their IDs*<br>
    <br>
    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.<br>
    <br>
    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).<br>
    <br>
    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. <br>
    <br>
    (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).<br>
    <br>
    In the mean time I'm living with a few limitations in the code
    posted above:<br>
    <br>
    - Users can only be a member of one customer group if they submit
    tickets via email; and<br>
    - 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.<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>