Group ID unavailable when editing the referenced entity

Hi Alan,

I think this exposes a more fundamental problem: what one expects to edit at group/X/
/Y/edit. In the group_membership plugin's case, you'd expect to edit the member info and will actually do so. In group_node's case you may expect to edit the node, but you're actually editing the relationship.

In order to fix this, we need 2 paths per piece of content in a group, one to edit the relationship and one to edit the actual entity inside of a group URL context. How we solve this, is tricky because of the aforementioned expectancy problem.

Something that would work for node, would look ugly for members:

• group/X/node/relationship/1: (The GroupContent entity)
• group/X/node/entity/1: (The Node entity, in a group URL context)

Versus:

• group/X/member/relationship/1: (The GroupContent entity)
• group/X/member/entity/1: (The User entity, in a group URL context)

The latter being bad because the whole point of GroupMembership is that it doesn't care about the data on the user, but more about the data on the relationship. The plugin doesn't even control access for editing the user.

I'd like to hear other people's opinion on this.

Sounds like this is another use case for #2718195: Add a computed field for entity's group(s) :)

Well, yeah. But it also makes sense to provide routes where you can view a group's entities because we can then make use of the route-based group contexts (for blocks for instance) and cache contexts.

The current tabs are there to have something already available. It currently is encouraged to create your own views, yes. This is because we're in alpha, nearing beta and I want to have really user friendly listings when we go full release, but right now they're not a top priority.

Hi,

@kristiaanvandeneynde
Now we have passed to beta version, have we something like that /group/8/node/234/edit or we have to create our own views????

Best regards
Khalil CHARFI

All of the relationships can already be edited at group/X/content/Y/edit.

There are no paths such as group/X/content/Y/entity/edit yet. We could implement that to allow you to view and edit the actual entity while staying in a group context URL.

The only thing we need to keep in mind then is permissions. We'd need a set of CRUD permissions for both the relationship and the entity itself. Like what Group Node already has in place.

In order to properly enforce that, however, we'd also need an entity grant system.

I really think we can pull this off, but it won't be easy and might be best to leave for when we have entity grants in core.

Bumping priority because I really want this feature (Note: I am the maintainer, don't do this yourself).

This feature is a must have so we don't loose group context during entity edition.

Thanks kristiaan for your work

Hello,
is there any update on progress concerning this feature?
Would it extend completely into the nodes? Or would it just be an other editing path?

I need a token for file save path of an image field with group name. So each group would have a file folder form themselves.

This is a great module with an even greater potential!

This is on the roadmap (see link on project page) for a full release.

Hi,

Hitting this issue on a current site, and am thinking of a slightly different solution.

What about providing a new views contextual filter default value provider plugin? (Haven't sussed out the name of this plugin type yet, but it would show up here):

... something along the lines of "Group ID from URL or current node"...

It could look for the same URL argument as the current "Group ID from URL", and if not found, look for an entity in the current route, a related Group Content entity, and get the gid from that?

This might fix the issues highlighted by alan.upstone in comment 10... once a node has been saved, future visits to the edit page can traverse a related group content entity to set the group id on a view...

Completely different approach: Purl module. Purl provides the ability to pass a context in with a path part -- using this, we could end up with the group name as either a subdomain, or the first path part of a URL -- which gets stripped off at the start of a request before delegating to the actual route handler.

I'm thinking this can then become a contextual filter for views, as well as a block context provider, among other things... about to go try out the dev version for 8.x.

Hi,

I've gone down the Purl route as described in my previous comment, and have gotten a (mostly) working solution! I had to do some work on Purl to get there, though. I've created a bunch of PRs for Purl on github, at https://github.com/activelamp/purl-d8, that make it mostly work, and then I've created a "group_purl" module that implements a Purl provider plugin, a Purl modifier plugin, a group context, and a views default_argument handler -- and with this all in place, it's working really well! Almost...

One issue to resolve still:

- Cache contexts -- right now menu links get rewritten with the group path, and these get cached and don't change when you go to a new group. Hoping to carve out time in the next day or two to address that.

So... the question becomes, where should group_purl live? I was planning to just create a new project on Drupal.org for it, and write a blog post describing how to get it all up and running. But then I thought about how this issue is a release blocker for Group module itself, so it might make more sense to bring it into Group, either as a submodule, or directly as plugins.

As a submodule, my current code should just drop in and work, pretty much unpatched. Or, I could move these plugins and the context into the Group namespace, given the status of this bug -- but this would add a dependency on Purl.

Happy to go any of these directions -- which would you prefer? A patch for Group module itself? A patch for group_purl as a submodule? Or should I just post it as its own separate project?

Following, as this is something we are currently investigating for a possible 'multisite'-acting site.
This ain't probably the right place to discus this, but one thing that bothers me a bit about group module is that you just can't use the normal 'admin/content' overview and node add paths to create and edit nodes. Unless I missed something. How I see it, a user is a member of a group and if this user logs in, he only sees the list of nodes belonging to the group he's a member of in drupals admin/content overview. When he clicks add content, on that node edit page I would expect a dropdown or some checkboxes to select the group this node has to go in.

@kriboogh this sounds similar to what we are building. I did consider (and would still consider) auto-creating the "group content" entities for nodes, when the group context is active... as it is, the provided group operations widget does this for you, although with its own path.

If a user has administer content, I think they might bypass the group permissions -- so I would tend to think this is not a good solution for Drupal admins to have their own view. But it's easily possible to create your own views that are filtered by the group, and create a group administrator role that can access these views.

With group_purl, all non-admin links get rewritten to keep that group context/path ahead of the regular paths. I think there's still some work to be done allowing exceptions to this -- right now if you follow a link to a node of a content type that is set to not "preserve Purl context", you get redirected out of the group -- and otherwise it's somewhat challenging at the moment to get out of the group context...

@freelock I'd definitely be interested in seeing your group_purl module whether in a sandbox or github. It seems to me like it can live as its own project ultimately. I'm wary of too many submodules in a single project (future support and maintainability reasons) but that's @kristiaanvandeneynde's call for Group.

(This is getting a little afar of the original point of this issue-- but I tackled the subdomain issue with https://github.com/unlcms/group_subdomain by just mapping the request's subdomain to the first part of a path alias. So example.unl.edu/about-us displays cms.unl.edu/example/about-us. It was an MVP for getting subdomains working with Groups but it's not robust enough and I need a better solution going forward.)

@ericras My original thought was to create a separate group_purl module... and given that I want to get it up, I think I'll go ahead and post that now... Not much difference between having as a submodule or a separate module, and I think that integrating this solution into Group itself may be too restrictive...

Have you worked with Purl at all? It supports subdomain contexts, and it would be pretty simple to create a Purl provider that sets the Group context from a subdomain. It would make total sense to have this as a plugin in "group_purl"... and chances are the same ContextHandler will work (possibly with a few modifications).

@kristiaanvandeneynde if you do want to bring this into Group module, let me know and I'll happily turn it over...

Update: Module posted. https://www.drupal.org/project/group_purl

@alan.upstone there has been some work on Purl for D8 taking place on github, so that's where I created an issue, and provided a bunch of PRs to get a working solution.

https://github.com/activelamp/purl-d8 is the maintainer's copy, and you can see my issue and 7 PRs I created for different things that stood in the way of a working module... with all those applied, I would call Purl an alpha release -- it pretty much works, is not widely tested, and has some performance problems, but it's something that pretty much works and we're now building on.

If you'd like a copy with all the PRs applied, you can use the master branch of my fork, https://github.com/freelock/purl-d8 .

Okay so there's a few misconceptions regarding what should go where. This issue is about being able to view nodes (or other grouped entities) while within the "group area"; i.e.: While the path starts with group/X.

So whether or not you can choose which groups a node should belong to on the edit form, whether or not you can add nodes from admin/content and still have them in a group, etc. all merit their own issue. To quickly answer these inline:
- Group selector could be shown on node edit form but only when the content plugin is configured to skip the 2nd step of the node add wizard.
- Admin/content should not be the place to add content to a group. We want a full "group experience" where all of the group editing and administering happens within the group space/zone/area. We can enable this if we need to, but that is way beyond the scope of this issue.

Regarding pURL, I used to love that module but it has since fallen from grace with newer modules showing up and it not receiving any updates. If it's revived, it could prove very useful indeed for creating mini-websites that each have their own path prefix or even URL, built on Group.

But for the functionality described here -making nodes available at group/X/node/1 or something- I feel this needs to come with Group out of the box. It's a commonly expected feature and it should not be up to the end user to configure pURL to get such functionality.

Hi,

This issue is about being able to view nodes (or other grouped entities) while within the "group area"; i.e.: While the path starts with group/X.

Well, that's possible to do now, using views with a Group ID in URL contextual filter. But the title of the issue is not that -- it's "Group ID unavailable when editing the referenced entity". As far as I'm concerned, the showstopper here is trying to use an entityreference field on a node within a group -- you cannot filter the list of nodes in the entityreference field to only contain those within the group.

That's what the Purl approach solves, among other things. With Purl, you can have /group/x/node/y/edit, and Purl strips off /group/x and provides it as a contextual filter for an entityreference view -- and now your edit form can be appropriately filtered.

So I think it's the edit route that's missing here -- entity.node.edit_form, not entity.node.canonical.

There's not that much to Purl, though, and I think the approach I proposed for Purl is a really good one for Group, whether you decide to use Purl or bring equivalent code into Group. The gist: the Drupal 8 kernel supports subrequests, so Purl (or equivalent) can act on the KernelEvents::REQUEST event. When it finds the group path, you can store it as a context, create a new request with the Group path stripped, and re-inject it into the Kernel. This subrequest can then use the normal Drupal 8 routing to send it to any defined route in the system, only now you have an active Group context.

The other thing we're currently doing in Purl is path_processor_outbound, which gets a chance to alter any Urls being generated. This allows you to add the /group/x prefix back into any link rendered on the page, and you have the link context and group context available to determine when.

Purl does seem to be built to do a lot more than that, and it also currently seems quite buggy -- they didn't notice this approach, so I've bolted it on. Adding those two items -- a REQUEST processor that spawns a subrequest when in a group, and a path processor that rewrites links -- along with setting an appropriate cache context -- would solve this issue and a great many others related to keeping users in a group until they follow links to explicitly leave the group...

One other nicety to Purl is it adds a Purl context field to menu links, so you can per menu item define whether the link should keep its current context, leave the context, or use a specific context (e.g. link to content in another group). You can also define this per content type, making non-group content types redirect out of the group.

I get how PURL works and it would indeed provide some benefits, but we cannot go about stripping the group/X part from the actual route because there are several routes that need that part in their path. I've not changed the topic title or summary, but as from #2 on I've always interpreted and treated it as something that should be solved by being able to act on nodes from within a group context.

Keep in mind that we already have code for extracting a group from the URL. It's being used by the cache contexts, operations block, etc. So once we make nodes available at group/X/foo/Y they will automatically be able to get a group context from the URL.

It's one of the final items left on the roadmap and definitely still on my radar. I had planned to get to this earlier but the UID1 issue I've been working on for core kept getting set back to Needs Work :/

Okay so attached is a patch which should allow you to view, edit and delete group content entities' target entities at:

• group/x/content/y/entity
• group/x/content/y/entity/edit
• group/x/content/y/entity/delete

A few notes:

1. This has not been thoroughly tested but it should work
2. The patch contains a few minor unrelated fixes I encountered along the way, will split those off before creating a final patch
3. This patch does not contain tests yet
4. This patch does not create tabs (local tasks)
5. This patch does not adjust any existing redirects, we may need to look into which ones we change to redirect to these new paths that keep you in the group space

Please test and provide feedback.

Hmm, rushed it a bit.

Hello @kristiaanvandeneynde, the patch #31 applied to Group 8.x-1.0-rc1 give me this error on Drupal 8.3.5, 8.4.3 or 8.5.x when I call group/x/content/y/entity/delete :
LogicException : The controller must return a response (Object(Drupal\node\Form\NodeDeleteForm) given). dans Symfony\Component\HttpKernel\HttpKernel->handleRaw() (ligne 162 de /Users/XXXX/devdesktop/cisirhv2-dev/docroot/vendor/symfony/http-kernel/HttpKernel.php).

Okay cool, anything else you encountered or just that? How did the other paths work for you?

@kristiaanvandeneynde, It's was same for the edit form, and the delete form. All was fine for viewing the entity. I think something go wrong when the controller 'GroupContentEntityController.php' build the form. I no have give a try to the other patch. Hope that will help, I'm in the need for this patch and it's little out of my skill. Thank for your help.

Okay, to be fair the patch was pretty time consuming to work on and I had only thoroughly tested the view path. Will try and check out + polish the edit and delete path this week.

Repeating part of #30:

Okay so attached is a patch which should allow you to view, edit and delete group content entities' target entities at:

• group/x/content/y/entity
• group/x/content/y/entity/edit
• group/x/content/y/entity/delete

A few notes since #30:

1. There are now tabs
2. The delete and edit routes now work
3. Both forms redirect to their original destinations. Will look into changing that.
4. We should also add some operations and links pointing to these new paths.

Please test and provide feedback.

This should take care of everything:

• Redirects after submitting the related forms
• Tabs on the entity page
• Operations and links pointing to the entities from the overview pages
• Modified forms so you can't "preview" and then lose track of where you were

What it lacks is:

• Tests
• A Views plugin to make linking to the view/edit/delete paths easier (now you have to manually craft the URL)

Contains an update hook that overwrites your group_node view with the most recent version! Do not update your DB if you modified that view. Instead, note your modifications, then update and reapply them.

A cool feature to add in a later stage would be two alias fields on the group content entity:

• Alias for the relation (/group/1/content/1)
• Alias for the entity when viewed within a group scope (/group/1/content/1/entity)

Depending on the plugin config, we'd hide certain alias fields where they don't apply. The only drawback being that we don't show the group content form when the wizard is disabled and I don't want to alter the target entity form (e.g. node form) to show the extra alias field there.

Yeah an update already got committed with that update number. Need to reroll the patch.

This is a reroll after merging in HEAD. I do think we need an update hook for the node view instead of simply overwriting the view as a whole, but for the time being this update function will do. USE ON A TEST SITE!

I have run in this same problem with RC2, so the patch apparently wasn't rolled in the code yet. Will try out if the patch works next.

The latest patch (#47) breaks group but the patch #42 works on my RC2 installation.

However, I have noticed something interesting: while edit permissions don't work, "delete" permission works even when viewing outside of the group content. The setup is:

User with no particular privileges is group owner.
- as a group owner he should be able to add, edit and delete nodes of type x in the group context.
- as a normal user he should not be able to do any of this outside the group context.

Results:
- the user can add new nodes of this type within the group context.
- without the patch, he can't edit them later
- without the patch he can't even view then within the group context.
- BUT: without the patch, he can delete them later - even though he is outside the group context!

Apparently. someone has resolved this issue in a different way in RC2 release, so that the group privileges are honoured within normal view/edit/delete path for the node. This is nice, but unfortunately only works for delete and not for the edit at the moment.

Hope this helps.

OK, I took a look at the code now.

As far as I can see, the gnode.module defines the necessary hooks for the "delete" and for the "update" operation in *exactly* the same way. And it *should* work in the normal edit mode for the node, so there is no need for these contextual edit links.

Facit: It works for delete. It doesn't for update. And I really don't see why it shouldn't, since the code appears to be exactly the same for two cases.

Could it be that the problem is in group.install? I can see there the following code:

/**
 * Change 'edit' into 'update' in permission names.
 */
function group_update_8012() {
  $config_factory = \Drupal::configFactory();

  foreach ($config_factory->listAll('group.role.') as $group_role_config_name) {
    $group_role = $config_factory->getEditable($group_role_config_name);

    // Replace 'edit any/own' with 'update any/own' in permission names.
    $search = '%^edit (any|own) (\S+) (\S+)$%';
    $replace = 'update $1 $2 $3';

    $permissions = $group_role->get('permissions');
    foreach ($permissions as &$permission) {
      $permission = preg_replace($search, $replace, $permission);
    }

    $group_role->set('permissions', $permissions);
    $group_role->save();
  }
}

Now, if the regexp replacement fails for any reason, then the database would be left with "edit" instead of "update" permissions and then nothing else would work for the update, while delete would work OK. How can I check if this is the case in my DB?

Ups, this is not a problem in groups. Sorry.

To sum it up: editing and delete permissions are working in default edit path for the nodes that are related to groups.

Now if only I could find some simple method for listing all referenceable entities that belong to the same group without having to edit the entity in a group path...

I have the exact problem described in #1 and #27. Using rc2 now. I've tried the links as described so clearly by alan.upstone in #41, but I get a page not found for the group/gid/content/relationid/entity/edit link for every entity.

As it stands, I cannot find any url that lets users edit nodes AND that includes the group context to feed into the entity reference fields. So, a user creates a node and can select other group nodes in an entity reference field, but when the same user tries to edit the node, the group context is lost.

Having tested and read and re-read this thread, I'm at a loss. Can someone please provide an update on this functionality? From my read, it looks like there should be a working edit link that includes the group context and was part of an alpha release over a year ago and should be part of rc2. But, I simply can't get it working.

#2718195: Add a computed field for entity's group(s) is now duplicate with #2813405: Add a field to view and edit content's groups, but it's still related to this issue...

#2906082: Figure out a way to cache lists using group permissions has now occupied update_N gnode_update_8006() so the function name will need bumping.

I am Facing problem in my view page I am unable to send the group Id to the link so that I can access the particular group and create the event inside that particular album.
Can anyone suggest me above problem!!..

I've found that setting up url aliases for the content within the group, as well as enabling the subpathauto module can produce urls like this:

http://test.com/company/group-title/event/private-event/edit

Do note that i'm also running the patch for groups that exposes [node:group:title] token to fully achieve this, #2774827: Get a token of a node's parent group to create a pathauto pattern

I am using the Group Version: 8.x-1.2 and facing same problem while editing content entity. The link to the referenced content entity itself (URL now has only node/9/edit) somehow group context is lost and can’t be used in the edit form.

It would be good to have the group ID available in the URL when editing nodes (group/8/node/9/edit). Do we have a patch or someone have any idea how he can have group id while editing the node.

I just want the mention here that it's important to at least one of us that links only add the group context when it actually exists - in the project I'm preparing, content exists outside of groups and a "copy" (ie reference to it) can be added to groups. This shouldn't prevent anyone seeing the original non-group reference.

I expect there'd be times at which you'd want this not to happen, so perhaps a switch should be make on a content type (in my case I'm thinking of a media bundle)?

I created a MR rerolling the patch on #47 against the latest 1.x release. During the reroll I did few changes compared with the patch I'd want to explain:

• gnode_entity_operation() <-- skipped to make merges easier because they were just code style changes
• gnode.module <--- removed unused Drupal\Core\Entity\EntityInterface inclussion
• src/Plugin/GroupContentEnablerBase.php <-- skipped the comment: "@todo This class is HUGE and should be using handlers like entity types do." Not sure if the comment still applies since I know you are working on new decoratable service handlers for groups 2.x
• src/Entity/Controller/GroupListBuilder.php <-- Skipped because it is deleting the "members" operation and I'm not sure how to act here so I was conservative because I wonder there wasn't side effects on this and maybe this is just legacy now. if it is legacy, should we remove also the "revisions" operation? I know groups wasn't revisionable in the moment of the creation of the patch but again I preferred to be conservative here. @kristiaanvandeneynde could you confirm if we should delete those operations or not?
• Renamed the hook_update_N because the update 8006 already exists

Among that, I added 3 views plugins for the links to the group content related entities, and updated the view to use them instead building the links manually using field rewrites.

I'm trying to fix the config schema errors without success. I would need help to solve them.

Although the patch works fine, I see a big drawback for some sites in terms of usability: Other tab links usually present on nodes (translation, layout builder..), they are not present anymore.
I'm trying to add them dynamically to the view, edit and delete set of tabs.