You are by no way limited to using the role system to denote groups in Zend_Acl
.
For example:
In one application, I have my base user object, implement Zend_Acl_Role_Interface
which, in this case returns a string that is specific for the user. For simplicity sake, let's just say something like user-1
, where the numeric portion is the user's unique ID.
When the user object is initialized, it adds itself to the ACL, with the user specific role inheriting from a more generic role (akin to a group.):
if(!$acl->hasRole($this)) {
$acl->addRole($this, $this->role); // Let's say role == 'member' here
}
This allows you to set general rules for the parent role (or roles, you can pass an array as the second argument to addRole, to have multiple parents. Also, remember that roles have a lineage all the way up the tree, so the parent role in this case may also have parent roles itself.)
So, to illustrate the flexibility here, let's assume this basic ACL set up (This is all theoretical, I'm writing it solely for the purpose of this answer):
$acl->addRole('guest');
$acl->addRole('member', 'guest');
$acl->allow('guest', 'comments', 'read');
$acl->allow('member', 'comments', 'write');
$user = $My_User_Model->find(1);
$acl->allow($user, 'comments', 'moderate');
$acl->isAllowed($user, 'comments', 'read'); // true
$acl->isAllowed($user, 'comments', 'write'); // true
$acl->isAllowed($user, 'comments', 'moderate'); // true
$acl->isAllowed('member', 'comments', 'moderate'); // false
And so on...
The beauty of the Zend Framework components is that you're not at all limited to using them in one specific way. Yes, while this can be daunting at times, and often requires a little more time invested on initial planning and implementation, it's great in the long run.
Also, personally, I'm not a fan of the direct mapping of ACL privileges to a controller/action construct. But that's a whole different conversation.