Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
- Grandparent (private)
-- Parent (public [to grandparent]
--- Child (public [to parent])
Child ends up being a totally public group instead of to parent. Child's node access is based on parent but not grandparent, because og_access only checks parents and og_subgroups only removes access to groups that don't have inheritence settings.
Comment | File | Size | Author |
---|---|---|---|
#12 | 2407399-og_subgroups-parent-12.patch | 5.04 KB | mpotter |
#11 | 2407399-og_subgroups-parent-11.patch | 4.87 KB | mpotter |
#5 | 2407399-og_subgroups-parent-5.patch | 4.4 KB | hefox |
#4 | 2407399-og_subgroups-parent-4.patch | 4.38 KB | hefox |
#2 | 2407399-og_subgroups-parent-2.patch | 4.34 KB | hefox |
Comments
Comment #1
hefox CreditAttribution: hefox commentedComment #2
hefox CreditAttribution: hefox commentedPatch was only checking the content access field (which groups may not have) instead of the group access field
Comment #3
JKingsnorth CreditAttribution: JKingsnorth commentedConfirmed that #2 fixes the issue - private groups under public groups are no longer publicly available. Patch applied cleanly.
Tested with:
Public Group
^ inherit
Private Group
Previously the Private Group was visible to non-members. Now it is only visible to direct and inherited members, as it is supposed to.
This issue still exists, but is probably specific to the OA distribution: #2445069: Section visibility by group not working correctly
Comment #4
hefox CreditAttribution: hefox at Phase2 commentedThis introduced another problem, fixing
Comment #5
hefox CreditAttribution: hefox at Phase2 commentedI'm not sure how I missed /that/ (in previous patches also)
Comment #6
rooby CreditAttribution: rooby commentedWill this patch help me achieve this structure
-Grandparent group (public) - Group content (private)
-- Parent group (private) - Group content (private)
--- Child group (private) - Group content (private)
Where a member of the grandparent group gets access to parent and child groups under it and a member of the parent group gets access to the child groups under it?
Comment #7
BrightBold@rooby - I haven't yet tried the patch above so don't know the answer, but also look at https://www.drupal.org/sandbox/liberatr/2449227 which will hopefully get converted into patch form if it does what people want. It was specifically designed to address some of these content inheritance issues.
Comment #8
rooby CreditAttribution: rooby commentedThanks for the info. Unfortunately that module doesn't quite cover my requirements.
This patch can pretty much get me what I needed in my above comment but what I didn't mention in my previous comment is that only some roles get public access to the grandparent group.
So for that I'm going to have to get the port of https://www.drupal.org/project/og_access_roles up to scratch (https://www.drupal.org/node/1853494).
Fingers crossed it doesn't need much work to get it compatible with the current version of OG.
After that I'm going to have to patch this module to support that roles based module.
Comment #9
mpotter CreditAttribution: mpotter commentedWe have been using this patch in Open Atrium for a while now. Marking this as RTBC and will commit it soon unless somebody has objections.
Comment #10
mpotter CreditAttribution: mpotter commentedSpoke a bit too soon. This patch needs to be altered a bit to handle some more general cases. Will post an updated patch with discussion soon.
Comment #11
mpotter CreditAttribution: mpotter commentedOK, here is the new patch for review.
The difference between this and #5 is refactoring the logic for determining if the parent groups are private or not. It adds a function og_subgroups_is_parent_private() which adds an alter hook for this.
The reason for this is that you might have different kinds of OG groups with either custom fields or values to determine if a child group should be forced to be private or not. There are some use-cases where having a private parent group does *not* cause the child to be private. Just checking the group_access field is a good default, but this alter hook allows it to be changed.
A specific example: In Open Atrium, having a private parent *space* should cause the child space to be private. But just having a private parent *group* should NOT cause the child space to be private. We want to be able to inherit membership from private access-groups without making the space itself private.
So, here is an updated patch with this refactor and alter hook:
Comment #12
mpotter CreditAttribution: mpotter commentedHere is a minor update with improved comments, fixed docblock, and fixed spelling.
Comment #13
JKingsnorth CreditAttribution: JKingsnorth commentedThat patch in #12 is included in the Open Atrium distribution and the behaviour I described in #3 is still working as expected. Thanks for the work on fixing this.
Two very minor comments about the patch, but nothing that would block it. I haven't checked the 'grandparent' logic in the original issue description though.
Double ternary operator not so readable? Expand it, or add a comment to explain the logic?
Unnecessary comment line (but who cares ;] )
Comment #15
mpotter CreditAttribution: mpotter commentedOK, committed this to a9d31c7.
I removed the comment and split the ternary operation over a few lines to make it more readable.
I also went back and tested the case shown in the OP to verify that it works now.
Comment #17
markdcI don't understand which fields to use in order to achieve this. Documentation?