Group Hierarchy With Roles/Groups with meteor-roles package

1
votes

I'm looking for a reliable, and respectable way to handle roles and groups with hierarchy in Meteor. I'm not married to the alanning:roles package and will gladly swap it out for a package that easily meets these demands.

The demands:

I need to be able to create an "infinite" amount of sub-groups. Say I have a team (Team A) with user(s) (Bob, Jim, Anna, Daisy, Tom, Jerry) and I want some of the members to be able to have control over users underneath them, but not above. So, to best illustrate this idea I present the following tree:

  • Bob (Team A)
    • Jim (Division 1)
      • Daisy (Managers)
    • Anna (Division 2)
      • Tom (Slave Drivers)
        • Jerry (Users)

So my current idea for how best to handle this, is by assigning groups with cascading groups where the tree would be represented as these role/group combinations:

  • bob : roles : ["role"], group: team_a
  • jim : roles : ["role"], group: team_a:division_1
  • daisy : roles : ["role"], group: team_a:division_1:managers
  • anna : roles : ["role"], group: team_a:division_2
  • tom : roles : ["role"], group: team_a:division_2:slave_drivers
  • jerry : roles : ["role"], group: team_a:division_2:slave_drivers:users

I'm not a huge fan of this structure as it doesn't really support the idea of groups very much as well as a bunch of other problems I can foresee already. But the only alternate I can think of would be something like this:

  • bob: roles: [
    • {["role"], team_a},
    • {["role"], team_a:division_1},
    • {["role"], team_a:division_1:managers},
    • {["role"], team_a:division_2},
    • {["role"], team_a:division_2:slave_drivers},
    • {["role"], team_a:division_2:slave_drivers:users} ]
  • jerry: roles: [
    • {["role"], team_a:division_2:slave_drivers:users} ]

Does this make more sense? It seems like I would have to update every user's permissions every time I create a sub-group. And it seems like the amount of defined groups could increase pretty quickly.

If I'm way off and there's a much easier way to pull this off, I'd appreciate being pointed in the right direction. With these routes, it definitely feels like I'm trying to make the roles package do something its not designed to do. Thank you.

1
javascriptmeteorpermissionsroles
It looks like you need a hierarchical data structure to store these relationships, and a tree view control is probably suitable for maintaining them. In terms of managing the permissions you will need to refer to this hierarchy, nothing that I know of in meteor can handle it. I think you would need to have something that provides simple methods to query permission of any person relative to any other and give a yes/no answer - Mikkel
hmm interesting, i still like the roles package atleast as a base for this. hopefully someone can come in here and relieve me of having to do it myself but I guess my best chance at the moment is to build upon what the roles package offers, probably change up the structure though to include the notion of "teams" cascading permissions downwards. - Bryan Gromadzki
that was a lot of fluff that didn't say anything. essentially, damn, it sounds like i have to change how roles sit in the db - Bryan Gromadzki

1 Answers

0
votes

If anyone is interested in this type of permissions management, feel free to check out the bgromadzki:meteor-teams package I've put together. Or the github page here: https://github.com/BRyeGmoney/meteor-teams

I used a similar premise as the roles package, but i switched the package's focus from roles to the groups (as in there's now a teams collection, rather than roles), which I named teams as groups seemed too loose a term. I intend to continue working on it a bit more, and appreciate any feedback as well as suggestions for what they might need.