Request Tracker Wiki - User contributions [en]

CustomConditionSnippets

2016-08-15T17:50:24Z

Kincl: Fixing greater than and adding pre blocks

= Introduction =

This page introduce you with some code that can be used in [[Condition]]s and is part of [[CodeSnippets]] series of articles.

= Custom conditions specifics =

Read [[WriteCustomCondition]] to understand basics of writing conditions.

= Code Snippets =

Here is list of various custom conditions you can use.

== On Create and variants ==

<pre>
return 0 unless $self->TransactionObj->Type eq "Create";
return 1;
</pre>

=== On Create, but queue is not 'xxx' ===

<pre>
return 0 unless $self->TransactionObj->Type eq "Create";
return 0 if $self->TicketObj->QueueObj->Name eq "xxx";
return 1;
</pre>

=== On Create with status resolved ===

If you create [[Ticket]] with status resolved then standard RT condition OnResolve wouldn't trigger.

<pre>
return 0 unless $self->TransactionObj->Type eq "Create";
return 0 unless $self->TicketObj->Status eq 'resolved';
return 1;
</pre>

== On Correspond/Comment and variants ==

<pre>
return 0 unless $self->TransactionObj->Type eq "Correspond";
return 1;
</pre>

=== On Correspond to Unowned Ticket ===

<pre>
return 0 unless $self->TransactionObj->Type eq "Correspond";
return 0 unless $self->TicketObj->Owner == $RT::Nobody->id;
return 1;
</pre>

Can be used in "On Correspond to Unowned Notify Admin Ccs With Admin Correspondence".

== On Status Change and variants ==

For historical reasons it's more correct to write this condition like this:

<pre>
my $txn = $self->TransactionObj;
my $type = $txn->Type;
return 0 unless $type eq "Status"
|| ( $type eq 'Set' && $txn->Field eq 'Status');
return 1;
</pre>

=== On Status Change to "resolved" ===
<pre>
my $txn = $self->TransactionObj;
my $type = $txn->Type;
return 0 unless $type eq "Status"
|| ( $type eq 'Set' && $txn->Field eq 'Status');

return 0 unless $txn->NewValue eq "resolved";
return 1;
</pre>

=== on Status Change from "new" to "open" ===

<pre>
my $txn = $self->TransactionObj;
my $type = $txn->Type;
return 0 unless $type eq "Status"
|| ( $type eq 'Set' && $txn->Field eq 'Status');

return 0 unless $txn->OldValue eq "new";
return 0 unless $txn->NewValue eq "open";
return 1;
</pre>

== On Queue Change ==
<pre>
return 0 unless $self->TransactionObj->Type eq "Set";
return 0 unless $self->TransactionObj->Field eq "Queue";
return 1;
</pre>
== On Owner Change and variants ==
<pre>
return 0 unless $self->TransactionObj->Type eq "Set";
return 0 unless $self->TransactionObj->Field eq "Owner";
return 1;
</pre>

=== On Owner Change from Nobody to Any ===
<pre>
my $txn = $self->TransactionObj;
return 0 unless $txn->Type eq "Set";
return 0 unless $txn->Field eq "Owner";
return 0 unless $txn->OldValue == $RT::Nobody->id;
return 1;
</pre>

=== On Take ===
<pre>
my $txn = $self->TransactionObj;
return 0 unless $txn->Type eq "Set";
return 0 unless $txn->Field eq "Owner";
return 0 unless $txn->OldValue == $RT::Nobody->id;
return 0 unless $txn->NewValue == $txn->Creator;
return 1;
</pre>

=== On Steal ===

See also [[OnStealEnhanced]]
<pre>
my $txn = $self->TransactionObj;
return 0 unless $txn->Type eq "Set";
return 0 unless $txn->Field eq "Owner";
return 0 if $txn->OldValue == $RT::Nobody->id;
return 0 unless $txn->NewValue == $txn->Creator;
return 1;
</pre>

=== On Give ===
<pre>
my $txn = $self->TransactionObj;
return 0 unless $txn->Type eq "Set";
return 0 unless $txn->Field eq "Owner";
return 0 unless $txn->OldValue == $RT::Nobody->id;
return 0 if $txn->NewValue == $txn->Creator;
return 1;
</pre>

=== On Give Up ===
<pre>
my $txn = $self->TransactionObj;
return 0 unless $txn->Type eq "Set";
return 0 unless $txn->Field eq "Owner";
return 0 unless $txn->OldValue == $txn->Creator;
return 0 unless $txn->NewValue == $RT::Nobody->id;
return 1;
</pre>

=== On Assign ===
<pre>
my $txn = $self->TransactionObj;
return 0 unless $txn->Type eq "Set";
return 0 unless $txn->Field eq "Owner";
return 0 unless $txn->OldValue == $RT::Nobody->id;
return 0 if $txn->NewValue == $txn->Creator;
return 1;
</pre>

=== On Re-Assign ===
<pre>
my $txn = $self->TransactionObj;
return 0 unless $txn->Type eq "Set";
return 0 unless $txn->Field eq "Owner";
return 0 if $txn->OldValue == $txn->Creator;
return 0 if $txn->NewValue == $txn->Creator;
return 1;
</pre>

=== Checks with acting user (actor) ===
<pre>
my $actor = $self->TransactionObj->CreatorObj;
</pre>

=== On action by privileged ===
<pre>
my $actor = $self->TransactionObj->CreatorObj;
return 1 if $actor->Privileged;
return 0;
</pre>

=== On owner's action ===
<pre>
my $actor = $self->TransactionObj->CreatorObj;
my $owner = $self->TicketObj->OwnerObj;
return 1 unless $actor->id == $owner->id;
return 0;
</pre>

== Checks with watchers and groups ==

=== When particular email address is in requestors ===
<pre>
return 1 if $self->TicketObj->IsWatcher(
Type => 'Requestor', Email => 'foo@bar.com'
);
return 0;
</pre>

=== When actor is member of one or more particular groups ===
<pre>
my @enforced_groups = ("Group 1","Group 2","etc");

my $actor = $self->TransactionObj->CreatorObj;

foreach my $gname (@enforced_groups) {
my $group = RT::Group->new( $self->CurrentUser );
$group->LoadUserDefinedGroup( $gname );
next unless $group->id;

return 1 if $group->HasMemberRecursively( $actor->id );
}
return 0;
</pre>

=== Owner is not in the group ===
<pre>
my $in_group = 'SupportManagers';

my $owner = $self->TicketObj->OwnerObj;
my $group = RT::Group->new( $self->CurrentUser );
$group->LoadUserDefinedGroup( $in_group );
return 0 if $group->HasMemberRecursively( $owner->id );

return 1;
</pre>

== Checks with Custom Fields ==

=== When current custom field value is X ===

<pre>
my $Ticket = $self->TicketObj;

return 0 unless $self->TicketObj->FirstCustomFieldValue('CustomFieldName') eq 'X';
return 1;
</pre>

=== On CustomField change ===
<pre>
return 0 unless $self->TransactionObj->Type eq 'CustomField';
return 1;
</pre>

=== On CustomField 'X' change ===
<pre>
return 0 unless $self->TransactionObj->Type eq 'CustomField';

my $cf = RT::CustomField->new( $self->CurrentUser );
$cf->Load( $self->TransactionObj->Field );
return 0 unless $cf->Name eq 'X';

return 1;
</pre>

=== On CustomField 'X' change from 'A' to 'B' ===
<pre>
my $txn = $self->TransactionObj;
return 0 unless $txn->Type eq 'CustomField';

my $cf = RT::CustomField->new( $self->CurrentUser );
$cf->Load( $txn->Field );
return 0 unless $cf->Name eq 'X';

return 0 unless $txn->OldValue eq 'A';
return 0 unless $txn->NewValue eq 'B';

return 1;
</pre>

=== When Custom Field 'X' is set to 'A' ===
<pre>
my $txn = $self->TransactionObj;
my $type = $txn->Type;
if ( $type eq 'Create' ) {
# CF can be set on create
return 0 unless $self->TicketObj->FirstCustomFieldValue('X') eq 'A';
} elsif ( $type eq 'CustomField' ) {
# CF can be changed later
my $cf = RT::CustomField->new( $self->CurrentUser );
$cf->Load( $txn->Field );
return 0 unless $cf->Name eq 'X';

return 0 unless $txn->NewValue eq 'A';
} else {
return 0;
}
return 1;
</pre>

=== On Correspond, set Custom Field "X" to "0" ===
<pre>
return 1;

my $ticket = $self->TicketObj;
my $cf_obj = RT::CustomField->new($RT::SystemUser);
my $cf_name = "X";
my $cf_value = "0";

$cf_obj->LoadByName( Name => $cf_name );
$RT::Logger->debug( "Loaded \$cf_obj->Name = ". $cf_obj->Name() ."\n" );
$ticket->AddCustomFieldValue( Field=>$cf_obj, Value=>$cf_value,
RecordTransaction=>0 );

return 1;
</pre>

== UserDefined2 (use with rt-crontool) ==
create a file UserDefined2.pm in lib/RT/Condition
<pre>
package RT::Condition::UserDefined2;
use base 'RT::Condition';
use strict;
=head2 IsApplicable

=cut

sub IsApplicable {
my $self = shift;
local $@;
my $retval = eval { $self->Argument; }; warn $@ if $@;
return ($retval);
}

RT::Base->_ImportOverlays();
1;
</pre>

With this you have a powerful way to check a customized condition. You can use it like that:
<pre>
bin/rt-crontool --verbose --log debug --search RT::Search::ActiveTicketsInQueue --search-arg Support --condition RT::Condition::UserDefined2 --condition-arg "if($self->TicketObj->Priority == 4){return(1);}else {return(undef);}" --action RT::Action::SetPriority --action-arg 7
</pre>

This example searches all tickets in queue Support, checks if the priority is 4 and sets the priority to 7. You may use arbitrary perl-code for the condition.
== add your own conditions ==

...

WriteCustomAction

2016-08-15T17:38:42Z

Kincl: Fixing greater than symbols post import from old wiki and adding pre wrappers

This text in Portuguese in [[WriteCustomActionBR]]

How to write custom action code

== Introduction ==

Included in RT3 is the ability to create your own custom ticket actions via the Web UI. The RT3 Custom Scrip capability lets you access the RT API and is a very powerful tool for customising RT.

== Basics ==

[[File:Example1ScripUI.png|thumb|left|325px|Modify a scrip UI]]Let's start with Web UI. Goto Configuration -> Globals -> Scrips -> New Scrip.

The Scrip UI will display the following selectors: Description, Condition, Action, Template and Stage. In the action selector you can pick actions based on files (modules). An outstanding action from this list is "User Defined". The rest of this document describes this action. So in the Action field, select "User Defined" from the menu.

Once you have selected "User Defined" from the Action Field, the following two Action code areas are enabled and used by RT:
* Custom action preparation code
* Custom action cleanup code

When a [[Transaction]] is created, RT does the following steps to enable all this magic and give you a chance to be a small God:

* Select [[Scrip|Scrips]]
* Check applicability of scrips by executing [[Condition]]s
* Execute preparation code scrip by scrip
* Scrips that fail will be thrown away
* Execute commit code of survived scrips proceeding scrip by scrip

When RT executes your perl Action code within this scrip, your code can become an actor upon the ticket. RT has already defined the variable $self. This variable represents an instance of class [=RT::Action::[[UserDefined]]], a subclass of <code>RT::Action::Generic</code>. You can get more info from perldoc and from the source code.

Instance <code>$self</code> provides your Action code with very useful methods:

<pre>
$self->TransactionObj
</pre>

Returns <code>RT::Transaction</code> instance, the transaction that has been created and caused all this.

<pre>
$self->TicketObj
</pre>

Returns <code>RT::Ticket</code> instance which represents the ticket. Our transaction was applied to it.

<pre>
$self->TemplateObj
</pre>

Returns the template (<code>RT::Template</code>) which was selected for this scrip.

=== Getting more info about these objects ===

You can get complete information about these objects from their POD (embedded documentation).

perldoc /opt/rt3/lib/RT/Ticket.pm
perldoc /opt/rt3/lib/RT/Ticket_Overlay.pm
perldoc /opt/rt3/lib/RT/Tickets.pm
perldoc /opt/rt3/lib/RT/Tickets_Overlay.pm
perldoc /opt/rt3/lib/RT/Transaction.pm
perldoc /opt/rt3/lib/RT/Transaction_Overlay.pm
perldoc /opt/rt3/lib/RT/Transactions.pm
perldoc /opt/rt3/lib/RT/Transactions_Overlay.pm
...

== Simple example ==

Ok, let's try to change something.

Requirement: There is a support queue for special customers where each request must have high priority on ticket creation.

[[File:Example1ScripBehavior.png|thumb|275px]]Preparation code:

<pre>
# we don't need any preparation yet.
return 1;
</pre>

Commit code:
<pre>
$self->TicketObj->SetPriority( 100 );
return 1;
</pre>

I hope that this example is understandable enough, but it has at least one weakness. I've hardcoded the priority value. Since RT lets the administrator define default final priority per queue, our code should reflect that.

<pre>
my $qfp = $self->TicketObj->QueueObj->FinalPriority || 100;
$self->TicketObj->SetPriority( int( $qfp * 0.9 ) );
return 1;
</pre>

This change to the logic first retrieves the [[FinalPriority]] of the current Queue or 100 if no [[FinalPriority]] is set for the Queue. Then it sets the Priority of this ticket to 90% of the retrieved Priority. The final 10% of the priority is reserved for very exclusive, super high priority requests.

== Errors handling ==

It's important to check errors to protect you from headache. Most methods in RT that change something return a tuple ($status, $msg). If $status is not true value then something failed and $msg is error text describing the reason. Let's extend our code:

<pre>
my $qfp = $self->TicketObj->QueueObj->FinalPriority || 100;
my ($status, $msg) = $self->TicketObj->SetPriority( int( $qfp * 0.9 ) );
unless ( $status ) {
$RT::Logger->error("Couldn't change priority: $msg");
return 0;
}
return 1;
</pre>

== What you can (not) do with scrips ==

You can manipulate almost any object in RT within a scrip.

* update properties of tickets, for example set properties of tickets with commands in email
* change linked tickets, for example [[OpenTicketOnAllMemberResolve]] and [[OpenDependantsOnResolve]]
* extract info from messages, implement own workflow, create approvals and many-many more actions

Let's talk about impossible things you don't even want to try to do with a scrip:

* you couldn't deny action scrip's triggered, for example you don't want to allow users to open ticket unless it has owner, you may think that you can create scrip "on ticket open block action if ticket has no owner", but it's impossible. I said impossible? no... sure you can create such scrip, but instead of preventing action you can revert it by setting status back to old value. yeah, this works but don't forget that it would be two transactions 'set open status' and 'set previouse status'. Each action could be applied to other scrips, so really it's not preventing action.
* you couldn't run scrip at some time, remember RT runs scrips after creating transactions, but of course we have solution for this situation - rt-crontool.

== How to be silent ==

Now you put SetXxxx calls all over the places in RT and suddenly note that strange transactions appear in tickets. They have creator [[RT System|RT_System]] and describe what you've done with your scrips. Sometimes it's better to be silent and not mislead users. These transactions also go through the steps described earlier and could trigger some conditions too. Just use the long form of SetXxx functions:

<pre>
$TicketObj->_Set(Field => 'Priority', Value => 90, RecordTransaction => 0);
</pre>

The zero in the [[RecordTransaction]] argument informs RT not to record the change as a new transaction.

== How to change ticket custom field values ==

Step 1, get the custom field (CF) object or ID. Don't use the hardcoded CF ID from the database. [why?] Step 2, get the CF object by ticket object by ticket object (I hope you remember how to get a ticket object) and CF name.

<pre>
...
my $CFName = 'MyCustomField';
my $CF = RT::CustomField->new( $RT::SystemUser );
$CF->LoadByNameAndQueue( Name => $CFName, Queue => $Ticket->Queue );
# RT has bug/feature until 3.0.10, you should load global CF yourself
unless( $CF->id ) {
# queue 0 is special case and is a synonym for global queue
$CF->LoadByNameAndQueue( Name => $CFName, Queue => '0' );
}

unless( $CF->id ) {
$RT::Logger->error( "No field $CFName in queue ". $Ticket->QueueObj->Name );
return undef;
}
...
</pre>

Now we could add value to ticket:
<pre>
my $Value = 'MyValue';
$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value );
</pre>
or
<pre>
$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value, RecordTransaction => 0 );
</pre>
you also could use custom field id instead of object.
<pre>
$Ticket->AddCustomFieldValue( Field => NN , Value => $Value );
</pre>

== Step by step or "Tickets, transactions and attachments" ==

Lets look what happens with RT from the beginning when a user clicks on create button in their browser. Web server gets request with queue id, ticket subject and body, owner and etc. RT fetches info from the request that is needed for Ticket record: its Queue id, Status, Subject, [[CurrentUser]](Creator), and then runs the next code:

<pre>
# init empty instance of RT::Ticket class
my $TicketObj = RT::Ticket->new( $session{'CurrentUser'} );

# create new record
# if you more familiar with SQL then it's INSERT
# this call is inherited from SearchBuilder API
my $id = $TicketObj->Create( %ARGS );
</pre>

Ticket is created and it's time to record transaction into table. RT has all info for this: ticket's id that was recently created and transaction type - 'Create'.

<pre>
# this call creates new transaction record
# this is very similar to situation with new ticket record
my $TransactionObj = $Ticket->_RecordTransaction( %ARGS );
</pre>

Transactions in RT has an many-to-one mapping with ticket. One ticket => one or more transactions. You can get collection of transactions by calling Transactions method on a ticket object:
<pre>
my $transactions = $TicketObj->Transactions;
</pre>
Each transaction belongs to only one ticket and you get ticket object with the following code:
<pre>
my $ticket = $TransactionObj->TicketObj;
</pre>
As you can see RT still didn't use content that you wrote in the body. Content is an RT::Attachment object. You know how RT creates new record and know about Ticket-Transaction relation, the same relationship applies to Attachments and Transactions.

== From "User Defined" to a module ==

User defined actions you write in the web UI are handy and quick way to write an action. However, at some point you want to re-use your action, make it configurable, edit it in more suitable editor rather than text area, make it more complex and consist of additional methods. So it's time to move from "User Defined" action to your first module file.

<pre>
use strict;
use warnings;

package RT::Action::MyAction;
use base qw(RT::Action::Generic);

sub Prepare {
my $self = shift;

... here goes preparation code ...

return 1;
}

sub Commit {
my $self = shift;

... here goes commit code ...

return 1;
}

1;
</pre>

''Note'': for RT4, replace '''RT::Action::Generic''' by '''RT::Action'''

That's it. Save it as '''lib/RT/Action/MyAction.pm''' (it is important that the file have the same name as the package ("MyAction" in the example)), fill in preparation and commit code then you can register your action in the DB. Use the following data file and [[AddDatabaseRecords]] instructions.

<pre>
@ScripActions = (
{
Name => 'My super duper action',
Description => 'Super-puper action that does hell of a job' ,
ExecModule => 'MyAction',
Argument => 'some argument if needed'
},
);
</pre>

Now your action in the DB and you can pick it for a scrip through the Web UI instead of picking "User Defined".

== See also ==

Other documentation on this wiki that may help

[[GlobalObjects]], [[ObjectModel]]

== Special thanks ==

* [[TimWilson]], who was the main editor and reviewer

WorkFlow

2016-08-15T17:32:40Z

Kincl: Fixing subtask documentation, added single quotes because wiki formatting was getting messed up

= Modeling Workflow in RT =

We had the requirement to make sure that when equipment was ordered for installation all necessary tasks were completed by the involved parties. Creating a single ticket and assigning it to each responsible party in turn had the problem of serializing the tasks, not giving advance warning, and not having a predetermined checklist of things to do. This is a fairly simple attempt to model a planned workflow in RT, using a master ticket for the installation, and child tickets for the subtask.

== Queue Setup ==

First, set up a new queue, which we'll call Installation. Nothing special here. Make sure that the correct people have permission to update the queue including the permission to set custom fields.

== Custom Field Setup ==

Next, create a custom field for each subtask. The name of the field should suggest the subtask to the reader, because the field description doesn't show up anyplace useful. We created custom fields 'Order Status', 'Power', 'DNS', 'Rack', 'Array', and '[[OSInstall]]'. Make each of type 'Select one value', which will make them into drop-down lists. For 'Order Status', we're using values such as 'Requirements', 'In Purchasing', 'Vendor', and 'Delivered' to indicate the status of the order. For the other fields we use the simple values 'Required' and 'Completed'. (We are still exploring whether the complexity of additional status values for these are useful.) The 'Required' status will become magic in the next steps. Go back to the Installation queue and enable these custom fields.

== Template Setup ==

Now we need some templates for the child tickets. These determine what will be in the child tickets when they are first created. Create them in the Installation queue; they don't need to be global. Name them something related to the subtask name for your sanity, but the name itself doesn't link them. Here is the [[PowerTicket]] template:

<pre>
===Create-Ticket: power
Subject: Power::{$Tickets{'TOP'}->Subject}
Parents: TOP
Queue: Installation
Owner: smith
AdminCc: jones
Content: Power requirements are needed for this equipment.
Please see the parent ticket for details.
ENDOFCONTENT
</pre>

The Owner of the ticket should be someone already defined in your RT database who will be responsible for the subtask, in this example smith. The [[AdminCc]] can be used for that person's backup or other interested parties. As of RT 3.4.2, both of these have to be users, not groups. It would be very nice if groups worked, to allow more dynamic updating of responsibilities if someone is away. Notification of the new owners is taken care of by the normal Create Ticket actions in the queue.

The Queue is the queue in which the new ticket is created. At the moment, we've elected to create them in the same queue as the parent ticket, but it may make more sense to create them in other queues. The Parent link will keep everything tied together if you do.

== Action Setup ==

Now we can glue the templates to the custom fields. To make this clean, I created a custom Condition, installed in $RTHOME/local/lib/RT/Condition/[[FieldRequired]].pm:

<pre>
# Local condition to check that a custom field
# has been set to "Required".
# -Chuck Boeheim 3/13/06

package RT::Condition::FieldRequired;
require RT::Condition::Generic;

use strict;
use vars qw/@ISA/;
@ISA = qw(RT::Condition::Generic);

=head2 IsApplicable

If the field named as an argument becomes 'Required'.
Only triggers on transitions, not if it already had
that value.

=cut

sub IsApplicable {
my $self = shift;
my $field = $self->Argument;
my $trans = $self->TransactionObj;
if ($trans->Type eq 'Create') {
return 1 if $trans->TicketObj->FirstCustomFieldValue($field) =~ /^Required/;
}
if ($trans->Type eq 'CustomField') {
my $cf = RT::CustomField->new($self->CurrentUser);
$cf->Load($field);
return 1 if $trans->Field == $cf->Id && $trans->NewValue =~ /^Required/;
}
return undef;
}

1;
</pre>

The new action can be installed with the following script, which needs to have your custom field names put in the appropriate place:

<pre>
# To install, install FieldRequired.pm in local/lib/RT/Conditions, and
# this script in local/etc/FieldRequired.install
# /path/to/rt3/sbin/rt-setup-database --action insert \
# --datafile /path/to/rt3/local/etc/FieldRequired.install
#
@ScripConditions = (
{ Name => 'On Power Required',
Description => 'Trigger when custom field Power becomes Required',
ExecModule => 'FieldRequired',
Argument => 'Power', # Your custom field name
ApplicableTransTypes => 'Any' },
{ Name => 'On DNS Required',
Description => 'Trigger when custom field DNS becomes Required',
ExecModule => 'FieldRequired',
Argument => 'DNS', # Next custom field name
ApplicableTransTypes => 'Any' },
# Repeat for additional fields
);
</pre>

Then add scrips to the Installation queue for each subtask that use your new conditions:

<pre>
Description: Create Power Ticket
Condition: On Power Required <== The ScripCondition Name in the previous step
Action: Create Tickets
Template: PowerTicket <== The template name in the template step above
Stage: TransactionCreate
</pre>

At this point, if you create a ticket in the Installation queue and set a custom field to 'Required' it will create the child ticket. It will also do this if you update an existing ticket to set a 'Required' status. This allows you to create a ticket for planning, and only initiate the subtasks at the time they are necessary.

== Completing Subtasks ==

Now one final piece of glue to update the parent status when the child completes. Create another scrip in the queue(s) that have the child tickets. (This is one reason to keep the child tickets in the installation queue.)

<pre>
Description: On Resolve, Update Parent
Condition: On Resolve
Action: User Defined
Template: Global Template Blank
Stage: TransactionCreate
</pre>

CustomCondition:
None

CustomActionPreparationCode:
<pre>
return 1;
</pre>

CustomActionCleanupCode:
<pre>
return 1 if ($self->TransactionObj->NewValue !~ /^(?:resolved|deleted|rejected)$/);
# Figure out which kind of child this is
my $cf_value = 'Completed';
my $cf_name;

my $subject = $self->TicketObj->Subject;
$cf_name = 'Power' if $subject =~ /^Power::/;
$cf_name = 'Network' if $subject =~ /^Network::/;
# Repeat for your custom field names.
# There may be a better way to do this.

# Alternative:
# Setup the templates to use the same name as the custom fields, then you can
# extract the name of each field from the subject, using Perl regex grouping.
# my $subject = $self->TicketObj->Subject;
# if($subject =~ /^(.*)::/)
# {$cf_name = $1;}

return undef unless $cf_name;

my $actor = $self->TransactionObj->CreatorObj;
my $actorname = $actor->RealName . ' (' . $actor->EmailAddress . ')';
my $CF_Obj = RT::CustomField->new($self->CurrentUser);
# current ticket is member of(child of some parents)
my $MemberOf = $self->TicketObj->MemberOf;
while (my $l = $MemberOf->Next ) {
# we can't check non local objects
next unless( $l->TargetURI->IsLocal );

# Update the custom field in the parent ticket to show completed.
$CF_Obj->LoadByName( Name => $cf_name,
Queue => $l->TargetObj->QueueObj->Id);
$CF_Obj->AddValueForObject( Object => $l->TargetObj,
Content => $cf_value );
my $id = $self->TicketObj->id;
my $status = $self->TicketObj->Status;
$l->TargetObj->Correspond(Content => <<'END');
Child ticket completed:
Ticket: $id
Status: $status
Subject: $subject
By: $actorname
END
}

return 1;
</pre>

WorkFlow

2016-08-15T17:23:31Z

Kincl:

= Modeling Workflow in RT =

We had the requirement to make sure that when equipment was ordered for installation all necessary tasks were completed by the involved parties. Creating a single ticket and assigning it to each responsible party in turn had the problem of serializing the tasks, not giving advance warning, and not having a predetermined checklist of things to do. This is a fairly simple attempt to model a planned workflow in RT, using a master ticket for the installation, and child tickets for the subtask.

== Queue Setup ==

First, set up a new queue, which we'll call Installation. Nothing special here. Make sure that the correct people have permission to update the queue including the permission to set custom fields.

== Custom Field Setup ==

Next, create a custom field for each subtask. The name of the field should suggest the subtask to the reader, because the field description doesn't show up anyplace useful. We created custom fields 'Order Status', 'Power', 'DNS', 'Rack', 'Array', and '[[OSInstall]]'. Make each of type 'Select one value', which will make them into drop-down lists. For 'Order Status', we're using values such as 'Requirements', 'In Purchasing', 'Vendor', and 'Delivered' to indicate the status of the order. For the other fields we use the simple values 'Required' and 'Completed'. (We are still exploring whether the complexity of additional status values for these are useful.) The 'Required' status will become magic in the next steps. Go back to the Installation queue and enable these custom fields.

== Template Setup ==

Now we need some templates for the child tickets. These determine what will be in the child tickets when they are first created. Create them in the Installation queue; they don't need to be global. Name them something related to the subtask name for your sanity, but the name itself doesn't link them. Here is the [[PowerTicket]] template:

<pre>
===Create-Ticket: power
Subject: Power::{$Tickets{'TOP'}->Subject}
Parents: TOP
Queue: Installation
Owner: smith
AdminCc: jones
Content: Power requirements are needed for this equipment.
Please see the parent ticket for details.
ENDOFCONTENT
</pre>

The Owner of the ticket should be someone already defined in your RT database who will be responsible for the subtask, in this example smith. The [[AdminCc]] can be used for that person's backup or other interested parties. As of RT 3.4.2, both of these have to be users, not groups. It would be very nice if groups worked, to allow more dynamic updating of responsibilities if someone is away. Notification of the new owners is taken care of by the normal Create Ticket actions in the queue.

The Queue is the queue in which the new ticket is created. At the moment, we've elected to create them in the same queue as the parent ticket, but it may make more sense to create them in other queues. The Parent link will keep everything tied together if you do.

== Action Setup ==

Now we can glue the templates to the custom fields. To make this clean, I created a custom Condition, installed in $RTHOME/local/lib/RT/Condition/[[FieldRequired]].pm:

<pre>
# Local condition to check that a custom field
# has been set to "Required".
# -Chuck Boeheim 3/13/06

package RT::Condition::FieldRequired;
require RT::Condition::Generic;

use strict;
use vars qw/@ISA/;
@ISA = qw(RT::Condition::Generic);

=head2 IsApplicable

If the field named as an argument becomes 'Required'.
Only triggers on transitions, not if it already had
that value.

=cut

sub IsApplicable {
my $self = shift;
my $field = $self->Argument;
my $trans = $self->TransactionObj;
if ($trans->Type eq 'Create') {
return 1 if $trans->TicketObj->FirstCustomFieldValue($field) =~ /^Required/;
}
if ($trans->Type eq 'CustomField') {
my $cf = RT::CustomField->new($self->CurrentUser);
$cf->Load($field);
return 1 if $trans->Field == $cf->Id && $trans->NewValue =~ /^Required/;
}
return undef;
}

1;
</pre>

The new action can be installed with the following script, which needs to have your custom field names put in the appropriate place:

<pre>
# To install, install FieldRequired.pm in local/lib/RT/Conditions, and
# this script in local/etc/FieldRequired.install
# /path/to/rt3/sbin/rt-setup-database --action insert \
# --datafile /path/to/rt3/local/etc/FieldRequired.install
#
@ScripConditions = (
{ Name => 'On Power Required',
Description => 'Trigger when custom field Power becomes Required',
ExecModule => 'FieldRequired',
Argument => 'Power', # Your custom field name
ApplicableTransTypes => 'Any' },
{ Name => 'On DNS Required',
Description => 'Trigger when custom field DNS becomes Required',
ExecModule => 'FieldRequired',
Argument => 'DNS', # Next custom field name
ApplicableTransTypes => 'Any' },
# Repeat for additional fields
);
</pre>

Then add scrips to the Installation queue for each subtask that use your new conditions:

<pre>
Description: Create Power Ticket
Condition: On Power Required <== The ScripCondition Name in the previous step
Action: Create Tickets
Template: PowerTicket <== The template name in the template step above
Stage: TransactionCreate
</pre>

At this point, if you create a ticket in the Installation queue and set a custom field to 'Required' it will create the child ticket. It will also do this if you update an existing ticket to set a 'Required' status. This allows you to create a ticket for planning, and only initiate the subtasks at the time they are necessary.

== Completing Subtasks ==

Now one final piece of glue to update the parent status when the child completes. Create another scrip in the queue(s) that have the child tickets. (This is one reason to keep the child tickets in the installation queue.)

<pre>
Description: On Resolve, Update Parent
Condition: On Resolve
Action: User Defined
Template: Global Template Blank
Stage: TransactionCreate
</pre>

CustomCondition:
None

CustomActionPreparationCode:
<pre>
return 1;
</pre>

CustomActionCleanupCode:
<pre>
return 1 if ($self->TransactionObj->NewValue !~ /^(?:resolved|deleted|rejected)$/);
# Figure out which kind of child this is
my $cf_value = 'Completed';
my $cf_name;

my $subject = $self->TicketObj->Subject;
$cf_name = 'Power' if $subject =~ /^Power::/;
$cf_name = 'Network' if $subject =~ /^Network::/;
# Repeat for your custom field names.
# There may be a better way to do this.

# Alternative:
# Setup the templates to use the same name as the custom fields, then you can
# extract the name of each field from the subject, using Perl regex grouping.
# my $subject = $self->TicketObj->Subject;
# if($subject =~ /^(.*)::/)
# {$cf_name = $1;}

return undef unless $cf_name;

my $actor = $self->TransactionObj->CreatorObj;
my $actorname = $actor->RealName . ' (' . $actor->EmailAddress . ')';
my $CF_Obj = RT::CustomField->new($self->CurrentUser);
# current ticket is member of(child of some parents)
my $MemberOf = $self->TicketObj->MemberOf;
while (my $l = $MemberOf->Next ) {
# we can't check non local objects
next unless( $l->TargetURI->IsLocal );

# Update the custom field in the parent ticket to show completed.
$CF_Obj->LoadByName( Name => $cf_name,
Queue => $l->TargetObj->QueueObj->Id);
$CF_Obj->AddValueForObject( Object => $l->TargetObj,
Content => $cf_value );
my $id = $self->TicketObj->id;
my $status = $self->TicketObj->Status;
$l->TargetObj->Correspond(Content => <<END);
Child ticket completed:
Ticket: $id
Status: $status
Subject: $subject
By: $actorname
END
}

return 1;
</pre>