SetPriority oddities

RT Users
1

-----BEGIN PGP SIGNED MESSAGE-----
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 :slight_smile: ).

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:

Create ticket → ticket gets created and priority is 50.

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.

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).

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMKff0AAoJEOI5XK2IuGDrhHgH/AwO+91nGJtPuLKyPN0DcKQ3
OTkwTKZDOaxXg29y7XQ8bp36ulB28SWKLRycnXsuw5+UCRvIEtyrdf8E7vra9exB
ljKyos/13IvvI7oRcWSOvtB4tBxXH2Bd14h7gOZ9UhX3MKyQCdSZAhEl0t2CGhKd
4vb9ie0fCcY+k0TAZd5mtMYZUR4w5CH7t99hUe2TIwpRjNmzx6pzyVGkC8Nl8+ym
0eKw4h26WEvOEHsPHVNWXT/iWo3/0UjrPV/r5vNSA9R+dhfPf5BBfw6dp+6N1zyL
XCPpTXXP/KHscRvmjws9GpouhDw5cdobXBqlX0zfMdd7kFDuFggOjpeGsiMBsmQ=
=ZDm1
-----END PGP SIGNATURE-----

2

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
LBNLOn Tue, Jun 29, 2010 at 6:41 AM, Marc Andersen maa@govcert.dk wrote:

-----BEGIN PGP SIGNED MESSAGE-----
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 :slight_smile: ).

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:

Create ticket → ticket gets created and priority is 50.

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.

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).

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMKff0AAoJEOI5XK2IuGDrhHgH/AwO+91nGJtPuLKyPN0DcKQ3
OTkwTKZDOaxXg29y7XQ8bp36ulB28SWKLRycnXsuw5+UCRvIEtyrdf8E7vra9exB
ljKyos/13IvvI7oRcWSOvtB4tBxXH2Bd14h7gOZ9UhX3MKyQCdSZAhEl0t2CGhKd
4vb9ie0fCcY+k0TAZd5mtMYZUR4w5CH7t99hUe2TIwpRjNmzx6pzyVGkC8Nl8+ym
0eKw4h26WEvOEHsPHVNWXT/iWo3/0UjrPV/r5vNSA9R+dhfPf5BBfw6dp+6N1zyL
XCPpTXXP/KHscRvmjws9GpouhDw5cdobXBqlX0zfMdd7kFDuFggOjpeGsiMBsmQ=
=ZDm1
-----END PGP SIGNATURE-----

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

3

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

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

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 :slight_smile: ).

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:

Create ticket → ticket gets created and priority is 50.

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.

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).

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@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@itst.dk
www.itst.dk