Migrated from SEC-1023
Luke Taylor said:
This provides a bridge between the expression language and the ACL module. It’s much easier to understand than the ACL voter approach and greatly reduces the amount of XML that’s needed. The security root object delegates to a configured instance of the PermissionEvaluator interface. Currently the only concrete implementation is AclPermissionEvaluator, which uses the Acl module. There are two options available.
1) hasPermission(#domainObject, permission)
2) hasPermission(#domainObjectId, ‘type’, permission)
Option 1) evaluates whether the current user has the given permission on the method argument called “domainObject”. Method argument names currently rely on debug information being present in the compile code.
2) Allows an ObjectIdentity to be generated from the supplied Id and ‘type’ (default implementation assumes a classname), allowing the permission to be evaluated when only the objects primary key information is available, rather than the actual domain object.
The permission information can currently be an integer, a string matching one of the permission names on the BasePermission class or a value which evalutates to a Permission or Permission type. Later we will include a pluggable strategy (possibly as part of the refactoring of PermissionFactory during SEC-1022). The permissions are then aren evaluated using the Acl module as normal.