I personally tested this with Open Atrium 2.25, but I don't think there is anything in the OA code that is interfering.

Steps to reproduce

  1. Create a new group called "Parent group":
    1. Set "Group visiblity" to "Private"
    2. Set "Group user inheritence" to "No"
  2. Create a new group called "Child group":
    1. Set "Group visibility" to "Private"
    2. For good measure, set "Group user inheritence" to "No"
  3. Create a new user (who is not an admin in any way)
  4. Add that user as a member of "Parent group" but NOT "Child group"
  5. Logout and login in as this new user
  6. Expected behavior: you shouldn't be able to access "Child group" since it's private, your not a member, and inheritence is disabled.
  7. Current behavior: you are able to access "Child group" and any of it's content

So, there is a group heirarchy of:

-Parent group
--Child group

Cause

Node access grants are being added by "og_access" which give permission to view to members of both the parent and child groups. Here's an example:

mysql> select * from node_access where nid = 39479;
+-------+-------+----------------+------------+--------------+--------------+
| nid   | gid   | realm          | grant_view | grant_update | grant_delete |
+-------+-------+----------------+------------+--------------+--------------+
| 39479 |     1 | og_access:node |          1 |            0 |            0 |
| 39479 | 39479 | og_access:node |          1 |            0 |            0 |
+-------+-------+----------------+------------+--------------+--------------+

Where 39479 is the nid of the child, and 1 is the nid of parent. Only the 2nd access grant should be listed (giving access to members of the child group), not the first (giving access to members of the parent).

I've traced this to code in og_access_node_access_records(). It's building a list of group nodes to grant access to their members. It adds the group itself by default. But it adds to that list, the result of og_get_entity_groups('node', $node) which will return the parent group!

So, it's giving view access to members of the parent group, while not knowing anything about the special inheritence fields from og_subgroups!

Proposed solution

Adding a hook_node_access_records_alter() which goes over all the grants from og_access and removes any grants that don't respect the inheritence fields.

Comments

dsnopek’s picture

Status: Active » Needs review
StatusFileSize
new1.01 KB

Patch is attached! Please let me know what you think.

dsnopek’s picture

Issue summary: View changes
dsnopek’s picture

Title: Child groups and their content is always visible to members of the parent group, even if inheritence is disabled » Child groups are always visible to members of the parent group, even if inheritence is disabled
StatusFileSize
new1.05 KB
new830 bytes

Turns out this actually only affects the group pages themselves (not child content) and, in fact, by applying my change to child content causes collateral damage! So, here's a new patch that limits this to group pages.

dsnopek’s picture

hefox’s picture

ahaha

just found out the same thing.

Do you think something in oa or og changed and caused this? I can't find anything.

Anyhow, remaining issue that nothing triggers a rebuild of child content when parent settings are changed. I swear there was!

  • hefox committed 9f34504 on 7.x-2.x
    Issue #2379865 by dsnopek and hefox: prevent viewing child groups when...
hefox’s picture

Status: Needs review » Fixed

Reworked based on what I did before finding this (as it uses internal functions) and commited.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.