[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