Your logs will tell you what mode you're in when the AL fires. That might help illuminate the issue.
Have you tried playing with the execution order of your Active links? Put the "$OPERATION$ != QUERY" one in front of the other one. That way you know you are in QUERY mode and the AL should fail. The next AL will succeed and do your search. Thad Esser Remedy Developer "Argue for your limitations, and sure enough, they're yours."-- Richard Bach "Kaiser Norm E CIV USAF 96 CS/SCCE" <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" <[email protected]> 11/26/2007 12:20 PM Please respond to [email protected] To [email protected] cc Subject Re: PERFORM-ACTION-APPLY Weirdness (UNCLASSIFIED) >I would avoid the wide open $OPERATION$ != QUERY because it will probably get you into trouble. There are lots of different states associated with the $OPERATION$ keyword. Thanks, but I want the workflow to fire in each of those states *other* than QUERY, so my qualification is fine. Really that's not the issue. The issue, in my mind, is that workflow continues processing despite the mode change...which I suppose isn't wrong, per se, just not what I expect. Perhaps what I need to do is put a hidden display only field on the form that gets set when the operation is begun and prevents the second AL from firing. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of FRANK, GORDON CTR DISA JSSC Sent: Monday, November 26, 2007 2:01 PM To: [email protected] Subject: Re: PERFORM-ACTION-APPLY Weirdness (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE That sounds right. You did move it to a MODIFY state after the modify. I would avoid the wide open $OPERATION$ != QUERY because it will probably get you into trouble. There are lots of different states associated with the $OPERATION$ keyword. For grins, try $OPERATION$ != GET or SET on the second one. I'm curious if it does the same thing? Gordon M. Frank DISA\Version FNS -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kaiser Norm E CIV USAF 96 CS/SCCE Sent: Monday, November 26, 2007 2:47 PM To: [email protected] Subject: PERFORM-ACTION-APPLY Weirdness ** Hey everyone...check this out: Let's say I have a form with two fields on it: Last Name and First Name. Now let's suppose that if I'm in SEARCH mode and I type a last name in the Last Name field and press <ENTER> I want Remedy to go out and pull up all the tickets where the Last Name = whatever I typed in the field. However, if the form is open in MODIFY or NEW mode and I type in a last name and press <ENTER> I want it to do a lookup of my customers form and fill in the Last Name and First Name of the customer in the customer form that matches. In summary, if in SEARCH mode and I type a last name and press <ENTER> I want it to execute a search. If in MODIFY or NEW, I want it to do a lookup and SET FIELDS. OK, easy enough. I create an AL that fires only if $OPERATION$ = QUERY. That AL does a simple PERFORM-ACTION-APPLY, which effectively is supposed to simply click the SEARCH button. Then I create an AL that fires only if $OPERATION$ != QUERY. This is the AL that does the lookup against my customer form and sets fields. Easy, right? Well here's where it gets weird. The PERFORM-ACTION-APPLY seems to throw a monkey wrench into things. Remember, both ALs are triggered by pressing <ENTER> (Return) in the Last Name field. If I'm in SEARCH mode, and I type a last name and press <ENTER>, my first AL should fire but my second should not. But believe it or not, the second one fires! The way it behaves, it seems as if the Return event (pressing <ENTER>) carries over to *after* the form mode is changed from SEARCH to MODIFY. So pressing <ENTER> triggers the first AL, which does PERFORM-ACTION-APPLY, which executes a search and displays the results pane. Then the second AL fires because it "sees" the <ENTER> event even *after* the search is conducted and the form mode has changed! Weird. Any thoughts on this? Thanks, Norm __20060125_______________________This posting was submitted with HTML in it___ Classification: UNCLASSIFIED Caveats: NONE ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" ***IMPORTANT NOTICE: This communication, including any attachment, contains information that may be confidential or privileged, and is intended solely for the entity or individual to whom it is addressed. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message is strictly prohibited. Nothing in this email, including any attachment, is intended to be a legally binding signature.*** _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
