CustomStatusesInRt4 - Revision history

Admin: 9 revisions imported

2016-04-06T20:03:37Z

9 revisions imported

New page

''To see how custom statuses are handled in prior versions refer to this article: [[CustomStatuses]] ''

Statuses are based on Lifecycles in RT 4. Lifecycles define how your tickets can move into and out of statuses.

For more about Lifecycles, please read the following official documentation:

* [http://bestpractical.com/rt/docs/latest/customizing/lifecycles.html Tutorial]
* [http://bestpractical.com/rt/docs/latest/RT_Config.html#Lifecycles Reference documentation]

== Community contributed hints ==
''(here you can add your hints, tips or anything you thing helpfull)''

* At lifecycle from->to you may notice the <code>'</code> (single quotes) around ABC-E at the from part as <code>'ABC-E'</code>. Unless you do this the <code> - </code> breaks the code

* If you don't define the transitions part, you won't be able to chose your new statuses in the ticket's basic field: status.

93.94.119.243: /* Community contributed hints */

2014-04-02T10:19:31Z

Community contributed hints

New page

'' To see how custom statuses are handled in prior versions refer to this article: [[CustomStatuses]] ''

Statuses are based on Lifecycles in RT 4. Lifecycles define how your tickets can move into and out of statuses.

For more about Lifecycles, please read the following official documentation:

* [http://bestpractical.com/rt/docs/latest/customizing/lifecycles.html Tutorial]
* [http://bestpractical.com/rt/docs/latest/RT_Config.html#Lifecycles Reference documentation]

== Community contributed hints ==
''(here you can add your hints, tips or anything you thing helpfull)''

* At lifecycle from->to you may notice the <code>'</code> (single quotes) around ABC-E at the from part as <code>'ABC-E'</code>. Unless you do this the <code> - </code> breaks the code

* If you don't define the transitions part, you won't be able to chose your new statuses in the ticket's basic field: status.
* Do not use '-' in any transition names, e.g. pending-update. Use '_' (underscore) instead. '-' (minus) causes silent failure where you can get into a transition but not back out.

62.77.228.242: /* Hints */

2012-08-02T14:06:42Z

Hints

New page

==Custom Status in RT 4==
''to see how it is handled in prior versions refer to this article: [[CustomStatuses]] ''

in RT4 a new lifecycle managebility is introduced, of which the statuses are a part of.

WARNING. '''DO NOT DELETE ANY OF THE DEFAULT STATUSES'''.

If you do, RT will break horribly.
<p style="border-style: initial; border-color: initial;">''From RTConfig.pm in RT 4.0.1:''</p>
==Lifecycles==
===Lifecycle definitions===
<p style="border-style: initial; border-color: initial;">Each lifecycle is a list of possible statuses split into three logic sets: '''initial''', '''active''' and '''inactive'''. Each status in a lifecycle must be unique. (Statuses may not be repeated across sets.)</p>

<p style="border-style: initial; border-color: initial;">Each set may have any number of statuses.</p>

<p style="border-style: initial; border-color: initial;">For example:</p>
default => {

initial => ['new'],

active => ['open', 'stalled'],

inactive => ['resolved', 'rejected', 'deleted'],

...

},
<p style="border-style: initial; border-color: initial;">Status names can be from 1 to 64 ASCII characters. Statuses are localized using RT's standard internationalization and localization system.</p>
====<u>initial</u>====
<p style="border-style: initial; border-color: initial;">You can define multiple '''initial''' statuses for tickets in a given lifecycle.</p>

<p style="border-style: initial; border-color: initial;">RT will automatically set its '''Started''' date when you change a ticket's status from an '''initial''' state to an '''active''' or '''inactive''' status.</p>

<h4 style="border-style: initial; border-color: initial; "><u>active</u></h4>

<p style="border-style: initial; border-color: initial;">'''active''' tickets are "currently in play" - they're things that are being worked on and not yet complete.</p>

<h4 style="border-style: initial; border-color: initial; "><u>inactive</u></h4>

<p style="border-style: initial; border-color: initial;">'''inactive''' tickets are typically in their "final resting state".</p>

<p style="border-style: initial; border-color: initial;">While you're free to implement a workflow that ignores that description, typically once a ticket enters an inactive state, it will never again enter an active state.</p>

<p style="border-style: initial; border-color: initial;">RT will automatically set the '''Resolved''' date when a ticket's status is changed from an '''initial''' or '''active''' status to an '''inactive''' status.</p>

<p style="border-style: initial; border-color: initial;">'''deleted''' is still a special status and protected by the '''DeleteTicket''' right, unless you re-defined rights (read below). If you don't want to allow ticket deletion at any time simply don't include it in your lifecycle.</p>

<p style="border-style: initial; border-color: initial;">Statuses in each set are ordered and listed in the UI in the defined order.</p>

<p style="border-style: initial; border-color: initial;">Changes between statuses are constrained by transition rules, as described below.</p>

<h3 style="border-style: initial; border-color: initial; ">Default values</h3>

<p style="border-style: initial; border-color: initial;">In some cases a default value is used to display in UI or in API when value is not provided. You can configure defaults using the following syntax:</p>
default => {

...

defaults => {

on_create => 'new',

on_resolve => 'resolved',

...

},

},
<p style="border-style: initial; border-color: initial;">The following defaults are used.</p>

<h4 style="border-style: initial; border-color: initial; ">on_create</h4>

<p style="border-style: initial; border-color: initial;">If you (or your code) doesn't specify a status when creating a ticket, RT will use the this status. See also Statuses available during ticket creation topic in this article.</p>

<h4 style="border-style: initial; border-color: initial; ">on_merge</h4>

<p style="border-style: initial; border-color: initial;">When tickets are merged, the status of the ticket that was merged away is forced to this value. It should be one of inactive statuses; 'resolved' or its equivalent is most probably the best candidate.</p>

<h4 style="border-style: initial; border-color: initial; ">approved</h4>

<p style="border-style: initial; border-color: initial;">When an approval is accepted, the status of depending tickets will be changed to this value.</p>

<h4 style="border-style: initial; border-color: initial; ">denied</h4>

<p style="border-style: initial; border-color: initial;">When an approval is denied, the status of depending tickets will be changed to this value.</p>

<h3 style="border-style: initial; border-color: initial; ">Transitions between statuses and UI actions</h3>

<p style="border-style: initial; border-color: initial;">A '''Transition''' is a change of status from A to B. You should define all possible transitions in each lifecycle using the following format:</p>
default => {

...

transitions => {

"" => [qw(new open resolved)],

new => [qw(open resolved rejected deleted)],

open => [qw(stalled resolved rejected deleted)],

stalled => [qw(open)],

resolved => [qw(open)],

rejected => [qw(open)],

deleted => [qw(open)],

},

...

},

<h4 style="border-style: initial; border-color: initial; ">Statuses available during ticket creation</h4>

<p style="border-style: initial; border-color: initial;">By default users can create tickets with any status, except deleted. If you want to restrict statuses available during creation then describe transition from '' (empty string), like in the example above.''</p>

<h4 style="border-style: initial; border-color: initial; ">Protecting status changes with rights</h4>

<p style="border-style: initial; border-color: initial;">A transition or group of transitions can be protected by a specific right. Additionally, you can name new right names, which will be added to the system to control that transition. For example, if you wished to create a lesser right than ModifyTicket for rejecting tickets, you could write:</p>
default => {

...

rights => {

'* -> deleted' => 'DeleteTicket',

'* -> rejected' => 'RejectTicket',

'* -> *' => 'ModifyTicket',

},

...

},
This would create a new C<RejectTicket> right in the system which you could assign to whatever groups you choose. On the left hand side you can have the following variants:
'<from> -> <to>'

'* -> <to>'

'<from> -> *'

'* -> *'
<p style="border-style: initial; border-color: initial;">Valid transitions are listed in order of priority. If a user attempts to change a ticket's status from '''new''' to '''open''' then the lifecycle is checked for presence of an exact match, then for 'any to '''open''' ', '''new''' to any' and finally 'any to any'. </p>

<p style="border-style: initial; border-color: initial;">If you don't define any rights, or there is no match for a transition, RT will use the '''DeleteTicket''' or '''ModifyTicket''' as appropriate.</p>

<h4 style="border-style: initial; border-color: initial; ">Labeling and defining actions</h4>

<p style="border-style: initial; border-color: initial;">For each transition you can define an action that will be shown in the UI; each action annotated with a label and an update type.</p>

<p style="border-style: initial; border-color: initial;">Each action may provide a default update type, which can be '''Comment''', '''Respond''', or absent. For example, you may want your staff to write a reply to the end user when they change status from '''new''' to '''open''', and thus set the update to '''Respond'''. Neither '''Comment''' nor '''Respond''' are mandatory, and user may leave the message empty, regardless of the update type.</p>

<p style="border-style: initial; border-color: initial;">This configuration can be used to accomplish what ''$ResolveDefaultUpdateType'' was used for in RT 3.8.</p>

<p style="border-style: initial; border-color: initial;">Use the following format to define labels and actions of transitions:</p>
default => {

...

actions => [

'new -> open' => { label => 'Open it', update => 'Respond' },

'new -> resolved' => { label => 'Resolve', update => 'Comment' },

'new -> rejected' => { label => 'Reject', update => 'Respond' },

'new -> deleted' => { label => 'Delete' },

'open -> stalled' => { label => 'Stall', update => 'Comment' },

'open -> resolved' => { label => 'Resolve', update => 'Comment' },

'open -> rejected' => { label => 'Reject', update => 'Respond' },

'stalled -> open' => { label => 'Open it' },

'resolved -> open' => { label => 'Re-open', update => 'Comment' },

'rejected -> open' => { label => 'Re-open', update => 'Comment' },

'deleted -> open' => { label => 'Undelete' },

],

...

},
<p style="border-style: initial; border-color: initial;">In addition, you may define multiple actions for the same transition.</p>

<p style="border-style: initial; border-color: initial;">Alternately, you may use '* -> x' to match more than one transition.</p>

<p style="border-style: initial; border-color: initial;">For example:</p>
default => {

...

actions => [

...

'new -> rejected' => { label => 'Reject', update => 'Respond' },

'new -> rejected' => { label => 'Quick Reject' },

...

'* -> deleted' => { label => 'Delete' },

...

],

...

},
====Moving tickets between queues with different lifecycles ====
<p style="border-style: initial; border-color: initial;">Unless there is an explicit mapping between statuses in two different lifecycles, you can not move tickets between queues with these lifecycles. Such a mapping is defined as follows:</p>
__maps__ => {

'from lifecycle -> to lifecycle' => {

'status in left lifecycle' => 'status in right lifecycle',

...

},

...

},

===Sample 1 - from RT_Config.pm===
Set(%Lifecycles,

default => {

initial => [ 'new' ],

active => [ 'open', 'stalled' ],

inactive => [ 'resolved', 'rejected', 'deleted' ],

defaults => {

on_create => 'new',

on_merge => 'resolved',

approved => 'open',

denied => 'rejected',

},

transitions => {

'''' => [qw(new open resolved)],''

# from => [ to list ],

new => [qw(open stalled resolved rejected deleted)],

open => [qw(new stalled resolved rejected deleted)],

stalled => [qw(new open rejected resolved deleted)],

resolved => [qw(new open stalled rejected deleted)],

rejected => [qw(new open stalled resolved deleted)],

deleted => [qw(new open stalled rejected resolved)],

},

rights => {

'* -> deleted' => 'DeleteTicket',

'* -> *' => 'ModifyTicket',

},

actions => [

'new -> open' => { label => 'Open It', update => 'Respond' },

'new -> resolved' => { label => 'Resolve', update => 'Comment' },

'new -> rejected' => { label => 'Reject', update => 'Respond' },

'new -> deleted' => { label => 'Delete' },

'open -> stalled' => { label => 'Stall', update => 'Comment' },

'open -> resolved' => { label => 'Resolve', update => 'Comment' },

'open -> rejected' => { label => 'Reject', update => 'Respond' },

'stalled -> open' => { label => 'Open It' },

'resolved -> open' => { label => 'Re-open', update => 'Comment' },

'rejected -> open' => { label => 'Re-open', update => 'Comment' },

'deleted -> open' => { label => 'Undelete' },

],

},

#''' don't change lifecyle of the approvals, they are not capable to deal with'''

# custom statuses

approvals => {

initial => [ 'new' ],

active => [ 'open', 'stalled' ],

inactive => [ 'resolved', 'rejected', 'deleted' ],

defaults => {

on_create => 'new',

on_merge => 'resolved',

},

transitions => {

'''' => [qw(new open resolved)],''

# from => [ to list ],

new => [qw(open stalled resolved rejected deleted)],

open => [qw(new stalled resolved rejected deleted)],

stalled => [qw(new open rejected resolved deleted)],

resolved => [qw(new open stalled rejected deleted)],

rejected => [qw(new open stalled resolved deleted)],

deleted => [qw(new open stalled rejected resolved)],

},

rights => {

'* -> deleted' => 'DeleteTicket',

'* -> rejected' => 'ModifyTicket',

'* -> *' => 'ModifyTicket',

},

actions => [

'new -> open' => { label => 'Open It', update => 'Respond' },

'new -> resolved' => { label => 'Resolve', update => 'Comment' },

'new -> rejected' => { label => 'Reject', update => 'Respond' },

'new -> deleted' => { label => 'Delete' },

'open -> stalled' => { label => 'Stall', update => 'Comment' },

'open -> resolved' => { label => 'Resolve', update => 'Comment' },

'open -> rejected' => { label => 'Reject', update => 'Respond' },

'stalled -> open' => { label => 'Open It' },

'resolved -> open' => { label => 'Re-open', update => 'Comment' },

'rejected -> open' => { label => 'Re-open', update => 'Comment' },

'deleted -> open' => { label => 'Undelete' },

],

},

);

===Sample 2 - adding custom statuses===
''(this is our own prod RTSiteConfig, its not much, but added ABC, ABC-E,Developing and At_client statuses)''
Set(%Lifecycles,

default => {

initial => [ 'new' ],

active => [ 'open', 'ABC', 'At_Client', 'ABC-E', 'Developing', 'stalled' ],

inactive => [ 'resolved', 'rejected', 'deleted' ],

defaults => {

on_create => 'new',

on_merge => 'resolved',

approved => 'open',

denied => 'rejected',

},

transitions => {

'''' => [qw(new open resolved)],''

# from => [ to list ],

new => [qw(open stalled ABC At_Client ABC-E Developing resolved rejected deleted)],

open => [qw(stalled ABC At_Client ABC-E Developing resolved rejected deleted)],

ABC => [qw(open stalled At_Client ABC-E Developing resolved rejected deleted)],

At_Client => [qw(open stalled ABC ABC-E Developing resolved rejected deleted)],

'ABC-E' => [qw(open stalled ABC At_Client Developing resolved rejected deleted)],

Developing => [qw(open stalled ABC At_Client ABC-E resolved rejected deleted)],

stalled => [qw(open ABC At_Client ABC-E Developing rejected resolved deleted)],

resolved => [qw(open ABC At_Client ABC-E Developing stalled rejected deleted)],

rejected => [qw(open ABC At_Client ABC-E Developing stalled resolved deleted)],

deleted => [qw(open ABC At_Client ABC-E Developing stalled rejected resolved)],

},

rights => {

'* -> deleted' => 'DeleteTicket',

'* -> *' => 'ModifyTicket',

},

actions => [

'new -> open' => { label => 'Open It', update => 'Respond' },

'new -> resolved' => { label => 'Resolve', update => 'Comment' },

'new -> rejected' => { label => 'Reject', update => 'Respond' },

'new -> deleted' => { label => 'Delete' },

'open -> stalled' => { label => 'Stall', update => 'Comment' },

'open -> resolved' => { label => 'Resolve', update => 'Comment' },

'open -> rejected' => { label => 'Reject', update => 'Respond' },

'stalled -> open' => { label => 'Open It' },

'resolved -> open' => { label => 'Re-open', update => 'Comment' },

'rejected -> open' => { label => 'Re-open', update => 'Comment' },

'deleted -> open' => { label => 'Undelete' },

],

},

);

===Hints===
''(here you can add your hints, tips or anything you thing helpfull)''
*At lifecycle from->to you may notice the " ' " around ABC-E at the from part as 'ABC-E' . This is due unless you do this the " - " breaks the code
*If you don't define the transitions part, you won't be able to chose your new statuses in the ticket's basic field: status.

[[Special:Contributions/80.95.70.19|80.95.70.19]] 12:15, July 26, 2011 (UTC)

Most of it: BestPractical: RT_Config.pm

Little bits: Daniel O.T

64.126.29.106: /* Sample 2 - adding custom statuses */ Added Quotes so examples won't error out

2012-01-14T00:31:10Z

Sample 2 - adding custom statuses: Added Quotes so examples won't error out

← Older revision		Revision as of 20:31, 13 January 2012
Line 435:		Line 435:
	transitions => {		transitions => {

	'' => [qw(new open resolved)],		'''' => [qw(new open resolved)],''


Line 499:		Line 499:

	);		);

	===Hints===		===Hints===
	''(here you can add your hints, tips or anything you thing helpfull)''		''(here you can add your hints, tips or anything you thing helpfull)''

64.126.29.106: /* Sample 1 - from RT_Config.pm */

2012-01-14T00:30:22Z

Sample 1 - from RT_Config.pm

← Older revision		Revision as of 20:30, 13 January 2012
Line 265:		Line 265:
	transitions => {		transitions => {

	'' => [qw(new open resolved)],''		'''' => [qw(new open resolved)],''


Line 346:		Line 346:
	transitions => {		transitions => {

	'' => [qw(new open resolved)],''		'''' => [qw(new open resolved)],''

80.95.70.19: Sample 1 - from RT_Config.pm

2011-07-26T12:16:05Z

Sample 1 - from RT_Config.pm

← Older revision		Revision as of 08:16, 26 July 2011
Line 238:		Line 238:

	},		},
	===Sample 1:===		===Sample 1 - from RT_Config.pm===
	Set(%Lifecycles,		Set(%Lifecycles,

Line 322:		Line 322:
	},		},

	#''' don't change lifecyle of the approvals, they are not capable to deal with		#''' don't change lifecyle of the approvals, they are not capable to deal with'''

	# custom statuses~~'''~~		# custom statuses

	approvals => {		approvals => {
Line 406:		Line 406:

	);		);

	===Sample 2 - adding custom statuses===		===Sample 2 - adding custom statuses===
	''(this is our own prod RTSiteConfig, its not much, but added ABC, ABC-E,Developing and At_client statuses)''		''(this is our own prod RTSiteConfig, its not much, but added ABC, ABC-E,Developing and At_client statuses)''

80.95.70.19: Created page with "==Custom Status in RT 4== ''to see how it is handled in prior versions refer to this article: CustomStatuses '' in RT4 a new lifecycle managebility is introduced, of which t..."

2011-07-26T12:15:00Z

Created page with "==Custom Status in RT 4== ''to see how it is handled in prior versions refer to this article: CustomStatuses '' in RT4 a new lifecycle managebility is introduced, of which t..."

New page

==Custom Status in RT 4==
''to see how it is handled in prior versions refer to this article: [[CustomStatuses]] ''

in RT4 a new lifecycle managebility is introduced, of which the statuses are a part of.

WARNING. '''DO NOT DELETE ANY OF THE DEFAULT STATUSES'''.

If you do, RT will break horribly.
<p style="border-style: initial; border-color: initial;">''From RTConfig.pm in RT 4.0.1:''</p>
==Lifecycles==
===Lifecycle definitions===
<p style="border-style: initial; border-color: initial;">Each lifecycle is a list of possible statuses split into three logic sets: '''initial''', '''active''' and '''inactive'''. Each status in a lifecycle must be unique. (Statuses may not be repeated across sets.)</p>

<p style="border-style: initial; border-color: initial;">Each set may have any number of statuses.</p>

<p style="border-style: initial; border-color: initial;">For example:</p>
default => {

initial => ['new'],

active => ['open', 'stalled'],

inactive => ['resolved', 'rejected', 'deleted'],

...

},
<p style="border-style: initial; border-color: initial;">Status names can be from 1 to 64 ASCII characters. Statuses are localized using RT's standard internationalization and localization system.</p>
====<u>initial</u>====
<p style="border-style: initial; border-color: initial;">You can define multiple '''initial''' statuses for tickets in a given lifecycle.</p>

<p style="border-style: initial; border-color: initial;">RT will automatically set its '''Started''' date when you change a ticket's status from an '''initial''' state to an '''active''' or '''inactive''' status.</p>

<h4 style="border-style: initial; border-color: initial; "><u>active</u></h4>

<p style="border-style: initial; border-color: initial;">'''active''' tickets are "currently in play" - they're things that are being worked on and not yet complete.</p>

<h4 style="border-style: initial; border-color: initial; "><u>inactive</u></h4>

<p style="border-style: initial; border-color: initial;">'''inactive''' tickets are typically in their "final resting state".</p>

<p style="border-style: initial; border-color: initial;">While you're free to implement a workflow that ignores that description, typically once a ticket enters an inactive state, it will never again enter an active state.</p>

<p style="border-style: initial; border-color: initial;">RT will automatically set the '''Resolved''' date when a ticket's status is changed from an '''initial''' or '''active''' status to an '''inactive''' status.</p>

<p style="border-style: initial; border-color: initial;">'''deleted''' is still a special status and protected by the '''DeleteTicket''' right, unless you re-defined rights (read below). If you don't want to allow ticket deletion at any time simply don't include it in your lifecycle.</p>

<p style="border-style: initial; border-color: initial;">Statuses in each set are ordered and listed in the UI in the defined order.</p>

<p style="border-style: initial; border-color: initial;">Changes between statuses are constrained by transition rules, as described below.</p>

<h3 style="border-style: initial; border-color: initial; ">Default values</h3>

<p style="border-style: initial; border-color: initial;">In some cases a default value is used to display in UI or in API when value is not provided. You can configure defaults using the following syntax:</p>
default => {

...

defaults => {

on_create => 'new',

on_resolve => 'resolved',

...

},

},
<p style="border-style: initial; border-color: initial;">The following defaults are used.</p>

<h4 style="border-style: initial; border-color: initial; ">on_create</h4>

<p style="border-style: initial; border-color: initial;">If you (or your code) doesn't specify a status when creating a ticket, RT will use the this status. See also Statuses available during ticket creation topic in this article.</p>

<h4 style="border-style: initial; border-color: initial; ">on_merge</h4>

<p style="border-style: initial; border-color: initial;">When tickets are merged, the status of the ticket that was merged away is forced to this value. It should be one of inactive statuses; 'resolved' or its equivalent is most probably the best candidate.</p>

<h4 style="border-style: initial; border-color: initial; ">approved</h4>

<p style="border-style: initial; border-color: initial;">When an approval is accepted, the status of depending tickets will be changed to this value.</p>

<h4 style="border-style: initial; border-color: initial; ">denied</h4>

<p style="border-style: initial; border-color: initial;">When an approval is denied, the status of depending tickets will be changed to this value.</p>

<h3 style="border-style: initial; border-color: initial; ">Transitions between statuses and UI actions</h3>

<p style="border-style: initial; border-color: initial;">A '''Transition''' is a change of status from A to B. You should define all possible transitions in each lifecycle using the following format:</p>
default => {

...

transitions => {

'' => [qw(new open resolved)],''

new => [qw(open resolved rejected deleted)],

open => [qw(stalled resolved rejected deleted)],

stalled => [qw(open)],

resolved => [qw(open)],

rejected => [qw(open)],

deleted => [qw(open)],

},

...

},

<h4 style="border-style: initial; border-color: initial; ">Statuses available during ticket creation</h4>

<p style="border-style: initial; border-color: initial;">By default users can create tickets with any status, except deleted. If you want to restrict statuses available during creation then describe transition from '' (empty string), like in the example above.''</p>

<h4 style="border-style: initial; border-color: initial; ">Protecting status changes with rights</h4>

<p style="border-style: initial; border-color: initial;">A transition or group of transitions can be protected by a specific right. Additionally, you can name new right names, which will be added to the system to control that transition. For example, if you wished to create a lesser right than ModifyTicket for rejecting tickets, you could write:</p>
default => {

...

rights => {

'* -> deleted' => 'DeleteTicket',

'* -> rejected' => 'RejectTicket',

'* -> *' => 'ModifyTicket',

},

...

},
This would create a new C<RejectTicket> right in the system which you could assign to whatever groups you choose. On the left hand side you can have the following variants:
'<from> -> <to>'

'* -> <to>'

'<from> -> *'

'* -> *'
<p style="border-style: initial; border-color: initial;">Valid transitions are listed in order of priority. If a user attempts to change a ticket's status from '''new''' to '''open''' then the lifecycle is checked for presence of an exact match, then for 'any to '''open''' ', '''new''' to any' and finally 'any to any'. </p>

<p style="border-style: initial; border-color: initial;">If you don't define any rights, or there is no match for a transition, RT will use the '''DeleteTicket''' or '''ModifyTicket''' as appropriate.</p>

<h4 style="border-style: initial; border-color: initial; ">Labeling and defining actions</h4>

<p style="border-style: initial; border-color: initial;">For each transition you can define an action that will be shown in the UI; each action annotated with a label and an update type.</p>

<p style="border-style: initial; border-color: initial;">Each action may provide a default update type, which can be '''Comment''', '''Respond''', or absent. For example, you may want your staff to write a reply to the end user when they change status from '''new''' to '''open''', and thus set the update to '''Respond'''. Neither '''Comment''' nor '''Respond''' are mandatory, and user may leave the message empty, regardless of the update type.</p>

<p style="border-style: initial; border-color: initial;">This configuration can be used to accomplish what ''$ResolveDefaultUpdateType'' was used for in RT 3.8.</p>

<p style="border-style: initial; border-color: initial;">Use the following format to define labels and actions of transitions:</p>
default => {

...

actions => [

'new -> open' => { label => 'Open it', update => 'Respond' },

'new -> resolved' => { label => 'Resolve', update => 'Comment' },

'new -> rejected' => { label => 'Reject', update => 'Respond' },

'new -> deleted' => { label => 'Delete' },

'open -> stalled' => { label => 'Stall', update => 'Comment' },

'open -> resolved' => { label => 'Resolve', update => 'Comment' },

'open -> rejected' => { label => 'Reject', update => 'Respond' },

'stalled -> open' => { label => 'Open it' },

'resolved -> open' => { label => 'Re-open', update => 'Comment' },

'rejected -> open' => { label => 'Re-open', update => 'Comment' },

'deleted -> open' => { label => 'Undelete' },

],

...

},
<p style="border-style: initial; border-color: initial;">In addition, you may define multiple actions for the same transition.</p>

<p style="border-style: initial; border-color: initial;">Alternately, you may use '* -> x' to match more than one transition.</p>

<p style="border-style: initial; border-color: initial;">For example:</p>
default => {

...

actions => [

...

'new -> rejected' => { label => 'Reject', update => 'Respond' },

'new -> rejected' => { label => 'Quick Reject' },

...

'* -> deleted' => { label => 'Delete' },

...

],

...

},
====Moving tickets between queues with different lifecycles ====
<p style="border-style: initial; border-color: initial;">Unless there is an explicit mapping between statuses in two different lifecycles, you can not move tickets between queues with these lifecycles. Such a mapping is defined as follows:</p>
__maps__ => {

'from lifecycle -> to lifecycle' => {

'status in left lifecycle' => 'status in right lifecycle',

...

},

...

},
===Sample 1:===
Set(%Lifecycles,

default => {

initial => [ 'new' ],

active => [ 'open', 'stalled' ],

inactive => [ 'resolved', 'rejected', 'deleted' ],

defaults => {

on_create => 'new',

on_merge => 'resolved',

approved => 'open',

denied => 'rejected',

},

transitions => {

'' => [qw(new open resolved)],''

# from => [ to list ],

new => [qw(open stalled resolved rejected deleted)],

open => [qw(new stalled resolved rejected deleted)],

stalled => [qw(new open rejected resolved deleted)],

resolved => [qw(new open stalled rejected deleted)],

rejected => [qw(new open stalled resolved deleted)],

deleted => [qw(new open stalled rejected resolved)],

},

rights => {

'* -> deleted' => 'DeleteTicket',

'* -> *' => 'ModifyTicket',

},

actions => [

'new -> open' => { label => 'Open It', update => 'Respond' },

'new -> resolved' => { label => 'Resolve', update => 'Comment' },

'new -> rejected' => { label => 'Reject', update => 'Respond' },

'new -> deleted' => { label => 'Delete' },

'open -> stalled' => { label => 'Stall', update => 'Comment' },

'open -> resolved' => { label => 'Resolve', update => 'Comment' },

'open -> rejected' => { label => 'Reject', update => 'Respond' },

'stalled -> open' => { label => 'Open It' },

'resolved -> open' => { label => 'Re-open', update => 'Comment' },

'rejected -> open' => { label => 'Re-open', update => 'Comment' },

'deleted -> open' => { label => 'Undelete' },

],

},

#''' don't change lifecyle of the approvals, they are not capable to deal with

# custom statuses'''

approvals => {

initial => [ 'new' ],

active => [ 'open', 'stalled' ],

inactive => [ 'resolved', 'rejected', 'deleted' ],

defaults => {

on_create => 'new',

on_merge => 'resolved',

},

transitions => {

'' => [qw(new open resolved)],''

# from => [ to list ],

new => [qw(open stalled resolved rejected deleted)],

open => [qw(new stalled resolved rejected deleted)],

stalled => [qw(new open rejected resolved deleted)],

resolved => [qw(new open stalled rejected deleted)],

rejected => [qw(new open stalled resolved deleted)],

deleted => [qw(new open stalled rejected resolved)],

},

rights => {

'* -> deleted' => 'DeleteTicket',

'* -> rejected' => 'ModifyTicket',

'* -> *' => 'ModifyTicket',

},

actions => [

'new -> open' => { label => 'Open It', update => 'Respond' },

'new -> resolved' => { label => 'Resolve', update => 'Comment' },

'new -> rejected' => { label => 'Reject', update => 'Respond' },

'new -> deleted' => { label => 'Delete' },

'open -> stalled' => { label => 'Stall', update => 'Comment' },

'open -> resolved' => { label => 'Resolve', update => 'Comment' },

'open -> rejected' => { label => 'Reject', update => 'Respond' },

'stalled -> open' => { label => 'Open It' },

'resolved -> open' => { label => 'Re-open', update => 'Comment' },

'rejected -> open' => { label => 'Re-open', update => 'Comment' },

'deleted -> open' => { label => 'Undelete' },

],

},

);
===Sample 2 - adding custom statuses===
''(this is our own prod RTSiteConfig, its not much, but added ABC, ABC-E,Developing and At_client statuses)''
Set(%Lifecycles,

default => {

initial => [ 'new' ],

active => [ 'open', 'ABC', 'At_Client', 'ABC-E', 'Developing', 'stalled' ],

inactive => [ 'resolved', 'rejected', 'deleted' ],

defaults => {

on_create => 'new',

on_merge => 'resolved',

approved => 'open',

denied => 'rejected',

},

transitions => {

'' => [qw(new open resolved)],

# from => [ to list ],

new => [qw(open stalled ABC At_Client ABC-E Developing resolved rejected deleted)],

open => [qw(stalled ABC At_Client ABC-E Developing resolved rejected deleted)],

ABC => [qw(open stalled At_Client ABC-E Developing resolved rejected deleted)],

At_Client => [qw(open stalled ABC ABC-E Developing resolved rejected deleted)],

'ABC-E' => [qw(open stalled ABC At_Client Developing resolved rejected deleted)],

Developing => [qw(open stalled ABC At_Client ABC-E resolved rejected deleted)],

stalled => [qw(open ABC At_Client ABC-E Developing rejected resolved deleted)],

resolved => [qw(open ABC At_Client ABC-E Developing stalled rejected deleted)],

rejected => [qw(open ABC At_Client ABC-E Developing stalled resolved deleted)],

deleted => [qw(open ABC At_Client ABC-E Developing stalled rejected resolved)],

},

rights => {

'* -> deleted' => 'DeleteTicket',

'* -> *' => 'ModifyTicket',

},

actions => [

'new -> open' => { label => 'Open It', update => 'Respond' },

'new -> resolved' => { label => 'Resolve', update => 'Comment' },

'new -> rejected' => { label => 'Reject', update => 'Respond' },

'new -> deleted' => { label => 'Delete' },

'open -> stalled' => { label => 'Stall', update => 'Comment' },

'open -> resolved' => { label => 'Resolve', update => 'Comment' },

'open -> rejected' => { label => 'Reject', update => 'Respond' },

'stalled -> open' => { label => 'Open It' },

'resolved -> open' => { label => 'Re-open', update => 'Comment' },

'rejected -> open' => { label => 'Re-open', update => 'Comment' },

'deleted -> open' => { label => 'Undelete' },

],

},

);
===Hints===
''(here you can add your hints, tips or anything you thing helpfull)''
*At lifecycle from->to you may notice the " ' " around ABC-E at the from part as 'ABC-E' . This is due unless you do this the " - " breaks the code
*If you don't define the transactions part, you won't be able to chose your new statuses in the ticket's basic field: status.

[[Special:Contributions/80.95.70.19|80.95.70.19]] 12:15, July 26, 2011 (UTC)

Most of it: BestPractical: RT_Config.pm

Little bits: Daniel O.T