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.
Hi.
Is there a Option for every creator of a Group to select if his Group public or privat.
I only see this as admin of the side in the Group Setting for each Group type but i don`t find Settings as creator for only this Group.
I would like to let each group owner decide whether his group or group node is public or only for the group. Preferably so that he can change it later.
Sorry for my bad english.
Comment | File | Size | Author |
---|---|---|---|
#11 | interdiff.txt | 624 bytes | Dylan Donkersgoed |
#11 | 2919982-11-group-and-group-node-access-selectable.patch | 2.93 KB | Dylan Donkersgoed |
#9 | 2919982-9-group-and-group-node-access-selectable.patch | 2.52 KB | a_mitch |
#8 | interdiff_6-8.txt | 1.72 KB | a_mitch |
#8 | 2919982-8-group-and-group-node-access-selectable.patch | 4.03 KB | a_mitch |
Issue fork group-2919982
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
Zemo CreditAttribution: Zemo commentedComment #3
johnsiciliI also opened a request for this as I couldn't find anything. Closing out my request for "within one group type there may be public and private groups."
Have you found a solution to this?
Comment #4
Dylan Donkersgoed CreditAttribution: Dylan Donkersgoed at Northern Commerce commentedOn the surface this doesn't seem to be too complicated. I:
#3 was an unexpected extra change that needed to be made for nodes specifically. This worked out of the box with groups themselves. Not sure if there's any other weird situations like that that need to be accounted for.
It will be necessary to clear your cache and rebuild your node permissions (with /admin/reports/status/rebuild) after applying this patch.
Comment #6
Dylan Donkersgoed CreditAttribution: Dylan Donkersgoed at Northern Commerce commentedHere's a rerolled patch for the current dev branch/more recent versions of the module. The logic it adds in Group::hasPermission() has changed a bit since the logic for calculating permissions has changed substantially. I'm actually not sure it's the most appropriate place to put it now but it does seem to work.
Comment #8
a_mitch CreditAttribution: a_mitch commentedRe Rolling for current dev branch
Comment #9
a_mitch CreditAttribution: a_mitch commentedRerolling for current dev
Comment #10
a_mitch CreditAttribution: a_mitch commentedComment #11
Dylan Donkersgoed CreditAttribution: Dylan Donkersgoed at Northern Commerce commentedThis patch does not take into account the 'bypass group access' permission so you can end up with situations where admins/superadmin cannot access groups. I'm attaching an updated patch to address that.
Comment #12
djdevinThis doesn't protect the group from anonymous users
outsider role ID is "group-outsider"
but $group roles only has "group-anonymous" in it so it doesn't mark the user as an outsider and returns true.
I think it should check getMemberRoleId() instead which is the equivalent of the authenticated user role within a group.
Comment #13
djdevinUpdated the issue fork.
Tested with an admin, logged in group member, logged in outsider, anonymous user.
Comment #15
Dylan Donkersgoed CreditAttribution: Dylan Donkersgoed at Northern Commerce commentedIt appears that the hook_node_grants() logic was lost in an earlier reroll. While hook_node_grants() specifically is no longer applicable we still need something similar for handling access in lists. I've pushed up a new commit to handle that. I'm also opening a WIP MR mainly so there's an easily accessible place to download the patch (i.e. https://git.drupalcode.org/project/group/-/merge_requests/6.patch).
Probably this patch should have some tests to go with it to catch issues like this. I don't have time for that right this second but may come back to it later so marking the MR as a WIP for now.
Comment #16
Dylan Donkersgoed CreditAttribution: Dylan Donkersgoed at Northern Commerce commentedDon't have time to fix it right this second myself but for anyone using this patch be aware that there is an issue with installing it on sites that already have groups. They'll end up having the is_private field set to NULL which will cause them to be excluded from lists as though they were private (since the filter checks for groups with is_private set to FALSE, not groups with a falsey is_private value). Probably the post_update hook in the patch should be expanded to set this value to FALSE by default. So I'm setting this to "Needs Work".
In the meantime if you want to use the patch on a site that already has groups you can fix it manually, e.g. "drush sqlq "UPDATE groups_field_data SET is_private = 0 WHERE is_private IS NULL; && drush cr".
Comment #18
Dylan Donkersgoed CreditAttribution: Dylan Donkersgoed at Northern Commerce commentedI've added a new MR against the 3.x branch. In addition to being 3.x compatible it fixes the update issue I mentioned above.
Comment #20
Dylan Donkersgoed CreditAttribution: Dylan Donkersgoed at Northern Commerce commentedI've closed the 3.0.x MR. Instead I've created a dev module at https://www.drupal.org/project/group_privacy. It works in a similar way but it alters the query provided by group and overrides the permission handler instead of patching the module.