Form validation

[chris_k]

Within a scoped application, what is the best method of performing form validation (client or server side), to prevent form submission

I will supply 2 use cases:

the below refers to a custom (and scoped) app, where we have extended the task table, with the table(s) we are accessing correctly setup to permit access from all application scopes. With the user on the record form, performing updates. The task will have been created via a separate, automated process. We are not accessing the record via Service Portal. sample URL: https://<instance>.service-now.com/nav_to.do?uri=<task-table_name>.do?sys_id=aa3192cf4f7843004e16afee0310c785

Use Case 1:

- Checking if a form has an attachment on update of the record

  - this would be done via a business rule or client side glide record against sys_attachment table

Use Case 2:

- Checking if date/time fields are correct, eg not in past, compare against a schedule.

  - would be done in a glideAjax via client side, or business rule

Methods that we are blocked from using:

- Client side glide record

      - would be used in a client onSubmit script

      - unsupported in application scope

- Synchronous glideAjax

      - would be used on a client onSubmit script

      - unsupported in application scope

- current.setAbortAction(true)

      - in a business rule

      - unsupported in application scope

[chris_k]

Hi David,

Within a scoped application, as I understand it:

1. ACLs would prevent the read/write of a field, not necessarily if the content of that field is correct/accurate on update of a record
2. Data Policies again would assist with read/write/mandatory of a specific field
3. Business rules cannot be used as current.setAbortAction(true) is unavailable
4. Client Scripts (onSubmit) also cannot be used due to inability to use synchronous glideAjax or GlideRecord

              - We could use onChange client scripts with async ajax, clearing the field value and adding a form message, we have this in place at a few areas, but clearing a value creates frustration for the users

While I have used a few workarounds, it seems so far that there are no (in application scope) methods of preventing a form submit where we need to use GlideRecord or server side API.

[Dave Smith1]

Business rules cannot be used as current.setAbortAction(true) is unavailable

I wasn't aware of that.   Could you put the condition in a condition field higher up, or is the criteria too complex for one field?

Also, what if you simply use return false; rather than current.setAbortAction() to prevent further processing?

Given that a BR is supposed to act as a record interceptor (or DB trigger) I'd be surprised if there's no way of halting further processing.

[chris_k]

Returning false in the business rule didnt appear do anything.

while we CAN use a condition, and the "Abort Action" (this works), the conditions do not give us the control we need to stop the transaction.

- we can check for date/time, but not if it is at or before "now", we can only get as close as 1 minute before or after.

- we cannot check other records on the same or another (unrelated) table. eg scheduling conflicts

- we cannot check if current has attachment.

although...it occurs to me now that perhaps if we create a script includes, and have the condition of the Business Rule use this, so we can use the "Abort Action" tick box on the Business Rule form, which does work within application scope.

            - this seems to be adding quite some complexity just to workaround an inability to use current.setAbortAction(), but at least it will work within the application scope.