Entities identified by strings as group content

You can also use this module for Group 1.x to achieve what the patch does: https://www.drupal.org/project/group_content_string_id →

If you use the module, there is no use for the patch in this issue.

@SocialNicheGuru

But, even if i add that module, when i remove the patch, i still get the error ^

I'm having the same issue as #286 ✨ Entities identified by strings as group content Closed: won't fix . Has anyone found a solution for this?

@yojohnyo Yes and no..

I've been able to finally remove the patch, after running these SQL commands first:

ALTER TABLE group_content_field_data ADD entity_id INT(11);
DELETE FROM key_value WHERE name='group_content.field_schema_data.entity_id_str';
DROP TABLE group_content__entity_id_str;
DELETE FROM key_value WHERE name='group_content.field_storage_definitions';

BUT BARE IN MIND - These are destructive commands! I have not tested fully, and I'm not sure yet if this causes new issues.

It didn't work to delete the group_content_field_data. I was able to uninstall the patch with code like this:

$entity_id_definition = \Drupal\Core\Field\BaseFieldDefinition::create('entity_reference')
        ->setLabel(t('Content'))
        ->setDescription(t('The entity to add to the group.'))
        ->setDisplayOptions('form', [
          'type' => 'entity_reference_autocomplete',
          'weight' => 5,
          'settings' => [
            'match_operator' => 'CONTAINS',
            'size' => '60',
            'placeholder' => '',
          ],
        ])
        ->setDisplayConfigurable('view', TRUE)
        ->setDisplayConfigurable('form', TRUE)
        ->setRequired(TRUE);

Tried removing patch #279 and sure enough ran into the DefaultTableMapping error in Groups 1.5. I haven't delved into trying to run SQL statements mentioned in #290 and #276 yet, mainly because I inherited this project and can't figure out what this patch is even used for (it's not groupmenu -- it might be workflows?)

@yojohnyo Could you clarify where you put this code and how you came up with it? Do you add it to an install/alter hook in a custom module or do you patch it into the Group module somewhere?

In addition to #290 - I've had better luck with this:

/**
 * Alter the database, to not have broken Groups module config.
 *
 * In the past, we used the group_entityqueue module on the site, however that
 * has later been removed as it was not necessary. In order to get
 * group_entityqueue to work, we needed to include a patch for groups:
 * https://www.drupal.org/files/issues/2021-08-24/2797793-279.patch
 * https://www.drupal.org/project/group/issues/2797793.
 *
 * This patch basically refactored groups, to save group content IDs as strings
 * instead of ints. This causes an ungodly amount of trouble with updating to
 * groups 2.x / getting groups 1.x ready for D10.
 * The problem now is that we cannot just remove the patch, as it didnt include
 * any uninstall hooks (or, atleast not any that works). If we just remove
 * the patch, Drupal will refuse to do anything, including CR and UPDB.
 * So, before removing the patch, we need to undo the mess that it has left
 * in the database. We'll port the data back to group_content_field_data, and
 * remove the entity_id_str references.
 */
function bupl_departments_deploy_fix_groups_db() {
  $database = \Drupal::database();

  // We need to re-add the entity_id column to group_content_field_data.
  // Get data from the table that the patch added ('group_content__entity_id').
  $database->query("ALTER TABLE group_content_field_data ADD entity_id INT(11);");
  $database->query("
    UPDATE group_content_field_data
    JOIN group_content__entity_id ON group_content_field_data.id = group_content__entity_id.entity_id
    SET group_content_field_data.entity_id = group_content__entity_id.entity_id_target_id;
  ");

  // Now, we can remove all the messed up config, from the old field.
  $database->query("DELETE FROM key_value WHERE name='group_content.field_schema_data.entity_id_str';");
  $database->query("DROP TABLE group_content__entity_id_str;");
  $database->query("DELETE FROM key_value WHERE name='group_content.field_storage_definitions';");
}

I reset my database and code back to before I removed the patch to try that^ as an update hook in a custom module. Ensuring it runs before removing the patch fixed the issue I was having with Group Menus, thanks!

Obviously I still needed to update the views that had broken handlers before, but I already had a config export to deal with those. The diffs for the views were only one line:

--- a/config/views.view.group_members.yml
+++ b/config/views.view.group_members.yml
@@ -689,7 +689,7 @@ display:
       relationships:
         gc__user:
           id: gc__user
-          table: group_content__entity_id
+          table: group_content_field_data
           field: gc__user
           relationship: none
           group_type: group

I still need to do more testing and possibly debugging but this looks promising for my use case.

Hello @ras-ben,

I use your code in a HOOK_update_N() before making the upgrade, it works fine. Thanks !

I had one more issue about an unexpected value on a field content_translation_uid. In fact I had few elements with a very high content_translation_uid, once I deleted them all updates were running OK.

I am not sure why those elements are not ok, il will dig up this issue. I just check a few things, but group have theirs contents.

I'm trying to update to Group 2.1.0 now and am running into an issue with updatedb; I can't tell if it's because of the removed patch or not. Does this look familiar to anyone?

group    9203        hook_update_n   9203 - Update group_content DB table, fields and indexes.

>  [notice] Update started: group_update_9203
>  [error]  Missing langcode field.
>  [error]  Update failed: group_update_9203
 [error]  Update aborted by: group_update_9203
 [error]  Finished performing updates.
Failed to run drush updb -y: exit status 1

This patch 🐛 field definition empty in group_update_9203 Needs review worked to get me past the langcode field error. I had some strange errors and outputs that went away after some cache rebuilding. But I've run into another issue: 💬 Error after upgrading from 1.5 -> 2.1 Active .

In addition to #293, I found out that I didnt have the correct table structure afterwards.
It seemed to cause issues with views that had groups relationship.

Here is the expanded deploy hook, that *seems* to work better - but, please, use it at your own risk :)

/**
 * Alter the database, to not have broken Groups module config.
 *
 * In the past, we used the group_entityqueue module on the site, however that
 * has later been removed as it was not necessary. In order to get
 * group_entityqueue to work, we needed to include a patch for groups:
 * https://www.drupal.org/files/issues/2021-08-24/2797793-279.patch
 * https://www.drupal.org/project/group/issues/2797793.
 *
 * This patch basically refactored groups, to save group content IDs as strings
 * instead of ints. This causes an ungodly amount of trouble with updating to
 * groups 2.x / getting groups 1.x ready for D10.
 * The problem now is that we cannot just remove the patch, as it didnt include
 * any uninstall hooks (or, atleast not any that works). If we just remove
 * the patch, Drupal will refuse to do anything, including CR and UPDB.
 * So, before removing the patch, we need to undo the mess that it has left
 * in the database. We'll port the data back to group_content_field_data, and
 * remove the entity_id_str references.<em></em>
 */
function MY_MODULE_deploy_fix_groups_db() {
  $database = \Drupal::database();

  // We need to re-add the entity_id column to group_content_field_data.
  // Get data from the table that the patch added ('group_content__entity_id').
  $database->query("ALTER TABLE group_content_field_data ADD entity_id INT(11);");
  $database->query("
    UPDATE group_content_field_data
    JOIN group_content__entity_id ON group_content_field_data.id = group_content__entity_id.entity_id
    SET group_content_field_data.entity_id = group_content__entity_id.entity_id_target_id;
  ");

  // Make sure the entity_id column has the correct index keys and properties.
  $database->query("
    ALTER TABLE `group_content_field_data`
    MODIFY COLUMN `entity_id` int(10) unsigned DEFAULT NULL COMMENT 'The ID of the target entity.',
    DROP INDEX IF EXISTS `group_content_field__entity_id__target_id`,
    ADD INDEX `group_content_field__entity_id__target_id` (`entity_id`),
    DROP INDEX IF EXISTS `group_content__entity_fields`,
    ADD INDEX `group_content__entity_fields` (`type`,`entity_id`);
  ");

  // Now, we can remove all the messed up config, from the old field.
  $database->query("DELETE FROM key_value WHERE name='group_content.field_schema_data.entity_id_str';");
  $database->query("DROP TABLE group_content__entity_id_str;");

  // If we don't delete the whole field_storage_definition, we run into errors,
  // when we remove the patch.
  $database->query("DELETE FROM key_value WHERE name='group_content.field_storage_definitions';");

  // Alternatively to removing the whole field storage definition, I'd prefer
  // to just remove the reference to entity_id_str, but I couldnt get that
  // to work.
  /** @var \Drupal\Core\KeyValueStore\DatabaseStorage $key_value */
  /*
    $key_value = \Drupal::service('keyvalue')->get('entity.definitions.installed');
    $group_field_defs_key = 'group_content.field_storage_definitions';
    $group_field_defs = $key_value->get($group_field_defs_key);
    unset($group_field_defs['entity_id_str']);
    $key_value->set($group_field_defs_key, $group_field_defs);
  */
}

And, in addition to that, I've also added this deploy hook to run **AFTER** the patch has been removed.
Again - use at your own risk, but it seems to work well for me.

/**
 * Update invalid entity updates.
 */
function MY_MODULE_deploy_entity_updates() {
  $entity_type_manager = \Drupal::entityTypeManager();
  $entity_type_manager->clearCachedDefinitions();

  $entity_type_ids = [];
  $change_summary = \Drupal::service('entity.definition_update_manager')->getChangeSummary();
  foreach ($change_summary as $entity_type_id => $change_list) {
    $entity_type = $entity_type_manager->getDefinition($entity_type_id);
    \Drupal::entityDefinitionUpdateManager()->installEntityType($entity_type);

    $entity_type_ids[] = $entity_type_id;
  }

  drupal_flush_all_caches();

  return t("Installed/Updated the entity type(s): @entity_type_ids", [
    '@entity_type_ids' => implode(', ', $entity_type_ids),
  ]);
}

@kristiaanvandeneynde If I'm in Group 1.4 and I'm using this patch, but it want to update to Group 1.5, what is the workaround? The patches do not work with 1.5 and this issue https://www.drupal.org/project/group/issues/3292139 → is for Group 2.0.

@gwvoigt, sadly I never found a patch here that was architecturally sound enough to want to risk having to maintain for years to come. Over the years, I have looked at patches, reviewed some of them and kept second guessing the approach (even if suggested by me) until things started moving more in one direction around comments #246, #250 and #284.

Ultimately, I've often warned people on Slack and in other issues against using the patch here because it was still so heavily in flux and there was no guarantee that it would ever land. So as far as telling you what the workaround is, the honest answer is: I don't know.

After almost 6 years of discussion, someone (ANNAI) finally came along and wanted to sponsor this issue, accepting that we would probably have to break BC and therefore release a new major version. The result of that is that after weeks of work we finally have Group releases that fully support config entities being grouped in a way that doesn't heavily impact performance and doesn't warp the API by needing to inspect what we're trying to group.

So as far as I am concerned -and as the issue status shows- I consider this issue fixed and I would advise anyone still relying on this patch to carefully consider their options:

• Do you want to keep relying on a patch that will never get committed and using modules that depend on this patch to even work, or
• Do you want to invest that same time in looking for a way to upgrade to v2 and get this supported functionality out of the box

Upgrading to v2 should be as simple as downloading the latest versions of your submodules and running drush updb, following the change records to see if any of your custom code needs updating too. However, undoing this patch might be a huge pain in the ass, as demonstrated by the latest comments. You could, perhaps, get away with a same-site migration for the grouped config entities.

@kristiaanvandeneynde Thank you for your detailed reply. We are going to try to undo the patch and upgrade to 2.0.

I think I've successfully extricated this patch from my installation of Group 1.5, at least that's which version I *thought* was installed. When I look at my production module list, I see 8.x-1.0-beta3. I removed all menu relationships manually. I manually added the functions from #298 & #299 as group_update_8026 & group_update 8027 to group.install, and executed database updates. This didn't result in errors, and I was able to uninstall the groupmenu module afterwards. Then I went into a couple of group entities' edit menus, and was able to click around a bit without errors.

So, I'd like to replicate this process in my production environment, but in order to do that, I need a patch file that will add these update methods to the group.install file. However, I'm not sure which version of Group I should check out locally in order to create that patch file. I would expect to work with 8.x-1.x, but that is missing some database updates. As an added complication, if I update group, I now get a 1.6 version. Composer gives the following output:
- Upgrading drupal/group (1.5.0 => 1.6.0): Extracting archive

And then the patch I've been using doesn't apply properly. So, I'm confused on a couple of counts: why does drupal's GUI report that I'm using 8.x-1.0-beta3 but composer says I'm using 1.5.0?

What is the best way for me to generate a patch against 1.5.0, so I add these group_update_xxxx functions and undo the database updates that this patch made?

@ras-ben, do you have any insight into why this command might not work?

$database->query("DELETE FROM key_value WHERE name='group_content.field_storage_definitions';");

I applied your patches (#298 & #299) as database updates to group v1.5, but I was still running into errors. I looked at a the key_value table, and found an entry named 'group_content.field_storage_definitions', so it appears that command didn't work. I removed that record manually and the error went away, so other than that, everything appears to be working.

Has anyone started working on a new module to integrate menu config entities as group content for 2.x? Can we start a drupal/group_menu module?

I figured out how to get it working. For some reason, as mentioned in my last post, the sql command to remove the storage definition didn't get removed, but this command worked when I executed directly on the database server. This patch should apply cleanly to 1.5; you might need to change the update numbers to get it to apply to 1.6. If anyone else needs it, this is the content of the patch file I'm using:

diff --git a/group.install b/group.install
index d05dbb1..38c3f0c 100644
--- a/group.install
+++ b/group.install
@@ -722,3 +722,69 @@ function group_update_8025(&$sandbox) {
   \Drupal::entityDefinitionUpdateManager()
     ->installFieldStorageDefinition('entity_id_str', 'group_content', 'group_content', $entity_id_str_definition);
 }
+
+function group_update_8026(&$sandbox) {
+  $database = \Drupal::database();
+
+// We need to re-add the entity_id column to group_content_field_data.
+// Get data from the table that the patch added ('group_content__entity_id').
+$database->query("ALTER TABLE group_content_field_data ADD entity_id INT(11);");
+$database->query("
+  UPDATE group_content_field_data
+  JOIN group_content__entity_id ON group_content_field_data.id = group_content__entity_id.entity_id
+  SET group_content_field_data.entity_id = group_content__entity_id.entity_id_target_id;
+");
+
+// Make sure the entity_id column has the correct index keys and properties.
+$database->query("
+  ALTER TABLE `group_content_field_data`
+  MODIFY COLUMN `entity_id` int(10) unsigned DEFAULT NULL COMMENT 'The ID of the target entity.',
+  DROP INDEX IF EXISTS `group_content_field__entity_id__target_id`,
+  ADD INDEX `group_content_field__entity_id__target_id` (`entity_id`),
+  DROP INDEX IF EXISTS `group_content__entity_fields`,
+  ADD INDEX `group_content__entity_fields` (`type`,`entity_id`);
+");
+
+// Now, we can remove all the messed up config, from the old field.
+$database->query("DELETE FROM key_value WHERE name='group_content.field_schema_data.entity_id_str';");
+$database->query("DROP TABLE group_content__entity_id_str;");
+
+// If we don't delete the whole field_storage_definition, we run into errors,
+// when we remove the patch.
+$database->query("DELETE FROM key_value WHERE name='group_content.field_storage_definitions';");
+
+// Alternatively to removing the whole field storage definition, I'd prefer
+// to just remove the reference to entity_id_str, but I couldnt get that
+// to work.
+/** @var \Drupal\Core\KeyValueStore\DatabaseStorage $key_value */
+/*
+  $key_value = \Drupal::service('keyvalue')->get('entity.definitions.installed');
+  $group_field_defs_key = 'group_content.field_storage_definitions';
+  $group_field_defs = $key_value->get($group_field_defs_key);
+  unset($group_field_defs['entity_id_str']);
+  $key_value->set($group_field_defs_key, $group_field_defs);
+*/
+}
+
+/**
+ * Alter the database, to not have broken Groups module config.
+ */
+function group_update_8027(&$sandbox) {
+  $entity_type_manager = \Drupal::entityTypeManager();
+  $entity_type_manager->clearCachedDefinitions();
+
+  $entity_type_ids = [];
+  $change_summary = \Drupal::service('entity.definition_update_manager')->getChangeSummary();
+  foreach ($change_summary as $entity_type_id => $change_list) {
+    $entity_type = $entity_type_manager->getDefinition($entity_type_id);
+    \Drupal::entityDefinitionUpdateManager()->installEntityType($entity_type);
+
+    $entity_type_ids[] = $entity_type_id;
+  }
+
+  drupal_flush_all_caches();
+
+  return t("Installed/Updated the entity type(s): @entity_type_ids", [
+    '@entity_type_ids' => implode(', ', $entity_type_ids),
+  ]);
+}

Rerolled the patch on 1.6, this fixed the PHP Fatal error: Uncaught TypeError: Drupal\Core\Entity\Sql\DefaultTableMapping::Drupal\Core\Entity\Sql\{closure}(): Argument #1 ($definition) must be of type Drupal\Core\Field\FieldStorageDefinitionInterface, __PHP_Incomplete_Class given in /app/public/core/lib/Drupal/Core/Entity/Sql/DefaultTableMapping.php:174 for us.

So to fix it properly you need to make the same steps as in the patch.
Note we used #279 patch.

First deployment iteration -- backup all fields

In our database entity_id_str was empty so I didn't include it inside copiying update, but if you have you should include this field too.

/**
 * Copy the entity_id field to temporary table and remove unneeded fields.
 */
function biointeractive_group_update_9001(&$sandbox) {
  $query = \Drupal::database()
    ->select('group_content__entity_id', 'g');

  $query->addField('g', 'entity_id', 'id');
  $query->addField('g', 'entity_id_target_id', 'entity_id');

  // Initialize the update process, create a temporary table.
  if (!isset($sandbox['total'])) {
    $sandbox['total'] = $query->countQuery()->execute()->fetchField();
    $sandbox['current'] = 0;

    \Drupal::database()
      ->schema()
      ->createTable('group_content_entity_id_update', [
        'fields' => [
          'id' => [
            'type' => 'int',
            'unsigned' => TRUE,
            'not null' => TRUE,
          ],
          'entity_id' => [
            'type' => 'int',
            'unsigned' => TRUE,
            'not null' => TRUE,
          ],
        ],
        'primary key' => [
          'id',
        ],
        'description' => 'Temporary storage for group_content entity_id field migration',
      ]);
  }

  $rows_per_operation = 500;
  $query->condition('entity_id', $sandbox['current'], '>');
  $query->range(0, $rows_per_operation);
  $query->orderBy('g.entity_id', 'ASC');

  $rows = $query->execute()->fetchAll(PDO::FETCH_ASSOC);
  if ($rows) {
    $insert = \Drupal::database()
      ->insert('group_content_entity_id_update')
      ->fields(['id', 'entity_id']);

    foreach ($rows as $row) {
      $insert->values($row);
      $sandbox['current'] = $row['id'];
    }

    $insert->execute();
    $temp_count = \Drupal::database()
      ->select('group_content_entity_id_update')
      ->countQuery()->execute()->fetchField();
    $sandbox['#finished'] = ($temp_count / $sandbox['total']);
  }
  else {
    $sandbox['#finished'] = 1;
  }

  if ($sandbox['#finished'] >= 1) {
    // Uninstall obsolete fields.
    $entityDefinitionUpdateManager = \Drupal::entityDefinitionUpdateManager();
    $entityDefinitionUpdateManager
      ->uninstallFieldStorageDefinition($entityDefinitionUpdateManager->getFieldStorageDefinition('entity_id', 'group_content'));

    $entityDefinitionUpdateManager
      ->uninstallFieldStorageDefinition($entityDefinitionUpdateManager->getFieldStorageDefinition('entity_id_str', 'group_content'));
  }
}

Second iteration

1. Uninstall patch

2. Re-install entity-id field

   /**
    * Re-install entity_id field.
    */
   function biointeractive_group_update_9002(&$sandbox) {
     // Borrowed this logic from the Comment module.
     // Warning! May change in the future: https://www.drupal.org/node/2346347
     $definition = \Drupal\Core\Field\BaseFieldDefinition::create('entity_reference')
       ->setLabel(t('Content'))
       ->setTargetEntityTypeId('group_content')
       ->setDescription(t('The entity to add to the group.'))
       ->setDisplayOptions('form', [
         'type' => 'entity_reference_autocomplete',
         'weight' => 5,
         'settings' => [
           'match_operator' => 'CONTAINS',
           'size' => '60',
           'placeholder' => '',
         ],
       ])
       ->setDisplayConfigurable('view', TRUE)
       ->setDisplayConfigurable('form', TRUE)
       ->setRequired(TRUE);
     \Drupal::entityDefinitionUpdateManager()
       ->installFieldStorageDefinition('entity_id', 'group_content', 'group_content', $definition);
   }
   
   

3. Restore the data for group_content entity_id.

   /**
    * Restore the data for group_content entity_id.
    */
   function biointeractive_group_post_update_restore_entity_id_data(&$sandbox) {
     $query = \Drupal::database()
       ->select('group_content_entity_id_update', 'g')
       ->fields('g', ['id', 'entity_id']);
   
     // Initialize the update process, install the field schema.
     if (!isset($sandbox['total'])) {
       $sandbox['total'] = $query->countQuery()->execute()->fetchField();
       $sandbox['current'] = 0;
     }
   
     // We're now inserting new fields data which may be tricky. We're updating
     // group_content entities instead of inserting fields data directly to make
     // sure field data is stored correctly.
     $rows_per_operation = 50;
     $query->condition('id', $sandbox['current'], '>');
     $query->range(0, $rows_per_operation);
     $query->orderBy('id', 'ASC');
   
     $rows = $query->execute()->fetchAllKeyed();
     if ($rows) {
       /** @var \Drupal\group\Entity\GroupContentInterface[] $group_contents */
       $group_contents = \Drupal::entityTypeManager()
         ->getStorage('group_content')
         ->loadMultiple(array_keys($rows));
   
       foreach ($group_contents as $id => $group_content) {
         $group_content->entity_id->target_id = $rows[$id];
         $group_content->save();
       }
   
       end($rows);
       $sandbox['current'] = key($rows);
       $moved_rows = Drupal::database()
         ->select('group_content_field_data')
         ->isNotNull('entity_id')
         ->countQuery()->execute()->fetchField();
       $sandbox['#finished'] = ($moved_rows / $sandbox['total']);
     }
     else {
       $sandbox['#finished'] = 1;
     }
   
     if ($sandbox['#finished'] >= 1) {
       // Delete the temporary table once data is copied.
       \Drupal::database()->schema()->dropTable('group_content_entity_id_update');
     }
   }
   
   

I am confuse, is this fix for version 2.x?

I am confuse, is this fix for version 2.x?

No. It's outdated.

For Group 1.6 you can use https://www.drupal.org/project/group_content_string_id →

I am on a site that has been running the patch and I am trying to move to v2. However, we do use the groupmenu module for our groups and, at every turn, there seems to be an error.

I tried adding the functions in #298 to the groups.install file but I get a WSOD when I do. The error there says TypeError: Drupal\Core\Entity\Sql\DefaultTableMapping::Drupal\Core\Entity\Sql\{closure}(): Argument #1 ($definition) must be of type Drupal\Core\Field\FieldStorageDefinitionInterface, __PHP_Incomplete_Class given in /code/web/core/lib/Drupal/Core/Entity/Sql/DefaultTableMapping.php on line 175 #0 [internal function]: Drupal\Core\Entity\Sql\DefaultTableMapping::Drupal\Core\Entity\Sql\{closure}(Object(__PHP_Incomplete_Class)). But, if I execute the SQL commands directly on my database, I can run the update functions.

Then, I try going to the menus tab on any group and I again get a WSOD. The error that time is Uncaught PHP Exception Error: "Call to a member function toLink() on null" at /code/web/modules/contrib/groupmenu/src/GroupMenuContentListBuilder.php line 61. I have tried adding a simple if statement to the buildRow function so it becomes

  /**
   * {@inheritdoc}
   */
  public function buildRow(EntityInterface $entity) {
    if (empty($entity->getEntity())) {
		return;
    }
    /** @var \Drupal\group\Entity\GroupContentInterface $entity */
    $row['id'] = $entity->id();
    $row['label']['data'] = $entity->getEntity()->toLink(NULL,'edit-form');
    $row = $row + parent::buildRow($entity);
    unset($row['entity_type'], $row['plugin']);
    return $row;
  }

and that will get me into the menu page. But, any related menus are gone. I try to relate a menu or create a new one and, again, I get a WSOD with the error saying Uncaught PHP Exception TypeError: "Drupal\group\Entity\Group::addContent(): Argument #1 ($entity) must be of type Drupal\Core\Entity\ContentEntityInterface, Drupal\system\Entity\Menu given, called in /code/web/modules/contrib/group/group.module on line 660" at /code/web/modules/contrib/group/src/Entity/Group.php line 154

And, before anyone mentions it, I have tried adding the Group Content with String IDs → module and it doesn't do anything.

That is to say nothing about how I have tried to upgrade to v2 after all of this and I have gotten issues with running the update script. Like the folks on https://www.drupal.org/project/group/issues/3322567 🐛 Error on update from 1.5 to 2.0 Active and https://www.drupal.org/project/group/issues/3363130 🐛 Database update errors when upgrading from 1.5 to 2.1 pluginid not found Active I have been having issues when trying to get group_update_9203 to run. I have gotten errors saying: Failed: Drupal\Core\Entity\EntityStorageException: The entity update process failed while processing the entity type group_content, ID: 7185. in Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->copyData() (line 220 of /code/web/core/lib/Drupal/Core/Entity/Sql/SqlFieldableEntityTypeListenerTrait.php).

Does anyone have a solution on how to uninstall the patch while still having the groupmenu module work?

Does anyone have a solution on how to uninstall the patch while still having the groupmenu module work?
I don't, but when facing a rough Groups upgrade recently, I ended up exporting the Group and Group content to .csv, then deleted all the content, re-built with Groups 3.0, then created a migration script into the new structure, with the .csv files as the datasource.
It was a headache, but not the nightmare that trying to get the upgrade to work was.