[rt-users] Approvals for resolved tickets?

Benjamin Weser weser at osp-dd.de
Wed Feb 20 11:08:50 EST 2008


Hi Samuel,

Since the built-in approvals didn't work for me I changed the workflow 
in RT that only a group of RT-users (in our case "project managers") 
have the right to change the ticket status directly. They are also 
responsible for assigning tickets (I removed the "Take") to developers 
and make the final appove and set the ticket to resolved. Developers can 
change the ticket status only indirectly using a custom field called 
"Development Status". I introduced new ticket statusses in_review, 
reviewed and completed and the above mentioned custom field "Development 
Status" with the values "In review.", "Review done.", "Work in 
progress.", "Work done." for that.

The lifetime of a ticket in our setup looks like that:
1) The requester creates the ticket. (Status=new, Owner Nobody)
2) Only members of the group "Project manager" are able to assign 
tickets to developers, so this is the first step of our approvals. 
Before assigning the tickets to somebody they can check and modify all 
entries (especially custom fields about priority, software release etc.) 
or clarify some facts with the requestor first. After assigning the 
ticket to a developer the ticket will get the status in_review then.
3) The developer will make an assumption about the effort of solving the 
request. After that he sets the CF "Development Status" from "In 
review." to "Review done." The ticket status will change indirectly to 
reviewed, "Nobody" will become Owner again so that the ticket will 
appear at the list of unowned tickets again.
4) The "Project manager"s turn again: They have to assign the ticket to 
a developer who should resolve it now. (Status=open, Owner=developer)
5) The developer will solve the request, sets the ticket status 
indirectly to "completed" using CF "Development Status" (change from 
"Work in progress." to "Work done."). In this case the developer will 
stay the owner of the ticket.
6) Now it's the turn of the project managers again. They finally have to 
decide if the ticket is resolved or not. Usually we have two kind of 
tickets: incidents and requests. Incidents are set to resolved as soon 
as possible and the requester will be informed via email then. Requests 
are usually collected and rolled out in a bunch with a patch or new 
release. All affected tickets will set to resolved then. But this 
decision is made by the project manager. They also can reassign a ticket 
to a developer if the work isn't finished yet, a bug was found or 
whatever and the requestor wouldn't notice at this point.

Maybe this sounds all a little bit complicated but it prevents 
developers from setting a ticket accidentally to resolved without 
permission from the management. Steps 2 and 3 are optionally and project 
manager can always reset the actual status to a different one. All this 
works with a bunch of scrips with custom conditions.

You don't have to set it up that complicated but maybe it gives you an 
idea that it's possible to work with a kind of approvals besides the 
built-in approvals and maybe you can catch it up and use something 
similar for your system.

Ben

 
Samuel P. Howard schrieb:
> Hi Kenn,
>
> At this point, we aren't using Approvals at all, so the answer about ANY 
> ticket is "sorta" ... we do have a few queues that we don't want to know 
> about ... we have other partners using queues in our RT implementation, 
> so we'd probably have to do a user defined condition, I suppose.
>
> I guess one of our questions was, can the Approvals feature be used for 
> the end of a ticket's life (onResolve), rather than the beginning 
> (onCreate)?
>
> Also, just doing an onResolve scrip, I didn't see an easy way to send 
> the response output (template, et al) to a specific user (who is not in 
> the AdminCC or any other list associated with the ticket) ... is there a 
> good example somewhere I could borrow from?
>
> Thanks,
> Sam
>
> Kenneth Crocker wrote:
>   
>> Samuel,
>>
>>
>>     Do you want to alert billing to ANY ticket that gets resolved, 
>> regardless if it was in the Approvals queue or not? if so, a simple 
>> scrip with the "onResolve" condition would do it. However, if you have 
>> other conditions you want considered, you will need to make that 
>> condition "User-defined" and put in your specific perl code for your 
>> other conditions. You could also create a special template for this 
>> particular notification which would include the pertinent ticket info 
>> so that person wouldn't have to go to RT and hunt up the ticket, etc.
>>
>> Kenn
>> LBNL
>>
>> On 2/19/2008 9:47 AM, Samuel P. Howard wrote:
>>     
>>> Hi.
>>>
>>> In order to help our billing person, I am trying to find a way to 
>>> alert her when a ticket gets resolved.  I've come up with a few 
>>> options, and would like some thoughts, opinions, suggestions, etc:
>>>
>>> 1 - Write a custom scrip that e-mails her upon Status -> Resolved
>>>
>>> 2 - Try to convince the Approvals feature to work on Ticket Resolved, 
>>> not Ticket Created
>>>
>>>  From these, the pros and cons so far:
>>>
>>> 1:
>>>   pros: should be pretty easy to implment
>>>   cons: piles of e-mail in her inbox
>>>   cons: the data is outside of RT, so hard for someone else to step 
>>> in if she goes on vacation, gets sick, etc
>>>
>>> 2:
>>>   pros: if it can be done, it should give a nice view via RT (single 
>>> location to go to for the data)
>>>   cons: can Approvals be convinced to work on Status->Resolved?
>>>
>>> Right now, we have a custom field that is used in a report to find 
>>> tickets that have not yet been billed, but there are a few problems 
>>> with this.
>>>
>>> 1 - no timely notification (i.e. she has to run the report daily and 
>>> try to figure out what's different to review each ticket for complete 
>>> data needed to do the billing)
>>> 2 - if the custom field "accidentally" gets flipped, the ticket never 
>>> shows in the report, so it never gets billed or accounted for.
>>>
>>> Hopefully, this gives some idea of what we are trying to achieve.  
>>> Suggestions welcome!
>>>
>>> Thanks,
>>> Sam
>>>
>>> _______________________________________________
>>> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>>>
>>> Community help: http://wiki.bestpractical.com
>>> Commercial support: sales at bestpractical.com
>>>
>>>
>>> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
>>> Buy a copy at http://rtbook.bestpractical.com
>>>
>>>       
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
> Community help: http://wiki.bestpractical.com
> Commercial support: sales at bestpractical.com
>
>
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
> Buy a copy at http://rtbook.bestpractical.com
>   




More information about the rt-users mailing list