Skip to main content
search
ARAS Events

Enable Editable Grids in Aras – Part 2

By August 26, 2021July 16th, 2023No Comments

In my last blog post, I discussed the basic functionality and configuration of Editable Grids, a new feature introduced in Aras Innovator V12sp16. I recommend reading the previous article before continuing if you have not already done so. Just to recap, users can now edit records directly in search and relationship grids.

As an Aras Administrator or Developer, you may have been left wondering, “Can I just enable the grid editing feature? What are the potential impacts?” If you have these types of questions, then I will answer them for you. One of the potential impacts to enabling grid editing is where you have a method written that validates the entered data. Another impact is where the entry of data in one field impacts the data in another field. These situations are addressed with the new client events called Change and Validate that can be hooked on ItemType properties. These events are very useful.  In this article I will provide input on how they work and a few related caveats.

In the Aras Innovator 12.0 Programmers Guide, the new events are referenced as Data Store Events. This could lead to some confusion for those who have been working with Aras for a while. The Data Store is used to sync data across the client environment regardless of the UI control used to expose the data. These new client events are executed on form fields, search grid cells, and relationship grid cells allowing the Administrator or Developer the ability to create a single method that executes when data is edited on any of these controls. This is paramount because if you enable grid editing on an ItemType, you will need to account for existing business logic where the impacted properties can be edited.

Consider an example where we want to enforce that the Change Coordinator cannot be the same as the Managed By user on an ECO. Without regard for grid editing, this validation would typically be handled with server events onBeforeAdd and onBeforeUpdate hooked on the ECO ItemType or with a client event hooked to the onChange event of the Change Coordinator and Managed By form properties. When considering grid editing, if the validation is implemented as a server event, then nothing needs to change as the server event is still triggered when the record is edited in the grid. However, if the onChange methodology is the implemented approach, you will have to make a change in the implementation as the onChange form property events will not execute when the record is edited in the grid. This is where the new Validate event comes in.

The idea behind the Validate event is to hook a method to the Change Coordinator (owned_by_id) and Managed By (managed_by_id) properties on the ECO ItemType. The method performs the validation and prevents the Change Coordinator and Managed By users being the same regardless of how the record is edited (form or grid). This results in one method that performs the validation everywhere the property can be edited and allows you to remove the method from the form properties’ onChange event.

Below is an example of the Validate method for the above scenario.

/* *****************************************************************************
Method Name: RL_validateOwnerAndManager
Created By/Company: phillip.cook/Razorleaf
Creation Date: 2021-08-25
Description: Method modified that validates Change Coordinator(owned_by_id) does not equal Managed By(managed_by_id).

Hooks:
Type: RL Express ECO (property owned_by_id, managed_by_id)
Event: Validate

Revisions:
Rev Date Modified By Description
2021-08-25 phillip.cook Initial creation
***************************************************************************** */
const currentItem = aras.itemsCache.getItem(itemId) || aras.itemsCache.getItemByXPath(`//Item[@id=”${itemId}”]`);
const owner = aras.getItemProperty(currentItem, ‘owned_by_id’, ”);
const manager = aras.getItemProperty(currentItem, ‘managed_by_id’, ”);
const valueID = value.id;

// one or both of the fields may be null
if (value === null) {
return {
valid: true
};
}

if (name === “managed_by_id” && (owner === valueID)) {
return {
valid: false,
validationMessage: `Change Coordinator and Managed By cannot be the same User.`
};
}

if (name === “owned_by_id” && (manager === valueID)) {
return {
valid: false,
validationMessage: `Change Coordinator and Managed By cannot be the same User.`
};

}

return {
valid: true
};

 

Hook the method to the owned_by_id and managed_by_id properties of the ECO ItemType and set the Event to Validate.

Once the method has been created and hooked to the desired properties, you can test the method by editing an ECO in different ways. Open an ECO and try to make the Change Coordinator and Managed By the same user. Note the error returned by the method.

Similarly, when editing the Change Coordinator or Managed By of an ECO in the search grid, the same error is presented to the user.

To illustrate the new Change event, consider an example where a part’s classification drives a prefix on the part’s name property. The following method will add the prefix “SW – “ to the part’s name when the classification is changed to Software.

/* *****************************************************************************
Method Name: RL_addPrefixToSoftwarePart
Created By/Company: phillip.cook/Razorleaf
Creation Date: 2021-08-25
Description: Method to add prefix to Part name when Classification is Software.

Hooks:
Type: Part(property classification)
Event: Change

Revisions:
Rev Date Modified By Description
2021-08-25 phillip.cook Initial creation
***************************************************************************** */
const itemNode = aras.itemsCache.getItem(itemId) || aras.itemsCache.getItemByXPath(`//Item[@id=”${itemId}”]`);
var classification = aras.getItemProperty(itemNode, ‘classification’, ”);
var currentName = aras.getItemProperty(itemNode, ‘name’);

if (classification !== ‘Software’) {

if (currentName.substring(0, 5) == “SW – “) {
var updatedName = currentName.substring(5);
aras.setItemProperty(itemNode, “name”, updatedName);
}
} else {
const prefix = ‘SW – ‘;
if (value.substring(0, 5) === prefix) {
return;
}
aras.setItemProperty(itemNode, “name”, prefix + currentName);
}

Hook the method to the classification property on the Part ItemType.

To test, search for the desired Part to update.

Edit the part search grid, change the classification of the part to the Software classification.

The updated Name will display in the grid.

Right Click and select “Done Editing”.

The Part can also be updated from the Form.

It is important to mention that properties on forms, search grids, and relationship grids cannot be disabled from the new Change and Validate Events.

Consider a situation where you have a method that conditionally sets a field on a form as read only or hides the field, and that field is also shown on the search or relationship grid. After Implementing Editable Grids, that conditional field is always editable in the grid and the Change and Validate events have no ability to prevent it from being changed. However, there are a few options to solve this issue:

  1. Remove the fields from the search and relationship grids. 
  2. Implement a Validate event on the conditional field that detects if the field should have a value and return an error if it should not.
  3. Implement a server-side method hooked onBeforeAdd and onBeforeUpdate that will detect if the condition is met where the field should not be populated and return an error preventing the add/update.

These examples were enhanced from the examples documented in the Aras Innovator 12 Programmer’s Guide. You can find additional information on these events in the guide. If you still find yourself running into questions or issues, our experienced Aras team at Razorleaf is ready to help you through the process, so don’t hesitate to reach out to us

Close Menu