AbortSubmit.js rule problem

[DanR.]

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?

[JoeBartlett]

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?

[DanR.]

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.

[JoeBartlett · Accepted solution]

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.

[JoeBartlett]

I might not have been clear enough so here are a couple scenarios where my modified rule will fire:

Scenario 1)

- Comments is blank

- Status is N/A

- User makes an edit to the item but only changes another field, leaving the others with their original vlaue and will cause the trigger to fire.

Scenario 2)

- Comments has a value

- Status is N/A

- User clears the Comments field and this will cause the trigger to fire.

Scenario 3)

- Comments has a value

- Status is 'Something Else'

- User edits the item and changes Status to 'N/A'

- The trigger will not fire here.

Scenario 4)

- Comments is blank

- Status us N/A

- User edits one or both of the Comments/Status fields to give them a different value.

- The trigger will not fire here.

I hope that helps shed some light on the rule logic.