[rt-users] Request for comments: Configurable Status

[Brett Barnhart]

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 at futuresource.com]
> Sent: Thursday, June 24, 2004 12:22 PM
> To: Kelly D. Lucas
> Cc: rt-users at 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.  
> 
> > 3) 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 at futuresource.com
> 
> 
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> 
> 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. 
>