question Combining Table and Field ACL rules in ITSM forum

Combining Table and Field ACL rules

daja — Mon, 21 Jul 2014 19:39:38 GMT

As we know, ServiceNow distinguishes between table and field level ACL rules. If both exist for a particular field, they both must evaluate to true in order to grant the specified access. I have a situation where I need a field rule to essentially trump a table rule, and am trying to wrap my head around the best way of doing so. A generic example:

The CI Owner (owned_by) should have write access to all fields on the CI record except u_custom_field_1.
Only members of the "Custom Group" group should be allowed to edit u_custom_field_1, on any CI.

As I see it, I can accomplish most of the above by one table level ACL rule against cmdb_ci that provides write access based on the owned_by value, and one field level ACL rule that checks if the user is a member of "Custom Group". That will prevent the CI Owner from editing this field if he/she is not in this group, as both rules must evaluate to true. However, for the same reason, members of "Custom Group" also cannot edit this field unless they are the CI Owner, due to the table level rule. This is undesirable.

My "brute force" approach to this problem would be to create field level ACL rules for every single field that I'm using on cmdb_ci, but for maintainability reasons that is obviously not a preferred option. Are there any alternatives? Could I approach the problem differently altogether?

Re: Combining Table and Field ACL rules

cbweiner — Tue, 29 Jul 2014 14:45:07 GMT

The following should work, provided other ACLs do not interfere.

- Write ACL on <table>.<none> where script evaluates to true for current.owned_by is current user or current user is a member of the "Custom Group" group

- Write ACL on <table>.* where script evaluates to true for current.owned_by

- Write ACL on <table>.u_custom_field_1 where script evaluates to true for current user is a member of the "Custom Group" group

<table>.u_custom_field_1 will be evaluated first, which will only allow write access to this field for members of the group. The <table>.* ACL will allow write access for all other fields on this table to the CI owner. The table level ACL will grant access to both conditions.

Re: Combining Table and Field ACL rules

daja — Wed, 06 Aug 2014 16:31:44 GMT

Thanks Chad, this helped solve my problem!

Re: Combining Table and Field ACL rules

pradeepshokeen8 — Fri, 15 Dec 2017 09:20:51 GMT

Hi Daja,

I do have the same requirement, wherein CI's can be edited by CI owners who can be identified by the owned_by field, here is an attempt from my side to achieve this but with no success.

var ra = false;

if(gs.getUserID() == current.owned_by) //gs.getUserID() would give me the sys_id of logged in user, but I am not sure how can I get the current value of opened owned_by CI

{

ra= true;

}

ra;

I am also looking on how can we refer to the opened record from ACL, current variable is not the correct way.

Any assistance from your end would be highly appreciated!!!

Re: Combining Table and Field ACL rules

prashantdharne — Mon, 18 Dec 2017 16:15:09 GMT

Hey Chad,

I have a different problem and I was hoping you could help me:

1. Config Management Lead should be able to update all fields on Application Table

2. Custom Role should be able to edit only 1 custom field on Application Table. But none of the other fields.

How can we do this? As soon as I write a field level ACL for the custom field, it overrides the table level ACL and then the Config Management Lead is not able to edit the field if the user is not having the Custom Role.

Config Management Lead - Record Level ACL

Custom Role - Field Level ACL to edit the field

Re: Combining Table and Field ACL rules

Prati — Thu, 26 May 2022 09:47:51 GMT

Hi,

Have you found solution for above query?

Custom Role should be able to edit only 1 custom field on Application Table. But none of the other fields.

please share it with me. I also have same requirement.