 | ||||
| Part 1 |
Part 2
| Part 3 | ||
Custom "Approve" and "Reject" buttons & beyond
It has always bothered me that the two important buttons "Approve" and "Reject" were colored the same as all other buttons.
Therefore, I wanted to give these buttons the appropriate styles in a customer project, so that the approving users are aided in choosing the right action by color:
But don't worry, this article is not about how to color buttons. That doesn't need to be explained to anyone anymore these days. However, this topic made me look a bit more behind the scenes to understand under what conditions a user is allowed to approve something.
Identify the right OOTB UI Actions
For the further investigations, we have to find out what the respective UI Actions are. Basically there are two approaches:
(1) As a user with admin rights, right-click on the button at the end of the form (this doesn't work for top buttons!) and then select "Edit UI Action":
(2) Go to table sys_ui_action and filter the correct UI Action:
Tough I prefer the first approach, it is helpful to go the second way. You will find a lot of "Approve" UI Actions, that is why it is important to apply the right filters.
Even the first UI Action can be ignored, two additional UI Actions remains. Let's have a look at the second UI Action first, because the condition looks too simple to be true.
The first time I saw this, I thought that one would be a joke! How can this simple status query decide whether a user may approve or not? After clicking around a bit, I found the solution to the riddle in the "Requires Roles" tab:
So be careful when using that list, as it is covered in the OOTB configuration by the "Workspace" tab and roles added here may be forgotten!
As this UI Actions is just for admin users, let's go to the next "Approve" UI Action:
"Requires Roles" list is empty - that's fine. And we can find a new condition "isApprovalMine(current)" which sounds like it could perform the necessary tests. But what is this notation? It cannot be a Script Include as there is no class reference. And the only other way to call central code are "Business Rules".
After executing a global code search, the Business Rule "getMyApprovals" (Sys ID: d59048357f00000101201a5caa73fc8e) was found, which also holds the function "isApprovalMine()". That Business Rule was last updated in 2014 and the code looks rather "old school". After searching around I came across the Script Include "ApprovalDelegationUtil" which seems to have been introduced with the Quebec version and has the description:
This script include contains APIs which act as a wrapper for older approval delegation and granular approval delegation APIs.
Although this Script Include also calls the function "isApprovalMine()" internally, I decided to prefer it.
To approve or not to approve - that is the question!
Later, when discussing licenses with customers, I realized that nowhere in the OOTB codes and conditions there was a query built in to check if the user had the "approver_user" role. And yes, that is right - you can test this out: a user without the "approver_user" role can approve! Really strange!
At page https://docs.servicenow.com/bundle/quebec-platform-administration/page/administer/roles/reference/r_... you can find the following explanation for the "approver_user" role:
Can modify requests for approval routed to them. They also have all capabilities of Requesters.
Note: There is a fee associated with this role. Do not assign it to users without confirming your organization has the appropriate entitlement.
So what does this mean? Does the Approver license no longer exist? Or will simply all users who have ever approved be billed later? To be honest, I don't know! But I wanted to make sure, that only users with an "approver_user" role can approve and that was when I decided to build my own "Approve" and "Reject" UI Actions.
Overriding OOTB UI Actions
The use of the "Overrides" field unfortunately does not lead to the desired result
Have you ever noticed the field "Overrides" at UI Action form?
Basically this field allows us to define a new UI Action without touching the old one and so this approach can save us from unnecessary "Skipped Records" during the next upgrade.
To override the OOTB UI Actions for "Approve" and "Reject" you can do the following:
- Open the OOTB UI Action you want to override.
- Open the context menu and select "Copy sys_id"
- Open the context menu and select "Insert and stay"
- Click on the magnifier icon right beside the "Overrides" field.
- Perform a filter query with the Sys ID from clipboard:
- Select the found record.
- Modify the new UI Action according to your needs.
Besides adjusting the button styles and adding the "approver_user" role to the "Require roles" list, I replace "isApprovalMine(current)" with the mentioned Script Include call:
current.state == 'requested' && (new ApprovalDelegationUtil().isMyApproval(current))
But after testing with a user that does not have the "approver_user" role, the OOTB buttons "Approve" and "Reject" are still offered. What went wrong?
It seems that using the "Overrides" option does not deactivate the overridden UI Action at all. If the condition of the overriding UI Action is not fulfilled then condition of the overridden UI Action is tested. And since the OOTB UI Action do not test for the "approver_role" they win.
The better way of deactivating OOTB UI Actions
The only option left is to deactivate the OOTB UI Actions ("Active" flag is unchecked). Now everything works as expected. A non-admin user without the "approver_user" is not offered the "Approval" and "Reject" buttons. And having that role, the user can see the new colored versions.
