Let’s look at such use case. There are Task entity objects, and these objects are matter of permissions. So, we have TASK_MANAGER role, and (at assigning/revoking) use $data to append/remove a taskId to/from array of taskId (represented as $data) to reflect those Tasks current User can manage. Ok, we can quickly get answer to a question “which Tasks does the user manage?”. But if we want to list all users managing concrete Task, we must scan all TASK_MANAGER role assignments, and for each such assignment search taskId in the assignment’s $data array. As far as users (managing tasks) amount is intended to be rather large, such scanning will be very inefficient.
Since your taskId is at a finer resolution than the role hierarchy in RBAC, you should seek a different way to accomplish your goal. For example, you may create another table to store the pairs of assignment-taskId.
Since your taskId is at a finer resolution than the role hierarchy in RBAC, you should seek a different way to accomplish your goal. For example, you may create another table to store the pairs of assignment-taskId.
Aha, it means I have not missed something obvious In fact, I have decorated subclassed CDbAuthManager wrt assignments/revoking, and also have thought about parallel table - the decoration permits accomplish it easy. Thanks!
If the role is varied with some data, you should divide this role into sub-roles (or tasks, operations). Allowing assignments of the same role to the same user would cause a lot of implementation trouble (e.g. what would be the PK for assignments?) It is also not intuitive when being used.
If the role is varied with some data, you should divide this role into sub-roles (or tasks, operations). Allowing assignments of the same role to the same user would cause a lot of implementation trouble (e.g. what would be the PK for assignments?) It is also not intuitive when being used.
Say, during a project lifetime new entity objects are creating and deleting - and we deal with permissions to these objects. So, everytime new such object is created, we must both modify the auth graph (roughly speaking, add auth item for this new object) and create new assignment(s) against this object (“alow this user to deal with this object”).
OTOH, if we allow multiple assignments with different $data (via adding $data to pk), we can keep the auth graph intact (last one can be created by install script), dealing with asignments only: "the auth graph is a law, assignemts follow life". When we create or delete an object with permissions, we deal with assignments only.
I can explain my interest in such "tuned" assignemnts. The project under development currently has 5 assignments/revoking (I mean API of CDbAuthManager subclass), and 3 of them are concrete entity object related.
I think auth graph (role tree) doesn't need to be static. If you still want so, maybe you can change the format of your $data to be an array so that it can contain multiple tasks? I still don't think we should add $data to PK because it complicates things a lot.
I think auth graph (role tree) doesn't need to be static. If you still want so, maybe you can change the format of your $data to be an array so that it can contain multiple tasks? I still don't think we should add $data to PK because it complicates things a lot.
Indeed, both approachs are possible, and, using implemented one, I use arrays now. OTOH, multiple assignments woud permit direct reverse search (was discussed above) and simplify users’ thinking
The project I'm working on, is the first one with not-trivial permission structure, so I have not experience, are or not such concrete-entity permissions assignments typical.
FYI, the current Yii RBAC implementation is based on my study about the original RBAC literature and the implementation in .NET. Yii's implementation is actually more flexible. That's another reason that I don't want to make the change because I believe this implementation should fit most needs and it doesn't deviate from widely accepted standard.
FYI, the current Yii RBAC implementation is based on my study about the original RBAC literature and the implementation in .NET. Yii's implementation is actually more flexible. That's another reason that I don't want to make the change because I believe this implementation should fit most needs and it doesn't deviate from widely accepted standard.
Hehe, .NET isn’t a rule for us… But, sure, I’m for simplicity and standards! - just am new in the area (as well in PHP).
In fact, I have decorated subclassed CDbAuthManager wrt assignments/revoking, and also have thought about parallel table - the decoration permits accomplish it easy. Thanks!