Approvals made, change status of orignal ticket

RT Users
1

Now I have a follow-up issue. Apparently my OpenDendentsOnResolve is
not working like I wanted.

As a recap:
I have two queues “TimeOff” and TimeOff-Approval"
(TimeOff-Approval is “disabled” like the ___Approval queue. Not sure if
that is a real problem or not, does not seem to be). A staff member
opens a ticket in “TimeOff” and that creates the two tickets in
“TimeOff-Approval” that the Supervisor and HR need to sign off on first.

Thanks to Gene, The Ticket created in “TimeOff” gets a status “pending”
(I added a new status to my RT_SiteConfig.pm)

Now once the two “TimeOff-Approval” tickets are resolved, I want the
“TimeOff” ticket’s status to be changed to “open”. As of right now, the “TimeOff” ticket remains “pending” even after approvals are approved.

I copy/pasted the “When a ticket has been approved by all approvers, add
correspondence to the original ticket” from the ___Approval queue.

I image this is where I can add the code needed to change the ticket
from “pending” to “open” but I don’t know how.

FROM THE “When a ticket has been approved by all approvers, add
correspondence to the original ticket”

CONDITION: On Resolve
ACTION: User Defined
TEMPLATE: All Approvals Passed
STAGE: TransactionCreate
CUSTOM CONDTION: blank
CUSTOM ACTION PREPARATION CODE:

-------------------------------------------------------------------

Find all the tickets that depend on this (that this is approving)

my $Ticket = $self->TicketObj;
my @TOP = $Ticket->AllDependedOnBy( Type => ‘ticket’ );
my $links = $Ticket->DependedOnBy;
my $passed = 0;

while (my $link = $links->Next) {
my $obj = $link->BaseObj;
next if ($obj->HasUnresolvedDependencies( Type => ‘approval’ ));

if ($obj->Type eq 'ticket') {
$obj->Comment(
    Content	=> $self->loc("Your request has been approved."),
);
$T::Approval  = $Ticket;    # so we can access it inside templates
$self->{TicketObj} = $obj;  # we want the original id in the token line
$passed = 1;
}
elsif ($obj->Type eq 'approval') {
$obj->SetStatus( Status => 'open', Force => 1 );
}
elsif ($RT::UseCodeTickets and $obj->Type eq 'code') {
my $code = $obj->Transactions->First->Content;
my $rv;

foreach my $TOP (@TOP) {
    local $@;
    $rv++ if eval $code;
    $RT::Logger->error("Cannot eval code: $@") if $@;
}

if ($rv or !@TOP) {
    $obj->SetStatus( Status	=> 'resolved', Force	=> 1,);
}
else {
    $obj->SetStatus( Status	=> 'rejected', Force	=> 1,);
}
}

}

Now magically turn myself into a Requestor Notify object…

require RT::Action::Notify; bless($self, ‘RT::Action::Notify’);
$self->{Argument} = ‘Requestor’; $self->Prepare;

return 0; # ignore $passed;

-------------------------------------------------------------------

CUSTOM ACTION CLEANUP CODE: blank

http://gentgeen.homelinux.org

Associate yourself with men of good quality if you esteem
your own reputation; for 'tis better to be alone then in bad
company. - George Washington, Rules of Civility

2

Kevin,

I have a situation similar to what you have but resolved it

differently. I don’t like the way RT changes the ticket numbers for
their approval queue, so I added two new status values “pending rq” and
"rq approvd" for pending request and request approved respectively. I
then created a new custom field called “Approval-Status” and created a
new group “Approval-Group”. Only members of the “Approval-Group” can
modify the CF “Approval-Status”. When a ticket comes in, it is in “new"
status. When the Approval-group modifies the CF to “Request Pending”, a
couple scrips are triggered; 1 to modify the ticket status to “pending
rq” and the other to send a notification to the requestor. When the
approval group modifies the CF to “Request Approved”, another couple
scrips are triggered the modify the ticket status to “rq approvd” and
send out a notification. I actually have a couple others values/scrips
for QA testing, rejected, etc. This way, the ticket status is
automatically modified by a control group that reviews and approves of
tickets thru the use of a CF. The big benefit is that the ticket history
is all there on one ticket so audit doesn’t have a fit. I’m not sure if
this helps you as you may already be totally committed to the
"Approval-Queue” design, but if not, try my way.

Kenn
LBNL

Kevin Squire wrote: