- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-26-2017 12:52 PM
when user is viewing a list of incidents (or tasks) they will get a message "Some rows removed from this list by Security constraints" What does this mean and how can I figure out what it causing it? We get it on various screens and chalk it up to permissios of some kind but I would really like to know how to get to the bottom of it becuase users who seemingly have the same exact groups and roles are seeing differnt records.... Please help.
Solved! Go to Solution.
- Labels:
-
Incident Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-26-2017 01:06 PM
there are two ways to debug this... quick and dirty and longer/slower...
quick and dirty... go to system security and disable all read rules on the table...
now verify they load ok as the user.
turn the rules back on one at a time and see which one breaks the user
longer slower...
as admin in system security turn on debug security rules.
impersonate the user
now try to load the list view
the bottom of the page will show ALL security rules and the results... look for the one with the red X in the left side <or ones>
the boxes will tell you if it failed on condition, script, roles, or all three.. and you can fix the rule from there...
in a case like this i will generally NOT update the existing rule but create a new read rule to grant access.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-26-2017 12:58 PM
I would review the ACL permission against the tables to see what is required to READ the records. The ACL level permissions are adding this message. Normally a better option would be to look into adding a before query Business rule that would remove the records that a user was not supposed to view if that was the intended outcome.
Example script: A default before-query business rule
To debug the ACLS i would also consider turning on the debug Debug Security under the System Diagnostics Application to help with understanding which rule is triggering the deny.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-26-2017 01:06 PM
there are two ways to debug this... quick and dirty and longer/slower...
quick and dirty... go to system security and disable all read rules on the table...
now verify they load ok as the user.
turn the rules back on one at a time and see which one breaks the user
longer slower...
as admin in system security turn on debug security rules.
impersonate the user
now try to load the list view
the bottom of the page will show ALL security rules and the results... look for the one with the red X in the left side <or ones>
the boxes will tell you if it failed on condition, script, roles, or all three.. and you can fix the rule from there...
in a case like this i will generally NOT update the existing rule but create a new read rule to grant access.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-02-2017 05:25 AM
so we did this and it looks like the vtb_task/read and the vtb_card/read are both returning false for the script
answer = new VTBBoardSecurity().canAccess(current.board);
How can we look at the code in this script - can't seem to find it anywhere.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-03-2017 04:13 PM
The code you are looking for is in the VTBBoardSecurity script include.
canAccess: function(boardRecord) {
// if they are the owner of the board, they can access it
if (boardRecord.owner == gs.getUserID())
return true;
return this.isBoardMemberOf(boardRecord.sys_id);
},
There are several more functions in this script include which are called from isBoardMemberOf(), but basically you can access the board if you are the owner or a member of the board.