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, 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?

That's my understanding.   Generally security applied at ACL level is reflected in forms, lists and in portal pages - I've no reason to believe UI Pages behave any differently (but YMMV - I'm not clued-up on UI Pages, sorry).

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?

Yes. I demonstrate this when teaching Sysadmin - I add a read rule against a field requiring the asset role and someone lacking that role finds it not only has vanished from their form/list, but they can't personalise their form/list and add it back in - it's invisible to them.

Note: again, with the roles, "HR Signature" should have "change" rights for someone with a specific role, not "admin".   Although "admin" can pretty much override anything, from a business point of view you've just delegated out a responsibility to a group of individuals (which may not be their job).   I understand the purpose of hiding it from ordinary users, but also consider whom should see it.

I'd also recommend creating two users for positive and negative testing then logging in as them.   Impersonation doesn't always work in some cases.