Group Hierarchy With Roles/Groups with meteor-roles package

Question

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.

Answer 1

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.