Default Ticket Owner?

I would like to have a default owner for tickets created in a specific queue, potentially just for those created via e-mail.

Is there a standard means of doing this?

My mail config is fine, but I’m about to hack it to add an --owner option to the existing --url and --queue.
Something tells me I’ll be doing a Bad Thing.

Thanks in advance

Lee Goddard
Internet Application Analysis/Development
European Aviation Safety Agency
Administrative Directorate

E: Lee.Goddard@EASA.EU.int
T: +49 221 89990 3221
F: +49 221 89990 3721
W: www.easa.eu.int
:: Ottoplat 1, D-50679 Köln, Germany

You could modify a queue-specific scrip to do this. I believe examples
are in the wiki under Contributions.

Goddard Lee wrote:

I would like to have a default owner for tickets created in a specific queue, potentially just for those created via e-mail.

Is there a standard means of doing this?

My mail config is fine, but I’m about to hack it to add an --owner option to the existing --url and --queue.
Something tells me I’ll be doing a Bad Thing.

Thanks in advance

Lee Goddard
Internet Application Analysis/Development
European Aviation Safety Agency
Administrative Directorate

E: Lee.Goddard@EASA.EU.int
T: +49 221 89990 3221
F: +49 221 89990 3721
W: www.easa.eu.int
:: Ottoplat 1, D-50679 K�ln, Germany


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O’Reilly Media at http://rtbook.bestpractical.com

WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at http://bestpractical.com/services/training.html

Drew Barnes
Applications Analyst
Raymond Walters College
University of Cincinnati

You could modify a queue-specific scrip to do this. I
believe examples are in the wiki under Contributions.

Thank you. I’ll have another look - I ended up adding a --queue option
to rt-mailgate, and updaing the ncessary to process it … But it would
be nice to do it in a more maintainable manner.

Cheers
Lee

Be careful about doing this!

We started down that path and quickly discovered that tickets weren’t
getting addressed because the guy we were defaulting to was on vacation
and no one else knew about the tickets. A “on vacation” concept was
considered, but ultimately we did something else.

We ended up writing a scrip that automatically assigns ownership to the
first AdminCC watcher to respond to the ticket. All new tickets generate
a notification to all AdminCC watchers. This has three benefits: it
provides flexibility in terms of who gets ownership, it exposes the
request to multiple people (faster response time), and users get a more
personalized response indicating someone will be working on it.

For example, a ticket is submitted to the FOO queue. All the adminCCs
get notified. One adminCC responds with “I’ll work on this in 15
minutes. But I have a question first…” which a) assigns the ticket to
the responder, b) opens the ticket, and c) provides useful feedback to
the requestor that someone is doing something.

It’s worked out fairly well so far, and it was pretty easy to implement.

-Eric

Drew Barnes wrote:

You could modify a queue-specific scrip to do this. I
believe examples are in the wiki under Contributions.

Thank you. I’ll have another look - I ended up adding a --queue option
to rt-mailgate, and updaing the ncessary to process it … But it
would
be nice to do it in a more maintainable manner.

I think I may have found it on the wiki or mailing list, but since I
have it right here…

Create a new scrip for that queue as follows:

Condition: OnCreate
Action: User Defined
Template: Global template: Blank
Stage: Transaction Create
Custom Condition:
Custom action prep. code: return 1;
Custom action cleanup code:

get actor ID

my $User = new RT::User($RT::SystemUser);

Put the email address of the user who needs to own tickets in this

queue in here!

$User->LoadByEmail(“user@domain.tld”);

my $Actor = $User->id;

if actor is RT_SystemUser then get out of here

return 1 if $Actor == $RT::SystemUser->id;

get out unless ticket owner is nobody

return 1 unless $self->TicketObj->Owner == $RT::Nobody->id;

ok, try to change owner

$RT::Logger->info(“Auto assign ticket #”. $self->TicketObj->id ." to

user #". $Actor );

my ($status, $msg) = $self->TicketObj->SetOwner( $Actor );
unless( $status ) {
$RT::Logger->warning( “Impossible to assign tickt to $Actor: $msg”

);

return undef;
}
return 1;

Be careful about doing this!

We started down that path and quickly discovered that tickets weren’t
getting addressed because the guy we were defaulting to was on
vacation
and no one else knew about the tickets. A “on vacation” concept was
considered, but ultimately we did something else.

We ended up writing a scrip that automatically assigns ownership to
the
first AdminCC watcher to respond to the ticket. All new tickets
generate
a notification to all AdminCC watchers. This has three benefits: it
provides flexibility in terms of who gets ownership, it exposes the
request to multiple people (faster response time), and users get a
more
personalized response indicating someone will be working on it.

For example, a ticket is submitted to the FOO queue. All the adminCCs
get notified. One adminCC responds with “I’ll work on this in 15
minutes. But I have a question first…” which a) assigns the ticket
to
the responder, b) opens the ticket, and c) provides useful feedback to
the requestor that someone is doing something.

I automatically assign after reply as well, but I have never had a
problem with this. When someone is on vacation, their backup takes their
issues, and addresses them.

The same problem would occur when someone assigns a ticket straight to
someone while they are on vacation, it happens. It’s the backups
responsibility to deal with their issues, looking over their queue.

This, combined with an incoming issues queue that doesn’t get
automatically assigned with people routing tickets, I’ve never had the
problem.