ACL rules determine user access to an object if the user meets all permissions required by the matching ACL rules. When a user attempts to access an object, RulePoint evaluates permissions of the matching ACL rules.
Based on the evaluation, RulePoint either grants or denies user access based on the following matching ACL rules:
If the ACL has a matching entry, where the user ID is the logged in user, has the required permissions, and the grant access for the permissions, the user can access the RulePoint object. For example, if a user has write permission for a specific object with grant access, that user can create, edit, or delete that object.
If the ACL has a matching entry, where the user ID is the logged in user, has the required permissions, but the deny access for the permissions, RulePoint denies user access to the object. For example, if a user has write permission for a specific object with deny access, that user cannot edit or delete that object.
If the ACL does not have a matching entry according to the first two rules, RulePoint invokes the parent ACL and runs the rules again until it finds a matching entry. When RulePoint reaches the end of the ACL hierarchy, and there are no more parent ACLs, it denies user access to the object. For example, if a user has read and write permission for a specific project, but no grant or deny access specified at the object level, that user will have the read and write access on all the objects in that project.