Hello all!
We went live with rt 4.0.04 last night and have been getting reports of
end-users being unable to change ticket status in ANY queue from New ->
Open.
Ticket 39927: Status ‘open’ isn’t a valid status for tickets in this queue.
We are using the ‘default’ Lifecycle which allows for ‘new’ -> ‘open’
default => {
initial => [ ‘new’ ],
active => [ ‘new’,’ open’, ‘stalled’ ],
inactive => [ ‘resolved’, ‘rejected’, ‘deleted’, ‘billed’ ],
…
Added ‘billed’ transaction status
transitions => {
’’ => [qw(new open resolved)],
# from => [ to list ],
new => [qw(open stalled resolved rejected billed
deleted)],
open => [qw(new stalled resolved rejected billed deleted)],
stalled => [qw(new open rejected resolved billed deleted)],
resolved => [qw(new open stalled rejected billed deleted)],
rejected => [qw(new open stalled resolved billed deleted)],
billed => [qw(new open stalled rejected resolved deleted)],
deleted => [qw(new open stalled rejected resolved billed)],
},
…
actions => [
‘new -> open’ => {
label => ‘Open It’, # loc
update => ‘Respond’,
},
…
Hello all!
We went live with rt 4.0.04 last night and have been getting reports
of end-users being unable to change ticket status in ANY queue from
New → Open.
Ticket 39927: Status ‘open’ isn’t a valid status for tickets in this
queue.
We are using the ‘default’ Lifecycle which allows for ‘new’ → ‘open’
default => {
initial => [ ‘new’ ],
active => [ ‘new’,’ open’, ‘stalled’ ],
inactive => [ ‘resolved’, ‘rejected’, ‘deleted’,
‘billed’ ],
…
Added ‘billed’ transaction status
transitions => {
‘’ => [qw(new open resolved)],
# from => [ to list ],
new => [qw(open stalled resolved rejected billed
deleted)],
open => [qw(new stalled resolved rejected billed
deleted)],
stalled => [qw(new open rejected resolved billed deleted)],
resolved => [qw(new open stalled rejected billed deleted)],
rejected => [qw(new open stalled resolved billed deleted)],
billed => [qw(new open stalled rejected resolved deleted)],
deleted => [qw(new open stalled rejected resolved billed)],
},
…
actions => [
‘new → open’ => {
label => ‘Open It’, # loc
update => ‘Respond’,
},
…
RT Training Sessions (http://bestpractical.com/services/training.html)
- Boston — March 5& 6, 2012
Seeing the following log message when attempting to set status from
‘new’ to ‘open’
Feb 3 11:37:39 track RT:
SelectQueue—33610—CreateTicket—1CurrentUserSelectQueue—33610—ShowTicket—1ticketsDefaultQueuecreate_in_typesActions_session_idCurrentSearchHashmy_rt_portletsSelectQueue—33610—CreateTicket—0NextPagei
at
/opt/rt4/local/plugins/RTx-AssetTracker/html/Callbacks/AssetTracker/Elements/Tabs/Privileged
line 11.
(/opt/rt4/local/plugins/RTx-AssetTracker/html/Callbacks/AssetTracker/Elements/Tabs/Privileged:11
time to dig
Hello all!
We went live with rt 4.0.04 last night and have been getting reports of end-users being unable
to change ticket status in ANY queue from New → Open.
Ticket 39927: Status ‘open’ isn’t a valid status for tickets in this queue.
This error means that open is invalid for the current Queue, not there
is no transition from new → open. Unfortunately, your truncated config
doesn’t fail locally. Are you sure you don’t have other lifecycles
configured and applied? If you look at the System Configuration page,
does it show the Lifecycle config you expect?
You could also tweak Ticket.pm’s SetStatus to warn when you encounter
the error so you could see $cycle->Name.
-kevin
Hello all!
We went live with rt 4.0.04 last night and have been getting reports
of end-users being unable
to change ticket status in ANY queue from New → Open.
Ticket 39927: Status ‘open’ isn’t a valid status for tickets in this
queue.
This error means that open is invalid for the current Queue, not there
is no transition from new → open. Unfortunately, your truncated config
doesn’t fail locally. Are you sure you don’t have other lifecycles
configured and applied? If you look at the System Configuration page,
does it show the Lifecycle config you expect?
Fixed, someone had a typo in the RT_Config.pm
‘active’ => [
‘new’,
=>’ open’,<= darn space between ’ and open
‘stalled’
],
-Ron
Hello all!
We went live with rt 4.0.04 last night and have been getting reports
of end-users being unable
to change ticket status in ANY queue from New → Open.
Ticket 39927: Status ‘open’ isn’t a valid status for tickets in this
queue.
This error means that open is invalid for the current Queue, not there
is no transition from new → open. Unfortunately, your truncated config
doesn’t fail locally. Are you sure you don’t have other lifecycles
configured and applied? If you look at the System Configuration page,
does it show the Lifecycle config you expect?
Fixed, someone had a typo in the RT_Config.pm
You really want all local configs in RT_SiteConfig.pm, not
RT_Config.pm. Next time you upgrade, any changes to RT_Config.pm will
be blown away.
You really want all local configs in RT_SiteConfig.pm, not
RT_Config.pm. Next time you upgrade, any changes to RT_Config.pm will
be blown away.
Why doesn’t Best Practical just do away this idea?
-
make install
put new RT_Config.pm in place
make a new ‘RT_SiteConfig’ help document from it (yes, Site)
if there is an RT_SiteConfig.pm in place
leave it alone
else
cp RT_Config.pm RT_SiteConfig.pm
-
Never mention “RT_Config.pm” anywhere. Mention
the help document you made from it.
[ Yes, I use RT_SiteConfig.pm, the gigantic WARNING ]
[ block in RT_Config.pm was obvious to me ]
You really want all local configs in RT_SiteConfig.pm, not
RT_Config.pm. Next time you upgrade, any changes to RT_Config.pm will
be blown away.
Why doesn’t Best Practical just do away this idea?
-
make install
put new RT_Config.pm in place
make a new ‘RT_SiteConfig’ help document from it (yes, Site)
if there is an RT_SiteConfig.pm in place
leave it alone
else
cp RT_Config.pm RT_SiteConfig.pm
-
Never mention “RT_Config.pm” anywhere. Mention
the help document you made from it.
Because having an RT_SiteConfig.pm that is the same as RT_Config.pm
means that RT can never tell you if you overrode the setting.
Go look at the System Configuration page, note that for each setting
it says core vs site. That’s a tremendously useful piece of
information.
Also keep in mind that RT can read from 3, 4 or even 5 local config
files so you can keep your setting distinct.
Having a sparse RT_SiteConfig.pm also makes it trivial as a sysadmin
to tell what you’ve changed locally, especially when looking back
through your source control.
The solution here is not more separation of the config files, but
moving more configuration into the database which is something that is
being worked on.
-kevin
Because having an RT_SiteConfig.pm that is the same as RT_Config.pm
means that RT can never tell you if you overrode the setting.
Sure it can. In those rare needs, the code can just compare
the value in RT_Config.pm to the one in RT_SiteConfig.pm.
If they’re the same, it was not overridden.
Also keep in mind that RT can read from 3, 4 or even 5 local config
files so you can keep your setting distinct.
Having a sparse RT_SiteConfig.pm also makes it trivial as a sysadmin
to tell what you’ve changed locally, especially when looking back
through your source control.
Isn’t that what revision diffs are for?
But okay. Just had to throw the idea out there.
Because having an RT_SiteConfig.pm that is the same as RT_Config.pm
means that RT can never tell you if you overrode the setting.
Sure it can. In those rare needs, the code can just compare
the value in RT_Config.pm to the one in RT_SiteConfig.pm.
If they’re the same, it was not overridden.
That’s not how RT’s Config system works.
If you’d be interested in providing a patch to support this,
lib/RT/Config.pm is the right place to start.
Also keep in mind that RT can read from 3, 4 or even 5 local config
files so you can keep your setting distinct.
Having a sparse RT_SiteConfig.pm also makes it trivial as a sysadmin
to tell what you’ve changed locally, especially when looking back
through your source control.
Isn’t that what revision diffs are for?
But okay. Just had to throw the idea out there.
You have revision diffs, I do too, that’s an unusual situation.
Also, when you’re handed an 8 year old RT install, it’s easier to tell
what the maintainer who left 5 years ago did.
Again, the solution is probably to push more things into the DB where
we can have better control.
-kevin