+=item reminder_on_open
+
+When a reminder is opened, the status will be changed to this value.
+
+=item reminder_on_resolve
+
+When a reminder is resolved, the status will be changed to this value.
+
+=back
+
+=head2 Transitions between statuses and UI actions
+
+A B<Transition> is a change of status from A to B. You should define
+all possible transitions in each lifecycle using the following format:
+
+ 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)],
+ },
+ ...
+ },
+
+=head3 Statuses available during ticket creation
+
+By default users can create tickets with a status of new,
+open, or resolved, but cannot create tickets with a status of
+rejected, stalled, or deleted. If you want to change the statuses
+available during creation, update the transition from '' (empty
+string), like in the example above.
+
+=head3 Protecting status changes with rights
+
+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:
+
+ 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> -> *'
+ '* -> *'
+
+Valid transitions are listed in order of priority. If a user attempts
+to change a ticket's status from B<new> to B<open> then the lifecycle
+is checked for presence of an exact match, then for 'any to B<open>',
+'B<new> to any' and finally 'any to any'.
+
+If you don't define any rights, or there is no match for a transition,
+RT will use the B<DeleteTicket> or B<ModifyTicket> as appropriate.
+
+=head3 Labeling and defining actions
+
+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.
+
+Each action may provide a default update type, which can be
+B<Comment>, B<Respond>, or absent. For example, you may want your
+staff to write a reply to the end user when they change status from
+B<new> to B<open>, and thus set the update to B<Respond>. Neither
+B<Comment> nor B<Respond> are mandatory, and user may leave the
+message empty, regardless of the update type.
+
+This configuration can be used to accomplish what
+$ResolveDefaultUpdateType was used for in RT 3.8.
+
+Use the following format to define labels and actions of transitions:
+
+ 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' },
+ ],
+ ...
+ },
+
+In addition, you may define multiple actions for the same transition.
+Alternately, you may use '* -> x' to match more than one transition.
+For example:
+
+ default => {
+ ...
+ actions => [
+ ...
+ 'new -> rejected' => { label => 'Reject', update => 'Respond' },
+ 'new -> rejected' => { label => 'Quick Reject' },
+ ...
+ '* -> deleted' => { label => 'Delete' },
+ ...
+ ],
+ ...
+ },
+
+=head2 Moving tickets between queues with different lifecycles
+
+Unless there is an explicit mapping between statuses in two different
+lifecycles, you can not move tickets between queues with these
+lifecycles. This is true even if the different lifecycles use the exact
+same set of statuses. Such a mapping is defined as follows:
+
+ __maps__ => {
+ 'from lifecycle -> to lifecycle' => {
+ 'status in left lifecycle' => 'status in right lifecycle',
+ ...
+ },
+ ...
+ },
+
+=cut
+
+Set(%Lifecycles,
+ default => {
+ initial => [ 'new' ],
+ active => [ 'open', 'stalled' ],
+ inactive => [ 'resolved', 'rejected', 'deleted' ],
+
+ defaults => {
+ on_create => 'new',
+ on_merge => 'resolved',
+ approved => 'open',
+ denied => 'rejected',
+ reminder_on_open => 'open',
+ reminder_on_resolve => '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',
+ '* -> *' => 'ModifyTicket',
+ },
+ actions => [
+ 'new -> open' => {
+ label => 'Open It', # loc
+ update => 'Respond',
+ },
+ 'new -> resolved' => {
+ label => 'Resolve', # loc
+ update => 'Comment',
+ },
+ 'new -> rejected' => {
+ label => 'Reject', # loc
+ update => 'Respond',
+ },
+ 'new -> deleted' => {
+ label => 'Delete', # loc
+ },
+
+ 'open -> stalled' => {
+ label => 'Stall', # loc
+ update => 'Comment',
+ },
+ 'open -> resolved' => {
+ label => 'Resolve', # loc
+ update => 'Comment',
+ },
+ 'open -> rejected' => {
+ label => 'Reject', # loc
+ update => 'Respond',
+ },
+
+ 'stalled -> open' => {
+ label => 'Open It', # loc
+ },
+ 'resolved -> open' => {
+ label => 'Re-open', # loc
+ update => 'Comment',
+ },
+ 'rejected -> open' => {
+ label => 'Re-open', # loc
+ update => 'Comment',
+ },
+ 'deleted -> open' => {
+ label => 'Undelete', # loc
+ },
+ ],
+ },
+# 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',
+ reminder_on_open => 'open',
+ reminder_on_resolve => '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', # loc
+ update => 'Respond',
+ },
+ 'new -> resolved' => {
+ label => 'Resolve', # loc
+ update => 'Comment',
+ },
+ 'new -> rejected' => {
+ label => 'Reject', # loc
+ update => 'Respond',
+ },
+ 'new -> deleted' => {
+ label => 'Delete', # loc
+ },
+
+ 'open -> stalled' => {
+ label => 'Stall', # loc
+ update => 'Comment',
+ },
+ 'open -> resolved' => {
+ label => 'Resolve', # loc
+ update => 'Comment',
+ },
+ 'open -> rejected' => {
+ label => 'Reject', # loc
+ update => 'Respond',
+ },
+
+ 'stalled -> open' => {
+ label => 'Open It', # loc
+ },
+ 'resolved -> open' => {
+ label => 'Re-open', # loc
+ update => 'Comment',
+ },
+ 'rejected -> open' => {
+ label => 'Re-open', # loc
+ update => 'Comment',
+ },
+ 'deleted -> open' => {
+ label => 'Undelete', # loc
+ },
+ ],
+ },
+);
+
+
+
+
+
+=head1 Administrative interface
+
+=over 4
+
+=item C<$ShowRTPortal>
+
+RT can show administrators a feed of recent RT releases and other
+related announcements and information from Best Practical on the top
+level Configuration page. This feature helps you stay up to date on
+RT security announcements and version updates.
+
+RT provides this feature using an "iframe" on C</Admin/index.html>
+which asks the administrator's browser to show an inline page from
+Best Practical's website.
+
+If you'd rather not make this feature available to your
+administrators, set C<$ShowRTPortal> to a false value.