When a subspace does not inherit its parent's members, misleading messages that suggest it does are displayed it.
As an admin, create a new space 'Space', set the user group inheritance to 'No', make the space 'Private'.
Create a new space 'Subspace', set the parent as the last space we created, make the space 'Private'.
Add an authenticated user as a member of the 'Space', ensure they are not a member of the 'Subspace'.
The authenticated user can now view the 'Space' but not the 'Subspace' - this is the desired behaviour.
However, looking at the 'Subspace' as an admin, we see a privacy message that says:
Only members of these can see this page
Spaces:
Space
This is not true and contradicts the settings we applied to the parent space.
Additionally, in the Members settings for the 'Subspace', we are told that the space is 'Inheriting members from: Space'. Again this is not actually the case.
I imagine this is because these messages only look at what the parent space is, and don't take account of the actual inheritance options we have set?
This is more of a usability improvement than a bug report, but it is quite misleading I think.
Parent spaces should only be listed if the current group is set to inherit its parent's users.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | oa_core-fix_user_inheritance_messages-2145297-4.patch | 1.8 KB | jkingsnorth |
Comments
Comment #1
mpotter commentedYep, confirmed.
Comment #2
totolearn commentedActually, can the member inheriting direction be setting to reversely?
For a organization, we have Comanpy A (CompA) as top space and , Business Unit 01 and 02 (BU01, BU02) as the subspace under CompA。
So, what we thought we can let all member of BU02 and BU01 should also belong to CompA (they are the same company).
But the current options is to let BU01 or BU02 to inherit member from CompA, not the other way.
So, maybe my understanding in using Space and subspace is not correct, or there is another practice to accomplish above structure?
Comment #3
jkingsnorth commentedThis might be an easy fix. I'll take a look at this today, just a tweak to the '_oa_core_build_visibility_links' function in oa_core\includes\oa_core_access.inc should do the trick.
@totolearn: This is an interesting idea, but it is a slightly larger issue/request that probably warrants a new issue - a feature request - being created for it? It may also be related to the upcoming: #2051597: Support to 2-way user inheritance on 2.x
Comment #4
jkingsnorth commentedHere's a first attempt at a patch that checks whether the parent node has og_user_inheritance set before listing it in the sidebar or in the members listing.
(I'm quite new to this so I look forward to hearing what I've done wrong!)
Comment #5
jkingsnorth commentedNope, this patch doesn't do the trick.
Sections in Spaces with inheritance off now do not display anything under 'Only members of these can see this page'. Their parent space should still be displayed here, even if they have inheritance turned off.
Comment #6
totolearn commentedI saw @mpotter's comment on "#2051597: Support to 2-way user inheritance on 2.x", so should I create a new issue for 2-way inheritance or already an issued created?
Comment #7
Argus commentedCleaning up old issues. I cannot reproduce this anymore. Please reopen if you think this is still an issue.