- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-23-2018 09:02 AM
Dear SN Community -
Hello once again! Here is a dozy (which will be solved in no time!) I want to create a new role that will inherent the same permission as another role, but then limit this new "role" to only see certain records. I have been unable to design this correctly in ACL rules since they are part of that inherited role. Do I (and I would hate this) get rid of that inheritance and just have it as another role with explicit permissions as the best course of action?
Thanks,
Shane
Solved! Go to Solution.
- Labels:
-
Scoped App Development
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-26-2018 04:34 AM
Yeah. My original suggestion or replies didn't work in the end. What did work up and what I ended up doing was to create table level rules [table]. read rules. In one that had "no role" listed in advanced answer = !gs.hasRole('new role'); made it so that that rule prevents things that were not matched. I had to fix a lot of roles to do this, but in the end, success.
The biggest take away is have everything documented so that you can see what is going on.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-23-2018 10:53 AM
As the Role 1 is inheriting all the roles from Role 2 then if you write an ACL to block access on Role 1 will automatically block access to Role 2 also. I would prefer getting rid of inheritance so that you can create two different roles.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-23-2018 05:45 PM
@Abhishek -
So I did end up separating the role inheritance. So that is better, but now that there is an three ACL Roles:
- new role ACL [table name].* read - only certain matching records
- old inherent role [table name].* read - all records
- public and all roles [table name].* read <-- issue I think
So the issue is that last ACL allows all other roles to read this table and the new role is hitting it. One of the issues is that ACL that is "all roles" allows the users to see the issues on a Service Portal so even if they were entering tasks temselves, they could see there enties without any problem even if they were not able to see the issues to "work on them". It's almost like I don't want that last ACL to hit for them if they are in the "agent" view in a way.
I don't know if this is confusing, but let me know!
And if you are asking, this new role does not have [table name].* write. In that rule I have:
- !gs.hasRole('new role') || gs.hasRole('admin')
which prevents them from writing to other entries if they did click on them now. I just don't want them to read it in the list.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-23-2018 06:14 PM
Not sure if I completely understand correctly. You have a 'public and all roles' ACL, which I assume means you want everyone to be able to read all the fields, except users with this new role? In that case do 'answer = !gs.hasRole('new role');' in the public and all roles ACL and delete the other two.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-26-2018 04:34 AM
Yeah. My original suggestion or replies didn't work in the end. What did work up and what I ended up doing was to create table level rules [table]. read rules. In one that had "no role" listed in advanced answer = !gs.hasRole('new role'); made it so that that rule prevents things that were not matched. I had to fix a lot of roles to do this, but in the end, success.
The biggest take away is have everything documented so that you can see what is going on.