I dodon’t know if this has been addressed yet, but I assume it is a
common request.
I would like to add more choices for the status field. Since these are
predefined by the system, is there an easy way to do this? Ideally, I
wish status was a user-defined field; however, I realize that might
complicate or take away from the the functionality of this field.
Thanks,
kdl
n’t know if this has been addressed yet, but I assume it is a common
request.
I would like to add more choices for the status field. Since these are
predefined by the system, is there an easy way to do this? Ideally, I
wish status was a user-defined field; however, I realize that might
complicate or take away from the the functionality of this field.
search the list archives, there was a related posting at May 20th, 2004,
titled “additional statuses possible?”
Jan
“Kelly D. Lucas” wrote:
I dodon’t know if this has been addressed yet, but I assume it is a common request.
I would like to add more choices for the status field. Since these are predefined by the
system, is there an easy way to do this? Ideally, I wish status was a user-defined
field; however, I realize that might complicate or take away from the the functionality
of this field.
Thanks,
kdl n’t know if this has been addressed yet, but I assume it is a common request.
I would like to add more choices for the status field. Since these are predefined by the
system, is there an easy way to do this? Ideally, I wish status was a user-defined
field; however, I realize that might complicate or take away from the the functionality
of this field.
search the list archives, there was a related posting at May 20th, 2004,
titled “additional statuses possible?”
Jan
“Kelly D. Lucas” wrote:
I dodon’t know if this has been addressed yet, but I assume it is a common request.
I would like to add more choices for the status field. Since these are predefined by the
system, is there an easy way to do this? Ideally, I wish status was a user-defined
field; however, I realize that might complicate or take away from the the functionality
of this field.
Thanks,
kdl n’t know if this has been addressed yet, but I assume it is a common request.
I would like to add more choices for the status field. Since these are predefined by the
system, is there an easy way to do this? Ideally, I wish status was a user-defined
field; however, I realize that might complicate or take away from the the functionality
of this field.
think in the current scheme, that’s what “stalled” means. Also, see
Linda Julien’s post from 4/15/2004 3:15PM, subject “Re: [Rt-users]
Custom Statuses”, for information on adding active or inactive status
representations…
Kelly F. Hickel
Senior Software Architect
MQSoftware, Inc.
952.345.8677 kfh@mqsoftware.com
-----Original Message-----
From: Dave Dennis [mailto:dmd@speakeasy.org]
Sent: Monday, June 21, 2004 1:13 PM
To: algermissen@acm.org
Cc: RT Users
Subject: Re: [rt-users] Adding more status types
search the list archives, there was a related posting at May 20th,
2004,
titled “additional statuses possible?”
Jan
“Kelly D. Lucas” wrote:
I dodon’t know if this has been addressed yet, but I assume it is
a
common request.
I would like to add more choices for the status field. Since these
are
predefined by the
system, is there an easy way to do this? Ideally, I wish status
was a
user-defined
field; however, I realize that might complicate or take away from
the
the functionality
of this field.
Thanks,
kdl n’t know if this has been addressed yet, but I assume it is a
common request.
I would like to add more choices for the status field. Since these
are
predefined by the
system, is there an easy way to do this? Ideally, I wish status
was a
user-defined
field; however, I realize that might complicate or take away from
the
the functionality
of this field.
I found it, it’s in a file with .mht, which probably stands for mail
handling text… ?? Here is what I pulled out of that file, bold is
reply, and italics is the original question:
There’s a pair of arrays in RT/Queue_Overlay.pm that define the
statuses supported by RT. The default scrips and user interface do
assume that you haven’t removed any of the shipping statuses.
Jesse, Do I understand you to be saying that I should be able to
ADD status values to the pair of arrays mentioned above (as long as I
=don’t change the existing ones, or their relative position), and
things should work??? That would be huge…
Yes, you could do exactly that, if you choose to go that route.
You can create yourself a Queue_Local.pm file, and you can override
those arrays, like this:
Queue_Local.pm
@ACTIVE_STATUS =3D qw(new open stalled my_other_status);
search the list archives, there was a related posting at May 20th, 2004,
titled “additional statuses possible?”
Jan
</pre>
"Kelly D. Lucas" wrote:
I dodon’t know if this has been addressed yet, but I assume it is a common request.
I would like to add more choices for the status field. Since these are predefined by the
system, is there an easy way to do this? Ideally, I wish status was a user-defined
field; however, I realize that might complicate or take away from the the functionality
of this field.
Thanks,
kdl n’t know if this has been addressed yet, but I assume it is a common request.
I would like to add more choices for the status field. Since these are predefined by the
system, is there an easy way to do this? Ideally, I wish status was a user-defined
field; however, I realize that might complicate or take away from the the functionality
of this field.
And then testing it with restarting apache and creating / resolving test ticket
using a new value… So thats great, thanks for the heads-up.
Two questions:
First: I was unable to get {RT}/local/lib/Queue_Overlay.pm
with the same change to work, want to make all changes to a ‘local’ …
What was I doing wrong? (This for testing was with a whole copy of default
Queue_Overlay.pm, should it have only had the specific lines needed not the
whole file?
Second question: Is it allowed to remove an item from an array,
for example we rarely to never use ‘stalled’ . Would it break
logic elsewhere in default code if ‘stalled’ were removed from the
array?
think in the current scheme, that’s what “stalled” means. Also, see
Linda Julien’s post from 4/15/2004 3:15PM, subject “Re: [Rt-users]
Custom Statuses”, for information on adding active or inactive status
representations…
–
Kelly F. Hickel
Senior Software Architect
MQSoftware, Inc.
952.345.8677 kfh@mqsoftware.com
-----Original Message-----
From: Dave Dennis [mailto:dmd@speakeasy.org]
Sent: Monday, June 21, 2004 1:13 PM
To: algermissen@acm.org
Cc: RT Users
Subject: Re: [rt-users] Adding more status types
search the list archives, there was a related posting at May 20th,
2004,
titled “additional statuses possible?”
Jan
“Kelly D. Lucas” wrote:
I dodon’t know if this has been addressed yet, but I assume it is
a
common request.
I would like to add more choices for the status field. Since these
are
predefined by the
system, is there an easy way to do this? Ideally, I wish status
was a
user-defined
field; however, I realize that might complicate or take away from
the
the functionality
of this field.
Thanks,
kdl n’t know if this has been addressed yet, but I assume it is a
common request.
I would like to add more choices for the status field. Since these
are
predefined by the
system, is there an easy way to do this? Ideally, I wish status
was a
user-defined
field; however, I realize that might complicate or take away from
the
the functionality
of this field.
First: I was unable to get {RT}/local/lib/Queue_Overlay.pm
with the same change to work, want to make all changes to a ‘local’ …
What was I doing wrong? (This for testing was with a whole copy of default
Queue_Overlay.pm, should it have only had the specific lines needed not the
whole file?
You only need to duplicate the functions you wish to override. But you
must duplicate entire functions, not just individual lines. You might have
better luck with Queue_Local.pm.
Second question: Is it allowed to remove an item from an array,
for example we rarely to never use ‘stalled’ . Would it break
logic elsewhere in default code if ‘stalled’ were removed from the
array?
As I recall, it was said that removing or altering the default statuses
would be a Bad Thing. If you have a great dislike for “stalled,” you may be
better off trying to change it at the presentation layer. Modify all the
Mason components responsible for displaying the statuses to substitute your
preferred name in the user visible areas but retain “stalled” in the back end.
I know I’ve said this before, but if you feel a need to change the
statuses, I would strongly suggest reconsidering a more RT like way of
solving your work flow. There are no API guarantees for statuses which
means that your custom statuses can break at any point with an upgrade.
Michael
Michael S. Liebman m-liebman@northwestern.edu http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”
I know I’ve said this before, but if you feel a need to change the
statuses, I would strongly suggest reconsidering a more RT like way of
solving your work flow. There are no API guarantees for statuses which
means that your custom statuses can break at any point with an upgrade.
I agree with Michael here, for what it’s worth. We needed slightly
more fine-grained control, to indicate whether a ticket was waiting
for client input, in testing, ready to put live, etc–all of which
fall under the ‘open’ status.
I actually did go to the code and add the additional states, but
decided not to apply the patch to the live server because it looked
as if it had the potential to make upgrades painful.
In the end, our solution was to add a custom field, ‘phase’, which
holds the additional values. I then modified the template so that you
always see the phase in addition to the status, if it is present.
It actually turned out that this model more accurately represents
how we think about the tickets than additional status entries would,
because for status it is always a progression from new to resolved,
whereas the phase can bounce between different states.
Anyhow, this is just another suggestion on how the different states
could be handled.
My group has been evaluating RT for 2 weeks now, and the only thing
we’ve found that will cause us implementation headaches is the rigid
definitions of the status field. I suspect that the status field is
this way, because alot of the logic flow of a ticket must be based on
the status. Is this assumption correct? If so, the solution is probably
not easy. However, one thing that comes to mind, is make status a user
defined field., like other useful user-defined fields such as
[priority, category, and as Ann has used, phases]. I haven’t thought
this through, so right now I’m just brain storming with some of you
that have been using this for some time… but I wonder how difficult
it would be to create a front-end to customizing scrips… for example:
After the custom defined fields are added, then have a U/I under
configuration for scrips. And in there, link the logic flow between the
field that have been defined. Maybe this would unnecessarily complicate
the entire system. Maybe there is an easier path and I’m not familiar
enough with the system to see it. I don’t want to get in the situation
where an upgrade breaks everything, or where we could not upgrade down
the road.
Any thoughts? I guess at a minimum, I want a way to add or remove
statuses, and connect the logic flow to them.
I know I've said this before, but if you feel a need to change the
statuses, I would strongly suggest reconsidering a more RT like way of
solving your work flow. There are no API guarantees for statuses which
means that your custom statuses can break at any point with an upgrade.
I agree with Michael here, for what it's worth. We needed slightly
more fine-grained control, to indicate whether a ticket was waiting
for client input, in testing, ready to put live, etc--all of which
fall under the 'open' status.
I actually did go to the code and add the additional states, but
decided not to apply the patch to the live server because it looked
as if it had the potential to make upgrades painful.
In the end, our solution was to add a custom field, ‘phase’, which
holds the additional values. I then modified the template so that you
always see the phase in addition to the status, if it is present.
It actually turned out that this model more accurately represents
how we think about the tickets than additional status entries would,
because for status it is always a progression from new to resolved,
whereas the phase can bounce between different states.
Anyhow, this is just another suggestion on how the different states
could be handled.
Adding a custom field is a great solution, but for one issue:
The custom field is not available from List.html or Update.html at ticket
resolve time. So the workflow of resolving a ticket suffers as the operator
must visit the Basics screen and make a special detour in order to complete the
resolve custom field value.
I know I’ve said this before, but if you feel a need to change the
statuses, I would strongly suggest reconsidering a more RT like way of
solving your work flow. There are no API guarantees for statuses which
means that your custom statuses can break at any point with an upgrade.
I agree with Michael here, for what it’s worth. We needed slightly
more fine-grained control, to indicate whether a ticket was waiting
for client input, in testing, ready to put live, etc–all of which
fall under the ‘open’ status.
I actually did go to the code and add the additional states, but
decided not to apply the patch to the live server because it looked
as if it had the potential to make upgrades painful.
In the end, our solution was to add a custom field, ‘phase’, which
holds the additional values. I then modified the template so that you
always see the phase in addition to the status, if it is present.
It actually turned out that this model more accurately represents
how we think about the tickets than additional status entries would,
because for status it is always a progression from new to resolved,
whereas the phase can bounce between different states.
Anyhow, this is just another suggestion on how the different states
could be handled.
My group has been evaluating RT for 2 weeks now, and the only thing we’ve
found that will cause us implementation headaches is the rigid definitions
of the status field. I suspect that the status field is this way, because
alot of the logic flow of a ticket must be based on the status. Is this
assumption correct?
Pretty much. If you take a step back from the process you are working on,
you will probably find the “status” of the process will fit into one of the
broad categories of the ticket status.
After the custom defined fields are added, then have a U/I under
configuration for scrips.
You may want to have a look at Arturius’s work flow based UI.
Any thoughts? I guess at a minimum, I want a way to add or remove
statuses, and connect the logic flow to them.
I would recommend leaving the statuses the way they are and add a custom
field for the specifics you want. For example, if you are trying to use RT
for a provisioning work flow, you would create the ticket with the “new”
status. This might be the first contact with the customer with regard to
the service you are going to provision for them. The status would change to
“open” when sales started working out the details. Your custom field would
be set to “sales.” Once things get worked out from there, the custom field
would get set to “field operations” so the could actually go out and do the
work. But the ticket status stays at “open.” Once the service is
provisioned, you would set the custom field to “billing” and again leave
the status as “open.”
It’s not until billing sends out the invoice that you set the status to
“stalled” to indicate you are waiting for a response from the customer.
Your custom field is still set to “billing.” That way you know that after x
amount of time, billing needs to follow up to find out where their payment
is. Additionally, you could set the status to “stalled” anywhere else in
your work flow, say when your custom field is “sales,” to indicate you are
waiting on the customer. But this time you know it is sales that has to do
the follow up. It shouldn’t be too difficult to get scrip with custom
conditions and actions and the cron tool to do what you need to based on
the relation between the ticket status and your custom field.
Hope that helps.
Michael
Michael S. Liebman m-liebman@northwestern.edu http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”
Actually, not in our case. We’ve had several workflow discussions in house
about this. What happens is a ticket can be stalled, but for what reason, and
custom fields arent available at resolve time, so that workflow is convoluted.
If we did it by custom statuses and expanded ‘stalled’ to mean stalled at the
vendors end or stalled inhouse, or even more granular stalled in house because
of shipping, or because of backorder, or what have you … we’d have a way to
split tickets out that exceeded our SLA, and be able to better explain why to
senior mgt, other than just saying they’re ‘stalled.’ We tried custom fields
for this and that works fine, except for the huge gotcha that the resolve
screens (Listing.html or Update.html) don’t show custom fields!!! So what good
would be a custom field showing a resolve code if you cannot see it without
chunking over to “Basics,” updating that, then sauntering back to Update.html
and resolving. Its a workflow headache I can’t unleash on a busy staff, sounds
like triviality there I am sure, but turning a 1-click resolve into a 3-4 click
resolve detour is just not acceptable, the custom fields needs to be on the
ticket resolve screens, imho.
My group has been evaluating RT for 2 weeks now, and the only thing we’ve
found that will cause us implementation headaches is the rigid definitions
of the status field. I suspect that the status field is this way, because
alot of the logic flow of a ticket must be based on the status. Is this
assumption correct?
Pretty much. If you take a step back from the process you are working on,
you will probably find the “status” of the process will fit into one of the
broad categories of the ticket status.
After the custom defined fields are added, then have a U/I under
configuration for scrips.
You may want to have a look at Arturius’s work flow based UI.
Any thoughts? I guess at a minimum, I want a way to add or remove
statuses, and connect the logic flow to them.
I would recommend leaving the statuses the way they are and add a custom
field for the specifics you want. For example, if you are trying to use RT
for a provisioning work flow, you would create the ticket with the “new”
status. This might be the first contact with the customer with regard to
the service you are going to provision for them. The status would change to
“open” when sales started working out the details. Your custom field would
be set to “sales.” Once things get worked out from there, the custom field
would get set to “field operations” so the could actually go out and do the
work. But the ticket status stays at “open.” Once the service is
provisioned, you would set the custom field to “billing” and again leave
the status as “open.”
It’s not until billing sends out the invoice that you set the status to
“stalled” to indicate you are waiting for a response from the customer.
Your custom field is still set to “billing.” That way you know that after x
amount of time, billing needs to follow up to find out where their payment
is. Additionally, you could set the status to “stalled” anywhere else in
your work flow, say when your custom field is “sales,” to indicate you are
waiting on the customer. But this time you know it is sales that has to do
the follow up. It shouldn’t be too difficult to get scrip with custom
conditions and actions and the cron tool to do what you need to based on
the relation between the ticket status and your custom field.
Hope that helps.
Michael
–
Michael S. Liebman m-liebman@northwestern.edu http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”
Thanks for detailing the needs of many of us. I think if RT is to be an
easy to use product for main stream, it needs to address this workflow
issue.
I don’t think that the 6 provided status types will ever fit each
organization, and it needs to be customized for each organization.
Has anyone scoped out how much work this would require? What I’m asking
for is the ability to add and remove status types that affect workflow.
Or, as Dave just pointed out, put the custom fields on the resolve
screens. Maybe this is more of a U/I issue than a workflow issue…
Actually, not in our case. We've had several workflow discussions in house
about this. What happens is a ticket can be stalled, but for what reason, and
custom fields arent available at resolve time, so that workflow is convoluted.
If we did it by custom statuses and expanded 'stalled' to mean stalled at the
vendors end or stalled inhouse, or even more granular stalled in house because
of shipping, or because of backorder, or what have you ... we'd have a way to
split tickets out that exceeded our SLA, and be able to better explain why to
senior mgt, other than just saying they're 'stalled.' We tried custom fields
for this and that works fine, except for the huge gotcha that the resolve
screens (Listing.html or Update.html) don't show custom fields!!!! So what good
would be a custom field showing a resolve code if you cannot see it without
chunking over to "Basics," updating that, then sauntering back to Update.html
and resolving. Its a workflow headache I can't unleash on a busy staff, sounds
like triviality there I am sure, but turning a 1-click resolve into a 3-4 click
resolve detour is just not acceptable, the custom fields needs to be on the
ticket resolve screens, imho.
My group has been evaluating RT for 2 weeks now, and the only thing we've
found that will cause us implementation headaches is the rigid definitions
of the status field. I suspect that the status field is this way, because
alot of the logic flow of a ticket must be based on the status. Is this
assumption correct?
Pretty much. If you take a step back from the process you are working on,
you will probably find the "status" of the process will fit into one of the
broad categories of the ticket status.
</pre>
After the custom defined fields are added, then have a U/I under
configuration for scrips.
You may want to have a look at Arturius's work flow based UI.
</pre>
Any thoughts? I guess at a minimum, I want a way to add or remove
statuses, and connect the logic flow to them.
I would recommend leaving the statuses the way they are and add a custom
field for the specifics you want. For example, if you are trying to use RT
for a provisioning work flow, you would create the ticket with the "new"
status. This might be the first contact with the customer with regard to
the service you are going to provision for them. The status would change to
"open" when sales started working out the details. Your custom field would
be set to "sales." Once things get worked out from there, the custom field
would get set to "field operations" so the could actually go out and do the
work. But the ticket status stays at "open." Once the service is
provisioned, you would set the custom field to "billing" and again leave
the status as "open."
It’s not until billing sends out the invoice that you set the status to
“stalled” to indicate you are waiting for a response from the customer.
Your custom field is still set to “billing.” That way you know that after x
amount of time, billing needs to follow up to find out where their payment
is. Additionally, you could set the status to “stalled” anywhere else in
your work flow, say when your custom field is “sales,” to indicate you are
waiting on the customer. But this time you know it is sales that has to do
the follow up. It shouldn’t be too difficult to get scrip with custom
conditions and actions and the cron tool to do what you need to based on
the relation between the ticket status and your custom field.
I’m far from an RT expert, but I’ve certainly poked through
some of the code. My guess is that as long as the status-changing
workflow is controlled by code, then removing status types
is very risky, and adding them is possible but could involve
a fair amount of work. (Risky == lots of work to adapt to
new releases.)
You could, however, “remove” some of the offending status
values by not displaying them in parts of the gui. That
ought to be fairly safe.
I don’t know what Jesse’s plans are, but 3.2.0rc1 clearly shows
he is adding flexibility. If more of the internal workflow
were to be put under control of scrips, there might come a time
when changing existing status values (and associated workflow)
would be safe, and maybe even gui-controlled to some extent.
I have to ask about your use of “mainstream”. My guess is that
no matter what RT is or becomes, there will always be mainstream uses
where it is almost good enough. Bug reporting, inventory control,
calendar/to-do lists, archiving of work done, planning of workflow
for large projects, integration with other databases, generalized
document workflow, etc. Good as it is, it can’t become everything
Actually, not in our case. We’ve had several workflow discussions in house
about this. What happens is a ticket can be stalled, but for what reason, and
custom fields arent available at resolve time, so that workflow is convoluted.
We’ve solve this problem with patch to RT WebUI which allow set CFs on
update page. Jesse said that this aproach has some hidden problems, but
we still use it because we need it.
Jesse, could you please comment on patch, what problem could happen with it?
If we did it by custom statuses and expanded ‘stalled’ to mean stalled at the
vendors end or stalled inhouse, or even more granular stalled in house because
of shipping, or because of backorder, or what have you … we’d have a way to
split tickets out that exceeded our SLA, and be able to better explain why to
senior mgt, other than just saying they’re ‘stalled.’ We tried custom fields
for this and that works fine, except for the huge gotcha that the resolve
screens (Listing.html or Update.html) don’t show custom fields!!! So what good
would be a custom field showing a resolve code if you cannot see it without
This also solvable and folks here sent patches that add CF values in
ticket listings.
We’ve added several status types here, and changed the logic to them a bit
as well - and it was relatively simple and doesn’t patch any of the core
code - it’s done via scrips or the ‘local’ directory.
For example, to define a new set of statuses, put this in
RTHOME/local/lib/RT/Queue_Local.pm:
use strict;
no warnings qw(redefine);
use vars qw(@STATUS@ACTIVE_STATUS@INACTIVE_STATUS $RIGHTS);
comment/correspondence doesn’t open a stalled ticket
owner comment/correspondence doesn’t open a pending ticket
I rearranged the main menu to separate lists into new/open, pending,
stalled, parked, and ones I requested
I created RTHOME/local/lib/RT/Action/AutoOpen_Local.pm and added a new
’Prepare’ sub which takes care of #1 and #2 #3 is simple copies and edits to RTHOME/local/html/Elements and
html/index.html
Done.
We use ‘pending’ to mean ‘pending customer correspondence’ and ‘stalled’ to
mean 'not enough time to work on this right now’
I want comments/correspondence to open pending tickets (aka a customer sends
something back in, so it’s not pending anymore)… but not to stalled tickets
(aka I or someone else makes a quick note, but it’s still a stalled item).
The changes I’ve made aren’t lengthy, so if something major changes in the
RT API that would break my code (doubtful), it’s not much work to adapt it.
I’ve happily upgraded throughout the RT3 series w/out issue, and the RT2 to
RT3 upgrade wasn’t horrible either.
senior mgt, other than just saying they’re ‘stalled.’ We tried custom fields
for this and that works fine, except for the huge gotcha that the resolve
screens (Listing.html or Update.html) don’t show custom fields!!! So what good
would be a custom field showing a resolve code if you cannot see it without
chunking over to “Basics,” updating that, then sauntering back to Update.html
and resolving. Its a workflow headache I can’t unleash on a busy staff, sounds
like triviality there I am sure, but turning a 1-click resolve into a 3-4 click
resolve detour is just not acceptable, the custom fields needs to be on the
ticket resolve screens, imho.
We’ve had this problem as well. My usual suggestion is to use the jumbo
view, because that does allow manipulation of custom variables. It’s not
perfect, however.
What I plan to do, when I get a chance, is modify the ‘resolve’ link
to display the jumbo view after changing jumbo to handle the ‘DefaultStatus’
argument. I’d also like to add a few extra submit buttons, and move the
comment section to higher in the page.
because we need it.