Problem with custom lifecycle

RT Users
1

Hi,

I’m setting up a new lifecycle to manage our change request process and
I’m seeing some odd behaviour which I’m sure is something obvious.

The lifecycle is pasted below. The straight line path seems to work OK
but whenever I try to transition from “assessed” to anything other than
"authorised" I get an error that says I can’t change from assessed to,
say, assessment and the history indicates that it has indeed changed
the status to authorised before attempting to change it to some other state.

What am I doing wrong ?

Many thanks,

Simon.

 changerequest => {
     initial         => [ 'new' ],
     active          => [ 'assessment', 'assessed', 'authorised',

‘implementation’, ‘review’],
inactive => [ ‘closed’, ‘rejected_by_cm’,
‘rejected_by_cab’, ‘deleted’ ],

     defaults => {
         on_create => 'new',
         on_merge  => 'closed',
         approved  => 'authorised',
         denied    => 'rejected_by_cm',
         reminder_on_open     => 'assessment',
         reminder_on_resolve  => 'review',
     },

     transitions => {
         ''       => [qw(new assessment)],

         # from            => [ to list ],
         new               => [qw(assessment assessed rejected_by_cm

deleted)],
assessment => [qw(assessed rejected_by_cm deleted)],
assessed => [qw(authorised assessment
rejected_by_cm rejected_by_cab)],
authorised => [qw(implementation review)],
implementation => [qw(review)],
review => [qw(closed)],
closed => [qw()],
rejected_by_cm => [qw()],
rejected_by_cab => [qw()],
deleted => [qw()],
},
rights => {
’* -> deleted’ => ‘DeleteTicket’,
’* -> *’ => ‘ModifyTicket’,
},
actions => [
‘new -> assessment’ => {
label => ‘Start Assessing’, # loc
update => ‘Respond’,
},
‘new -> assessed’ => {
label => ‘Ready for CAB’, # loc
update => ‘Respond’,
},
‘new -> rejected_by_cm’ => {
label => ‘Reject (CM)’, # loc
update => ‘Respond’,
},
‘new -> deleted’ => {
label => ‘Delete’, # loc
},
‘assessment -> assessed’ => {
label => ‘Ready for CAB’, # loc
update => ‘Respond’,
},
‘assessment -> rejected_by_cm’ => {
label => ‘Reject (CM)’, # loc
update => ‘Respond’,
},
‘assessed -> authorised’ => {
label => ‘Authorise (CAB)’, # loc
update => ‘Respond’,
},
‘assessed -> assessment’ => {
label => ‘Return for Assessment’, # loc
update => ‘Respond’,
},
‘assessed -> rejected_by_cm’ => {
label => ‘Reject (CM)’, # loc
update => ‘Respond’,
},
‘assessed -> rejected_by_cab’ => {
label => ‘Reject (CAB)’, # loc
update => ‘Respond’,
},
‘authorised -> implementation’ => {
label => ‘Release to Implementation’, # loc
update => ‘Respond’,
},
‘authorised -> review’ => {
label => ‘Pass to Review’, # loc
update => ‘Respond’,
},
‘implementation -> review’ => {
label => ‘Pass to Review’, # loc
update => ‘Respond’,
},
‘review -> closed’ => {
label => ‘Close CR’, # loc
update => ‘Comment’,
},
],
},

2

I think I have found the culprit - there’s a load of Global Scrips
(probably hangovers from our original 3.x install, we’re now on 4.2.2
via 4.0.8) and one of those is “On Correspond Open Tickets” - I think
this is possibly running and getting confused as there’s no Open state
in this lifecycle.

So new question - is there an easy way to migrate these 14 Global Scrips
down to specific queues, or can I stop them running on a specific queue ?On 26/02/2014 19:37, Simon Wilcox wrote:

I’m setting up a new lifecycle to manage our change request process
and I’m seeing some odd behaviour which I’m sure is something obvious.

3

Try RT-Extension-QueueDeactivatedScrips. Search inside Github.> Am 26.02.2014 um 23:50 schrieb Simon Wilcox simonw@simonwilcox.co.uk:

I think I have found the culprit - there’s a load of Global Scrips (probably hangovers from our original 3.x install, we’re now on 4.2.2 via 4.0.8) and one of those is “On Correspond Open Tickets” - I think this is possibly running and getting confused as there’s no Open state in this lifecycle.

So new question - is there an easy way to migrate these 14 Global Scrips down to specific queues, or can I stop them running on a specific queue ?

On 26/02/2014 19:37, Simon Wilcox wrote:
I’m setting up a new lifecycle to manage our change request process and I’m seeing some odd behaviour which I’m sure is something obvious.

–
RT Training London, March 19-20 and Dallas May 20-21
http://bestpractical.com/training

4

Hi,

That looks promising but no indication that it works with 4.x.

I’m not very familiar with RT’s extension mechanisms, should I expect
something targeting 3.x to work seamlessly on 4.x ?

Simon.On 27/02/2014 07:13, Torsten Brumm wrote:

Try RT-Extension-QueueDeactivatedScrips. Search inside Github.

5

Hi Simon,
There is an updated version:

GitHub - dmsimard/RT-Extension-QueueDeactivatedScrips: Extension built for Best Practical's Request-Tracker. Provides an interface to disable global scrips on a per-queue basis.> Am 27.02.2014 um 09:55 schrieb Simon Wilcox simonw@simonwilcox.co.uk:

Hi,

That looks promising but no indication that it works with 4.x.

I’m not very familiar with RT’s extension mechanisms, should I expect something targeting 3.x to work seamlessly on 4.x ?

Simon.

On 27/02/2014 07:13, Torsten Brumm wrote:
Try RT-Extension-QueueDeactivatedScrips. Search inside Github.

–
RT Training London, March 19-20 and Dallas May 20-21
http://bestpractical.com/training

6

Hi Simon,
There is an updated version:
GitHub - dmsimard/RT-Extension-QueueDeactivatedScrips: Extension built for Best Practical's Request-Tracker. Provides an interface to disable global scrips on a per-queue basis.

All of the functionality of this extension should already be in core
in 4.2, so I’m not sure of the relevance here.

-kevin

7

I’m setting up a new lifecycle to manage our change request process
and I’m seeing some odd behaviour which I’m sure is something
obvious.

The lifecycle is pasted below. The straight line path seems to work
OK but whenever I try to transition from “assessed” to anything
other than “authorised” I get an error that says I can’t change from
assessed to, say, assessment and the history indicates that it has

Making a sample RT with your Config (wrapped in Set(%Lifecycles,
yourconfig) and a queue with that Lifecycle, I can click on a ticket
after creation and change the statuses from assessed to assessment
without error.

You’ll need to provide more details about your eror.

I think I have found the culprit - there’s a load of Global Scrips
(probably hangovers from our original 3.x install, we’re now on
4.2.2 via 4.0.8) and one of those is “On Correspond Open Tickets” -
I think this is possibly running and getting confused as there’s no
Open state in this lifecycle.

So new question - is there an easy way to migrate these 14 Global
Scrips down to specific queues, or can I stop them running on a
specific queue ?

Click on Admin → Scrips → Scrip Name
click on Applies To
Unselect it globally, assign to relevant queues.

Keep in mind that ‘Open Tickets’ in RT 4.2 doesn’t use ‘open’, it
moves it to the first active status, so your ‘open’ is leaking from
somewhere else, presumably another scrip with more custom code.

-kevin

8

Keep in mind that ‘Open Tickets’ in RT 4.2 doesn’t use ‘open’, it
moves it to the first active status, so your ‘open’ is leaking from
somewhere else, presumably another scrip with more custom code.

Yes - we appear to have a Global Scrip (On Correspond Open Tickets) that
re-opens the ticket exactly as you describe (authorised is the first
active status in the transition list for assessed, n.b. not the first in
the active list[1])

I think I need to move all the Scrips from Global to Queue based and
then allocate them out to each queue individually.

I can’t seem to find a facility to turn a Global Scrip off on a
per-queue basis.

Simon.
[1] Extract from previous:
changerequest => {
initial => [ ‘new’ ],
active => [ ‘assessment’, ‘assessed’, ‘authorised’,
‘implementation’, ‘review’],
inactive => [ ‘closed’, ‘rejected_by_cm’,
‘rejected_by_cab’, ‘deleted’ ],

     transitions => {
         ''       => [qw(new assessment)],

         # from            => [ to list ],
         new               => [qw(assessment assessed rejected_by_cm

deleted)],
assessment => [qw(assessed rejected_by_cm deleted)],
assessed => [qw(authorised assessment
rejected_by_cm rejected_by_cab)],
authorised => [qw(implementation review)],

9

Keep in mind that ‘Open Tickets’ in RT 4.2 doesn’t use ‘open’, it
moves it to the first active status, so your ‘open’ is leaking from
somewhere else, presumably another scrip with more custom code.

Yes - we appear to have a Global Scrip (On Correspond Open Tickets)
that re-opens the ticket exactly as you describe (authorised is the
first active status in the transition list for assessed, n.b. not
the first in the active list[1])

You can read the documentation for that Scrip Action to understand how
it works.

http://bestpractical.com/docs/rt/latest/RT/Action/AutoOpen.html

I think I need to move all the Scrips from Global to Queue based and
then allocate them out to each queue individually.

I can’t seem to find a facility to turn a Global Scrip off on a
per-queue basis.

You must have missed this in my previous email.

Click on Admin → Scrips → Scrip Name
click on Applies To
Unselect it globally, assign to relevant queues.

-kevin

10

Keep in mind that ‘Open Tickets’ in RT 4.2 doesn’t use ‘open’, it
moves it to the first active status, so your ‘open’ is leaking from
somewhere else, presumably another scrip with more custom code.

Yes - we appear to have a Global Scrip (On Correspond Open Tickets)
that re-opens the ticket exactly as you describe (authorised is the
first active status in the transition list for assessed, n.b. not
the first in the active list[1])
You can read the documentation for that Scrip Action to understand how
it works.

RT::Action::AutoOpen - RT 5.0.5 Documentation - Best Practical

Many thanks - I’ll read up on that.

I think I need to move all the Scrips from Global to Queue based and
then allocate them out to each queue individually.

I can’t seem to find a facility to turn a Global Scrip off on a
per-queue basis.
You must have missed this in my previous email.

Click on Admin → Scrips → Scrip Name
click on Applies To
Unselect it globally, assign to relevant queues.

No, I didn’t miss it but that’s not the same thing although it achieves
the same end effect. I understand that this is the correct way to do
what I want and I’ll be implementing it this way today.

I have a much better idea of how these things work now, thank you for
your advice :slight_smile:

Simon.