It seems to me that most content entity types will want to provide a means to create a new entity within a group.

This functionality is currently only in GroupNode. Could it be moved into the base class for other entity types to use?

One thing is that GroupMembership would need to override this, as the module doesn't currently allow users being created directly as group members.

Comments

joachim created an issue. See original summary.

kristiaanvandeneynde’s picture

Yeah, I was thinking of doing that.

It would require me to revisit the wizard to not simply extend the node (or entity) form, but try to manipulate it differently using the form object somehow.

The thing I had in mind here was not just to allow modules to create entities within a group by means of a wizard, but also allow Group to then control access to said entities using grants. To realize this, core first needs an entity grant system. Something I'm working on here: #777578: Add an entity query access API and deprecate hook_query_ENTITY_TYPE_access_alter()

joachim’s picture

Issue summary: View changes
kristiaanvandeneynde’s picture

Status: Active » Closed (outdated)

No longer valid as the whole routing system got ripped out of the group content plugins :)

I am still planning on making entity access generic as soon as the entity grant system lands.

joachim’s picture

Status: Closed (outdated) » Active

> No longer valid as the whole routing system got ripped out of the group content plugins :)

Can I ask what it's been replaced with?

I was using this routing system in my custom Group content module, and now it's all gone!

kristiaanvandeneynde’s picture

We used to have per-plugin routes, which was a mess to maintain. So now we have general routes that can be beautified using Pathauto.

Check GroupContentRouteProvider and routes starting with entity.group_content. to see what replaced it. Basically, every piece of group content now lives at group/X/content/Y and we have an issue to make the "content" part be dynamic through Pathauto using the plugin's "pretty_path_key".

So the create form is now taken care of for you in GroupContentForm. If you want to be able to alter it for just your plugin, we may need to look into implementing ::getFormId() and ::getBaseFormId() there. Although you could easily let your form alter check for the entity's plugin ID.

If you have any more questions, please let me know.

joachim’s picture

As far as I can tell, the routes that are provided by GroupContentRouteProvider are these:

- group/GID/content -- which is meant for admin users, and not really suitable for non-technical users
- group/GID/content/add -- local action on the above route.
- group/GID/content/add/PLUGIN_ID -- that only allows me to adopt an existing content entity.

I don't see where the form to create a new content entity is provided.

kristiaanvandeneynde’s picture

Ah you mean like Group Node does: The 2-step wizard. I'm sorry for the confusion there :)

There are actually discussions in several places right now as to how we want to allow someone to create an entity within a group. The best solution using the current system would be to generalize the wizard we have in Group Node to work for every content entity.

There's a few drawbacks, however:

  • Some people have been complaining about the second step, so we need to find a way to make that optional.
  • Ideally we need to be able to disable this wizard, so group_membership for example would not let you create actual users.
joachim’s picture

> Some people have been complaining about the second step, so we need to find a way to make that optional.

I remember that coming up on another issue back when I was first working with Group. My suggestion IIRC was that if the group membership entity has no fields, it should be skipped. Alternatively, this is something that could be configured in the Group Content Enabler plugin?

> Ideally we need to be able to disable this wizard, so group_membership for example would not let you create actual users.

Likewise, the GCE plugin class could say outright this isn't doable in the case of group_membership. Additionally, the plugin configuration could enable or disable this. So: 1. code says 'never' or 'maybe', and configuration can say 'yes' or 'no' in the latter case.

Any thoughts on where all of this should go? And on this issue or other(s)?

I'm about to write group integration for 2 if not 3 custom entity types, so I'm either going to write this generically in my own classes, or I can write this as patch(es) to Group module.

kristiaanvandeneynde’s picture

Perhaps it's time to spin this off into its own issue, as comments about it are being posted left and right. Most recently here: #2736233-20: Port Subgroup (ggroup) to the D8 version

joachim’s picture

Subgroups? Sorry, I don't see how that's related...

kristiaanvandeneynde’s picture

It's not, but it goes to show that with almost every new plugin, the discussion pops up as to how we will present the form. So maybe this needs its own issue.

kristiaanvandeneynde’s picture

Status: Active » Closed (outdated)

Everything that was happening in Group Node form-wise has now been made generic and has been added to the base module. See: #2819595: provide a generic and extensible UI for adding new content into a Group