Inherited group membership

Hi Baps,

Can I ask why you chose to use Groups - and have the Spaces inherit those Groups - for Space membership? If you're adding users to a Group, that's not any more work than adding them to the Space directly...

Anyway, I think the breadcrumb menu was changed in one of the recent updates - it used to allow inherited Spaces, but now, as you know, does not. The concern is that managers who had inherited access to a large number of Spaces, but were only really active in a few, would find their breadcrumb menu overwhelmed by the inherited Spaces. There's an issue about it here: https://www.drupal.org/node/2141373

I think I recall that you can add links to Spaces into the 'Main menu' menu, and they'll still only appear for users who have the correct access permission. Worth testing that out for yourself, though, as I could be wrong.

I have a similar complaint. We have partners who manage many projects. It's a citizen science initiative. Each partner may have an infinite number of projects. Each project is set up as a space, and each project is public. But there are subspaces, sections, and content that is not necessarily public. Not all partner members are to be members of every project. There would essentially be teams, but teams can only be added to one space. I decided I would use groups as teams, but teams that could be added to multiple projects. The issue I'm having is that the project space is inheriting the permissions of the "Team Group", and causing problems. I hope I can resolve this, but I don't have much hope. Therefore we'll need to add individual members over and over again to each project. This will become a tedious task over time. I would argue the role of teams should be expanded to include the possibility of teams being members of multiple spaces, and team members being full members of the space. For the one project I experimented with teams, being a team member did not give you privileges of being a space member, even though that team was a member of the space.

Thank you,
Sean

Noone else has come across this or finds this behavior odd? I'd have thought it was pretty fundamental in terms of access.

Thanks,

Baps.

It's fair to say that a Team that can belong to multiple Spaces is, essentially, a Group.

If you've set up a few Teams in one Space that are also relevant for other Spaces it would make sense to be able be able to have them belong - or work in - multiple Spaces. However, it also makes sense for the devs to a) avoid duplicating work unnecessarily, and b) to separate the roles of Groups and Teams so that site-builders don't duplicate unnecessarily.

It's worth submitting a feature request, but I can see them suggesting you just use a Group.

baps11,
In response to your original problem, there is an only-slightly clunky workaround. I've set up an intranet the same way you want to set up your client-based site, with Groups providing inherited membership to a variety of Spaces. I created a view that displays published Space-type nodes, sorted alphabetically, and added a block display. That block goes on the /spaces page, which I changed to the Radix Bryant Flipped layout. This means that users can see every Space they have access to alongside the normal lists of their favourite Spaces and Spaces that they are a direct member of. If a user does not have access to a Space, it will not appear in this list.

cuoloir007/Sean,
Apologies if I've not understood your issue correctly, or if you've tried this, but... in the top-level project Spaces, have you tried changing the 'Inheritance' settings to "No - subgroups of this group won't inherit its users" and "Child's permissions - inherited users in this group's subgroups will have the permissions of a generic member of that subgroup"? I haven't experimented with these very much but I think they're meant to provide a way to separate sub-Space membership from its parent Space... So you could have the parent Space be public, then set the sub-Space as private and inherit membership from a Group.

Also, as far as I can tell, you can't have private Sections within a public Space. Either the Space's Group will just have access all the same, or it'll be a combination of the Space's Group and the Group that you specify - the user will have to be a member of both. I think sub-Spaces are required for private Sections.

Kieran