Private inherited space does not show on space page; add the Inherited tab to the space listing

Yep, I actually have an issue on my internal JIRA instance to add an "Inherited" tab to your space listing that would show those kind of spaces.

I don't want to mix them with the normal Subscribed Members because in many use cases, high-level users (like Executives) have *access* to lots and lots of spaces via inheritance (LDAP groups) but only actively participate in certain spaces that they are direct members of. And they don't really want the huge list of inherited spaces to clutter the direct membership spaces.

I think "My Spaces" is a bit too generic since it doesn't distinguish between the Spaces you are actively participating as a direct member vs those spaces you just happen to have access to via inheritance.

Sorry can't help myself.. :P

Can this be solved with views?
I got lost when I reached the 'contextual filter/ entity relationship area (OG relationships are still a nightmare to me).

It would be a very complex view, so not sure if it's possible. Inherited groups are implemented on og_subgroups by making the child group/space a "member" of the parent space (using og_membership). Then there are separate og_membership relations for putting Users as members of a space.

So, to show all spaces (including inherited) you'd need to recursively get a list of all parents of a subspace, then get all users that are members of any parent.

Honestly, it's probably better to wait until I add the Inherited tab to the space listing. It's easier to do it in code than in Views.

Agreed (gladly :)

Whilst I can understand the reasoning for the suggestion in #1...

I don't want to mix them with the normal Subscribed Members because in many use cases, high-level users (like Executives) have *access* to lots and lots of spaces

... I think that inclusion or exclusion of inherited Space membership in the toolbar or on the /spaces page should be an option decided by the site admin. Our situation will be the opposite of the above example; users will have direct membership to only a few Spaces, but access to all Spaces is granted for all users (barring a few, which is why they can't be public) by inheriting membership from a Group. As it is, a user of one Space will have access to another (via inherited membership) but they won't see it in the navigation.

Also - this is not necessarily a common usage - I've created a user directory (for other users to view) that takes advantage of direct Space membership as a way of indicating their area of work. Having every user be a direct member of every Space would make this useless.

We're finding that people are finding it confusing that they can access spaces through inheritance, but don't see the spaces listed in the drop-down menu.

Our OA site is private, so all staff are put into a staff group which is then inherited by the spaces. Having the sitemap is ok, but it creates more clicking than seems necessary.

Very few people are explicit members of spaces, but they're not able to navigate through the drop-down.

I understand you're thinking for not everyone wanting to see all the inherited spaces, but, as someone else has pointed out, that's not a universal requirement, so having the option for the menu would be fab.

ta
Mark

The toolbar has already been changed in the recent 2.25 version. The Home "spaces" dropdown now shows a list of "Recent Spaces" regardless of whether it's a subspace or not. So as a user uses the site, this drop-down should fill with their most actively used spaces.

This ticket is only for adding inherited spaces to the user's dashboard "Subscribed Spaces" widget.

The problem with showing all subspaces in the dropdown is that without actually showing the hierarchy, a flat list of spaces/subspaces will be even more confusing to users. The sitemap has a drop-down menu in the upper-right corner that shows the entire space/subspace hierarchy, so you can easily access that without "a lot of clicks".

If I've understood correctly, msharp.chi isn't talking about subspaces being hidden or available in the Home "spaces" dropdown, rather that it only shows spaces that the user is a direct member of.

In both our cases, most space membership is inherited from one common space. With the Home "spaces" dropdown only showing spaces that the user is a direct member of, the spaces that the user is an inherited member of are much less obvious.

I agree that including subspaces in the dropdown can be confusing, so I've left mine showing only primary spaces; what we're thinking of is a similar toggle for showing only direct membership or direct and inherited membership spaces.

Thanks both for your comments. Sometimes we can get so deep into something that we forget what the first time user might expect.

As I described, all our users are inherited into spaces, so clicking on the Spaces tab or the drop-down to see subscribed spaces, for the first time user, will reveal nothing.

Their first impression is that there's nothing to view (and for some of my colleagues, this seems to be a deal-breaker). But we know that's not true, they're inherited users of everything, they just need to go to the sitemap (something they've probably never done on any other system) and click on an eye symbol (again something they've probably never done before) to get to the space landing page.

Only at this stage can they start to favourite things and begin to track down the things they're interested in.

I think I'm almost tempted to drop the menu and rewrite it to be something a bit more useful. In the meantime, I'll be listing all the spaces available on the authenticated user homepage as a quick start.

Mike, I am fully appreciative of the amount of work that has gone into OA, and that we've got an interesting platform to work from, for free. I'm just trying to get to a place of the "bleeding obvious" for users who aren't interested in information architecture.

I think this has been addressed in OA 2.60+ by adding a link to /spaces. Please reopen if needed.