ACL Hierarchy

[kailashthiyagar]

sanjivmeher

Hi Sanjiv,

This is the continuation of our discussion "ACL for Extended table".   Right now, in my personal instance, i created a table "EUTS Demand" in my custom scope. I created ACL with the role as "EUTS Admin". Added "Abel Tuter" to the role as well

The initial ACL which got created by default has the name as "Table". "None". When i impersonated as "Abel", all the fields are coming as "Read only" when i try to create a new record in "EUTS Demand".

I created another Write ACL with the name as "Table"."*", and "Create" ACL with the name as "Table"."*" then when i impersonated as "Abel", i m able to see all the records coming as editable.

Q:In normal table creation(not the extended ones), an ACL with name "Table"."None" would work when we add the user but its not working here..

Still there are some fields which are referenced to other tables are not even appearing on the form, "Goal", "Program", "Work Notes",   "Watch List". why???

This is my personal instance, i guess you can request admin password. If not let me know.

ServiceNow

[SanjivMeher]

Use true instead. Try below

if ( gs.hasRole('project_user') ) {

      if ( PPMRoleClassMapper.validateAccess(gs.getUser(), current.sys_class_name true) )

              answer = true;

      else

              answer = false;

}

else

      answer = true;

[kailashthiyagar]

Yes sanjivmeher

I used this way and it has worked fine

var sysClass = current.sys_class_name || current.getRecordClassName() || current.getTableName();

      if ( PPMRoleClassMapper.validateAccess(gs.getUser(), sysClass) )

[Dave Smith1]

Kailash Thiyagarajan wrote:


I created ACL with the role as "EUTS Admin". 

There are three parts to an ACL:

• role = EUTS Admin (which isn't a good name - try to avoid "admin" in a role name)
• object = table.NONE/table.field/table.*
• operation = read/create/write/delete

- you may need to clarify what else is in the ACL; your description there is somewhat ambiguous.

My recommendation is that you create yourself a security model, i.e.: begin by defining what desired outcomes are, for example:

• Abel can read all fields, but only amend table.assigned
• Bhara can read all fields except table.price and table.cost
• Carly can change any fields, but not add new records
• Dennis can create new records and amend existing ones, but not delete any

- or as people say in the ITIL world: Security Management before Access Management = clarify what it is you want to see before determining how to go about it.

[kailashthiyagar]

Thanks david-smith

will do next time.. i m getting into unknown path. If i have to wait to ask the right question, the wait never be over.. Just my thought.

After this post only, i got to know the impact of parent table on extended table ACL. i read through wiki but i got information only about the "None", "*" and Field level which one would take precedence over the other. I dont get any information on extended table ACL hierarchy.. (May be i would have missed it too)

And Thanks sanjivmeher for clarifying this and taking ur time.

[Dave Smith1]

Kailash Thiyagarajan wrote:
 If i have to wait to ask the right question, the wait never be over.. Just my thought.

Hahaha! Always the way, yup!

After this post only, i got to know the impact of parent table on extended table ACL. i read through wiki but i got information only about the "None", "*" and Field level which one would take precedence over the other. I dont get any information on extended table ACL hierarchy.. (May be i would have missed it too)

For what it's worth, a quick crash course:

• there needs to be a .NONE rule in place before any .field or .* rules are processed.   The docs has a diagram on this (which - IMO - is confusing), but suffice to say that if you remove the incident.NONE:read rule then any read rules for incident.caller, incident.priority, incident.urgency etc are completely nullified.
• the hierarchy is:
  • check table.field   (e.g.: incident.caller) for that operation
  • if none, check parentTable.field (e.g.: task.caller) for that operation
  • etc... all the way up the hierarchy
  • .. finally, check *.field (*.caller) to see if there are any default rules right at the top of the tree.
• If none of those exist, then check the .* rules, e.g.:
  • table.*
  • parentTable.*
  • grandparentTable.*
  • .. etc... until getting to *.*

i.e.: stick to that field, work your way all the way up to the level above the base table, and if nothing matches then work your way through the .* rules in the same way.

So yeah, sometimes the parent rules can give unexpected results.

Hope that helps!