[rt-users] SetPriority oddities.

[Marc Andersen]

Hi Kenn

Thank you for the input. It might very well be some kind of cache problem.
To follow up on the example below where I type in 100 as priority.

By using RT::Logger i see the following:
Jun 30 18:55:34 ubuntu RT: Priority_after_SetPri: 50 ((eval 3725):17)
Jun 30 18:55:34 ubuntu RT: TransPriority_after_SetPri_oldvalue: 50
((eval 3725):18)
Jun 30 18:55:34 ubuntu RT: TransPriority_after_SetPri_newvalue: 100
((eval 3725):19)

The logs are right after the SetPriority method has been called. The
first log line checks what the actual priority is:
$RT::Logger->error("Priority_after_SetPri: ".$self->TicketObj->Priority);

The next two lines I check what the old and new values of the
transactionobject is and was:
$RT::Logger->error("TransPriority_after_SetPri_oldvalue:
".$self->TransactionObj->OldValue);
$RT::Logger->error("TransPriority_after_SetPri_newvalue:
".$self->TransactionObj->NewValue);

So you can see there is some confusion in RT about what the values are.
The priority itself is 50....but the new value of the transactionobject
is 100.

I simply do not know if this will present some problem further down the
road or if I should file it as cosmetic (maybe a bug?).

I guess what I need is a scrip that ignores anything typed into the
priority field in this case (with a more complicated condition check in
the final script).

Any ideas?

Btw: Can anyone reproduce this behaviour?

br
Marc

On 2010-06-29 19:01, Kenneth Crocker wrote:
> Marc,
> 
> I could be wrong but I suspect that what you are seeing after you made a
> change has to do with what is in cache.
> 
> Your scrip code was for "Cleanup" so after RT made your change to 100,
> the "Cleanup" scrip came along and changed it back to 50, but cache
> still has what you TYPED into that field.
> 
> That's my best guess. Hope it helps.
> 
> Kenn
> LBNL
> 
> On Tue, Jun 29, 2010 at 6:41 AM, Marc Andersen <maa at govcert.dk
> <mailto:maa at govcert.dk>> wrote:
> 
> Hi everyone
> 
> I've been trying to wrap my head around RT for a couple of days now
> (actually RT-IR).
> Currently I am trying to add some business logic (yes...scrips :) ).
> 
> I noted some oddities while trying to set my priority field using custom
> fields. I can essentially get it to work, but I have not been able to
> figure out why I run into the problem below.
> 
> So I made up a very simple scrip to illustrate my point:
> 
> Condition: on Transaction
> Action: User defined
> Global Template: Blank
> Stage: Transaction Batch
> 
> Custom action cleanup code:
> $self->TicketObj->SetPriority (50);
> 
> 
> Then I set about to test it:
> 
> 1)
> Create ticket --> ticket gets created and priority is 50.
> 
> 2)
> Edit ticket --> I update anything but the priority in the ticket, just
> to trigger the script. For instance by changing the tickets subject. -->
> Save changes -->  Priority remains 50.
> 
> 3)
> Edit ticket --> this time I update the priority field and set it to,
> say, 100. The expected outcome: priority will be set to 50 by the script
> --> Save changes --> actual outcome: the priority field _seems_ to be
> set to 100, although the script was triggered (confirmed by using
> RT::Logger).
> 
> 4)
> Now this is where I get confused. Somehow, my script was overruled in
> 3). However, as soon as I access the ticket again by navigating to the
> ticket, i.e. clicking on display or selecting the ticket in the left
> menu bar or otherwise navigating around, the priority will be at 50,
> without my scrip running again.
> 
> So my guess is, that my script actually saved the right priority in the
> database, but didn't update some essential object when displaying the
> ticket right after pressing 'Save Changes'
> 
> Does anybody know what is happening here?
> 
> Please bear in mind that the scrip here just illustrates my point and is
> not the actual final scrip I want to use in production (which would be
> setting the priority through several custom fields).
> 
> Hope somebody has an answer.
> 
> regards

Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com





> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
> Buy a copy at http://rtbook.bestpractical.com

-- 
Marc Andersen
IT Security Analyst
Direct: + 45 3545 0164
E-mail: maa at govcert.dk

The Danish GovCERT

Ministry of Science, Technology
and Innovation

National IT and Telecom Agency
Holsteinsgade 63
DK-2100 København O
Tel.: +45 3545 0000
Fax: +45 3545 0010
E-mail: itst at itst.dk
www.itst.dk