A Groovy Tip For User-Specific Fields

A common request from our clients is preventing certain users from editing certain fields. This task is fairly simple for custom fields, but requires a slightly more robust groovy expression for native fields. A special case to be aware of is when more than one user role should have editing capability. In this use case, the script must validate the current user’s security role against multiple criteria. A common pitfall when writing this expression is calling the current user role multiple times to check for a match with different access permitted roles. This seems to be the obvious strategy.

 

An example of this logic would read something like:

 

if(adf.context.getSecurityContext().isUserInRole(‘ZBS_SALES_ADMINISTRATOR_JOB’) ||

adf.context.getSecurityContext().isUserInRole(‘PermittedRole2) ||

adf.context.getSecurityContext().isUserInRole(‘PermittedRole3))

               {

                              return true

               }

               else

               {

                              return false

               }

 

Did you know this simple groovy could be slowing your system down? In the script above, the system is invoking the API on every instance of “adf.context.getSecurityContext()”. Instead of calling the current user role every time, we can call it once and store that value locally as a variable. The variable is then compared to the permitted roles as if they were a list of values. The improved groovy script would read something like:

 

def userRole = adf.context.getSecurityContext();

 

if(userRole.isUserInRole(‘ZBS_SALES_ADMINISTRATOR_JOB’) ||

userRole.isUserInRole(‘PermittedRole2’) ||

userRole.isUserInRole(‘PermittedRole3’))

               {

                              return true

               }

               else

               {

                              return false

               }

 

Although this is a simple code improvement, it cuts out 2 API calls. When this type of validation may exist for many fields, on many objects, the number of API calls can build up quickly and slow system performance for your users. This is particularly true since these validations are “run-time” validations, meaning they are triggered by user actions and occur in the background while a user goes about his or her daily routine. Luckily, a simple code clean up here can put your UI in good shape. 

 

This is just one way to save you time and potentially speed up system performance. To read more articles on groovy tips, check out our blog and type 'groovy' in the search bar.