Have a group status field that affects access

Suresh,

Please read the issue tag guidelines and abstain from adding random tags on issues.

For groups I don't think this is a good idea. What will happen to a group's members when the group is unpublished? Will they lose their permissions? What happens to its content? etc.

Unless someone comes up with a good use case for it, I'd rather abstain from implementing unpublished groups.

I would think that we’d need several states for Groups. I propose:

1. Active (normal, way things work now — visible to and editable by whoever has permissions)
2. Suspended (invisible to all but Site and Group Admins, all content and users remain but non-Admins can’t access any of that group’s content except their own)
3. Closed (invisible to all but Site Admins — even Group Admins can’t access anything — useful for paid group services when a group hasn’t paid up — content remains but is inaccessible to all except User 1 and maybe Administrators)

For Suspended and Closed, the Users (and Group Admins in the case of Closed) would retain permissions but would be Blocked from logging in, or would be redirected to a specific page when they do (such as a billing payment page).

I reopened it because I have a valid use case for this feature in that some publishers want it.

A typical scenario would be where a group is brought together for an event. The Group is created and then at the end of the event they want to close the whole Group down. With the Group unpublished the members would lose access to the content.

There needs to be an option to close the group, to prevent users from joining or adding content.

Okay, I’m using group to represent courses in elearning. I want to be able to prepare a course (group entity) before it is published to the masses. And then maybe unpublished it at times it is not required. I would not want to lose it’s current relationships whilst unpublished but I’d not want normal users to be able to interact with it or its content. Essentially, I’d like it to behave as though nobody except the admin role was a member until published again.

I could use this again on https://new.horizonsunlimited.com/tstories to publish/unpublish stories as they are edited and expand usage of group into events - I’d like to prepare events before they are published to the masses.

I changed the Issue Title to reflect that we’re no longer talking about Publish / Unpublish, which is the wrong terminology (and wrong concept) to use for this, and also that the desirable status options should amount to more than a binary checkbox-type setting. I still like what I detailed in my #4 with Active / Suspended / Closed status.

Also requesting this functionality for the 7.x-1.x branch.

To expound a bit: this should probably be named “Group Access Status” with options as follows:

1. Active: (normal, way things work now — visible to and editable by whoever has permissions)
2. Suspended: (invisible to all but Site and Group Admins, all content and users remain but non-Admins can’t access any of that group’s content except that which they own)
3. Closed: (invisible to all but Site Admins — even Group Admins can’t access anything, not even their own content — useful for paid group services when a group hasn’t paid up — content remains but is inaccessible to all except User 1 and maybe Administrators)

There may be possible additional options. Ideas?

Earlier I said that with Suspended and Closed, that logins should be blocked or redirected. I rescind that and now say that just the Group-implemented permission grants should be suspended. Login Redirects should be handled via Rules, which would allow more power and could work right away once the Status itself exists (assuming it’s properly accessible to Rules).

Such Rules would need to be crafted with the proper conditionals to handle the situation where a person is a member or Group Admin of more than one Group, at least one of which is Active and at least one of which is Suspended / Closed. Obviously we wouldn’t want to lock them out of the Active Groups’ content.

Rules could hypothetically also do things like detect if the user is a Group Admin, then, on attempt to view a Closed Group Page that the user is Admin of, redirects to a payment page that would, upon verification of payment, set the Group Status to “Active.” Non-Admin members would instead be redirected to a page that says something to the effect of, “Sorry, but {group name}’s membership has expired and is suspended. Please inform your Group Admin, {admin name}, and encourage him/her to render payment, which s/he can do by logging in and coming here.”

Hi,
After you apply patch run command drush updb -y because I added new field 'group_access_status'
go to the /admin/group and there you should see new column Group Access Status.
All of your previous groups should have default status 'active'.

1. Active: (normal, way things work now — visible to and editable by whoever has permissions)
2. Suspended: (invisible to all but Site and Group Admins, all content and users remain but non-Admins can’t access any except their own content)
3. Closed: (invisible to all but Site Admins — even Group Admins can’t access anything, not even their own content — useful for paid group services when a group hasn’t paid up — content remains but is inaccessible to all except User 1 and maybe Administrators)

All of that should work, but for 'suspended' and 'closed' status I think there should be some configuration.
For example, if I have Roles Moderators and Group Admins I want both of them to access Group and Group Content, but I don't want to apply permission 'Administer Group' to Role Moderators, with this patch there is no option to change this behavior...
For Group Admin I am assuming it's user with permission 'bypass group access'.

Just chiming in to say that it might be a (long) while before I start adding this type of functionality to Group because there is so much more that still needs doing.

But, looking at the patch, there is also good news! Seeing as you're mainly altering access control handlers, you could write a small module that swaps out the group and group content ACHs with your own copies that extend the original ones, albeit with your minor changes.

If you happen to go down that path, please make sure to post a link to said module here.

This is a requested feature for an application I am working on. I applied matjaz_zavski (#10s) patch and it is looking good so far. Thanks

I have a perfect use case for this and think this is _absolutely_ reasonable.

My use case is tied to commerce_license functionality whereby members of groups must have their group pay for a license for membership. What this requires is the proper Plugin for the commerce_license module that would activate or deactivate the group based on the license. Without this functionality, I would have no way to blanket remove access to our site if a Group admin did not pay for the annual license.

+1 for this enhancement.

@matjaz_zavski, thanks for your patch #10 incorporating my suggestions!

In my use case, I’m using #2317195-88: Allow more than one parent by node / subgroup-patched 7.x-1.0-beta6+21-dev, which is a major rewrite of 7.x (especially in gnode and ggroup submodules), so that patch is useless to me personally, but I can see the concepts and it gives me hope of being able to implement it there myself.

I believe that 8.x includes Multiple Parent Groups functionality built-in, without need for a patch. This brings up some considerations re: access for nodes or other content that have multiple parent groups: what to do if only one or some but not all of the parent group(s) of a given content entity is Suspended or Closed?

I would assume that the access should be handled based on the User who’s logged in, and the group(s) that s/he belongs to. If the User is a member of any Group that’s still Open, then any content under that Group should remain accessible to that User as per the access settings for that User’s Role in that Group Type, even if the User is also a Member of one or more Suspended or Closed Groups that are also Parent(s) of the content Entities in question.

But I can also imagine use cases for a stricter reverse implementation: if a Group is Suspended or Closed, access is denied to all non-Admins (or non-Group Admins in the case of Suspended) to all content Entities that that Group is a Parent of, even if the User is a Member or even Group Admin of some other Open Group that’s also a Parent of the content in question.

Maybe we should have additional options for those, so that it’s set on a per-group basis? Maybe a checkbox that is disabled (grayed out) if Open is selected but becomes enabled if Suspended or Closed is selected, to deny access even to content that has one or more Open Groups as additional Parents and even to Members of said Open groups?

I think the access status field functionality will need to be expanded with some level of configuration specific to child groups so that there is not fixed logic or assumed logic. In the case of child groups, the child and/or parent group might have additional configuration for what to do with members of child groups and include the logic in a configuration setting - 'Block member access to this group if any parent groups are closed' 'Block member access to this group if all parent groups are closed' - or some such setting.

I would assume that the access should be handled based on the User who’s logged in, and the group(s) that s/he belongs to. If the User is a member of any Group that’s still Open, then any content under that Group should remain accessible to that User as per the access settings for that User’s Role in that Group Type, even if the User is also a Member of one or more Suspended or Closed Groups that are also Parent(s) of the content Entities in question.

That makes sense to me and my use case.

Maybe we should have additional options for those.

- yes, I think the options would have to be set on the child group, right? As above, decide if the group is closed if either ONE or ALL parent groups are closed.

I can't update my current groups.

drush entity-updates
group entity type :
The Group Access Status field needs to be updated.
Do you wish to run all pending updates? (y/n): y
Cache rebuild complete. [ok]
Finished performing updates.

But if I goto status reports there is still an issue.
I can run the drush command again and the same shows up

it would be nice if this was a field that would show up on the manage form tab. (

+1 for fields that allow us to publish or unpublish a group. My use case aligns with folks that need the ability to stage and decommission subsites that are groups.

I've repeated this model a few times in D7 with Organic Groups, including the Documentation Sections on D.o and two large government sites where the groups were subsites that would spend time in an unpublished state until the content was fully written and then would go live with a publish action.

+1 for group publish/unpublish option. I need this to keep sanity on the site - group owners and their team memebrs should have a possibility to develop their group without publishing it and then decide to make it public.

Admittedly, this is possible to do today - just add a "Do you want to make this public?" boolean variable to a group and filter on it in a view...

I tried this and it seemed to remove access even for the admin user of any group to do any CRUD operations on any existing groups.

@Deno If it's just views you're interested in limiting, you're right, but this patch I believe is intended to go further and extend the permissions/access plugin of the group itself so that even if you know the URL to an unpublished group you still can't get to it without the proper permissions.

+1 for group status as well. We need to be able to have users work to port content, and not release the group until they are complete.

Reviewing the patch now. Seems reasonable.

Has any thought been giving to an implementation using the core EntityPublishedInterface / EntityPublishedTrait with groups?

use Drupal\Core\Entity\EntityPublishedInterface;
use Drupal\Core\Entity\EntityPublishedTrait;

This issue overlaps with #2873212: Add a status to the group (Publish/Unpublish)

For us, matjaz_zavski's patch worked correctly. We are able to add status and restrict user access. But we need more fine grain control over permission, so we are adding those in this patch.

#27 patch will only apply to 8.x-1.0-rc2

@arijits.drush
This is depercated and should be avioidedt('string') use $this->t('string) instead
GroupAccessControlHandler::checkAccess

-        return GroupAccessResult::allowedIfHasGroupPermission($entity, $account, 'view group');
+        return $this->checkGroupStatusAccess($entity, $account, 'view group');

You should create another method inside `GroupAccessResult` or another service or PermissionChecker
GroupAccessControlHandler::checkGroupStatusAccess
Use `===` instead, create new constants for `active` and `suspended`

+    // If group is suspended.
+    elseif ($entity->getGroupAccessStatus() == 'suspended') {
+      // Check if user have 'administer group' permission or
+      // 'administrator' role of if have user id 1.
+      if (GroupAccessResult::allowedIfHasGroupPermission($entity, $account, 'administer group')->isAllowed() || AccessResult::allowedIfHasPermission($account, 'bypass group access')->isAllowed() || GroupAccessResult::allowedIfHasGroupPermission($entity, $account, 'bypass suspended group status')->isAllowed()) {
+        return AccessResult::allowed();
+      }
+      else {
+        return AccessResult::forbidden();
+      }
+    }
+    // If Group is closed.
+    elseif ($entity->getGroupAccessStatus() == 'closed') {
+      // Check if user is administrator or have account id of 1.
+      if (AccessResult::allowedIfHasPermission($account, 'bypass group access')->isAllowed() || GroupAccessResult::allowedIfHasGroupPermission($entity, $account, 'bypass closed group status')->isAllowed()) {
+        return AccessResult::allowed();
+      }
+      else {
+        return AccessResult::forbidden();
+      }
+    }

That can be handled inside one `elseif`

+    // Return forbidden.
+    else {
+      return AccessResult::forbidden();
+    }

Return early...

if ($entity->getGroupAccessStatus() !== 'suspended' AND $entity->getGroupAccessStatus() !== 'active') {
return AccessResult::forbidden();
}

GroupContentAccessControlHandler::checkAccess
Conditions in if/elseif are just too much can boiled down into multiple lines...

+    // Check other access.
+    else {
+      /** @var \Drupal\group\Entity\GroupContentInterface $entity */
+      return $entity->getContentPlugin()->checkAccess($entity, $operation, $account);
+    }

Return early

GroupContentAccessControlHandler::form

+        '#description' => t('Invisible to all but Site and Group Admins, all content and users remain but non-Admins can’t access any except their own content.'),

Something is wrong with the text

You are missing tests!

In thinking about this some more (great to see actual progress on this!), I think at least one more option should be available:

• Hidden — Same as Active for purposes of access, but is hidden by default from queries that would return a list of active, visible groups, such as for a master landing page or groups search or list of groups a user could join. To include Hidden (or Suspended or Closed) groups in the results, conditions or flags would need to be used. This would be analogous to Secret Groups on Facebook, for instance, and I think would satisfy the original request for Unpublished Groups (I think the terms “Publish(ed)” and “Unpublish(ed)” should only refer to content and never to groups). This could be used for setting up a group before making it visible but still having it and its content accessible to those who were given a URL enabling them to join the group.

I disagree that Groups should not have the option for workflow. Any entity that renders at a path should have the option for both revisions and workflow: node, term, group, etc. These are all "content" that an editor might want to stage because they have fields and layout.

A common use case for the Group module is to create smaller sites within a larger Drupal installation. The group is typically the homepage in this model with several fields of content of its own.

I can imagine revisioning support will become even more important as the content staging thing becomes a non-experimental module

Neither patches are applying clean for me on 8.x-1.x-dev.

For update module to version 8.x-1.0-rc3 use next patch

Only removed a trailing whitespace from group-general_acces_status-2850377-34.patch:16 (#34).

RC3 patch

This seems to overlap heavily with #2829966: Support for Revisions on groups, in particular #2873212: Add a status to the group (Publish/Unpublish). Tempted to call this duplicate and move effort over there for a more complete solution.

Judging from the comments,
https://www.drupal.org/project/group/issues/2873212 is ready (?) and about to be rolled into the next release.

That would make this issue obsolete....

Hi,
i have a use case not covered by a simple "published / unpublished" status.
I use group to organise events. Users can join the group to register to the event.
I would like to control the "join" permission by a "status" field (taxonomy for eg) to gradually allow permissions regarding users roles. Finally users with "early joiner" role can register to the event when the "status" field take the value 'early registration'. The others can only register when field take the value 'fully open'.

I see that like using the "permission by term" logic to control 'join group' permission.

I will read patches proposed here and see how to use them or develop my own module, but if this function can be implemented by "pro", it would be helpful.
By the way, I would be happy to get some help to find the right way to interact with group permission :). I haven't found out yet the right documentation to explain that.

CBE

Looks like #2829966: Support for Revisions on groups will provide this functionality. Will test with my existing configuration.

Anyone have recommendations on how to update the data base schema if you used patch #10. I'm trying to remove the "group_access_status" field but it just keeps coming back. And then I have various entity field errors.

/**
 *  Remove the old group_access_status field
 */
function my_module_update_8001()
{

  $schema = Database::getConnection()->schema();
  $fieldExists = $schema->fieldExists('groups_field_data', 'group_access_status');

  // Check if field already exists.
  if ($fieldExists === TRUE) {
    $schema->dropField('groups_field_data', 'group_access_status');
  }
  drupal_flush_all_caches();
}

Ok, got my answer from some tinkering. If you were like me and used patch #10 to add this functionality but no longer want it because you are applying #2873212: Add a status to the group (Publish/Unpublish), you need to use this method to properly remove the added 'group_access_status' field.

/**
 *  Remove the old group_access_status field definitition
 */
function my_module_update_8001() {
  $definition_update_manager = \Drupal::entityDefinitionUpdateManager();
  if ($group_access_status = $definition_update_manager->getFieldStorageDefinition('group_access_status', 'group')) {
    $definition_update_manager->uninstallFieldStorageDefinition($group_access_status );
  }
}

Patch #2873212 set all of the Groups to published ('status' === 1), so if you have any suspended, you may need to use this update function PRIOR to running the above:

  $query = \Drupal::database()->update('groups_field_data');
  $query->fields([
    'status' => 0,
  ]);
  $query->condition('group_access_status', 'suspended');
  $query->execute();

For group module version 8.x-1.3

Hi,

I have 2 clients with the need for this -- both e-commerce related, we want to be able to suspend the group entirely by unpublishing it, which should make it so users in those groups cannot see or access their content. Essentially the simple "Active" or "Closed" options from comment 3 and 9 -- we don't need "suspended".

The patch does not apply cleanly to 1.4, so I was going through and updating the patch. Now that there's a status field and revisioning, I'm wondering if this can be simplified to use the regular publishing status, and just enforce access (based on new group permissions).

I think I'm going to update the patch in that direction -- use the "status" field, add group permissions as described here to control whether people of various group/outsider roles can access content when status is 0. I would think "suspended" could be spun out into a different field/functionality.

To be clear, I'm not planning to update user accounts based on this -- on the sites I'm building this for, users who are not in a group can't do much on the site at all, and it's possible for a user to be a member of multiple groups. So if a group gets unpublished, we revoke all access to content in those groups, and leave the user accounts alone.

Does this approach work for others?

Cheers,
John