I’m taken over delopment of upgrading/modifying RT in our security shop.
I upgraded successfully to 3.6.1 with apache 2.0.58, php 5, mod_perl
(adjusted webmux.pl), and so on. Now working on the mods. I’ve
already found the way to include “pending customer” as one of the
options on the main page (i.e. new, open, pending customer) as
requested by my managers.
i’ve received some other, very unusual requests. The most curious one is
to create a new queue (easy), that is populated automatically by
tickets upon resolution.
This queue will be called something like “peer review”. Resolved
tickets aren’t actually resolved, they are automagically placed in this
queue, where a peer must review the ticket first before resolution.
Weird, eh?
Now, it may be that a queue is not the optimal solution. Maybe a
new category, like new, open, review, pending customer.
However, I’m thikning that a queue, called Peer Review, can be populated
automagically upon resolution via a custom scrip, which dumps all resolved
tickets into the queue, and if the peer determines something additional
must be done, can choose to reopen the ticket.
Am I on the right track here?
Thanks folks. Any advice is much appreciated.
However, I’m thikning that a queue, called Peer Review, can be populated
automagically upon resolution via a custom scrip, which dumps all resolved
tickets into the queue, and if the peer determines something additional
must be done, can choose to reopen the ticket.
Am I on the right track here?
Thanks folks. Any advice is much appreciated.
You want to look into approvals. See the wiki and list archives for details.
Regards,
Harald
Harald,
I may be wrong, but I think that the RT "Approval" method changes the
ticket number. To us, it seems more prudent to keep ticket numbers
constant throughout it’s journey to being “Resolved”. So, we created an
“Approval” Queue, which is administrated by a group that reviews
requests before they can be taken and reviews test results before th
ticket can be resolved. We created a couple new status’s (“pending rv”,
“rq approvd”, “qa approvd”, “rejected”) and use these statuses in
combination with some CF’s and scrips to initiate correspondence to
allow tickets to be reviewed, taken, assigned, worked on, tested, and
finally resolved. The scrips check various CF’s and the status field
before it will allow certain status changes to complete. That way we
have a complete audit trail of the movement of a certain ticket number
throughout it’s movement from new to resolved. It’s not as cumbersome as
the RT method either.
Kenn
LBNL
Wagener, Harald wrote:> Am 21.09.2006 19:11 Uhr schrieb “Judson Main” jmain@ssmg.org:
However, I’m thikning that a queue, called Peer Review, can be populated
automagically upon resolution via a custom scrip, which dumps all resolved
tickets into the queue, and if the peer determines something additional
must be done, can choose to reopen the ticket.
Am I on the right track here?
Thanks folks. Any advice is much appreciated.
You want to look into approvals. See the wiki and list archives for details.
Regards,
Harald
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Thanks.
I’ve spent some time reading the Approvals link over and over, and it’s clearly not
what I want. I need something on resolve only - or something different from
resolve, but unfortunately, I can find no way to adjust new, open, update, resolve
choices within RT without major hacks. Not a pretty thing.
I may, of course, be wrong about this, but our choice here is to have the analyst
work the ticket to the point of completion, and then, and only then, have another
analyst check their work.
Right now, the optional plan is to send an e-mail on resolved tickets either for
the day, or for the week, which the recipients can then review. This may be the
simplest and easiest to implement.
Feel free to kick this newbie in the butt if he ain’t reading the Approvals section
right - even if this newbie isn’t a newbie, but a multi-decade veteran! 
Jud.
On Fri Sep 22 3:21 , “Wagener, Harald” sent:
Interesting. I’ve been under the impression that it’s very difficult to
change the status’. Changing them in the actual perl is not something
I’m fond of, but did, successfully, but that was a replacement, not
an addition.
Would you be so kind as to point me towards a scrip or other type
of plugin that I could use for this? I believe it would help for my
problem.
Thanks much,
Jud.On Fri Sep 22 13:20 , Kenneth Crocker KFCrocker@lbl.gov sent: Harald, I may be wrong, but I think that the RT “Approval” method changes the ticket number. To us, it seems more prudent to keep ticket numbers constant throughout it’s journey to being “Resolved”. So, we created an “Approval” Queue, which is administrated by a group that reviews requests before they can be taken and reviews test results before th ticket can be resolved. We created a couple new status’s (“pending rv”, “rq approvd”, “qa approvd”, “rejected”) and use these statuses in combination with some CF’s and scrips to initiate correspondence to allow tickets to be reviewed, taken, assigned, worked on, tested, and finally resolved. The scrips check various CF’s and the status field before it will allow certain status changes to complete. That way we have a complete audit trail of the movement of a certain ticket number throughout it’s movement from new to resolved. It’s not as cumbersome as the RT method either. Kenn LBNL Wagener, Harald wrote:
Am 21.09.2006 19:11 Uhr schrieb “Judson Main” jmain@ssmg.org>:
However, I’m thikning that a queue, called Peer Review, can be populated
automagically upon resolution via a custom scrip, which dumps all resolved
tickets into the queue, and if the peer determines something additional
must be done, can choose to reopen the ticket.
Am I on the right track here?
Thanks folks. Any advice is much appreciated.
You want to look into approvals. See the wiki and list archives for details.
Regards,
Harald
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com