- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-13-2018 10:54 AM
Within a table.* ACL, is this ACL called for each individual field in the table?
If so, is there any way to get the field its being called against in the script?
For example:
if(current.targetfieldname == 'state'){
answer = true;
} else {
answer = false;
}
The reason I ask is because I have a table with 100 rows, and want to an easier way to manage field level security without writing 100 ACLs.
Solved! Go to Solution.
- Labels:
-
Scripting and Coding
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-17-2020 01:04 AM
Hi,
I appreciate it is a bit a late but I found your post when I was looking for an answer to the same question. You can actually do this now so maybe it's changed in the last 2 years.
table.* ACLs do iterate through the columns and treat them differently. There is a variable root_rule which holds the root rule name.
For example if your were creating sys_user.* ACL, gs.log(root_rule); would return log entries like:
- sys_user.user_name
- sys_user.name
- sys_user.location
- etc....
So in your ACL script you can get the current column being controlled with root_rule.replace('sys_user.','');
I'd love to take credit for this but I found it in one of the Scoped HR ACLs so thanks to those guys 😄
Cheers
Rob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-13-2018 11:01 AM
That wouldn't help you, would only set the return for that ACL so with your above example, if the field was state, it would return true, meaning the table.* ACL would be true (for whatever it is read/write/etc).
I do not know away around this other than to group as best you can, determine which scenario has the largest set of fields and use that for the table.* ACL, then for the remaining set individual table.field name ACL to govern access.
Alternately you could create rules to set the form view for the user and have specific forms set up, however you may still need to control access from lists.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-13-2018 11:13 AM
Thanks, so the table.* ACL is only evaluated once? and it isnt re-evaluated for each field?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-13-2018 11:18 AM
That's correct.
When ACL's evaluate they look for the specific table.field ACL, then table.*, then *.field (parent table), then table level, then *. Docs for process.
So in the case of table.* this will be the field level ACL for all fields on the table that do not have specifically defined ACL.
table1 has 3 fields
state, group, user
have 2 field ACL
table.*
table.state
In the above example, the table.* governs group and user fields, and state has its own.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-17-2020 01:04 AM
Hi,
I appreciate it is a bit a late but I found your post when I was looking for an answer to the same question. You can actually do this now so maybe it's changed in the last 2 years.
table.* ACLs do iterate through the columns and treat them differently. There is a variable root_rule which holds the root rule name.
For example if your were creating sys_user.* ACL, gs.log(root_rule); would return log entries like:
- sys_user.user_name
- sys_user.name
- sys_user.location
- etc....
So in your ACL script you can get the current column being controlled with root_rule.replace('sys_user.','');
I'd love to take credit for this but I found it in one of the Scoped HR ACLs so thanks to those guys 😄
Cheers
Rob