[rt-users] Custom Field issue

[Kenneth Crocker]

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