Default versus calculated field values

It is an easy mistake to make, to think that giving a table column (AKA field) a default value, and giving it a calculated value, have effectively the same result. However, this is not the case. Default and calculated values behave quite differently, and should be used for quite different purposes.

In this section, we'll explore what each are (and are not) meant to be used for, and the difference in behavior between them. We'll also discuss field calculation scripts, and best practices regarding default and calculated fields.

Default values

Default field values can be quite simple: a string, an integer, or whatever data-type matches the field's type.

Default values

You can get a fair bit more advanced with it though, by using the javascript: keyword in the beginning of your value similar to the way we can run scripts in the condition builder. Any code after the javascript: would be executed on the server when the form loads, or when a record is inserted into the database (but not when updated) without a value in that field.

Default value scripts will have access to the current object, but remember that on a new record form, the default value is calculated on the server, before/while the form is loaded. At that time, there is no data in the current object.

If there is no value in the field when it is inserted into the database, then the default value will be applied. However, if any value exists in the field when the record is created, the default value is not calculated or used.

Given that, in addition to on insert (as long as the field is blank on insert), the default value is also calculated in order to be displayed in the new record form, consider the following code:

javascript:'Record created by ' + gs.getUser().getDisplayName() + ' on ' + current.getValue('sys_created_on') + '.';

By using the current object in the above code in the Default value field, when the form loads, we're getting a blank value for the sys_created_on field, but the rest of our code still executes. Thus, on the new record form, we'll see a default value like this:

Record created by John Smith on .

Note the lack of the expected creation date in the default value string.

If we were to erase this value on the new record form or leave it blank by creating the record in a way that doesn't use the form (such as via a script or through list editing), then the default value would be re-evaluated on insert, at which point there would be a current object for it to reference, so we would get the expected output. However, if we load the form, get the value with the missing creation date, and then save it, then the incorrect value will be saved to the database. The default value will not be re-evaluated on insert, because the field would now have a value in it!

Tip

Pro Tip

When creating a new record from the form, the default value will be pre-populated in the field to which it applied (as we learned above). However, you can prevent this from happening so that the default value only puts data into the field on insert (and not on the new record form) by checking if the current object is populated. Here is an example using the same code as above, but wrapped in a conditional block that should cause it to only populate the default value if the record is being inserted into the database (when the current object is available):

javascript:if (!current.sys_created_on.nil()) { 'This record was created by ' + gs.getUser().getDisplayName() + ' on ' + current.getValue('sys_created_on'); }

This behavior is what fundamentally separates the default value functionality from the calculated field functionality.

Calculated values

While default values apply only on form load or on insert, and are not re-evaluated if the field is updated later or if the value changes, calculated fields always apply, and are re-evaluated whenever the record is updated. Also, while a field's default value may be scripted using the javascript: keyword, calculated fields are always scripted.

To enable setting a field as calculated, begin by loading the Advanced view of the field dictionary record by clicking on the Advanced view UI Action:

Calculated values

Next, go to the Calculated Value form section, and check the Calculated checkbox. This will enable the field calculation script editor:

Calculated values

Calculated field values do have access to the current object (just like default value scripts), but since they are re-evaluated whenever the record is updated, it's less of an issue that the current object is empty when loading the new record form.

Even though it would be changed once submitted, it's best to avoid a user seeing null in a calculated field on the new record form. It's often a good idea to put in some filler text to be displayed if the current object is empty, or even leave the field blank before it's submitted, as you can see in the following example script:

(function calculatedFieldValue(current) {

   var userName, updatedDate;
   if (current.sys_created_on.nil()) {
      return '';
   }
   var grUser = new GlideRecord('sys_user');
   if (grUser.get(gs.getUserID())) {
      userName = grUser.getDisplayValue();
      updatedDate = current.getValue('sys_updated_on');
      return 'Record updated by ' + userName + ' on ' + updatedDate + '.';
   }

})(current);
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.222.125.171