Skip to main content
D
DanR.1-Visitor
1-Visitor
May 1, 2013
Solved

AbortSubmit.js rule problem

  • May 1, 2013
  • 1 reply
  • 1886 views

The AbortSubmit.js script that comes with the ALM solution is supposed to abort a submit when the established rule is true. If it is true an error message is displayed of your choosing when you create the pre-trigger. The problem I am having is with the rule I've created. It keeps saying it is true, which essentially displays the error message.

My rule

and

|-or

| |- Comments = - Unspecified -

| |- Comments[New Value] = - Unspecified -

|

|-or

|- Status = N/A

|- Status[New Value] = N/A

Comments field is a longtext data type

Status field is a picklist data type

Using this rule an abort submit error should only fire if the Status=N/A and Comments= - Unspecified - (I.E. the text box is blank). However, it fires every time. Is there something wrong with my rule? Is it possible to check if a text field is blank or empty?

    Best answer by JoeBartlett

    In that case, I would change the rule to be like this:

    and

    |- Comments[New Value] = - Unspecified -

    |- Status[New Value] = N/A

    The [New Value] portion only looks at the the value which the field will have once the edit session is done. This will look at the value whether or not the field has actually been edited so you do not need to check if the field was empty before the edit session.

    In my rule, the trigger will fire if the Comments field was blank and the Status field is N/A when the edit session started, as well as if the user decides to clear the Comments field and set the Status to N/A during the edit session if it was not already. The reason you probably had the trigger fire more often than you expected was because it was also checking the values before the edit session.

    1 reply

    J
    JoeBartlett21-Topaz I
    21-Topaz I
    May 1, 2013

    Hi Daniel, what your rule shows above is "If the Comments field is empty before the edit OR after the edit, and the Status field is N/A before the edit or after the edit". Does this sound like it would always fire in your situations?

    If Comments started as a blank value, it would even fire if you were to give it a value as long as the Status field is or was N/A. I find it very useful to write-up a story version of the conditions I want to enforce and then start building the logic from there. What is the logic you are trying to enforce here?

    D
    DanR.1-VisitorAuthor
    1-Visitor
    May 3, 2013

    I'm trying to enforce the user to enter comments if the status is N/A. So if the comments is blank and the status is N/A the rule is true, thus the abortsubmit script displays the message. What I'm trying to enforce is for the user to enter comments in the comment field when the status is N/A. If the user selects a status of N/A and enters comments, then the rule is false and will not fire. For some odd reason it fires.

    J
    JoeBartlett21-Topaz IAnswer
    21-Topaz I
    May 3, 2013

    In that case, I would change the rule to be like this:

    and

    |- Comments[New Value] = - Unspecified -

    |- Status[New Value] = N/A

    The [New Value] portion only looks at the the value which the field will have once the edit session is done. This will look at the value whether or not the field has actually been edited so you do not need to check if the field was empty before the edit session.

    In my rule, the trigger will fire if the Comments field was blank and the Status field is N/A when the edit session started, as well as if the user decides to clear the Comments field and set the Status to N/A during the edit session if it was not already. The reason you probably had the trigger fire more often than you expected was because it was also checking the values before the edit session.

      Terms & ConditionsAccessibility statement