Thank you for reply. But I don’t want to create another role. This approach conduces to incrementing count of roles and troubles of support such data structures.
Unfortunately, Yii doesn’t implement some important RBAC standing:
deny rules for roles relationship;
assign business rules to roles relationship
In consideration of this restrictions I cannot utilize Yii’s RBAC in my authorization scheme
But let’s examine a situation if role that should be excluded from ‘B’ for inheritance of ‘A’ also should be excluded for inheritance of another role, for example ‘C’. In this case we have to define more complex bizrule for excluded role. This bizrule must consider all of inheritances like referred above (from B to A and from B to C).
This problem solves by assign bizrules to roles relationships. But Yii does not support feature like this
I’m working on an enhanced version of the RBAC where I guess I could add optional conditions for each relationship. Unlike the bizrule, the conditions would not be PHP code and be a set of boolean tests using a simple syntax. One of the reasons I chose to write my own version is to possibly avoid using bizrules (don’t want PHP code in my database). The other was to reduce the number of db queries.
Of course I’m interest for your work. And I could be able to help with developing.
This enhancement will be extremely useful. For example, you don’t need to create couple of unnecessary roles, such as ‘updateOwnPost’. You can simply set bizrule to relation between role ‘user’ and role ‘updatePost’. That’s all!
Now through limitation of Yii I obliged to use Zend_Acl
I’m handing this with a feature I call ‘computed role’. These computed roles will not normally be assigned to any user in the database but would be assigned by the code. By default, the rbac module will provide one computed role - ‘Anonymous User’ or ‘Authenticated User’. In your code, when you do an access check, you can specify additional computed roles such as ‘Author’, ‘Owner’, ‘Manager’, ‘Supervisor’ or such. These roles would be dependent on the target object and is best supplied by the code that would be dealing with the target object. This would obviate the need for bizrules in many cases and keep the logic where it most makes sense.