Overlapping Business rule and Client scripts

[jeremy_gardner]

Hello,

We have a asset record that contains, among other things, an "assigned to user" field which is a reference to the user table. When editing that user through the form view, a client script gets called that creates and queries a GlideRecord for that user's location and service line (our own custom fields added to user record). It then adds those values to similar fields on the asset record.

I'd also like people to be able to edit the records from the list view. When editing the "assigned to user" field, I was going to create a business rule that gets the user record, creates/queries a GlideRecord, then populates the corresponding location and service line fields on the current asset record.

Each of these parts works fine, however when editing through the form view both the client script AND the business rule get called.

Is there a way to tell the business rule to only fire if the client script did not? Or at least have some logic in the business rule that determines if the update came from the form or list? Something?

The wiki says best practice for both form and list editing is to use client scripts AND business rules, but the business rule wil run on both. What am I missing?

Thanks!
Jeremy

[Mark Stanger]

Hey Jeremy,

My first thought would be to get rid of the client script completely. As a general rule, if you can script it in a business rule instead, you should. If you do need to have it in a client script for some reason then you might have to set up a hidden field on the form that could be set when the client-side action had been completed. Then your business rule could check for the value of that field to see if it should run.

You could also try checking for the action name clicked to submit the record in a business rule. The action name would be present from a form submission, but wouldn't be present from a list submission. I'm not sure if it would work, but it's worth a try.

//Get the 'Action name' value for the UI action clicked
action.getActionName();

[jeremy_gardner]

Thanks Mark! I need to run the client script as well, so I think your suggestion on action.getActionName() is probably what I need. However, I'm getting stuck with some of my logic, most likely due to my lack of javascript knowledge.

I was using 'typeof action' to test if action existed. When record updated through list (ie action doesn't exist), using ( typeof action == 'undefined' ) works just fine. When record updated through form (ie action does exit), then that same statement seems to "hang". None of my gs.log statements afterwards are seen.

HOWEVER, when I change my test to use (typeof [action] != "undefined"), then it works for the form edit but not the list edit. I'm not really sure what type of object/array action is, just testing various things, but perhaps someone might point me in the right direction?

Thanks!
Jeremy

[jeremy_gardner]

By request, adding some additional comments around a business case for doing this.

Use our own internal custom billing fields attached to user records, asset records, etc. When asset is assigned to a user, script will get billing fields from user record and add them to asset record. However, those fields are provided as "defaults" and could be overridden if necessary.

- If done through the form, we want the data to show up on the record when the user is selected so that the data can be verified and changed (if necessary).
- If done through the list, that action can run in the background and update the record.

IE, if you want to accept default codes, you can use the list. If you want to change default codes, you can use the form. We would like to keep the list edit option available so they can do mass assignments, if necessary, however we need the client script for the interactive capabilities.

There are two issues when editing through the form. One is that this logic gets performed twice (once through client script, once through biz rule). The other is that if someone overrides the defaults in the form, the biz rule will still run on update, query the user record (again) and set codes back to the default.

Let me know if this makes sense, or if there's a better way to accomplish this.

Thanks!
Jeremy

If someone edits through form and over

[john_roberts]

Seems like you're also saying....

If assigned to changes and the form gets new user info fields then do nothing.
If assigned to changes from list and new user fields do not change, then update the fields.

So how about a business rule that checks for that?

if (current.assigned_to.changes() && !current.billing_field.changes()) {
   //update the billing fields
}