Empty page when trying to create group node

This should be resolved as part of #2819595: provide a generic and extensible UI for adding new content into a Group. Please confirm and close this issue if it is.

Hello,

I've installed Group 8.x-1.0-beta5 and unfortunately the issue is still there.
Any idea on how to fix this?

Thanks

Laurent

Can you provide steps to reproduce? Preferably on a clean environment such as a simplytest.me instance.

I'm seeing the same problem, using version 8.x-1.0-rc1.

Steps to reproduce:
1. Create new group type with default settings.
2. Install 'Group node (Basic page)' with default settings.
3. Give members 'Access group node overview' and all 'Group node (Basic page) - Entity: ...' permissions.
4. Create an authenticated user and add as member.
5. Log in as the authenticated user and go to /group/1/nodes.
6. Click the "+ Create Node" button.

This takes you to /group/1/node/create, with title "Create Node" and no content.

Note that the "Create Basic Page" button in the Group Operations block on /group/1/nodes works fine, linking to group/1/content/create/group_node:page.

Thanks for a great module!

I think I just found where is maybe a problem
If you enable permission for this group type
Group content (Basic page) - Relationship: Add entity relation
Then you get a form and create content, but If you disable it you just get a blank page.

I can confirm #6.

1. Enable "Entity: Add content entities" (`create group_node:foo entity`): I see a Create Node button which leads to an empty form.
2. Enable "Relationship: Add entity relation" (`create group_node:foo content`): The form now works, but I also see a Relate Node button which I don't want.

I can confirm this issue on my own site and on simplytest.me using rc2. As stated in #5, clicking the "Create Basic Page" button in the sidebar works fine. The issue is when clicking the "+ Add node" button on the group/#/node page.

Simplytest.me:
https://davu.ply.st
Username: user1
Password: user1

#6 also worked for me as a temporary fix.

I can confirm this issue. Same as #6 and #7.

Please fix this!

I can confirm that #6 has isolated the issue. The access check for this particular page is looking for permission to create group content, while there is a separate permission to create entities in the group. I think it is the intended functionality of the page to allow for easy creation of new entities related to the group, not the group content entities that relate content to a group,

My patch changes the query made for the access check to see if the user can create entities in the group instead of just the group content relationship entity.

I'm using Group 8.x-1.0-rc2 and can confirm both #6 and #7. Will plan to give the patch in #10 a shot.

Marking as Needs review

Cool, thanks for finding this problem and a fix everyone! Could someone be so kind to write a basic browser test (extend the GroupBrowserTestBase class) to prove that this patch fixes the problem?

Well shoot. When we applied @mike.mcdonald's patch, we did not initially notice that it causes an issue with group membership. (We can no longer add a member from the members page.)

I think it is the correct direction, but we can't use createEntityAccess as users and the members relationship doesn't act as a normal entity.

Marking as "needs work" and will do a little refactoring of the patch.

The initial patch did cause issues with more group content types than are at issue here, specifically membership, as @joshuami pointed out in #14. So, a fix needs to be handled on more specific access checks on individual content types.

There are two patches here. One adds an override of createAccess on the gnode-specific GroupContentEnabler to check for entity creation permissions for the group rather than the default content relationship. The other patch does the same for those that are using the patch that adds group media content here: https://www.drupal.org/files/issues/2018-07-24/2984315-3.patch

I did some QA to test for the issue regarding group membership and I can attempt to write a test case, but I'm really unfamiliar with Drupal and PHP testing, so it'll probably take a while for me to do that, in case anyone else is more capable in that realm.

+++ b/modules/gnode/src/Plugin/GroupContentEnabler/GroupNode.php
@@ -105,4 +107,12 @@ class GroupNode extends GroupContentEnablerBase {
+    return GroupAccessResult::allowedIfHasGroupPermission($group, $account, "create $plugin_id entity");

This seems to allow access to Create as well as Relate pages now:
/group/%/content/add/group_node:[node-type]

Add a patch file for people using the GroupMedia module.
Update: posted to the wrong issue queue.

I am providing a patch that solves a problem of #17 as well as the one mentioned in the issue summary.

It works as following:
- In order to access group/%/content/create page, a user needs create $plugin_id entity permission
- In order to access group/%/content/add page, a user needs create $plugin_id content permission

@joshuami Could you please test this patch with your use-case mentioned in #14?

I've implemented a temporary workaround to this bug by giving group members the permission to relate existing content but then using hook_block_view_alter to unset $build['content']['group_content.group_node_relate_page'] to hide the button from them. It's a hack but it temporarily solves the problem for me.

Any idea when the fix in #20 will be rolled into the stable version?

I'm on 8.x-1.0-rc5

I can't believe that this issue still exists in the latest version. Is there a fix?

Thanks btw for a great module.

Go to Groups > Group types > Click "Edit permissions" at "Operations".

Under EACH Group node type, check the box for Member for the item "Relationship: Add entity relation Allows you to add an existing content entity to the group."

Then no longer empty page at "Add new content"

But I don't want them to be able to add existing content—that's what this patch is fixing.

Thanks for #20. It works as advertised.

Tested the patch given in #20 on 8.9.

It works and fixes the issue reported. Please find the SS attached for ref. RTBC+1

It works for me. Thanks.

The maintainer commented in #13 this needs an automated test before it is committed.

This bug is still present in 1.3 version. I confirm patch #20 solves it. Thanks everybody !

As already stated 3 years ago, could someone please write a browser test that visits both pages with a handful of scenarios?

• Has no permissions
• Has permission A
• Has permission B
• Has permission A and B

With A and B being the permissions from the latest patch.

Bug is still present in 1.4 as well. Patch #20 resolves this as well.

Does it have to do with only having a single gnode plugin enabled? I assume if there are multiple content types enabled for the group type, the add new button would navigate you to a page with additional links for each content type.

Created a merge request with patch #20 + functional tests requested in #30

After applying the patch #20:

vendor/bin/phpunit --filter GroupContentFormTest --testdox
PHPUnit 9.5.21 #StandWithUkraine

Runtime:       PHP 7.4.3
Configuration: /var/www/mysite/phpunit.xml

Group Content Form (Drupal\Tests\gnode\Functional\GroupContentForm)
 ✔ Create group content form access  19578 ms
 ✔ Attach group content form access  20276 ms

Time: 00:40.423, Memory: 10.00 MB

OK (2 tests, 40 assertions)

This issue persists in version 3.0.0-beta2 and effects the site administrator.

Repeatable with a fresh install of drupal + group module. Add content type as prescribed above and you get nothing on the "Add Content" page, but this applies to administrator, not just other users.

I looked at the patch and I don't see groupcontentcontroller.php in the module files for 3.0.0. Please advise.

This issue was opened for 1.x-dev branch. Patch in #20 does the job for this branch.
I added some tests that need to be reviewed and tested by the community before a merge could be done.

I guess we would need to open another issue related to the current issue for the branch 3.0.0-beta2 cause the patch provided in #20 and the tests I wrote would need to be updated.

Can confirm the issue exists in 3.0.0-beta3 as well. Blank screen on "Add Content" page with User with administrator role.

This is indeed still present in 2.0.x and 3.0.x, the following code always checks for GroupRelationship create access, even though the add page should call the plugin's access control handler.

    // Filter out the bundles the user doesn't have access to.
    $access_control_handler = $this->entityTypeManager->getAccessControlHandler('group_content');
    foreach ($relationship_types as $relationship_type_id => $relationship_type) {
// THIS IS WRONG.
      $access = $access_control_handler->createAccess($relationship_type_id, NULL, ['group' => $group], TRUE);
      if (!$access->isAllowed()) {
        unset($relationship_types[$relationship_type_id]);
      }
      $this->renderer->addCacheableDependency($build, $access);
    }

Moving to 2.0.x/3.0.x as 1.5 was the final version for the 8.x-1.x branch (bar security releases)

• Rerolled MR !53 against 8.x-1.x
• Opened MR !58 for 2.0.x :
  1. Added group-2842630-40-v2.patch provided in #40
  2. Adapted the functional tests I wrote for 8.x-1.x to match with 2.0.x

vendor/bin/phpunit --filter GroupContentFormTest --testdox
PHPUnit 9.5.24 #StandWithUkraine 🇺🇦

Runtime:       PHP 8.1.9
Configuration: /var/www/mysite/phpunit.xml

Group Content Form (Drupal\Tests\gnode\Functional\GroupContentForm)
 ✔ Create group content form access [14456.43 ms]
 ✔ Attach group content form access [14901.76 ms]

Time: 00:29.750, Memory: 10.00 MB

OK (2 tests, 42 assertions)

Moving forward to 3.0.x in order to open a new MR

• Opened MR !59 for 3.0.x :
  1. Added group-2842630-40-v3.patch provided in #40
  2. Adapted the functional tests I wrote for 2.0.x to match with 3.0.x

vendor/bin/phpunit --filter GroupContentFormTest --testdox
PHPUnit 9.5.24 #StandWithUkraine 🇺🇦

Runtime:       PHP 8.1.9
Configuration: /var/www/mysite/phpunit.xml

Group Content Form (Drupal\Tests\gnode\Functional\GroupContentForm)
 ✔ Create group content form access  13392 ms
 ✔ Attach group content form access  13551 ms
Time: 00:27.346, Memory: 10.00 MB

OK (2 tests, 42 assertions)

Hi @kristiaanvandeneynde, I've tried patch group-2842630-40-v2.patch on current Group v2, but it looks it's not working: the page is still empty. I'm using the group admin user which has all the permissions enabled.

EDIT: I was trying on beta version, the -dev version (with the patch) works fine. Thank you.

EDIT: just found it has been fixed on 2.x-dev version with the same method :-)

Before the patched code there is a function addPageBundles() which should returns the relatable types but this function does not returns the correct list.

I don't understand the logic behind the following function:

  /**
   * Retrieves a list of available relationship types for the add page.
   *
   * @param \Drupal\group\Entity\GroupInterface $group
   *   The group to add the relationship to.
   * @param bool $create_mode
   *   Whether the target entity still needs to be created.
   * @param string|null $base_plugin_id
   *   (optional) A base plugin ID to filter the bundles on. This can be useful
   *   when you want to show the add page for just a single plugin that has
   *   derivatives for the target entity type's bundles.
   *
   * @return \Drupal\group\Entity\GroupRelationshipTypeInterface[]
   *   An array of relationship types, keyed by their ID.
   *
   * @see ::addPage()
   */
  protected function addPageBundles(GroupInterface $group, $create_mode, $base_plugin_id) {
    $storage = $this->entityTypeManager->getStorage('group_content_type');
    assert($storage instanceof GroupRelationshipTypeStorageInterface);

    $relationship_types = $storage->loadByGroupType($group->getGroupType());
    foreach ($relationship_types as $relationship_type_id => $relationship_type) {
      $relation = $relationship_type->getPlugin();

      // Check the base plugin ID if a plugin filter was specified.
      if ($base_plugin_id && $relation->getBaseId() === $base_plugin_id) {
        unset($relationship_types[$relationship_type_id]);
      }
      // Skip the bundle if we are listing bundles that allow you to create an
      // entity in the group and the bundle's plugin does not support that.
      elseif ($create_mode && !$relation->getRelationType()->definesEntityAccess()) {
        unset($relationship_types[$relationship_type_id]);
      }
    }

    return $relationship_types;
  }

More precisely the line:

if ($base_plugin_id && $relation->getBaseId() === $base_plugin_id) {

If I negate the comparison it works as expected:

if ($base_plugin_id && $relation->getBaseId() !== $base_plugin_id) {

But I don't know if this could break something.

I applied this patch group-2842630-40-v3.patch but the issue still exists in drupal 9.4.5 and group v3

I confirm this bug. So apparently it only concerns the administrator? Hope to find a fix auickly. Thanks for that guys!

For info, I installed a brand new Drupal locally, installed Groups module, activated the 2 modules, created a group type and a group. Configured the entities that can be related to this group type (Article) and I have a webpage on this URL: group/1/node/create.

I willl have a look to see if it is different when you are not admin of the website.

Good news: it is not related to my original installation on my other project ;-)

Enjoy your day!

The block group actions does not show as well. Surely it is related to the bug.

I just tried to create a group with a second user: no possibility to create content either.

I confirm changing line 191 (see #47):

// Check the base plugin ID if a plugin filter was specified.
if ($base_plugin_id && $relation->getBaseId() !== $base_plugin_id) {
unset($relationship_types[$relationship_type_id]);

does the job!

Many thx to https://www.drupal.org/u/finex

Agreed.

Also - this issue is related: https://www.drupal.org/project/group/issues/3317459

-mike

And now, when I wanna create a group, it does not... I really need this on 3 projects ;-(

I have the same problem. I have installed three content types as group nodes for a group type. I gave the permissions, but if I go to the Create content page as group admin (/group/1/node/create) it shows nothing. I'm running Drupal 9.4.8 and Group module 3.0.0-beta3

Okay so I thought I had already committed the patch from #40 but it seems that's not the case. I'll commit it soon and then people should try the latest dev to see if things are working.

All the comments were either already fixed in dev or fixed by this patch. Closing as fixed for now.

Hmm actually you didn't merged the functional tests I wrote to cover this use case. I'll have to rebase the branches but to me it's not fixed until the tests are merged.