ACL Help !!

[vidishaagarwal5]

How to Solve this --->

Users with Role A should have write access to all field except Configuration Item on incident table and Role B should have write access to Configuration Item field and all other fields should be read only

[Chaitanya ILCR · Accepted solution]

Hi @vidishaagarwal5 ,

create ACL incident.* with role A

create incident.cmdb_ci ACl with role B

if required also create a incidnet.None ACL with 2 roles

Please mark my answer as helpful/correct if it resolves your query.

Regards,
Chaitanya

[Shashank_Jain · Accepted solution]

@vidishaagarwal5 ,

Confirm the requirement :

• Role A → Can write to all fields on Incident except Configuration Item (read-only for this field).

• Role B → Can write to Configuration Item field only; all other fields are read-only.

  Create field-level ACLs for incident.Configuration Item.

  • For write → give access only to Role B.

  • For read → allow both Role A and Role B.

• For all other fields:

  • Create a field write ACL granting Role A.

  • Deny write for Role B (so Role B can only read).

[John Gilmore · Accepted solution]

3 ACLs total to accomplish this:

• Grant Read to Incident Table (be careful with this one, read is probably already granted to all users for this table, if all users in Role A and Role B already have read access then no changes are necessary)
  
  • type: record
  • operation: read
  • name: select only the table leave the second option empty
  • roles: A & B
• Grant Write to all Incident Table Fields
  • type: record
  • operation: write
  • name: select the table and for the second box select the asterisk (*)
  • roles: A
• Grant Write to Configuration Item Field
  • type: record
  • operation: write
  • name: select the table and for the second box select the configuration id field
  • roles: B

The most granular rule will override all those above it. So You grant read to the table as the default for both roles. You then grant only Role A write to the entire table. You then grant only Role B write to the configuration id field which supercedes the second rule granting write for the whole table. This both grants write for the field to Role B and restricts write permissions to Role A that would otherwise be granted by the second ACL.

[Chaitanya ILCR · Accepted solution]

Hi @vidishaagarwal5 ,

create ACL incident.* with role A

create incident.cmdb_ci ACl with role B

if required also create a incidnet.None ACL with 2 roles

Please mark my answer as helpful/correct if it resolves your query.

Regards,
Chaitanya

[Shashank_Jain · Accepted solution]

@vidishaagarwal5 ,

Confirm the requirement :

• Role A → Can write to all fields on Incident except Configuration Item (read-only for this field).

• Role B → Can write to Configuration Item field only; all other fields are read-only.

  Create field-level ACLs for incident.Configuration Item.

  • For write → give access only to Role B.

  • For read → allow both Role A and Role B.

• For all other fields:

  • Create a field write ACL granting Role A.

  • Deny write for Role B (so Role B can only read).

[John Gilmore · Accepted solution]

3 ACLs total to accomplish this:

• Grant Read to Incident Table (be careful with this one, read is probably already granted to all users for this table, if all users in Role A and Role B already have read access then no changes are necessary)
  
  • type: record
  • operation: read
  • name: select only the table leave the second option empty
  • roles: A & B
• Grant Write to all Incident Table Fields
  • type: record
  • operation: write
  • name: select the table and for the second box select the asterisk (*)
  • roles: A
• Grant Write to Configuration Item Field
  • type: record
  • operation: write
  • name: select the table and for the second box select the configuration id field
  • roles: B

The most granular rule will override all those above it. So You grant read to the table as the default for both roles. You then grant only Role A write to the entire table. You then grant only Role B write to the configuration id field which supercedes the second rule granting write for the whole table. This both grants write for the field to Role B and restricts write permissions to Role A that would otherwise be granted by the second ACL.

[Ravi Gaurav · Accepted solution]

1) READ ACL: table.None → roles ITIL and ITIL_ADMIN

Corrected result:

• Both ITIL and ITIL_ADMIN can see the records (rows).

• Field visibility depends on field-level ACLs.

  • If no field read ACLs exist → they’ll see all fields.

  • If field read ACLs exist and they don’t pass them → those fields will be blank/denied.

Your line “with no field level restrictions” isn’t guaranteed by table.None; that’s only true if you haven’t defined field-level read ACLs.

---

2) READ ACLs:

• table.None → roles ITIL and ITIL_ADMIN

• table.* → role ITIL_ADMIN only

Corrected result:

• ITIL_ADMIN: sees records and fields (passes row via table.None and fields via table.*).

• ITIL: sees records (passes row via table.None) but fails fields (blocked by table.*), so fields appear blank/denied unless there are additional field ACLs that allow ITIL.

So it’s not “only ITIL_ADMIN will have read access”—ITIL has row access but not field access.

---

3) READ ACLs:

• table.None → role ITIL_ADMIN

• table.* → role ITIL

Result (your statement is right):

• ITIL: has field-level access via table.* but no row access (no table.None for ITIL) → cannot see any records.

• ITIL_ADMIN: passes row via table.None; field visibility depends on whether any field ACLs exist and are passed (if only table.* for ITIL exists, ITIL_ADMIN would fail field access and see blank fields).