New statuses --> broken workflows

Hi all -

I recently added some new statuses to my Lifecycles and now my workflows
seem to be somewhat broken. For example, if I have an Open ticket, if a
user replies to that ticket via email it will be moved to Stalled. That
is not how it should be. I made my Lifecycle changes in RT_SiteConfig.pm
and took a backup of the original RT_SiteConfig.pm. When I put the
original back in place, all workflows work as expected – so I obviously
screwed something up with the Lifecycles, but I just can’t see what it is.
The new statuses are considering, userWait, vendorWait and scheduled.
Any help is appreciated…

Set(%Lifecycles,
default => {
initial => [ ‘new’ ],
active => [ ‘considering’, ‘open’, ‘stalled’, ‘userWait’,
‘vendorWait’, ‘scheduled’
],
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

considering scheduled userWait vendorWait)],
open => [qw(new stalled resolved rejected deleted
considering scheduled userWait vendorWait)],
considering => [qw(new stalled resolved rejected deleted
scheduled userWait vendorWait)],
scheduled => [qw(new stalled resolved rejected deleted
considering userWait vendorWait)],
userWait => [qw(new stalled resolved rejected deleted
scheduled)],
vendorWait => [qw(new stalled resolved rejected deleted
scheduled)],
stalled => [qw(new open rejected resolved deleted considering
scheduled userWait vendorWait)],
resolved => [qw(new open stalled rejected deleted considering
scheduled userWait vendorWait)],
rejected => [qw(new open stalled resolved deleted considering
scheduled)],
deleted => [qw(new open stalled rejected resolved considering
scheduled)],
},
rights => {
‘* → deleted’ => ‘DeleteTicket’,
‘* → *’ => ‘ModifyTicket’,
},
actions => [
‘new → open’ => {
label => ‘Open It’, # loc
update => ‘Respond’,
},
‘new → resolved’ => {
label => ‘Resolve’, # loc
update => ‘Respond’,
},
‘new → rejected’ => {
label => ‘Reject’, # loc
update => ‘Respond’,
},
‘new → deleted’ => {
label => ‘Delete’, # loc
},
‘new → considering’ => {
label => ‘Consider’, # loc
update => ‘Comment’,
},
‘new → scheduled’ => {
label => ‘Schedule’, # loc
update => ‘Comment’,
},
‘new → userWait’ => {
label => ‘userWait’, # loc
update => ‘Comment’,
},
‘new → vendorWait’ => {
label => ‘vendorWait’, # loc
update => ‘Comment’,
},

        'open -> stalled'  => {
            label  => 'Stall', # loc
            update => 'Comment',
        },
        'open -> resolved' => {
            label  => 'Resolve', # loc
            update => 'Respond',
        },
        'open -> rejected' => {
            label  => 'Reject', # loc
            update => 'Respond',
        },
        'open -> considering' => {
            label => 'Consider', # loc
            update => 'Comment',
        },
        'open -> scheduled' => {
            label => 'Schedule', # loc
            update => 'Comment',
        },
        'open -> userWait' => {
            label => 'userWait', # loc
            update => 'Comment',
        },
        'open -> vendorWait' => {
            label => 'vendorWait', # loc
            update => 'Comment',
        },


        'stalled -> open'  => {
            label  => 'Open It', # loc
        },
        'stalled -> resolved'  => {
            label  => 'Resolve', # loc
            update => 'Respond',
        },
        'stalled -> considering' => {
            label => 'Consider', # loc
            update => 'Comment',
        },
        'stalled -> scheduled' => {
            label => 'Schedule', # loc
            update => 'Comment',
        },
        'stalled -> userWait' => {
            label => 'userWait', # loc
            update => 'Comment',
        },
        'stalled -> vendorWait' => {
            label => 'vendorWait', # loc
            update => 'Comment',
        },

        'considering -> open'  => {
            label  => 'Open It', # loc
        },
        'considering -> scheduled' => {
            label => 'Schedule', # loc
            update => 'Comment',
        },
        'considering -> stalled' => {
            label => 'Stall', # loc
            update => 'Comment',
        },
        'considering -> userWait' => {
            label => 'userWait', # loc
            update => 'Comment',
        },
        'considering -> vendorWait' => {
            label => 'vendorWait', # loc
            update => 'Comment',
        },

        'scheduled -> resolved'  => {
            label  => 'Resolve', # loc
            update => 'Respond',
        },

        'resolved -> open' => {
            label  => 'Re-open', # loc
            update => 'Comment',
        },
        'rejected -> open' => {
            label  => 'Re-open', # loc
            update => 'Comment',
        },
        'deleted -> open'  => {
            label  => 'Undelete', # loc
        },
    ],
},

Max McGrath https://www.linkedin.com/pub/max-mcgrath/1b/3a6/a21
Network Administrator
Carthage College
262-552-5512
mmcgrath@carthage.edu

Hi all -

Hi Max,

I recently added some new statuses to my Lifecycles and now my workflows
seem to be somewhat broken. For example, if I have an Open ticket, if
a user replies to that ticket via email it will be moved to Stalled.

That sounds like a scrip is firing. Do you have a scrip that modifies the
ticket status?

That is not how it should be. I made my Lifecycle changes in
RT_SiteConfig.pm and took a backup of the original RT_SiteConfig.pm. When
I put the original back in place, all workflows work as expected – so I
obviously screwed something up with the Lifecycles, but I just can’t see
what it is.

Have you tried making one change at a time and then verify the correctness
of that one change?

It looks like you have just the one “default” lifecycle. Is that correct?

We use perl in the lifecycle portion of the config to drive it. Once you
get beyond two lifecycles it is very hard to edit and verify by hand. Also,
if your lifecycle is a fully connected graph, then you can use perl to make
all the transitions arrays programatically.

-m