Re: [rt-users] SetPriority oddities.
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 50but 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 m...@govcert.dk mailto:m...@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: m...@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 Fax: +45 3545 0010 E-mail: i...@itst.dk www.itst.dk Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] SetPriority oddities.
-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 :) ). 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 -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
Re: [rt-users] SetPriority oddities.
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 m...@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 :) ). 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 -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 Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
