[rt-devel] Custom Life Cycles and Scrip Conditions

[Alexander Reintzsch]

Hi,

I created a custom lifecycle and an also mapped it to the default lifecycle.  I mapped the custom lifecycle in both ways with the default lifecycle.

Now I want to create a scrip. With the default lifecycle there is the "On Resolve" condition. But this doesn't apply then my custom Resolve state is about to be set.

In RT_Config I also found these lines:

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:

    default => {
        ...
        defaults => {
            on_create => 'new',
            on_resolve => 'resolved',
            ...
        },
    },

The following defaults are used.

Which I suppose is not what I need or has not been implemented yet.

But before I create a custom condition I wanted to be sure.

I found the code for "On Resolve" is located in lib/RT/Condition/StatusChange.pm and in the database in the table ScripConditions.

I guess I need to rewrite lib/RT/Condition/StatusChange.pm to include RT::Lifecycle->MoveMap. Is this correct?

If so, this would be my way to go:

109,111d108
<     elsif ( $argument =~ /^\s*new:\s*(.*)\s*$/i ) {
<         $new_must_be = $1;
<     }
114a112,115
>     # By default argument is always the new status
>     elsif ( $argument =~ /^\s*(?:new:)?\s*(.*)\s*$/i ) { 
>         $new_must_be = $1; 
>     }
121a123,129
>     # If the ticket belongs to a different lifecycle, then the ticket's new status can also be compared to its mapped counterpart in default lifecycle
>     if ($lifecycle->Name ne 'default' && $lifecycle->HasMoveMap( 'default' )) {
>         my $defaultLifecycle = RT::Lifecycle->Load( Name => 'default');
>         $RT::Logger->debug('The lifecycle has a MoveMap to default. Looking for matching status in default lifecycle.');
>         $new_must_be .= ',' . $defaultLifecycle->MoveMap( $lifecycle )->{lc $new_must_be};
>     }
>

What is the change?
By default the argument (which is taken from the database and there it ist set to "resolve" not "new:resolve") is the value of the new status to be checked against. i.e. "On Resolve" uses "resolve". So $new_must_be will be the argument. Even if set without the preceding "new:".

Then if the ticket belongs to another lifecycle than 'default' and there is a MoveMap from 'default' to that custom lifecycle the ticket belongs to, then also add the mapped counterpart to the $new_must_be.

What is the advantage?
One doesn't have to write a new condition if using another custom lifecycle and can still use the default conditions like "On Resolve" and "On Reject" if there is a mapping between the lifecycles. The Database does not need to be changed. Which would be the other way. You could edit the entry for "On Resolve" in the table ScripConditions and use the argument "new:resolve,myresolve".

Thank you very much for your thoughts in this matter. If you like this code you can use it as you please.

Sincerely yours,
Alexander