Plugin config: Delete entity along with GroupContent

Just found this which I think relates to a problem I'm having: #2854068: Relation not deleted when node is deleted

From an entity/node object, is it possible to determine if the entity is part of a group?

Hi imclean,

Here's the code we use to check if a node is part of a group, and if so to redirect to the group alias version of the node:

<?php

namespace Drupal\trinity_group_node_redirect\EventSubscriber;

use Drupal\group\Entity\GroupContent;
use Drupal\node\Entity\Node;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Drupal\Core\Path\CurrentPathStack;
use Symfony\Component\HttpKernel\Event\GetResponseEvent;
use Drupal\group\Entity\GroupContentInterface;
use Symfony\Component\HttpFoundation\RedirectResponse;

/**
 * Class RequestSubscriber.
 *
 * @package Drupal\trinity_group_node_redirect
 */
class RequestSubscriber implements EventSubscriberInterface {

  /**
   * Drupal\Core\Path\CurrentPathStack definition.
   *
   * @var \Drupal\Core\Path\CurrentPathStack
   */
  protected $pathCurrent;

  /**
   * Constructor.
   *
   * @param \Drupal\Core\Path\CurrentPathStack $path_current
   *   Current path object.
   */
  public function __construct(CurrentPathStack $path_current) {
    $this->pathCurrent = $path_current;
  }

  /**
   * {@inheritdoc}
   */
  public static function getSubscribedEvents() {
    $events['kernel.request'] = ['kernelRequest'];

    return $events;
  }

  /**
   * This method is called whenever the kernel.request event is dispatched.
   *
   * @param GetResponseEvent $event
   *   The requested event.
   */
  public function kernelRequest(GetResponseEvent $event) {
    $canonical_path = \Drupal::service('path.current')->getPath();
    $canonical_path_args = array_values(array_filter(explode('/', $canonical_path)));

    if (count($canonical_path_args) == 2 && $canonical_path_args[0] == 'node' && is_numeric($canonical_path_args[1])) {
      $node = Node::load($canonical_path_args[1]);
      if (!empty($node)) {
        /** @var GroupContentInterface $content_group */
        foreach (GroupContent::loadByEntity($node) as $content_group) {
          $source_path = $content_group->toUrl()->toString();
          $response = new RedirectResponse($source_path);
          $response->send();
        }
      }
    }
  }

}

Hopefully that can be some help to you.

I ve done some code for this.

Patch #7 works for me.

Maybe it would be nice too if the user could decide what should happen with the related content after the group deletion. (keep or delete) ?

I had to update the patch with the current 8.x-1.x state.

I just ran into this issue. My use case is in an automated test using Drupal Test Traits https://gitlab.com/weitzman/drupal-test-traits. The test automatically cleans up created entities during tearDown(), in the order that they were created. In my test, a user was being deleted before its content and that led to GroupContent deletions which led to re-saving of the content (e.g. a node-page). The re-save failed with Drupal\Core\Entity\EntityStorageException: Update existing 'node' entity while changing the ID is not supported.

I also saw this happenning when users are deleted, as they own nodes that get deleted which leads to GroupContent getting deleted and so it goes.

A re-roll of patch #9 to meet the current state of the dev branch

@moshe weitzman I couldn't reproduce the error you are receiving.

I just wanted to say that I'm having trouble with GroupContent::postDelete during migrate-rollback.
Here's my error message:
Drupal\Core\Entity\EntityStorageException: Update existing 'user' entity while changing the ID is not supported.

My use case is similar to #11 but not exactly the same: an automated Behat test automatically cleans up created users during tearDown(). In my test, a user was being deleted before its membership and that led to GroupContent deletions which led to re-saving of the user. The re-save failed with Notice: Trying to get property 'pass' of non-object in web/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/PasswordItem.php line 50 (Drupal\Core\Entity\EntityStorageException). In my case, the user-to-be deleted was not the owner of any group, but only a member of one. I could not reproduce the problem using Drupal's web UI either.

Re-rolled #12 anyway to meet the current state of the 8.x-1.x branch so it's also applicable to 8.x-1.4 (the latest stable release).

Here is a patch for group 2 and 3...

The patch in #15 is working for our website as we do not allow sharing content between groups.

Anyway, the proposed solution, is good when:

• Content is not shared at all
• Content is shared between same group type
• Their is no conflict in the delete settings -for the same relation plugin- in the multiple group types

But, I wonder what should happen in case an entity is shared between 2 groups of different group type; where the relation plugins in each group type has different settings for entity deletion. For example:

• Having group type A and group type B
• Enable the relation plugin for Page content type in both A and B group types
• In group type A: The configs for the plugin is > "Delete target entity when group relation is deleted" (So we always want to delete - No matter if the entity is being shared or not.)
• In group type B: We keep the default > Do not delete the entity (The option do delete the target entity is not selected).
• Create 2 groups: Group X of type A and Group Y of type B
• Create a page node in group X and share it with group Y
• 1. If the user deleted the relation in group X, the node will be deleted
• 2. If the user deleted the relation in group Y, the node won't be deleted

Case #1:
It is deleting an entity that is being shared with other group (of different type) that assumes an entity should not be deleted when deleting its relation.

I think we should have a third option e.g. "Only delete when all same relation plugins in other group type allow to delete".
When this option is selected, Case #1 won't delete the target entity as it is being shared with a group of another type that prevents deleting the target entities!

Here's a version of the patch for Group 1.0.x (tested on 1.6.0) that combines the patch from #12 with the patch from #3 of this issue: https://www.drupal.org/node/3364703

The two are unrelated, but since they touch the same code, you can't apply both at once. This is likely something that only a few people would run into and probably frowned upon by maintainers, but uploading anyways. All this does differently from #12 is reload the entity in order to check that it still exists before saving. Strangely the code comments around line 216 of GroupContent.php imply that this is already happening, but it's clearly not.

The $entity->delete() revealed that we're missing to install the users_data table, this failed in a custom test that was extended GroupKernelTestBase, so adding an install_schema() call to fix that.

Also there's a hidden branch with changes that combine these here with the ones for #2872697: Stop saving an entity when it gets added to or removed from a group comment #54 in case someone needs this too.