Can I restrict view of application module based on an attribute?

robpickering · ‎10-24-2014

I would like to restrict visibility of an Application Module based on an attribute on the sys_user table, rather than by role.

Is that possible?

I know I could create a new role and assign it to everyone I need to, but I'd prefer to use an existing attribute "u_is_manager" on my sys_user table.

-Rob

Michael Ritchie · ‎10-26-2014

OK here is some example code that may work for you.

Add a new field to the sys_app_module table called Visibility (u_visibility in the database). In my example I made it a choice with 3 values: manager, nonmanager, both.
Set the appropriate values on the modules according to your requirements.
Create a new business rule: System Definition\Business Rules
Name: Navigation Query - or whatever you want to call it
Table: Module (sys_app_module)
Check Active and Advanced checkboxes
When to Run: Before
Check Query Box
Script See below

if(!gs.hasRole("admin") && gs.getSession().isInteractive() && gs.getUserName() != "guest"){


       var qc = current.addQuery('u_visibility', "both");


       qc.addOrCondition('u_visibility', '');


       if (gs.getImpersonatingUserName() != null) {


               gs.getSession().clearClientData('navQuery');


       }


       var navQuery = gs.getSession().getClientData('navQuery');


       if (navQuery == null) {


               var isManager = gs.getUser().getRecord().getValue('u_is_manager');


               if (!isManager) {


                       qc.addOrCondition('u_visibility', 'nonmanager');


                       gs.getSession().putClientData('navQuery', 'nonmanager');


               } else {


                       qc.addOrCondition('u_visibility', 'manager');


                       gs.getSession().putClientData('navQuery', 'manager');


               }


       } else {


               qc.addOrCondition('u_visibility', navQuery);


       }


}

Explanation of the above:

Before query business rules are like ACLs where they can restrict access to data. They are basically filters that are applied when a user does a query.
This code doesn't run if you have the admin role, if this is a web service (nonInteractive), or if the user is guest (meaning the login screen)
So the query doesn't run all the time, I am putting the Is Manager value into a Session variable called navQuery and use it instead of the lookup each time
It adds filters for the Visibility setting first and then I check to see if an admin user is impersonating someone and if so I am clearing the Session value
If the session value isn't set, it does a lookup to see if the user is a manager or not and sets the appropriate condition and sets the session variable.

Hopefully this makes sense. Please reply if not as I am happy to answer questions. I am traveling a little this week so my responses could be delayed.

View solution in original post

k0a1a · ‎06-14-2017

I used this approach to provide different menus for groups of requestors. It worked just fine for a while, but stopped working recently (we're on latest Istanbul patch level). It seems to be related to the way SNOW caches menus, and I suspect it does based on the set of user's roles. Now all my requestors get the same menu, and what they get depends on which requestor accessed SNOW first after cache flush. New menu is built from items visible to this user and is then available to all requestors. (I wish it's that predictable as I described; in fact it's not, so I can't confirm even this, quite pessimistic, diagnosis anyway).

Beware.

hirotosakai · ‎08-01-2017

I faced a similar problem. Nav menu is cached against user role instead of individual user. If the cache exists, no query to sys_ui_module will occur.