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

[Ankur Bawiskar]

Hi Chris,

For attachment validation although you cannot use gel() and GlideRecord() in scoped app there is a workaround for this

1) Create an update set in global scope

2) Create catalog client script onSubmit in Global scope in the above update set and check for attachment mandatory on form submission and it will stop form submission in Service Portal as well

Script:

var sys_id = gel('sysparm_item_guid').value;

      var attachment = new GlideRecord('sys_attachment');

      attachment.addQuery('table_name','sc_cart_item');

      attachment.addQuery('table_sys_id',sys_id);

      attachment.query();

      if (!attachment.next()) {

              alert("Please add the vendor file as attachment");

              return false;

      }

      return true;

Same goes for the Second requirement. have catalog client script in global scope and do glide ajax and use synchronous.

Mark Correct if this solves your issue and also hit Like and Helpful if you find my response worthy based on the impact.

Thanks

Ankur

[chris_k]

Hi Ankur,

Thanks for that.

In the end, I did have to use a global scoped client script/business rule. This post was written after I had implemented this workaround. (i use g_form.getUniqueValue() to get the sysid on client side though)

But at best, this would be a workaround. And kind of defeats the purpose of having an application scope. Surely there is a best practice way of doing this in a scoped application.

Note: I have already lodged an enhancement request to be able to perform a synchronous GlideAjax call for just this reason.

[Ankur Bawiskar]

Hi Chris,

ServiceNow has stopped support of gel(), DOM and GlideRecord in client side because of performance reason. not sure how they can help in this regards.

Also if you want to have the requirement achieved you will have to use workaround.

There are quite a few things in ServiceNow which could not be achieved directly for which workaround exists to achieve that.

Mark Correct if this solves your issue and also hit Like and Helpful if you find my response worthy based on the impact.

Thanks

Ankur

[Dave Smith1]

Chris Kortman wrote:

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

First question is: what are you actually validating?   Most people wish to validate values against specific fields.  

Methods available are:

1. ACLs prevent unauthorised changes to specific fields
2. data policies set fields mandatory (can't be empty) or unique (prevent collisions)
3. business rules can apply field content checks post-submission but pre-capture.   It won't stop erroneous data being specified in the field, but will prevent it from being saved when "Submit"/"Save"/"Update" is clicked
4. client scripts give instant feedback (so displays before form submission) but are bypassed when data is being supplied without using that form.

That's a prioritised (ordered) preference list. Client scripts are the "most friendly", but being much closer to the user also require more maintenance overhead.   I try to go for rulesets closest to the data where possible.