Does write ACL grant read access?

[Ren Magalona2]

Just confirming, does write ACL grant read access automatically? Scenario is, if there is a read ACL defined and you didnt evaluate to true but you did evaluate to true in write ACL, does it give you both write and read access on that record?

Thanks

[James Fricker]

Which is different to how HR COE Security Rules work because Write rules also grant Read Access and Read rules are not required unless someone needs readonly access.

[Allen Andreas]

Hi @James Fricker 

HR COE Security Policies are really meant to "lay on top" of the access already given. This means that HR Groups by default, without a COE Security Policy could read and write on all cases, but when you create an HR COE Security Policy you can limit who can do what.

For example:

• You can specify that only Group A can read cases within a specific HR COE
• You can specify that only Group B can write to cases within a specific HR COE

With that said, HR COE Security Policies don't grant "read" access when you select the "write" checkbox on it. The ACLs underneath would be what is granting read access and your COE Security Policy is now just limiting who can "write" to the cases.

More explanation can be found here as well in another Community forum post: https://www.servicenow.com/community/hrsd-forum/coe-acl-configuration/m-p/1320247/highlight/true#M15... 

[James Fricker]

> HR COE Security Policies don't grant "read" access when you select the "write" checkbox on it. 

Maybe you should read the code?

[Allen Andreas]

Hi @James Fricker 

Thanks for your suggestion to read the code 😀

As I mentioned above, all HR agents can read all HR cases unless there's a COE Security Policy that's relates to the service the case is about, is active, and the condition specified is relevant to the case. With that said, if you were to review the rest of the code from the script include you screenshotted, you'll see that if you were to only create a "write" COE Security Policy, then you are actually taking away "read" access from everyone who does not pass that "write" COE Security Policy. So, I guess you could say the reverse in that it "gives read access", because you're in fact taking away read access from everyone else and "giving read access" to only those who pass that "write" COE Security Policy. It could be said both ways, I guess.

If you needed someone to then "read" the case, then you'd have to create a "read" COE Security Policy that applies to that service or add them to the "write" COE Security Policy such that they pass, but of course they could then "write" to it as well.

COE Security Policies operate in a default allow whereas ACLs operate in a default deny behavior. So, yes, they are different than ACLs.

With all of that said, the context and scope of this question that was posted 4 years ago was specifically about ACLs and not HR COE Security Policies, but I suppose your reply is true statement, it just doesn't have anything to do with the question originally asked.

Thank you for pointing out an alternative way that access to something could be evaluated and given!

[James Fricker]

> With all of that said, the context and scope of this question that was posted 4 years ago was specifically about ACLs and not HR COE Security Policies, but I suppose your reply is true statement, it just doesn't have anything to do with the question originally asked.

Sorry sheriff, I did not see your badge.