Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Role group functionality is "broken" #3

Open
kristianmandrup opened this issue May 21, 2011 · 2 comments
Open

Role group functionality is "broken" #3

kristianmandrup opened this issue May 21, 2011 · 2 comments

Comments

@kristianmandrup
Copy link
Owner

I think the role groups functionality needs some more work.
Each user should be able to join different groups, hence the need for a #role_groups column or a separate RoleGroup model with table similar to the functionality of role.

When a user joins a role_group, he could automatically be given the roles of that group, but what if he then is taken out of that group? Then we can't simply delete those same roles, as he might have had that role individually before. Bad idea!

Better then to just evaluate the role groups dynamically on demand. Later we could cache this result (fx by storing array of roles in the datastore), then invalidate the cache result for that user whenever his relationships with a role or role group changes, using event triggers? Note: We won't have support for nested role groups!

on_role_group_change
  find all users referencing that group and update their cache result

# whenever a role group is added or removed for a user

on_add_user_role_group user
  update roles of group to user (merge into Set)

on_remove_user_role_group user
  update cache of user

on_remove_user_role user
  update cache of user # can't simply remove role, since might be part of a group

on_add_user_role user
  add role to cache (merge into Set)

What do you think?

@stanislaw
Copy link

I don't believe that role groups functionality must be
the same as the one of roles. I think in that case you
will have unnecessary duplication.
Groups would do the work, that roles do now.

For my needs I considered groups as roles superposition
mechanism to significantly simplify collecting
specific information
for more than one role (controller, and the most
on view layer) in many places. For example if admins
and instructors have
the same logic in particular place, we just put them
into specific group and make
controller & views selecting stuff not with roles,
but with groups.

This approach implies, that we don't need to set up
groups for users
(there's no case as fx deleting group for user), but only for roles.
Group is just a bunch of roles.

And so nested hash (not table as with roles case)
with "role groups => [roles...]" is enough for group
functionality, if it works the way I described.

Having just a hash 'group=>roles' (or may be you know better way to store such simple construct) -
we'll have "denormalized" (if I properly understand denormalization from Rails Antipatterns book)
way of roles-groups connection, and hence better performance, than double-joining roles AND role-groups.

Of course, caching will be needed here anyway.

What do you think about this approach?

My point is that overcomplexity with groups is not needed here.
May be according to your vision, groups should have application, that
is much wider than I described. Let me know.

@kristianmandrup
Copy link
Owner Author

The current role group approach follows exactly the design pattern you have describe here. In this design, users can not be members of role groups. The role groups is simply a way to group a set of roles (and currently implemented as a hash!).
However how should you check the user according to group relationship in this model?
I think something more advanced is needed... I'm also considering the concept of role masquerading.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants