User table field view

[Cirrus]

Good afternoon,

This is probably pretty basic but I just wanted to check. I need to add two fields to the sys_user table which only show when company is X. UI Policy, all good.

Now I want to set it up such that if the company is X, only users with role Y will see these two fields displayed when they look at a user record.

I tried adding a script condition gs.hasRole("role Y") to the said UI policy, but no joy. Any user with access to the user table can still see these fields.

We have a minefield of ACLs associated with sys_user, such that if I create read and write ACLs for role Y against the two fields, again any user can read and write, but before I tackle this aspect of the build, I just wanted to check if I am right in trying to achieve the display aspect through a UI policy?

Thanks

[Cirrus]

So, I have added the two fields to sys_user, and created two write acls to sys_user.field1 and sys_user.field2 for users with the role x. The problem seems to be that we have one other write acl on the table scripted as:  

Description: Users with no role cannot update any user record but their own

Roles Required: SNC_INTERNAL

Script: 

if (gs.getUserID() == current.sys_id || gs.getUser().hasRole("y"))
answer = true;
else
answer = false;

This ACL appears to trump all others, and is preventing write access to the whole form, including the two new fields, for users with role x. If I create a new ACL on the table just for role X then the user can update all fields, which is a big no no.

Any suggestions on how to overcome this?

[Brian Lancaster]

Looks like this was an OOB rule that was modified if the name is sys_user.*.  It should not have any roles listed and should only have the script of.  

if (gs.getUserID() == current.sys_id || gs.getUser().hasRoles()) 
    answer = true;
else 
    answer = false;

[Cirrus]

And herein lies my problem. We added role Y as we have a requirement to allow our servicedesk access to the sys user table. This sits alongside the acl on sys_user* which has the code you mention above. 

[Brian Lancaster]

everybody has read to the sys_user table by default. OOB users with a role have access to all records read only.  So you should not have had to add role('y') as gs.hasRole cover all roles.  Also once you give specific read access it should overwrite the ACL for everybody else.  Can you share you read roles for the fields only certain users should have access to or did you only create write ACLs.

[Cirrus]

Brian, 

Thanks for your help on this. The reason for having role Y in the script is because servicedesk agents with this role need the ability to create or update existing user records. If I remove it, they can no longer do this in a call handling situation (its to do with a customized integration of users and contacts in our deployed solution, whereby all contacts are created as users and we use class to set them as contacts....long story!). However, they have no direct access to the Organisation/Users module and so dontsee the additional two fields anywhere, so no issue with this aspect. Its currently the only write ACL on the table.

The read ACLs are OOB I think -

sys_user*, role = snc_internal and script as per your previous entry.

sys_user, role snc_internal, no script

Our user with role Z can read the user table, including their two additional fields, but cant write to any of it, despite having the two write acls for the two new fields. If I am interpreting you correctly - "once you give specific read/write access (role Y) it should overwrite the ACL for everybody else" - I can overcome this by adding role Y and role Z to the write acl script, but then role Z users have full write acess to all fields, which is the bit I am trying to overcome. Only role Y is allowed that.

So without creating individual write ACLs for each field for role Y which is just ridiculous, I need to find a way to give role Z users write access to just these two fields and nothing else on the table. Do I have to start looking at a client script?