Recently upgraded to 4.0 and getting these errors:
[Mon Jun 13 17:58:55 2011] [warning]: RT::ActiveStatus undefined, falling back to deprecated defaults (/opt/rt3/lib/RT/Queue_Overlay.pm:202)
[Mon Jun 13 17:58:55 2011] [warning]: RT::InactiveStatus undefined, falling back to deprecated defaults (/opt/rt3/lib/RT/Queue_Overlay.pm:222)
[Mon Jun 13 17:58:55 2011] [warning]: RT::InactiveStatus undefined, falling back to deprecated defaults (/opt/rt3/lib/RT/Queue_Overlay.pm:222)
[Mon Jun 13 17:58:55 2011] [warning]: RT::ActiveStatus undefined, falling back to deprecated defaults (/opt/rt3/lib/RT/Queue_Overlay.pm:202)
[Mon Jun 13 17:58:55 2011] [warning]: RT::InactiveStatus undefined, falling back to deprecated defaults (/opt/rt3/lib/RT/Queue_Overlay.pm:222)
[Mon Jun 13 17:58:55 2011] [warning]: Deep recursion on subroutine “RT::Queue::SubjectTag” at /opt/rt3/lib/RT/System.pm line 232. (/opt/rt3/lib/RT/System.pm:232)
Figure something to do with an old setting (commented out now):
#Set(@ActiveStatus, qw(new open research stalled));
and the new Lifecycle.
Is this the correct way to add “research” to the status pulldown?
#Lifecyles
default => {
initial => [‘new’],
active => [‘open’,‘research’,‘stalled’],
inactive => [‘resolved’, ‘rejected’, ‘deleted’],
},
It’s not showing up, I’m still seeing those errors, and it seems to me that config is missing something.
Would be wonderful to have a Wiki doc on the Lifecycles. The RT_Config.pm isn’t very detailed.
Recently upgraded to 4.0 and getting these errors:
[Mon Jun 13 17:58:55 2011] [warning]: RT::ActiveStatus undefined, falling back to deprecated defaults (/opt/rt3/lib/RT/Queue_Overlay.pm:202)
[Mon Jun 13 17:58:55 2011] [warning]: RT::InactiveStatus undefined, falling back to deprecated defaults (/opt/rt3/lib/RT/Queue_Overlay.pm:222)
[Mon Jun 13 17:58:55 2011] [warning]: RT::InactiveStatus undefined, falling back to deprecated defaults (/opt/rt3/lib/RT/Queue_Overlay.pm:222)
[Mon Jun 13 17:58:55 2011] [warning]: RT::ActiveStatus undefined, falling back to deprecated defaults (/opt/rt3/lib/RT/Queue_Overlay.pm:202)
[Mon Jun 13 17:58:55 2011] [warning]: RT::InactiveStatus undefined, falling back to deprecated defaults (/opt/rt3/lib/RT/Queue_Overlay.pm:222)
[Mon Jun 13 17:58:55 2011] [warning]: Deep recursion on subroutine “RT::Queue::SubjectTag” at /opt/rt3/lib/RT/System.pm line 232. (/opt/rt3/lib/RT/System.pm:232)
is /opt/rt3 your upgraded RT?
You appear to have left a lot of code around from 3.x
You skipped the part of docs/UPGRADING-4.0 which tells you that you
cannot just make upgrade into /opt/rt3 without lots of failures.
Is this the correct way to add “research” to the status pulldown?
We’d need to see the full piece of code, and you also need to add
transition rules
#Lifecyles
default => {
initial => [‘new’],
active => [‘open’,‘research’,‘stalled’],
inactive => [‘resolved’, ‘rejected’, ‘deleted’],
},
It’s not showing up, I’m still seeing those errors, and it seems to me that config is missing something.
Would be wonderful to have a Wiki doc on the Lifecycles. The RT_Config.pm isn’t very detailed.
I find the RT_Config.pm Lifecycle documentation to be quite complete.
We updated it slightly to talk about rights in 4.0.1
Specific examples of things that can be updated would be useful.
I’d much prefer that enhanced Lifecycle documentation ship with RT, as
it is more likely to stay up to date.
-kevin
Good catch, didn’t notice that!
Let me go check.
Thanks Kevin!
That got rid of my warnings in the log. Don’t know how it was finding the old installation, but I moved the folder and all seems well.
Can someone provide an example of their lifecycle configuration in RT_SiteConfig.pm?
Still not seeing my “research” status option in the pull downs.
That got rid of my warnings in the log. Don’t know how it was finding the old installation, but I moved the folder and all seems well.
Can someone provide an example of their lifecycle configuration in RT_SiteConfig.pm?
Still not seeing my “research” status option in the pull downs.
Please provide what you’re doing in RT_SiteConfig.pm, the whole
Lifecycles stanza.
Did you have an /opt/rt4 and /opt/rt3? The fact that rt3 was being
loaded into memory by your webserver is scary and points to a
misconfiguration and quite possibly a different RT_SiteConfig.pm being
loaded.
-kevin
This is it:
#Lifecyles
default => {
initial => [‘new’],
active => [‘open’,‘research’,‘stalled’],
inactive => [‘resolved’, ‘rejected’, ‘deleted’],
},
Like I said, it doesn’t look right and the RT_Config.pm examples seem to be missing something.
I had an /opt/rt3 and an /opt/rt4 and everything pointing to /opt/rt which is a soft link to /opt/rt4. I moved /opt/rt3 to /opt/old.rt3.
I grep’d the RT_SiteConfig.pm and no rt3 returned.
This is it:
#Lifecyles
default => {
initial => [‘new’],
active => [‘open’,‘research’,‘stalled’],
inactive => [‘resolved’, ‘rejected’, ‘deleted’],
},
Like I said, it doesn’t look right and the RT_Config.pm examples seem to be missing something.
You need to copy the entire Set(%Lifecycles … ); from RT_Config.pm
to RT_SiteConfig.pm and modify it. You can’t copy snippets into
RT_SiteConfig.pm.
-kevin
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.
BTW, found the problem with the /opt/rt3 and /opt/rt4. My /etc/aliases was using the /opt/rt3. Fixed now.
I’d agree. I must be missing something. Here is from RT_Config.pm: (Doesn’t seem to provide a full example.)
Scroll down. Search for Set(%Lifecycles
-kevin
Ah ha! I was using perldoc to view it. Using vi I found the section. See, I knew I was being a bonehead.