I'd agree. I must be missing something. Here is from RT_Config.pm: (Doesn't
seem to provide a full example.)
Lifecycle definitions
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.) Each set may have any
number of statuses.
For example:
default => {
initial => ['new'],
active => ['open', 'stalled'],
inactive => ['resolved', 'rejected', 'deleted'],
...
},
Status names can be from 1 to 64 ASCII characters. Statuses are
localized using RT's standard internationalization and localization system.
initial
You can define multiple initial statuses for tickets in a given
lifecycle.
RT will automatically set its Started date when you change a
ticket's status from an initial state to an active or inactive status.
active
Active tickets are "currently in play" - they're things that are
being worked on and not yet complete.
inactive
Inactive tickets are typically in their "final resting state".
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.
RT will automatically set the Resolved date when a ticket's status
is changed from an Initial or Active status to an Inactive status.
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.
Statuses in each set are ordered and listed in the UI in the defined
order.
Changes between statuses are constrained by transition rules, as
described below.
