[rt-users] Custom Field issue

[Kenneth Crocker]

John A. Walker wrote:
> OK ... We are running RT 3.4.5 and I'm having trouble trying to 
> achieve something that we want to do.  I think I'm close but I just 
> need a little help to get over the edge.
>
> Basically, for specific queues, we have a custom field that contains a 
> list of users.  The list of users is a list of people that can approve 
> tickets.  When a user is selected an approval ticket is generated for 
> the specified user.  If no one is selected (no value) then it creates 
> the ticket normally.  This part works fine.
>
> We realized that if someone might create the ticket initially not 
> thinking that it needs to be approved and then discover that it 
> approval is required.  We wanted to make it so a user could go back 
> and select an approver and generate the approval request as it would 
> if it were done at the original creation of the ticket.
>
> What I was thinking I could do is compare the old value of the custom 
> field with the current value of the custom field and if they had 
> changed I could return 1 and run the approval template.  If this can 
> be done, I would also want to check to see if the new value was "no 
> value" and if it were then I would return 0.
>
> I have searched the archives and can come up with stuff that is close 
> but nothing that actually does a check on the old value of a custom 
> field within the scrip.  Part of the problem is that I'm not entirely 
> sure what the proper syntax of referring to the fields and their 
> values.  So if there is some place that can give me a break down of 
> how to do this that would be great.
>
>
> Here is the contents of the User Defined Condition as it works on the 
> creation of a ticket:
>
> if (($self->TransactionObj->Type eq "Create") and 
> ($self->TicketObj->FirstCustomFieldValue('Approval required by:') =~ 
> /\w/)) {
>      return 1;
> }
> return 0;
>
>
> Here is the contents of the template that is called by the above scrip:
>
> ===Create-Ticket: manager-approval
> Subject:     Approval of { $Tickets{'TOP'}->Subject() }
> Queue:       ___Approvals
> Type:        approval
> Owner:       { $Tickets{'TOP'}->FirstCustomFieldValue('Approval 
> required by:') }
> Depended-On-By:  { $Tickets{'TOP'}->Id() }
> RefersTo:    { $Tickets{'TOP'}->Id() }
> Content:     Please review and approve this request.
> ENDOFCONTENT
>
>
>
> I was attempting to add further checks in the scrip that basically 
> look to see if the transaction type is not equal to "Create" .  If 
> that was the case then I would look at the custom field value 
> ('Approval required by:') and see if it had changed.
>
> I sure hope someone has something I can run with.  I don't even have 
> to have the complete answer.  Just point me in the right direction.  
> Any help would be greatly appreciated.
>
> Thanks
> John
>
> _______________________________________________
> 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
>
>
> We're hiring! Come hack Perl for Best Practical: 
> http://bestpractical.com/about/jobs.html
>
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