Scoped Application ACL issues with table wildcard rule

[emyrold]

I am having difficulty figuring out how to setup my ACLs on a custom app I'm building.   In section 2.2, sixth bullet down Using Access Control Rules - ServiceNow Wiki

It says you can only create table wildcard rules in the global scope.

I have created a custom table in a scoped app:

release_task   extended from task

I have 15 or so fields some from task and some new directly on the table.   I mostly wanted the fields ready only except for a couple fields I wanted open.

I intended to create one release_task.* (table wildcard write rule) to make all fields read only except for admin.   then create a few release_task.fieldname write rules with no roles to open them up.

When I turn on Security debug and impersonate a non-admin user, the field-level rule show as being "Not Evaluated" see attached screen shot.

Any suggestions?

[emyrold]

So I recreated the table in the Global Scope to rule out the possibility that ACLs process differently their than in Global and I am still seeing the same issue.

The Table.*   wildcard on the extended table does not make everything read only.   It seems like the star rule only applies to the fields locally created on the extended table.

See screen shot, where Customer, Type, Classification and SN Application (all created on the extended table) are read only from the star rule but other fields from task are not seeming to be affected by the star rule.

[glenn_pinto]

Hi Erik,

I believe you need to have .none rules on the base and extended tables with no roles/scripts/conditions to open the record to ESS users that have no roles, then you need table.* rules on either the base or base and extended to lock down the fields to just the admin and then table.field rules to open them up with ACLs that have no roles/scripts/conditions.

In your example, you are creating the table.* on the extended table. You could try creating it instead on the base table which will cascade down to the child table, but I don't believe it works the other way as you have it set up because the fields you inherit from the base table still live on the base table, so a rule on the extended table only affects fields explicit to that extended table. Clear as mud I am sure

[emyrold]

Thanks Glenn...!! really appreciate it!   don't mind a little mud...   🙂

[srinivasthelu · Accepted solution]

Hi Emrold,

Yes. Wiki says

Field ACL rules are processed in the following order:

1. Match the table and field name. For example, incident.number.
2. Match the parent table and field name. For example, task.number.
3. Match any table (wildcard) and field name. For example, *.number.
4. Match the table and any field (wildcard). For example, incident.*.
5. Match the parent table and any field (wildcard). For example, task.*.
6. Match any table (wildcard) and any field (wildcard). For example, *.*.

The first matching evaluation stops ACL rule processing at that field level. This means that when a user passes or fails a field ACL rule, the system stops searching for matching field ACL rules below that level.

So, that means, table.* is overruled by   parentTable.field. I believe that is what happening in your case. If so you would need to create additional table.* acls

Hope this helps.

Cheers

Srini

Please mark this as helpful/correct answer if it does so.

[emyrold]

Thanks Srini,

Seems like if I set a write rule on extendedTable.none   (with no conditions, roles or scripts) it opens everything up, then I lock each field down selectively.   Trying to not modify ACL's up at base because not sure what the impact would be on other tables extending off of task... to much to test.   Thanks everyone!   -e