Support for being in multiple groups at once?

[smeijer]

I couldn't find it in the docs, so I apologize if I missed something and it is already supported.

It should be great if a user could be member of multiple groups at once.

Let's say I need to list all project information that a specific freelancer requires. A freelancer (user) works for multiple Corporations and each Corporation has a specific ProjectTeam the freelancer is member of.

Translated to some document structure, it would be something like:

   Users: [{ ... }],
   Coorporations: [{
      name: WeDrinkBeers,
      teams: [{ "#1", "#2" }]
      },{
      name: WeLoveLemonade,
      teams: [{ "#A", "#B" }]
   }],
   ProjectTeams: [{
      _id: "#1",
      //...
   },{
      _id: "#2",
      //...
   },{
      _id: "#A",
      //...
   },{
      _id: "#B",
      //...
   }]

Now let's say the Freelancer is in the group for Coorporation 1 (WeDrinkBeers), but as he is only part of team 1, he isn't allowed to see information about team 2. An other Freelancer works on both Coorporations, and is member of the ProjectTeams 2, A and B. He wishes to see all his current information at once, but being able to show only the information for one specific ProjectTeam also.

As I see it, each ProjectTeam should be a unique group. But than we need some way to assign a user to multiple groups, and make sure that the current partition can be based on multiple groups.

Something like: Partitioner.setActiveUserGroups(userId, Session.get('showProjectIds'))

[mizzao]

No, this isn't supported right now, but it could be implemented at a low level using a $in Mongo query representing a set of partition groups rather than a single one.

I don't have a use for this, but you're welcome to fork and implement it. You should perhaps think about whether just storing the membership in A and B elsewhere, and toggling between them for the sake of publications, is enough for your user interface though - and whether you actually need the cursor rewriting for A and B at the same time.

The original idea of this package was to simplify writing publications and methods across multiple different "worlds" or "instances". Long-term membership across multiple groups wasn't part of the original goal, but I'm open to new ideas.

[thetechnaddict]

I'm thinking around partitioning by locality, avoiding hierarchies - so whilst there may be a group for a city and a group for a neighbourhood of that city they are both groups in their own right - so far a standard partitioning.

In practice (in the real world) they need to connect up those groups - sending delegates to each other for instance.

From your comment above, @mizzao , I am thinking that I can have users in more than one group so long as my interface allows them to switch - in this example 'leave' one locality and 'enter' another.

So for example they could take part in discussions/chats in their city group and then leave that and go and have a chat with their neighbourhood group so long as they don't expect to see both sets of chats at the same time.

Effectively two different logins -

Have I understood you correctly?

[mizzao]

For those who are interested, @kristijanhusak seems to have tried this; looks decent:

https://github.com/kristijanhusak/meteor-partitioner/tree/multiple-groups

[kristijanhusak]

Yes, it's already used on one project, looks like it's working fine for now.

@mizzao do you want me to merge it here?

[mizzao]

I'd like to merge it in at some point, but no rush. Good to know that it's there and I'm happy to review and merge when I get a moment.

If you want to rebase off master, that would be nice.