Custom status on reply

RT Users
1

I’m trying to make a new lifecycle. It includes the usual statuses (new, open, etc.) and a few additions called pending-customer, pending-tech, and pending-other. The idea is to make it easier to see when a ticket needs someone to ask the end user a second time, “Can you provide the [computer number, username, room] where the problem is happening?” I thought that a search for pending-customer and lastupdate < -1 week would do the trick.

That seems to be working. What I need next is to make any reply from the end user change the status to pending-tech or even just plain “open”. I think I need to make a scrip for this, but I’m not sure how. Can anyone offer advice?

Or am I missing a much easier way to do this?

2

A scrip is the usual way to do this. You’ll need an “on correspondance” one with a blank template (as you’re not send any email out) and user defined actions. The action would need to check if the ticket is in a status that you want to reopen from and then, if it is, change the status of the ticket object to be “pending-tech” (or “open” or whatever you want). Note that when setting the status on the ticket you would normally generate a chain of other scrips that fire off (such as “on status change” and “on transaction” ones). There are ways round this, but that would depend on whether you needed to avoid the status change being a recorded transaction (as opposed to just quietly setting the field in the ticket’s entry in the database).

So for example we have a script that allows replies to tickets currently in a custom “awaiting_info” or “stalled” status to be moved back to “open”. The scrip has an “on correspondence” condition with a blank template and a custom user defined action which is in two parts:

The custom action preparation code:

my $TicketObj = $self->TicketObj;
my $status = $TicketObj->Status;
if($status eq 'awaiting_info' || $status eq 'stalled') {
  return 1;
} else {
  return 0;
}

and the custom action itself:

my $TicketObj = $self->TicketObj;
$TicketObj->SetStatus(Status => 'open');
return 1;

We actually want the status change transaction side effects here, so I’ve not gone to any trouble to avoid them. We just attach this to the few queues where groups want this status transition to take place (not every team here does).