The update from version 2.3.0 to 3.3.0

My problem is solved by uninstalling the group_support_revisions module

Tests for that submodule do go green, so unless there are steps to reproduce on a clean install, this cannot be fixed.

same for me. add member is completely gone. testing the reinstall of group via devel now. if that doesn't work, will try uninstalling group_support_revisions.

neither worked for me.

here is the url for adding a member if anyone needs it: /group/[group:gid]/content/add/group_membership

idk if that's the actual token, [group:gid], but just know that's where the group id goes.

I'm also having issues adding/editing group memberships with Groups 2.3.0. On my /[group]/memberships page, the "+ Add member" button is gone and I can only edit memberships that I created, even though I have the administrator role and have configured the appropriate insider and outsider group roles that sync with the sitewide administrator role.

The Add member button and Edit membership links appear if I uninstall the group_support_revisions module or if I downgrade to Groups 2.2.2 and Flexible permissions 1.1.0.

Also, interestingly I do technically have the permissions necessary to add a member by manually going to /[group]/content/add/group_membership, even though the button doesn't appear on the group membership page. Likewise, I can edit memberships by manually going to /[group]/content/[id]/edit, even though the edit links don't appear on the group membership page or on /[group]/content/[id]

So it seems that it's only miscalculating my permissions when deciding whether or not to show the buttons/links.

While I appreciate people chiming in to report it's broken for them too, I need steps to reproduce or I cannot investigate this. Leaving open for a while to give people the opportunity to provide these steps, but I'll be forced to close this issue if I can't reproduce it.

Hi kristiaan I hope this helps

Create a new group type `example` (with admin role) granted to creator and don't make them complete membership on group creation.
Observe permissions page for group and see that inside administrator has all boxes checked green since they are marked as "is_admin".
Create a new group of type `example` as admin user.
Navigate to /group/1/content/create/group_membership and experience 403 access denied.

Hi, I also have this issue after updating to 3.3. It persists regardless of using Claro or GIN admin themes. Steps to replicate are as follows

1) update Group module to 3.3
2) Navigate to a Groups membership page.
3) A list of members is present but no link to add a member shows on the controller with the listing toa llow for navigation to the membership join form.

I was able to reproduce this issue with a clean install of Drupal 10.3.7. Here are the steps to reproduce:

1. composer require drupal/group:^2.3
2. drush en flexible_permissions entity group gnode group_support_revisions
3. Create a group type named "Base group" at /admin/group/types
- Check "The group creator automatically becomes a member"
- Uncheck "Group creator must complete their membership"
- Check "Automatically configure useful default roles"
- Check "Automatically configure an administrative role"
- Check "Automatically assign this administrative role to group creators"
4. Install node content plugins using default settings for Article and Basic Page at /admin/group/types/manage/base_group/content
5. Create a group named "Group One" at /admin/group
6. Go to group page at /group/1 and click Members tab
7. Notice there's no "Add member" button on /group/1/members despite being listed as a member of the group with the Admin role

8. Disable Group Support Revisions module with drush pmu group_support_revisions
9. drush cr
10. Refresh /group/1/members and notice that the "Add member" button is now visible

In addition to the issues above we noticed the that global roles that were assigned to edit one content type could no longer edit nodes that were in groups. For example:

1. Global (Outsider) role of "Person Administrator" (PA) assigned to edit all nodes of content type of "Person"
2. After upgrade to 3.3 the PA could only edit Person nodes that were NOT in groups
3. Disabling the group_support_revisions module allowed them to edit all nodes of Person again (expected/previous behavior)

@richarddavies thanks for those steps, will have a look!

Okay I was able to reproduce this on a clean install of Group 3.3.x, so this has nothing to do with the upgrade path. Tentatively adjusting title until I know more.

Okay this bug was introduced in 📌 Since symfony/dependency-injection 6.4: "Symfony\Component\DependencyInjection\ContainerAwareTrait" is deprecated Fixed . In that issue, we dropped the requirement for relation type handlers to set themselves as "shared: false" because we can set it for them. However, the actual decorating services still need to declare that manually.

Reverting the overzealous removals should fix your problem.

MR coming up.

There, please review but I'm confident this fixes the issue. I'm surprised the tests didn't fail on this so will see if I can adjust them.

+1 Tested the MR and can confirm it is working as expected.

I can also confirm it has resolved both the missing Add member button and being able to edit group memberships that you didn't create.

Okay, going to see if I can get tests in, though. We don't want to accidentally reintroduce this bug in the future.

+1 that this fixed an issue we were seeing where some of the tabs in the Local Tasks block were missing. Thanks as always to @kristiaanvandeneynde for the incredible support. There are very few other maintainers who take such great care of their module.

Trying a different approach where the service provider in Group makes it so no-one will ever have to specify "shared: false" again. This is easier to test as I can now test for the container definitions in a kernel test. Still needs said tests, though.

And probably a change record and updated documentation.

Feeling confident about the MR now, just needs a CR and docs update.

Change record here: https://www.drupal.org/node/3488636 →
Updated docs here: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

We should probably at one point create a dedicated documentation page for that rather than hide it away in an upgrade guide.

Will commit and release in the morning

Thank you! I just want to confirm that this fix will also be applied to the 2.3 branch, right?

As always for v2/3, it will be applied to both branches

Thank you again!

One piece of general feedback though regarding these issues, wouldn't it be better to name the issue based on the symptom/problem instead of the solution? As a Drupal user, if I have a problem and I'm searching through the issue queue to see if there's a related issue, I'm going to have a harder time finding it if it's named based on the solution or fix because all I know is what symptoms or errors I'm currently seeing. For example, this issue's current title doesn't give me any clues as to what problem this issue addresses.

+1 for @richarddavies

For documentation purposes, to help others with the same problem finding the solution: today I asked for help on Slack and @kristiaanvandeneynde pointed me to this issue while he was working on the hotfix release.

@mvonfrie
As site administrator and group administrator, on the group contents view, I see the action "Add existing content" but not the action "Add new content". The user has all available permissions on the group. I found that the add existing content route requires _group_relationship_create_any_access while the add new content route requires _group_relationship_create_any_entity_access. And the corresponding access checks return different results: Drupal\group\Access\GroupRelationshipCreateAnyAccessCheck returns allow while Drupal\group\Access\GroupRelationshipCreateAnyEntityAccessCheck returns neutral.
What am I missing? Drupal is 10.3.8 and group is 3.3.0.

@kristiaanvandeneynde
Do you have group_support_revisions enabled?

@mvonfrie
Yes.
BTW, I have a similar problem with the "Add member" action on the group members view. The access result is neutral as well.

Re #36: The reason we cannot always use a title to describe a single symptom is because one problem might lead to multiple symptoms and then it muddies the waters. This is what happened here. Instead, we point out the problem in the title so that the release notes contain the right information, but have the IS and/or comments describe some of the symptoms.

If you use the search feature, you'd still be able to find the most relevant issues then, even if the title might not immediately give away that it's the one you're looking for.

Yes, choosing the best title is not always going to be without challenge. Sometimes you may need to be a little more generic or focus on the most common symptoms, but even then it's way more user-friendly than a title based on the low level fix/change that was made.

Sure, the issue may currently still show up in issue search results, but good luck trying to correctly identify the right one from the other 20+ issues when all of them have meaningless titles that don't relate at all to the problem you're experiencing. You're forced to randomly click on various issues hoping to get lucky.

I still maintain that the best title describes the "business value" or change from the end-user perspective, not the underlying technical implementation details. For example, "Fix various permission issues causing missing buttons/links to add/edit group membership and content" is a much better description of what this issue fixes and how it improves the module over "Automatically set all relation handlers and decorators as 'shared: false'". The technical implementation is only a means to an end. Focus on the end goal, not how you got there.

Automatically closed - issue fixed for 2 weeks with no activity.