Request for comments: Configurable Status

RT Users
1

In the traditional RT model, the “Status” field is a simple, limited
list of possible states that a ticket can be in. Roughly: untouched,
active, temporarily inactive, permanently inactive. For more advanced
workflow, we’ve recommended that users create custom fields or use
multiple queues to represent different workflow stages. Of late,
there’s been an upswing in the number of users who would rather simply
modify the existing “status” field.

Would a simple editable per-queue ordered list of possible statuses
(stati?) be sufficient for your needs? Do you need to control which
status transitions are allowed? Do you need to be able to lock down
certain statuses such that they’re only selectable by specific users?

Best,
Jesse
2

Jesse wrote:

Would a simple editable per-queue ordered list of possible statuses
(stati?) be sufficient for your needs?

That would definitely a great first step and would probably be good
enough for most people.

Do you need to control which status transitions are allowed? Do you
need to be able to lock down certain statuses such that they’re only
selectable by specific users?

These things both sound great to me and I would prefer them over the
former option. They would allow much more advanced workflows in RT
(relative to 3.0, I haven’t tried 3.1/3.2). Those are both great from a
quality assurance perspective and might make RT attractive to new
audiences that are also interested in workflow or that would otherwise
choose a commercial package with similar functionality. More
specifically, I can see right now how both of these features would fit
in at my organization and I am certain I would use them.

I wonder if it wouldn’t be a good idea, over the long-term, to continue
rolling more advanced capabilities into custom fields and simply make
Status a custom field that is configured a certain way by default. Of
course, this would involve a lot of work, even figuring out what to do
about indexing Status if it’s just a custom field.

On the other hand, more and more advanced functionality and flexibility
serves to complicate RT and perhaps discourage users that don’t need
such features. I suppose the compromise between flexibility and
user-friendliness lies in pursuing advanced features but having a good
set of common default settings. The most common complaint about RT may
be that setup is complicated (though things seem to be getting better in
this respect all the time); if push comes to shove, it’s probably better
to make RT easier to setup rather than have certain advanced
functionality that a minority of users will leverage.

Just my two cents.

MD

3

As the one that inadvertently started this, I wanted to say that I think the
existing RT statuses are fine, IF “Custom Fields” were available throughout RT
and not just on some pages. This would allow workflow resolve status
customizations to be solved by Custom Fields rather than hardcode server-wide
status changes.

But if there are unforseen issues with that, configurable statuses (per queue)
would be amazing and great, too.

Kind regards,

In the traditional RT model, the “Status” field is a simple, limited
list of possible states that a ticket can be in. Roughly: untouched,
active, temporarily inactive, permanently inactive. For more advanced
workflow, we’ve recommended that users create custom fields or use
multiple queues to represent different workflow stages. Of late,
there’s been an upswing in the number of users who would rather simply
modify the existing “status” field.

Would a simple editable per-queue ordered list of possible statuses
(stati?) be sufficient for your needs? Do you need to control which
status transitions are allowed? Do you need to be able to lock down
certain statuses such that they’re only selectable by specific users?

Best,
Jesse

–

The rt-users Archives

RT Developer and Administrator training is coming to LA, DC and Frankfurt this spring and summer.
http://bestpractical.com/services/training.html

Sign up early, as class space is limited.

4

In the traditional RT model, the “Status” field is a simple, limited
list of possible states that a ticket can be in. Roughly: untouched,
active, temporarily inactive, permanently inactive. For more advanced
workflow, we’ve recommended that users create custom fields or use
multiple queues to represent different workflow stages. Of late,
there’s been an upswing in the number of users who would rather simply
modify the existing “status” field.

Would a simple editable per-queue ordered list of possible statuses
(stati?) be sufficient for your needs? Do you need to control which
status transitions are allowed? Do you need to be able to lock down
certain statuses such that they’re only selectable by specific users?

My opinion:

I think my users would be happy even without queue-based status fields.
They already agreed to the list that we use for status fields, and these
are used by all queues even though the list is not a perfect match for
all queues.

So, a queue-based list of possibilities would be sufficient.

I like the fact that the existing values are also grouped in to
categories, and that these categories can be used to determine the
display. I would prefer that the groups be retained so that I could
modify templates to display depending upon groups, instead of hardcoding
status values in the templates.

For controling which are allowed, or enforcing a certain order, I would
expect to use custom code, although it would be nice to have an example
of how to do this.

I don’t need to restrict values to certain people beyond the existing
‘delete’ restriction, but I can see how some people would. I suspect
there would be the tempatation to roll ‘approval’ in to this section
(that’s certainly our workflow–someone makes a new request, project
manager must appre, developer starts request, project manager tests,
project manager states change can go live, developer puts it live,
project manager checks and resolves request).

  • Ann
5

I’m very new to the system, and not a Perl developer, nor do I want to
be. So, there is a developer on my staff, but his opinion is the less
programming we do, the better the system will be for us. The 2 main
reasons, which I think are obvious:

* Time to deploy
* Less risk involved

system, the better. Also, the more changes we implement at a code level,
the greater chance we have of breaking the system. Especially when we
upgrade or patch modules, etc.

With the above disposition, I favor some sort of menu under Config, that
would allow the following functionality:

* Add or remove status
* OR
* Add or remove a user defined status [I'll call it ticket state],
  and tie it to the logic flow of the ticket

If I could have it per queue, it is the most useful, as our organization
is looking at using it in this way:

  1. Tickets can be generated by a number of groups within [and later,
    maybe outside the company] for the purpose of issue tracking

  2. The owner of the ticket may exchange hands numerous times, depending
    on if the issue is related to:

    • demo/installation [Sales Engineers]
    • system configuration [tech support]
    • enhancements or tech data [prod mgt]
    • bugs [dev/SQL]

  3. So obviously there will be states like fixed, verified, that there
    won’t be for the demo/installation issues. And in product marketing,
    they will have states regarding feature enhancements that other groups
    will not have.

So, with the above in mind, I’m not sure how to best implement it, not
knowing the code internals, but this would be my goal. I’m also planning
to have a custom field for:

* issue category
* issue severity
* issue priority [probably 5 priorities]
* product
* product version
* product serial number
* customer and all customer contact info

So, in this system, we’ll be able to capture the history of:

* specific customers
* specific products [by tracking serial numbers]
* product versions
* where most of our time is spent based on products, categories, or
  customers
* and this will give our sales dept the ability to look in and see
  where issues are with their accounts

So, having said all this, do you think my plans are too all encompassing
for RT?

Any comments welcomed.

kdl

K.D. Lucas
lucaskeli@fastmail.fm

Jesse wrote:

6

Our support group really wanted to do custom status via the status
field, and not by custom fields. Primarily because the custom fields
are not integrated into the search, resolution, report “screens” (as
reported by others). So, either customer status values (which we have
now), or better integration of custom fields would solve that issue.

I’d also like to be able to do scrips based on status changes, which I
think I can do now, but haven’t gotten into scrips that much. It seems
to me that by doing this, you’ve covered the more complex workflow
scenarios, without making it too difficult for beginning users…

Kelly F. Hickel
Senior Software Architect
MQSoftware, Inc.
952.345.8677
kfh@mqsoftware.com

-----Original Message-----
From: Jesse [mailto:jesse@bestpractical.com]
Sent: Wednesday, June 23, 2004 4:09 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Request for comments: Configurable Status

In the traditional RT model, the “Status” field is a simple, limited
list of possible states that a ticket can be in. Roughly: untouched,
active, temporarily inactive, permanently inactive. For more advanced
workflow, we’ve recommended that users create custom fields or use
multiple queues to represent different workflow stages. Of late,
there’s been an upswing in the number of users who would rather simply
modify the existing “status” field.

Would a simple editable per-queue ordered list of possible statuses
(stati?) be sufficient for your needs? Do you need to control which
status transitions are allowed? Do you need to be able to lock down
certain statuses such that they’re only selectable by specific users?

Best,
Jesse

–

The rt-users Archives

RT Developer and Administrator training is coming to LA, DC and
Frankfurt

7

Kelly,

Good point about searching, as that is one key area that my corporate
management will insist upon.

So I’m curious is there is an easy way to search on custom fields?

kdl

K.D. Lucas
lucaskeli@fastmail.fm

Kelly F. Hickel wrote:

8

Kelly D. Lucas wrote:

Kelly,

Good point about searching, as that is one key area that my corporate
management will insist upon.

So I’m curious is there is an easy way to search on custom fields?
Yes, it’s possible.
Request Tracker Wiki

9

I think that RT can be more flexible but not compliacted
by having it use intelligent defaults. That is, deliver what
we have today but with a more flexible code base so that
it can be extended even more easily.

-Todd

10

Custom Fields show up at the search ticket screen (in Refine Search) now, on the
queue I have set up with custom fields “Open Status” and “Resolve Status”.

What we lack imho is once you “update all tickets at once” you cannot change
these custom fields, also when you are resolving a ticket individually, custom
fields don’t appear there either. If we had both of those, leaving the
status arrays alone would be fine for my org’s workflow.

Kind regards,

Kelly,

Good point about searching, as that is one key area that my corporate
management will insist upon.

So I’m curious is there is an easy way to search on custom fields?

kdl

K.D. Lucas
lucaskeli@fastmail.fm

Kelly F. Hickel wrote:

Our support group really wanted to do custom status via the status
field, and not by custom fields. Primarily because the custom fields
are not integrated into the search, resolution, report “screens” (as
reported by others). So, either customer status values (which we have
now), or better integration of custom fields would solve that issue.

I’d also like to be able to do scrips based on status changes, which I
think I can do now, but haven’t gotten into scrips that much. It seems
to me that by doing this, you’ve covered the more complex workflow
scenarios, without making it too difficult for beginning users…

–
Kelly F. Hickel
Senior Software Architect
MQSoftware, Inc.
952.345.8677
kfh@mqsoftware.com

-----Original Message-----
From: Jesse [mailto:jesse@bestpractical.com]
Sent: Wednesday, June 23, 2004 4:09 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Request for comments: Configurable Status

In the traditional RT model, the “Status” field is a simple, limited
list of possible states that a ticket can be in. Roughly: untouched,
active, temporarily inactive, permanently inactive. For more advanced
workflow, we’ve recommended that users create custom fields or use
multiple queues to represent different workflow stages. Of late,
there’s been an upswing in the number of users who would rather simply
modify the existing “status” field.

Would a simple editable per-queue ordered list of possible statuses
(stati?) be sufficient for your needs? Do you need to control which
status transitions are allowed? Do you need to be able to lock down
certain statuses such that they’re only selectable by specific users?

Best,
Jesse

–

The rt-users Archives

RT Developer and Administrator training is coming to LA, DC and

Frankfurt

this spring and summer.
http://bestpractical.com/services/training.html

Sign up early, as class space is limited.

The rt-users Archives

RT Developer and Administrator training is coming to LA, DC and Frankfurt this spring and summer.
http://bestpractical.com/services/training.html

Sign up early, as class space is limited.

The rt-users Archives

RT Developer and Administrator training is coming to LA, DC and Frankfurt this spring and summer.
http://bestpractical.com/services/training.html

Sign up early, as class space is limited.

11

Jesse wrote:

In the traditional RT model, the “Status” field is a simple, limited
list of possible states that a ticket can be in. Roughly: untouched,
active, temporarily inactive, permanently inactive. For more advanced
workflow, we’ve recommended that users create custom fields or use
multiple queues to represent different workflow stages. Of late,
there’s been an upswing in the number of users who would rather simply
modify the existing “status” field.
Jesse, as you can see many users want extended statuses because CFs
aren’t available in places where it should be.

I don’t like idea that somebody can change statuses set.

If it would be then it would be in 3.2.x or even more in 3.4.x, but now
with ‘Advanced RT Search Builder’ we can construct complex queries on CFs.
As I can see it also allow customize output of search results and save
search query.
I think there is few steps needed to meet required flexibilty in this area:

  1. Add ability to modify ticket’s CFs on reply/comment/resolve… actions.
  2. Add ability to put saved searches on own home page.
  3. Add ability to output CFs in search results.

IMHO feature 1) should be in RT in any case.
We use one global CF State with 12 values that is something like
extended status and patch that I sent.

  1. Our supporters pray on it. They change CF State on almost all actions.

  2. Our developers love it. They can stall ticket and set up State =
    ‘Deffered/Later’ to prevent autoopenning. They can change product,
    module or build num where issue was resolved with one click while
    commenting/replying.

  3. I use it because nobody knows in company whether it’s in GUI or in RT
    core bug is :slight_smile:
    …

     		Best regards. Ruslan.
12 
* demo/installation [Sales Engineers]
* system configuration [tech support]
* enhancements or tech data [prod mgt]
* bugs [dev/SQL]

It seems natural to me to arrange queues according to the
people that do the work and get notifications and move
tickets to the appropriate queue for different stages
of work.

  1. So obviously there will be states like fixed, verified, that there
    won’t be for the demo/installation issues.

Can’t you move the ticket out of the queue for the people who fix
or verify once it no longer needs their services? In the appropriate
queue it is either done or not.

And in product marketing,
they will have states regarding feature enhancements that other groups
will not have.

What should happen if you move a ticket into a queue that doesn’t
include it’s current status as one of the choices? Marketing people
generally aren’t going to ‘solve’ a problem of feature enhancements.
You need to push such a ticket to a queue watched by developers and
let them send it back when the marketing people have something to
sell.

One thing I’ve sometimes wanted and haven’t figured out an easy
way to accomplish is to include the current owner or perhaps
all the watchers of the current queue as a cc for notifications
even though the ticket is being moved to a queue that doesn’t
normally include them and it may subsequently have its ownership
changed too. For a single user you could add the email as a
cc but it would be nice to be able to use the same group references
you create for permissions as watchers and add-on cc:'s tied
to individual tickets. Maybe what I’m really asking for in addition
to letting groups be watchers is to to allow a ticket to appear
in multiple queues so instead of moving it out of it’s original
queue for special services you could add it into the queue watched
by others in some workflow step without losing track of it yourself.

In case I’ve missed something, is there currently any way to find
a ticket you’ve pushed to another queue if you no longer own it or
if you weren’t the original owner? Say something comes in to a
support queue that needs development work to fix and is pushed to
an appropriate queue. Is there any way for a different support
person to know if those tickets have had any subsequent activity or if
they are being ignored? Something like ‘search for tickets that were
moved out of the support queue but not yet resolved’? I’d like them
to be generally out of the way while someone else has them but not
completely forgotten.

Les Mikesell
les@futuresource.com

13

Personally, I don’t move tickets around queues unless it was placed
wrongly…

For a given project, I have a project queue, a programming queue, and a
testing queue.

I may not want the original requestor to see all the notes back and forth
about programming and testing. So, I use the dependencies a lot.

A given project will have one project ticket.
Each project will have one or more programming ticket.
Each programming ticket will have a testing ticket.

Part of the reason for this is accountability. I am the project manager, so
I own the project.
However, the programmer is the owner of the programming ticket and I am the
requestor.
The testor is the owner of the testing ticket and the programmer is the
requestor.

If you move the ticket around… you loose that paper trail. Programmer 1
moved the ticket to queue 2… was their part done or did they give up or
something else happen?

I would agree that it would be nice to have “Resolved” have permissions. We
do not allow our programmers to resolve a ticket. The Project manager needs
to do that. We are small enough that we just made the rule and ask people to
follow it, but it isn’t enforcable.

14

I was planning to use [queues] in the following way:

One potential path:
[Sales] <====> [Support] <===> [Dev]

A second:
[Sales] <===> [ProdMgt] <===> [Dev]

Basically, anything could possibly be “fixed” within any [queue] above,
or could be passed on to a different queue for assistance or escalation.
However, it would flow back to the originator for final closure. So
although the owner would change hands, it would go back to the
originator for the final approval of any ticket closure.

So, as long as someone was able to track the , I would think
they would have the ability to see all of the history of any issue that
came in or out of the queue… Is this the way the system works or am I
missing some critical piece of info?

K.D. Lucas
lucaskeli@fastmail.fm

Brett Barnhart wrote:

15

The trouble as I see it with this approach, which we discussed in house, is that
a ticket can get lost fairly easily as it traverses queues. By “lost” I mean
that something entered into one queue by the original requestor will then
get processed through to its ‘pending’ queue, something’s done on it,
then it eventually winds up in the ‘resolved’ queue. But unless you look
for the ticket by “requestor” or by a specific memory for the ticket number,
the ticket has no easy way, by date perhaps, to be located out of a crowd
several days later.

In our workflow, tickets come in from customers, potential customers, or from
other vendors or people we buy stuff from, and the ticket goes into the queue
that it fits for what type of work it is – systems work, dev work, network work
or IT. since a large number of our tickets can require interfacing to vendors
we created a separate queue ‘vendors’ for tickets that were pending waiting for
vendor callback. But this started to be bad, cause Joe creates a ticket on
monday in Systems, and on Tuesday it gets stalled into Vendors, now its thursday
and Joe can’t find his original Systems ticket.

If you see what we mean here…

Thanks, sorry for long winded…

I was planning to use [queues] in the following way:

One potential path:
[Sales] <====> [Support] <===> [Dev]

A second:
[Sales] <===> [ProdMgt] <===> [Dev]

Basically, anything could possibly be “fixed” within any [queue] above,
or could be passed on to a different queue for assistance or escalation.
However, it would flow back to the originator for final closure. So
although the owner would change hands, it would go back to the
originator for the final approval of any ticket closure.

So, as long as someone was able to track the , I would think
they would have the ability to see all of the history of any issue that
came in or out of the queue… Is this the way the system works or am I
missing some critical piece of info?

K.D. Lucas
lucaskeli@fastmail.fm

Brett Barnhart wrote:

Personally, I don’t move tickets around queues unless it was placed
wrongly…

For a given project, I have a project queue, a programming queue, and a
testing queue.

I may not want the original requestor to see all the notes back and forth
about programming and testing. So, I use the dependencies a lot.

A given project will have one project ticket.
Each project will have one or more programming ticket.
Each programming ticket will have a testing ticket.

Part of the reason for this is accountability. I am the project manager, so
I own the project.
However, the programmer is the owner of the programming ticket and I am the
requestor.
The testor is the owner of the testing ticket and the programmer is the
requestor.

If you move the ticket around… you loose that paper trail. Programmer 1
moved the ticket to queue 2… was their part done or did they give up or
something else happen?

I would agree that it would be nice to have “Resolved” have permissions. We
do not allow our programmers to resolve a ticket. The Project manager needs
to do that. We are small enough that we just made the rule and ask people to
follow it, but it isn’t enforcable.

-----Original Message-----
From: Les Mikesell [mailto:les@futuresource.com]
Sent: Thursday, June 24, 2004 12:22 PM
To: Kelly D. Lucas
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Request for comments: Configurable Status

On Thu, 2004-06-24 at 08:31, Kelly D. Lucas wrote:

  • demo/installation [Sales Engineers]
  • system configuration [tech support]
  • enhancements or tech data [prod mgt]
  • bugs [dev/SQL]

It seems natural to me to arrange queues according to the
people that do the work and get notifications and move
tickets to the appropriate queue for different stages
of work.

  1. So obviously there will be states like fixed, verified,

that there

won’t be for the demo/installation issues.

Can’t you move the ticket out of the queue for the people who fix
or verify once it no longer needs their services? In the appropriate
queue it is either done or not.

And in product marketing,
they will have states regarding feature enhancements that

other groups

will not have.

What should happen if you move a ticket into a queue that doesn’t
include it’s current status as one of the choices? Marketing people
generally aren’t going to ‘solve’ a problem of feature enhancements.
You need to push such a ticket to a queue watched by developers and
let them send it back when the marketing people have something to
sell.

One thing I’ve sometimes wanted and haven’t figured out an easy
way to accomplish is to include the current owner or perhaps
all the watchers of the current queue as a cc for notifications
even though the ticket is being moved to a queue that doesn’t
normally include them and it may subsequently have its ownership
changed too. For a single user you could add the email as a
cc but it would be nice to be able to use the same group references
you create for permissions as watchers and add-on cc:'s tied
to individual tickets. Maybe what I’m really asking for in addition
to letting groups be watchers is to to allow a ticket to appear
in multiple queues so instead of moving it out of it’s original
queue for special services you could add it into the queue watched
by others in some workflow step without losing track of it yourself.

In case I’ve missed something, is there currently any way to find
a ticket you’ve pushed to another queue if you no longer own it or
if you weren’t the original owner? Say something comes in to a
support queue that needs development work to fix and is pushed to
an appropriate queue. Is there any way for a different support
person to know if those tickets have had any subsequent activity or if
they are being ignored? Something like ‘search for tickets that were
moved out of the support queue but not yet resolved’? I’d like them
to be generally out of the way while someone else has them but not
completely forgotten.

Les Mikesell
les@futuresource.com

The rt-users Archives

RT Developer and Administrator training is coming to LA, DC
and Frankfurt this spring and summer.
http://bestpractical.com/services/training.html

Sign up early, as class space is limited.

The rt-users Archives

RT Developer and Administrator training is coming to LA, DC and Frankfurt this spring and summer.
http://bestpractical.com/services/training.html

Sign up early, as class space is limited.

16

Personally, I don’t move tickets around queues unless it was placed
wrongly…

Most of ours are ‘placed’ by customers mailing to support aliases and
they generally don’t know if they are doing something wrong (likely)
or the software really is broken (less likely, but stuff happens…).
Different sets of people need to deal with different types of
problems. Probably 90% of the tickets have one question, one answer
and are resolved by the first support person to see them. The others
can be a lot messier and I want to minimize the clutter and
notifications for people who don’t need to see them.

I may not want the original requestor to see all the notes back and forth
about programming and testing. So, I use the dependencies a lot.

We use comments vs. replies to control what the requestor sees but
dependencies might be what I need to hold the view in one queue
while work is completed by another group. If there were a quick
and easy way to create a linked dependent ticket in the other
queue and stall the current one until the child is resolved it
could work. I still think continued correspondence with the
requestor should find its way to both sets of people as work
continues at least as an option. The customer or support person
may come up with a work-around that makes the development job
unnecessary.

A given project will have one project ticket.
Each project will have one or more programming ticket.
Each programming ticket will have a testing ticket.

I take it you don’t create these dozens of times a day, though…

If you move the ticket around… you loose that paper trail. Programmer 1
moved the ticket to queue 2… was their part done or did they give up or
something else happen?

The ticket does show a transaction history, so anytime you can find it
you can see what steps happened in what order. The catch is that you
need to remember something about the ticket to find it after it leaves
your queue - there’s nothing left to remind you that it is not
completed.

Les Mikesell
les@futuresource.com

17

“Kelly D. Lucas” wrote:

Is this the way the system works or am I
missing some critical piece of info?

Suggestion:

Use queues to categorize tickets (e.g. Incident, Request for change, etc)
use ownership (and group membership) for responsibilities and watchers
for access control for other interested parties.
Do not use queues for responsibilities.

Does that help?

Jan

K.D. Lucas
lucaskeli@fastmail.fm

Brett Barnhart wrote:

Personally, I don’t move tickets around queues unless it was placed
wrongly…

For a given project, I have a project queue, a programming queue, and a
testing queue.

I may not want the original requestor to see all the notes back and forth
about programming and testing. So, I use the dependencies a lot.

A given project will have one project ticket.
Each project will have one or more programming ticket.
Each programming ticket will have a testing ticket.

Part of the reason for this is accountability. I am the project manager, so
I own the project.
However, the programmer is the owner of the programming ticket and I am the
requestor.
The testor is the owner of the testing ticket and the programmer is the
requestor.

If you move the ticket around… you loose that paper trail. Programmer 1
moved the ticket to queue 2… was their part done or did they give up or
something else happen?

I would agree that it would be nice to have “Resolved” have permissions. We
do not allow our programmers to resolve a ticket. The Project manager needs
to do that. We are small enough that we just made the rule and ask people to
follow it, but it isn’t enforcable.

-----Original Message-----
From: Les Mikesell [mailto:les@futuresource.com]
Sent: Thursday, June 24, 2004 12:22 PM
To: Kelly D. Lucas
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Request for comments: Configurable Status

  • demo/installation [Sales Engineers]
  • system configuration [tech support]
  • enhancements or tech data [prod mgt]
  • bugs [dev/SQL]

It seems natural to me to arrange queues according to the
people that do the work and get notifications and move
tickets to the appropriate queue for different stages
of work.

  1. So obviously there will be states like fixed, verified,

that there

won’t be for the demo/installation issues.

Can’t you move the ticket out of the queue for the people who fix
or verify once it no longer needs their services? In the appropriate
queue it is either done or not.

And in product marketing,
they will have states regarding feature enhancements that

other groups

will not have.

What should happen if you move a ticket into a queue that doesn’t
include it’s current status as one of the choices? Marketing people
generally aren’t going to ‘solve’ a problem of feature enhancements.
You need to push such a ticket to a queue watched by developers and
let them send it back when the marketing people have something to
sell.

One thing I’ve sometimes wanted and haven’t figured out an easy
way to accomplish is to include the current owner or perhaps
all the watchers of the current queue as a cc for notifications
even though the ticket is being moved to a queue that doesn’t
normally include them and it may subsequently have its ownership
changed too. For a single user you could add the email as a
cc but it would be nice to be able to use the same group references
you create for permissions as watchers and add-on cc:'s tied
to individual tickets. Maybe what I’m really asking for in addition
to letting groups be watchers is to to allow a ticket to appear
in multiple queues so instead of moving it out of it’s original
queue for special services you could add it into the queue watched
by others in some workflow step without losing track of it yourself.

In case I’ve missed something, is there currently any way to find
a ticket you’ve pushed to another queue if you no longer own it or
if you weren’t the original owner? Say something comes in to a
support queue that needs development work to fix and is pushed to
an appropriate queue. Is there any way for a different support
person to know if those tickets have had any subsequent activity or if
they are being ignored? Something like ‘search for tickets that were
moved out of the support queue but not yet resolved’? I’d like them
to be generally out of the way while someone else has them but not
completely forgotten.

Les Mikesell
les@futuresource.com

The rt-users Archives

RT Developer and Administrator training is coming to LA, DC
and Frankfurt this spring and summer.
http://bestpractical.com/services/training.html

Sign up early, as class space is limited.

The rt-users Archives

RT Developer and Administrator training is coming to LA, DC and Frankfurt this spring and summer.
http://bestpractical.com/services/training.html

Sign up early, as class space is limited.

Jan Algermissen http://www.topicmapping.com
Consultant & Programmer http://www.gooseworks.org

18

Suggestion:

Use queues to categorize tickets (e.g. Incident, Request for change, etc)
use ownership (and group membership) for responsibilities and watchers
for access control for other interested parties.
Do not use queues for responsibilities.

I think it makes more sense for the queues to tie to the people
performing the services. Otherwise you’d have to set watchers
on every ticket and people would always have to look through
the ‘wrong’ queues for tickets that might need their service.

The only time it is a problem is when a ticket doesn’t neatly
fit a single category or service and more than one group needs
to work on it. Then you have to make the choice of moving the
ticket to the right people or making the people come get
the ticket - or come up with something better that isn’t too
hard.

Les Mikesell
les@futuresource.com

19

Yes, I think I understand how you would implement and why. I think the
most problematic issue arises is when tickets need to move from one
queue or back again because that is our workflow… by design. Since in
the beginning, we don’t know if a ticket is something simple or possibly
a software, or even later could become a hardware bug. And each of these
queues is a different group of people with different purposes. I think
there are built in users, like originator, that may or may not be
informed when updates happen.

I think the easiest way to do this, is when one owner decides to place a
ticket in a different queue, that they place themselves as a watcher.
And they would remain a watcher until the ticket was completed and came
back to them to verify it was resolved.

Does the logic of the system support this?

kdl

K.D. Lucas
lucaskeli@fastmail.fm

Jan Algermissen wrote:

20

I think the easiest way to do this, is when one owner decides to place a
ticket in a different queue, that they place themselves as a watcher.
And they would remain a watcher until the ticket was completed and came
back to them to verify it was resolved.

Does the logic of the system support this?

Yes, that works and if the owner doesn’t change it still stays
‘visible’ even if no action happens in the other queue. However
if you give ownership to someone in the other queue (which seems
to make sense in terms of screen clutter) you now won’t see it
grow old and moldy when the new owner goes on vacation.

Les Mikesell
les@futuresource.com