what is the difference between * and None in acl?

Kannan Nair
Tera Contributor

I have read many articles on this but still have some doubt. In developer instance i have created 2 read acls. One with None and the other with *. The None is granting the read access and * is not. Which one is a field level and which one is a table level acl?

10 REPLIES 10

Ankur Bawiskar
Tera Patron
Tera Patron

Hi Sanker,



The * when applied with table.* applies to all the fields so it is at field level.


The None when applied with table none applies at the table level.



Below links will be helpful for you


Difference between /none and /* ACL


Evaluating Row level and Field level ACLs



Mark Correct if this solves your issue and also hit Like and Helpful if you find my response worthy based on the impact.


Thanks


Ankur


Regards,
Ankur
✨ Certified Technical Architect  ||  ✨ 9x ServiceNow MVP  ||  ✨ ServiceNow Community Leader

Hi @Ankur Bawiskar ,

if i have table.none acl and in that roles are given + below script is attached:

 

if( gs.getUser().hasRole("sn_cmp.cloud_admin") || current.sys_created_by == gs.getUserName() ||| current.isNewRecord())
{answer=true;
}
else {
answer = new CMPCheckPermission().checkPermission(current.getTableName(),current.getValue("sys_id"),gs.getUserID(),"read");
}  so do we consider as table + row level acl or only row level acl? and if only row level acl (bcz of current getting used in script) then where's the table level acl
 
if i use canRead() before query/next then will it be fine , just to check table level access?
GlideRecord opSignatureGlide = new GlideRecord(OperationSignatureConstants.SN_CMP_RB_OP);
if(!opSignatureGlide.canRead())
{
throwAccessError(fLogger, AccessErrorHelper.OperationType.READ)
}

Harish KM
Kilo Patron
Kilo Patron

In ACL what the difference between *   it has useful info abt ACL check


Regards
Harish

Dave Smith1
ServiceNow Employee
ServiceNow Employee

This is something that puzzled me immensely when first dealing with ACLs, so it took me a bit to work out.



The easiest way I found I understood them was the following:


  • incident.assigned_to = a rule for this specific field (assigned_to), in this table (incident).   Think of it as a key for a certain cabinet in a room
  • incident.* = a rule for other fields that aren't covered by specific field ones. Think of it as an unlabelled key that is used if you aren't given a cabinet key
  • incident.NONE = a rule for the table itself.   Think of it as a key to the room's door - if there's no table.none rule, all other field rules are redundant.


On our sysadmin courses, I demonstrate this by creating a new table and permit app access to a user but the user finds they can't see the underlying table until I add some ACLs.   Once I add table.* = read:userrole, they can see the list (and also note that a table.NONE rule has been added) but later when I remove this .NONE rule, any other read rules are completely ignored.



In my opinion, the .NONE rule doesn't really add further security that can't be handled by a combination of .* and .fieldname rules.   Other than the constraint of it having to be there, I've yet to be given a use case where it's needed - it feels like an unnecessary extra step that doesn't actually add anything.