I want to check that a certain custom field is defined when a user tries to resolve a ticket. If it is not defined, I don’t want to allow the resolve to proceed, and I want to show a status message to the user letting them know that the resolve failed because they need to provide a value for this custom field.
I can detect whether the CF has a value, but I can’t figure out how to prevent the resolve or display a message to the user in the Results area. I did figure out that I could just set status back to open in my scrip action, but unfortunately the Results area still reads “Status set from open to resolved” even though the ticket is still open, because the initiating transaction was open → resolved. I cannot figure out how to write into that Results area at all to let the user know the resolve did not work.
Is there any way to abort the attempted resolve transaction if the CF is undefined and leave a message for the user saying why?
Thanks,
Fran
Fran Fabrizio
Director of Information Systems
UAB College of Arts and Sciences
HHB560C | 205.996.5698 | fabrizio@uab.edu
I want to check that a certain custom field is defined when a user tries to resolve a ticket. If it is not defined, I don’t want to allow the resolve to proceed, and I want to show a status message to the user letting them know that the resolve failed because they need to provide a value for this custom field.
I can detect whether the CF has a value, but I can’t figure out how to prevent the resolve or display a message to the user in the Results area. I did figure out that I could just set status back to open in my scrip action, but unfortunately the Results area still reads “Status set from open to resolved” even though the ticket is still open, because the initiating transaction was open → resolved. I cannot figure out how to write into that Results area at all to let the user know the resolve did not work.
Is there any way to abort the attempted resolve transaction if the CF is undefined and leave a message for the user saying why?
In Ticket/Update.html, you should look at code that call
/Elements/ValidateCustomFields and do something like this. (i.e. set
check_failure=1; and add you’re message to @results (which will be
displayed to user using /Elements/ListActions like every
information/error messages in RT)).
In Ticket/Update.html, you should look at code that call
/Elements/ValidateCustomFields and do something like this. (i.e. set
check_failure=1; and add you’re message to @results (which will be
displayed to user using /Elements/ListActions like every
information/error messages in RT)).
Great, thanks, that looks very helpful. Can you access @results from a ScripAction? I’ve read elsewhere that it’s not possible. Can you access the $m HTML::Mason request or HTML::Mason components from a ScripAction?
Thanks,
Fran
In Ticket/Update.html, you should look at code that call
/Elements/ValidateCustomFields and do something like this. (i.e. set
check_failure=1;
Looked at this for a couple more hours this afternoon and decided to abandon the ScripAction approach and try to accomplish this via callback instead. Unfortunately, the checks_failure variable is not exposed to any of the callbacks in Update.html like it is in Create.html. That appears to make it very difficult to cause a ticket update to fail from a callback. Is overlaying the entire Update.html file the only way to accomplish this? Was trying to avoid that and the resulting headaches with future upgrades if possible. Any ideas?
Thanks,
Fran
In Ticket/Update.html, you should look at code that call
/Elements/ValidateCustomFields and do something like this. (i.e. set
check_failure=1;
Looked at this for a couple more hours this afternoon and decided to
abandon the ScripAction approach and try to accomplish this via
callback instead. Unfortunately, the checks_failure variable is not
exposed to any of the callbacks in Update.html like it is in
Create.html. That appears to make it very difficult to cause a ticket
update to fail from a callback. Is overlaying the entire Update.html
file the only way to accomplish this? Was trying to avoid that and
the resulting headaches with future upgrades if possible. Any ideas?
exposing check_failure in a callback is a good idea. Can you provide a
patch for this so it will go in RT core?
exposing check_failure in a callback is a good idea. Can you provide a
patch for this so it will go in RT core?
This simple patch was sufficient for me:
— /usr/local/rt/local/html/Ticket/Update.html 2010-08-26 08:25:06.000000000 -0500
+++ /usr/local/rt/share/html/Ticket/Update.html 2010-08-24 08:33:38.000000000 -0500
@@ -168,7 +168,7 @@
my @results;
-$m->callback( Ticket => $TicketObj, ARGSRef => %ARGS, checks_failure => $checks_failure, results => @results, CallbackName => ‘Initial’ );
+$m->callback( Ticket => $TicketObj, ARGSRef => %ARGS, results => @results, CallbackName => ‘Initial’ );
unless($DefaultStatus){
$DefaultStatus=($ARGS{‘Status’} ||$TicketObj->Status());
It might make sense to also expose checks_failure in other callbacks in Update.html, but hooking in at Initial seems pretty flexible on its own.
-Fran
Sorry, I created that patch pre-coffee this morning, and the patch was going backwards. Here’s the real patch:
— /usr/local/rt/share/html/Ticket/Update.html 2010-08-24 08:33:38.000000000 -0500
+++ /usr/local/rt/local/html/Ticket/Update.html 2010-08-26 08:25:06.000000000 -0500
@@ -168,7 +168,7 @@
my @results;
-$m->callback( Ticket => $TicketObj, ARGSRef => %ARGS, results => @results, CallbackName => ‘Initial’ );
+$m->callback( Ticket => $TicketObj, ARGSRef => %ARGS, checks_failure => $checks_failure, results => @results, CallbackName => ‘Initial’ );
unless($DefaultStatus){
$DefaultStatus=($ARGS{‘Status’} ||$TicketObj->Status());
exposing check_failure in a callback is a good idea. Can you provide a
patch for this so it will go in RT core?
This simple patch was sufficient for me:
thanks, applied on 3.8-trunk, will be in next release.