Thanks for reply Simone, I see the complexity and the limitless recursion that can occur... I guess, I will go with flat group of access which will overlap... My main issue was that I would avoid having two way to assign the same set of permissions... Let say I have tool A, so I create group A, so any users member of group A has access to tool A... That why I would had reuse group A to provide access to tool A to all member of group B, which could also provide access to group C, D, etc. This implies refactoring to RBAC by having auth_membership relation between group and not only user and group which prevent having foreign key for user_id and have a "group_member_id" (sorry no better name) that is kind of duplicated group_id... It would surely break web2py membership verification since web2py surely make the assomption that there is always an user id attach to membership relation which could not be the case.
So, I follow your advice and keep it simple... The only drawback that I see is that I may end with differents groups that provide access to the same ressource... group A above has access to tool/func A and group "Department X" which could have also access to tool A and another set of function at the same time... Thanks again Richard On Mon, Nov 23, 2015 at 5:06 PM, Niphlod <[email protected]> wrote: > This has been reported before but it just triggers for the next level up > in the hierarchy (Group C that manages access to Group B that manages > access to Group A). > RBAC as is is a complete and finite tool to manage permission: it enforces > (as many other things in web2py) sane defaults, levelling all permissions > hierarchies to one level. > The fact that you'd need to code your own "hierarchy of permission upon > permission" shouldn't stop you (and frankly, if put on a piece of paper, > isn't hard to implement) > > Loosely said, you can choose any of two ways: > - have your groups linked by some other external reference, and > recursively querying for membership > - manage ephemeral groups that can be flatly queried, basically > multiplying permissions flattening the structure > > Recursively querying the database to check for permission is really heavy, > but if your app needs it, go for it. > Think, though, that you need to check if a user "X" belonging to only one > group, Group A, has access to resource "Z". > In hierarchy-defined groups (the structure more familiar to a human > brain), you'd need to traverse all permissions to "Z" (that are only given > to Group C), then see if a Group B has access to everything Group C has > access to, then if a Group A has access to everything that Group B has > access to. > > A way to check for the user "X" in one step if has access to "Z" is easy, > too, and generally less resource intensive... > When you create resource "Z", you grant access to Group C, AND Group B, > AND Group C. > OR, you can assign to user "X" Group A AND Group B AND Group C, and assign > "Z" permissions to C only. > > Granted, the less resource intensive way NEEDS to plan a "manage > permissions" machinery accordingly to your needs, but you need to ask > yourself how many times your app assigns/revokes permission and how many > times it checks for permissions (and how many times will you feel more > comfortable debugging it :-P). > > > > On Monday, November 23, 2015 at 4:11:55 PM UTC+1, Richard wrote: >> >> Hello, >> >> I would like to know how (if possible) I can manage group access for >> permission granted by other role. For example, I have group A, that allow >> user member from it to access func A... But how can I create or represent >> that all members of group B can grant the access to group A and group C for >> instance? In web2py the membersphip don't allow to represent that a role is >> a member of another role... So how to avoid a repetitive assignment by >> using group assignment? >> >> Thanks >> >> Richard >> > -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
