#access control

> I'm wondering about the form group-request-node.

In my case I use this form to render it on the group page itself, same way as you do in all other places in your module, get a node instance and create request form with the gnode relation entity programmatically. Why not to keep the form? If you try to render the form so user can request moderation of a new node membership via entity form before it threw the fatal error as the entity metadata had no such a form entry, so how it was possible to render a form at all? What was a way to actually create a moderated request?

With the form you deleted you could programmatically eg grab the node from a route context or create a new node on the fly (in my case I create booking node instance with all the fields you configure at the fieldable group content entity api, so I gather date the user wants to book a group entity for, in submit create a node, fill it's fields from the input and create moderation request).

Eg same way you could configure multiple fields on content entity field and form display settings page, and render it eg in a sidebar of a node full/teaser view modes with the possibility to request the page's node membership. Now if the form doesn't exist is it possible to use fieldable entity form to make a membership request form? What is the workflow to add nodes to the group with moderation? Why it's necessary to select a node from the nodes list on the membership request form? I guess it's more naturally to render form in context of some node. If you want to select node you can create multistep form with node selection and then reuse the same entity form with node context from the previous step.

I've removed that form. If it has value we should remake it so that it asks which group to add the entity to - I think?

I found more grequest overlaps so fixed them at the same time, and added a couple of tests.

I'm not 100% that they've all be cleaned up. So I'll roll out another alpha.

If you spot some more do open another issue, MR.

It helps, me at least, if you keep the MR with multiple individual commits, for each issue/problem/thing-being-fixed, rather than as one bigger commit.

I'm wondering about the form group-request-node. I notice I'd made a comment in the test that the module should probably use the default group generated forms.

Did you just have the error when the module presently called this form.
Or is there a good use for using a different form?

fixed conflicts with 3.0.x due to #6

Refactored, adjusted logic a bit to properly handle plugin ids group_node & group_node_request conditions,

Please note that I found another fatal & fixed it:
https://git.drupalcode.org/project/gnode_request/-/merge_requests/2/diff...
https://git.drupalcode.org/project/gnode_request/-/merge_requests/2/diff...

request form render caused before:

Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException: The "group_relationship" entity type did not specify a "group-request-node" form class. in Drupal\Core\Entity\EntityTypeManager->getFormObject() (line 212 of core/lib/Drupal/Core/Entity/EntityTypeManager.php).
Drupal\Core\Entity\EntityFormBuilder->getForm() (Line: 91)

Ah, the 'could you not use' confused me, I guess you are fine with the approach just asked to use base id callback instead of manual check, yes sure, makes sense

Hi,
Grequest code is valid as it's bound to users and plugin id behaves differently in there. Also as grequest and gnoderequest previously defined the same machine name routes for entity links if you install both modules at once one or other module will override routes depending on modules weight and when access tried to check the route result actually others module controller was called and provided false check result when it was expecting the access object interface.

Regarding the starts with, can you elaborate what is the concern about it?

In grequest you have one id for the plugin in group nodes there are no such a plugin and it has pattern gnode_request:article, gnode_request:basic_page & so on, depending on bundled enabled in the group node settings, so previous code didn't pass any access checks at all due to this, so now I check and if there is at least one plugin which starts with node request prefix I pass the check, mb group nodes interface was changed a bit and before it was the other way, it's why I mentioned it in the description.

Hi,

Thanks for this, it's quite likely there are issues with grequest (as lots of the code came from there). I'll try and get to test it soon. One thing I noticed immediately though. Could you not use {$plugin}->getBaseId() in place of getPluginId() and then looking for the str_starts_with?

for 3.0.0-alpha1