- Issue created by @kristiaanvandeneynde
- 🇧🇪Belgium kristiaanvandeneynde Antwerp, Belgium
We could also decorate the PermissionChecker service to merge the scopes. That might actually be more logical.
The reason we have paths such as /group/{group}/content/add/{plugin_id} to add content to a group is because back when Group was developed for Drupal 8, there was no way to selectively hand out permissions. So we couldn't blanket grant someone permission to /node/add and then try to make it so they would only add nodes to their groups. A secondary problem was that we would need to know what Group entity they wanted to add the node to.
Fast-forward 7 years and we now have the Access Policy API in core. Which means we can completely get rid of the awkward wizards at the path mentioned above. Instead, we can now hand out the "create page content" permission only when the user is inside a certain Group context. While they are in said context and visit node/add/page, they will have access and the form will be modified to contain the required GroupRelationship fields (if any) and upon save, the node will be added to the Group.
Group context you say? Well, the idea is that we create a tiny module called group_context_select that, just like group_context_domain → , only contains a context provider to provide a Group the user selected. This could be via dropdown in the admin bar or other means if necessary.
Once you select a group, the Group module will hand out the corresponding permissions in the Drupal scope to allow you to use the regular UI as if you were creating a node inside the whole website. The benefit is that you could easily swap out group_context_select for group_context_domain or any other context provider and everything would still work.
Many, all of the custom routes and wizards we have now will go away.
None
None
Active
4.0
Code
We could also decorate the PermissionChecker service to merge the scopes. That might actually be more logical.