[rt-users] SetPriority oddities.

Kenneth Crocker kfcrocker at lbl.gov
Tue Jun 29 13:01:17 EDT 2010


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.


On Tue, Jun 29, 2010 at 6:41 AM, Marc Andersen <maa at govcert.dk> wrote:

> Hash: SHA1
> 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
> - --
> Marc Andersen
> IT Security Analyst
> The Danish GovCERT
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> OTkwTKZDOaxXg29y7XQ8bp36ulB28SWKLRycnXsuw5+UCRvIEtyrdf8E7vra9exB
> ljKyos/13IvvI7oRcWSOvtB4tBxXH2Bd14h7gOZ9UhX3MKyQCdSZAhEl0t2CGhKd
> 4vb9ie0fCcY+k0TAZd5mtMYZUR4w5CH7t99hUe2TIwpRjNmzx6pzyVGkC8Nl8+ym
> 0eKw4h26WEvOEHsPHVNWXT/iWo3/0UjrPV/r5vNSA9R+dhfPf5BBfw6dp+6N1zyL
> XCPpTXXP/KHscRvmjws9GpouhDw5cdobXBqlX0zfMdd7kFDuFggOjpeGsiMBsmQ=
> =ZDm1
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
> Buy a copy at http://rtbook.bestpractical.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20100629/8aad18e7/attachment.htm>

More information about the rt-users mailing list