get user role in UI Page

[davilu]

Hi, I'm trying to create a UI page that has certain fields readonly based on role.   I have the following code in my client script, but I'm getting errors in my console saying gs is not defined and   $(...).ready is not a function.   Can someone help me debug this?   Am I even on the right track?

var roles = [];

var gr = new GlideRecord('sys_user_has_role');  

gr.addQuery('user', gs.getUserID()) ;  

gr.query();  

while(gr.next()) {  

roles.push({

role : gr.getDisplayValue('role') //Will give the sys_id of the roles  

});

}

if (roles.indexOf('admin')) {

document.getElementById('signature').readonly = true;

document.getElementById('signature').style.backgroundColor   = '#ddd';

}

[Dave Smith1]

David Lu wrote:

Hey Dave, I looked into this briefly, but am a bit confused of how to apply ACL's on specific fields to specific UI Pages. Is there any material on this?

Ah... no.. I may have been barking up the wrong tree here.

If those fields track back to columns in a DB table, then ACLs are your friend.   If they're form fields in a page you've created, that's another matter.

For what it's worth, g_user.hasRole('admin') is often an invalid test because admin has bypass rights to everything, so it's kinda like a lock asking if they hold a skeleton key.   I'd also recommend testing using non-admin accounts, since all bets are off with admin override.

[fredflintstone]

For what it's worth, g_user.hasRole('admin') is often an invalid test because admin has bypass rights to everything, so it's kinda like a lock asking if they hold a skeleton key.   I'd also recommend testing using non-admin accounts, since all bets are off with admin override.

Could you explain this more?   I can't think of any scenarios where g_user.hasRole('admin') would return true for any user that does not explicitly have the admin role.   My understanding was that the admin role can override other roles/ACLs, but other roles/ACLs cannot override admin.   In any case, g_user.hasRoleExactly() ignores the admin override and can be used instead.

[Dave Smith1]

My interpretation of g_user.hasRole('rolename') is g_user.hasRoleExactly('rolename') || g_user.hasRoleExactly('admin') - having the admin role trumps the test.   Many times I've seen it unnecessarily added to ACLs - the "Admin Override" checkbox deals with that.

My warning is simply that users holding the admin role tend to have bypass privileges embedded in the platform in many places that using that role for a test gives unexpected results; it's safer to create another role and use that as a privilege that can be bestowed (via group membership, of course) to permit higher levels of access than giving away admin role.   This adheres to the Principle of Least Privilege.  

Similarly, platform admins don't tend to get involved with the day-to-day BAU activities so it should be considered rare to test if the user happens to hold this role.   Finding a lot of code containing admin checks is indicative of too many users holding this role - and no real security model that honours Separation Of Duties.

[fredflintstone]

Makes sense, thanks for the reply!

[davilu]

Hey Dave, so are you saying if the UI Page field is connected to a column in a table, then if I change the ACL of that column, it will reflect on the UI Page as well?

So if I have a table in the background that has a column for HR Signature and Signature of Employee and I connect it to my UI Page, if I change the ACL for HR Signature to only be writeable for admins, if I impersonate someone who does not have admin rights, then the UI Page would show that HR Signature field as readonly?