As discussed in #2797793: Entities identified by strings as group content in great detail, there are use-cases for having config entities as group content. While the "string ID problem" is a big part of achieving that, in theory there could also be config entities (or at the very least non-content entities) that have integer IDs. It would still not be possible to add them as group content, because ContentEntityInterface is typehinted in various places.
Since no content-entity specific funtionality is used, let's broaden those typehints to allow anything implementing EntityInterface to be added as group content - at least in the code. The ID storage issue (and possibly other problems) can then be tackled independently.
Broaden all typehints / type-checks for ContentEntityInterface to EntityInterface
Provide patch
-
GroupInterface::addContent(), GroupContent::loadByEntity(), GroupContentStorage::createForEntityInGroup() and GroupContentStorage::loadByEntity() accept entities that only implement EntityInterface, not ContentEntityInterface.
-
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 3223575-2.patch | 10.04 KB | tstoeckler |
Comments
Comment #2
tstoecklerCreated a simple patch for this. Unit tests pass locally and in the kernel tests I only had one failure, which I think was due to the PHPUnit version, though, so I'm somewhat optimistic that the patch will be green.
Comment #3
ericras commentedI'm using this with success with the group_webform module (patched with #3248452: Support group_content_string_id module on group_webform and using group_content_string_id module).
I haven't personally verified that "no content-entity specific funtionality is used" but if that's the case since patch #2 lit up green, then I'm all for it.
Comment #4
akalam commentedThis is already fixed in Group 2.x and 3.x:
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib...
For example, the method \Drupal\group\Entity\Group::addRelationship accepts any instance of EntityInterface