.Custom Validation v2020.4

Basics

The feature allows the Admin to define customized Validation routines on any table. These routines can be executed before Saving or Deleting records on any table. The validation routines can also target specific records in the table the validation is assigned to.

This Grid will allow Users to add Custom Validation routines to Save and Delete actions on the application data.

• Description: A description field to provide an identifying name for this validation routine.
• Table Name: The Database table name to which this validation is be applied.
• Table Record: The specific RECID number that should be validated. Leave this blank to apply the validation to all records.
• Action: Save or Delete options specifying the table action that should be validated.

CAUTION: When creating Custom Validations, it is better to have a handful of large Custom Logic than it is to have numerous amounts of short Custom Logics defined for your Organizations Custom Validations. This is because as the number of Custom Validations that trigger on the same form increases, application performance begins to suffer, and can eventually start risking application timeouts. It is also important to ensure the same Custom Logic is not running multiple times on the same records as this also will reduce application performance if a large number of records undergo this same change at once, such as the case with any Validations that might trigger from a Service Desk Action. The performance issue originates from the delay in starting a new validation after one executes. When this delay occurs multiple times during the execution of an extended task, such as completing a large number of Service Desk Actions, this can push the process to take too long and trigger application timeouts.

Logic tab

The Logic tab is where the Custom Logic can be written and reviewed.

A User can quickly review the code written for the specific event with the  button.

Users will be limited to the white-listed functions for PHP in PCR-360. A list of the functions can be seen in PCR-360 by clicking on the button.

Debug tab

The Debug tab shows the results of debug function calls. This debug information is cleared after 24 hours.

Prerequisites

This feature is intended for Administrators and an understanding of PHP language and syntax is Required. You must also be aware of language compatibility for the version of PHP installed on the webserver. For validation that requires querying other data, an understanding of SQL is necessary, particularly variants specific to your database platform.

Usage

In a typical validation routine, some Boolean condition is tested, and FALSE is returned if it fails. Returning false at any time during the routine will stop the routine processing and cause the validation to fail, preventing the Save or Delete. Before the return, an error message should be set to provide feedback to the Users.

Scope

Validators are written and executed within a subset of PHP syntax, and at run time they have scope access to three arrays of data $data, $params, and $user. For security purposes, only a subset of PHP functions has been whitelisted.

$data

A key/value paired array of data that is being sent to the database.

'Save:' The array contains the actual data that is being saved to the database. There will be a key/value pair for every column that is being passed to the SQL insert or update command, keys matching the actual table column names. The array will always contain a RECID index. For updates, this will be an integer value. For inserts, it will be the string “addNew”.

In this example, the "RECID" index in the $data array is used to determine if this Save is adding a new record.

if($data["RECID"] == "addNew"){

'Delete:' The array is a listing of integer RECIDs for all the records that will be deleted from the table. It is an array of arrays the inner level being key/value pairs corresponding to column names and database values for the records that will be deleted.

$params

A key/value paired array of parameters that were passed to the Save or Delete functions. This parameter array will be different from form to form and Grid to Grid. Since the validation happens on the table level, it is not good to rely on this data unless the use-case depends on only validating interactions from a specific source.

In this example, an "isCompletion" index in the $params array from the Service Desk Action form is used to determine if this save is completing the Service Order Action. Since we cannot rely on these indexes always being present, we use the isset() check to look for the existence before checking the value.

if(isset($params["isCompletion"]) && $params["isCompletion"] === true){

$user

A key/value paired array of User information about the currently logged in User. The example below shows options that are available in this array.

$user = [
     'isSysAdmin' => TRUE
     'isCoordinator' => FALSE
     'isCustomerCenterOnly' => FALSE
     'attributes' => [
        'CONTACTS_RECID' => 1
        'NAME' => 'Pcr Demo'
        'FIRST_NAME' => 'Pcr'
        'LAST_NAME' => 'Demo'
        'DEPT_HIERARCHY_RECID' => NULL
        'TENANTS_RECID' => 0
        'EMAIL' => 'demo@pcr.com'
    ]
]

Syntax of Validations and Building Queries

Custom Validation shares a set of common syntax and available functions with the other types of Custom Logic. There are also various built-in functions to assist in querying data in order to do the lookups validations require.

Content

There's no easy way to monitor Custom Validation for output, especially while writing the code for it because there's no "real" data to pass through the code when it is being written.

Here are a couple of options, one of which is fairly easy but doesn't show the actual data being validated, the other is more involved, but makes it possible to observe actual data that goes through the code that is being written.

Note: Too many different "Call" methods contained within Custom Validations may cause timeouts

Data Dictionary

If only the key names of the $data array are of interest, that is always the database row that is being validated. The columns that belong to the table can be found in the Data Dictionary by navigating to "Admin > Data Dictionary"

Look up the table that the code is being written for, the column names are the keys that are expected to be seen in that variable, this will enable references to them to be made in the code. For example, SERVICES:

Then write PHP code for the check desired.

if ($data['BILLABLE'] == 0) {
// Set an error because Services aren't Billable, or whatever...
}

This approach doesn't let you view real data, though. 

• Not ALL column/value pairs are always included. Some inserts and updates omit columns that have defaults or are left unaltered in a given process.
  • The User writing the validation should monitor the data in order to observe what is being passed through.

Data Monitoring

If the data that is being checked needs to be seen, so that an idea what it looks like as it's being processed can be viewed, multiple browser tabs will be needed.

1. Custom Validation - see the code being written
   • Navigate to "Admin > Custom Logic > Validation" to view the records.
2. Form the Validation runs against (example from above, Service Form)

3. In the Custom Validation code, add this to the top:

   $dataMap = [];
   // Covers undefined variable bug - $data IS defined during execution
   if (!isset($data)) {
   $data = [];
   }
   foreach ($data as $column => $item) {
   // Replace strings for values that don't convert well
   // switch isn't naturally type-strict, so the cases need to be.
   switch (true) {
   case $item === null:
   $item = 'null';
   break;
   case $item === true:
   $item = 'true';
   break;
   case $item === false:
   $item = 'false';
   break;
   case $item === '':
   $item = '{empty string}';
   break;
   }
   $dataMap[] = $column . ' => ' . $item;
   }
   $this->setError(implode("<br>", $dataMap));
   return false;

4. Once that's added to the CV code, go to the Form where the CV is applied. Save the record.

The $data variable's contents should be displayed on a dialog message:

This can also be done for $params or $user.

Error Messages

Once a Custom Validation has been triggered, regardless of what data input method triggers the Validation, a message will be reported back to the User identifying itself as a result of Custom Validation. The first part of the error will display the name of the organization to help identify that the error was a Custom Validation and not one of the standard errors from the application. The message from the Validation will appear after the name.

These two functions setError() and setWarning() can have a number of different returns. In addition to the type of message set, the return will also determine behavior. The following table explains the expected results of using either function and the return values. In the table, "not-false" means any return that is not Boolean false. False-ish values (0, empty string, etc.) do not count.

Function

Return

Result

setError()

false

setError()

not-false

setWarning()

false

setWarning()

not-false

setError() + setWarning()

false

setError() + setWarning()

not-false

What this means is that the return dictates whether the action passes (false: no, not-false: yes)and what dialog type Users get (false: error, not-false: warning). Messages just correspond to the type of return sent.

For all of the following examples, a Custom Validation was written to require a Reference on all Services.

Forms

 If a Custom Validation is triggered while using a given form, the message will appear in the following manner:

Imports

When a Custom Validation is triggered during an Import the message will be output into the Imported Records grid as an Error. The message content from the Error will appear in the 'Error Description' column of the grid.

To see the errors, navigate to Admin > Imports/ Exports: Import Files > Imported Records.

API

Custom Validations returned from the API will return a status of "failure" and the Customer Validation message.

Custom Validations can also be configured to call the API to create other application records.

// set the save data
$payload = [
    "type" => "IN",
    "csr" => "1",
    "owner" => "1",
    "owner_type" => "contact",
    "prob_code" => "1",
    "description" => "Sample Validation to create an Incident"
];

$this->call("saveServiceDesk", $payload);

return true;

The above example is for how a User might create a Custom Validation to call the Service Desk API endpoint, and create an Incident. For more information on API functionality see that API Articles in this wiki.