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.

Issue fork group-2919982

Command icon 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:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Zemo created an issue. See original summary.

Zemo’s picture

Title: Group and Group Node Access for each creator? » Group and Group Node Access selectable for each creator?
johnsicili’s picture

I 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?

Dylan Donkersgoed’s picture

Assigned: Zemo » Unassigned
Status: Active » Needs review
FileSize
3.72 KB

On the surface this doesn't seem to be too complicated. I:

  1. Added a new "Is Private" base field and related method for checking it to Group entities
  2. Added some code in Drupal\group\Entity\Group::hasPermission() to return FALSE if the group is marked as private and the user has the outsider role
  3. Adjusted gnode_node_grants() to exclude private groups from the outsider grants

#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.

Status: Needs review » Needs work

The last submitted patch, 4: 2919982-4-group-and-group-node-access-selectable.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Dylan Donkersgoed’s picture

Here'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.

Status: Needs review » Needs work

The last submitted patch, 6: 2919982-6-group-and-group-node-access-selectable.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

a_mitch’s picture

a_mitch’s picture

a_mitch’s picture

Status: Needs work » Needs review
Dylan Donkersgoed’s picture

This 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.

djdevin’s picture

This doesn't protect the group from anonymous users

$account_is_outsider = in_array(
          $this->type->entity->getOutsiderRoleId(),
          array_keys($group_roles)
        );

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.

djdevin’s picture

Updated the issue fork.

Tested with an admin, logged in group member, logged in outsider, anonymous user.

Dylan Donkersgoed’s picture

It 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.

Dylan Donkersgoed’s picture

Component: Group (group) » Code
Status: Needs review » Needs work

Don'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".

Dylan Donkersgoed’s picture

Status: Needs work » Needs review

I'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.

Dylan Donkersgoed’s picture

I'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.