John A. Walker wrote:
Kenn - Thanks for taking the time to respond. It is greatly
appreciated. Let me explain a little more and then you can let me
know if what you're doing would still apply. In essence we were
wanting the user, as they create the ticket, to be able to select the
person that needed to approve the ticket. We did this by creating a
custom field with the list of users that can approve a ticket. Once
a user creating the ticket selected a person to approve, the ticket
create process would also create the approval request for the person
selected as the approver.
I can't tell for sure but I'm thinking that you have a certain group
of users that are allowed to look in the approval queue and users
simply submit approvals into this queue? If I've misunderstood how
your situation works let me know. Perhaps what you are doing would
work for our situation. The key to our situation is the need to have
a ticket creator be able to select the user they want to approve a
ticket. If that can be done with your method and you have the time
please give me a little more detail.
Thanks again.
John
John,
You seem to have gone to a lot of work to get some form of
approvals going with certain people being allowed to do that, but it
looks to me like you went the long way around the barn. Without ANY
PERL scrips or anything, I have a Queue set aside for approvals, it
receives requests by any group (of users) allowed or the group that
"supports" (Approvals-Support) with the right privileges can create,
own, whatever the needs are to/for a request. Then when approved,
they (the approvers) merely change the owner to "nobody" and change
the Queue to where the requests belongs. Everything is in history
under the same ticket number (great for auditors). By creating all
this code, you may have created a house of cards that will be
difficult to maintain, whereas by using RT as-is, we have much less
maintenance to perform. Think about it. I really have no advice to
give about all the extra code.
Kenn
John,
Yes, you are partially correct. We have a queue whose sole purpose
is to filter request for several other support queues. We don't allow
the users (or requestors) to create tickets in the technical support
Queues directly, only to the Approvals Queue. The members of the group
that has been assigned privileges for that Approval Queue (like owners,
create (a sub-ticket) or in some cases, like a training issue or
permissions, they even resolve the ticket and the ticket never goes on
to our technical support Queue) all know what type of tickets to deal
with. The difference from your understanding is we don't let the
requestor select the person who will approve the ticket. We have a group
of approvers (in a group assigned privileges to the Approval Queue) who
already know what they can work on/approve. If a ticket for Accounts
Payables shows up in the Approvals Queue, a member of our
Approvals-Support Group KNOWS he has been assigned to work with AP so he
will see the ticket when he checks the approvals Queue and TAKE the
ticket, based on what he reads in the subject matter or based on the
requestor name. Now he owns it and researches the problem and either
resolves the problem (training issue or whatever) or he realizes that
this request needs technical support. So he then makes a change to the
STATUS field (we put in a change and added some new statuses like "rq
approvd", "rejected" (you're only allowed 10 characters for that
field)), changes the owner to "nobody" (we tried to create a scrip to do
this automatically upon Queue Change and couldn't get it to work
correctly so we have the approver do it manually right now until we can
get the scrip to work properly), then the approver changes the Queue to
the appropriate Technical Support Queue, in this case the "AP" Queue.
Then the "AP-Support" group or AdminCc of the "AP" Queue sees the ticket
in their Queue and either the AdminCc assigns an owner or one of the
technicians that are members of that support group takes the ticket and
it gets worked on. We like this method better than the built in RT
Approvals work-flow because all the history stays with the original
ticket number (and we have been seeing ALOT of e_mails from users having
difficulty in getting the RT-Approval function to work, plus the
RT-Approvals functon sets up a "hidden" approval queue for "each" Queue
and creates a new ticket when approved and we like the flexibility of
being able to set up a visible Approval Queue that can handle the
requests of many support queues - without being hidden). This is also
perfect for our auditors. They actually smile when they see this history
all on one ticket. We also like this design because it uses the basic RT
functionality without a lot of extra scrips being written (and therefore
maintained). I've been in this business (Data Processing, I know - old
term) for over 35 years and if I've learned anything, it's that the less
you complicate something, the easier it is to run, maintain, and debug.
"simpler" is just better, at least for me. Anyway, thats the way we do
it and it's working just fine. Our users love it because they can still
monitor the progress of their request from waiting for approval to being
moved to a technical Queue for work, to resolution, the Technical
support group assigned to the Queue that handles the work for "AP" like
it because they aren't bothered by a bunch of requests that are not
technical and can be handled by a Business Analyst, and our Auditors
love it because all the history is there under 1 ticket number.
Anyway, that's what we have created by design. If this is something
you think will work for you, great. It certainly does for us and as I
said, it's a lot simpler.
Kenn
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
We're hiring! Come hack Perl for Best Practical:
http://bestpractical.com/about/jobs.html
