Dynamic Entity Reference: support discovering relatable resource types

This is not a bug; DER simply doesn't have the necessary normalizer yet — it only has a HAL-specific normalizer (see #2844946: Add DynamicEntityReferenceItemNormalizer for serialization module).

Funny enough, this came up just yesterday in the API-First Initiative meeting: see #3027430: Dynamic Entity Reference normalization support.

So, see you in #3027430: Dynamic Entity Reference normalization support :)

@steveworley just posted an amazing comment at #3027430-8: Dynamic Entity Reference normalization support, which led me to reopen this issue. This is what he wrote:

Thanks for pointing this out @wim.

I understand that its just a normaliser that isn't picking this up and serialising correctly, I still think the modules implementation for discerning these fields might be too greedy given the error I was receiving. For reference the error is:

"detail": "`field_ref_dynamic` is not a valid relationship field name. Possible values: field_ref_dynamic."

When including a DER field the output says that you should be able to use the field. All you would need to do to replicate this is:

- Define a field that extends DataReferenceTargetDefinition
- Don't add target_type in the field

This triggers the following flow:

- getRelatableResourceTypesByField will return your field but it will be an empty array
- resolveInternalIncludePath checks to see if the key returned is empty

I think it's just a case that getRelatableResourceTypesByField should do more checking and resolveInternalIncludePath should maybe rely on the getRelatableResourceTypesByField to check for the field. If my field doesn't have the right configuration it shouldn't show that I can request it.

Gah, Chromium ate my comment 😠

We'll need a failing regression test for this in JsonApiRegressionTest.

target_type, handler_settings are both null so the settings of the field cannot be understood by the method.

This appears to be the root cause.

I installed DER and created a field. Indeed, target_type is absent. Which makes sense, because the goal of DER is to allow it to be selected by the user. And \Drupal\jsonapi\ResourceType\ResourceTypeRepository::calculateRelatableResourceTypes() indeed assumes that target_type exists (meaning only one entity type can be referenced), thus coupling it to core's entity_reference and preventing contrib's dynamic_entity_reference.

A DER field storage config has settings like this:

settings:
  exclude_entity_types: false
  entity_type_ids:
    comment: comment
    node: node

This allows comment and node. But if the exclude_entity_types boolean is flipped from false to true, that is inverted. Fortunately, \Drupal\dynamic_entity_reference\Plugin\Field\FieldType\DynamicEntityReferenceItem::getTargetTypes($settings) exists so we don't need to duplicate all that logic.

And the DER field config has settings like this:

settings:
  comment:
    handler: 'default:comment'
    handler_settings:
      target_bundles:
        comment: comment
      sort:
        field: _none
      auto_create: false
      auto_create_bundle: ''
  node:
    handler: 'default:node'
    handler_settings:
      target_bundles:
        article: article
        page: page
      sort:
        field: _none
      auto_create: false
      auto_create_bundle: article

Allowed target bundles must be selected.

The target_type handling obviously is very different in DER, but the target_bundles handling is similar.

Ideally, both ER and DER would provide a standardized way to get this information. I am concerned that doing this makes it impossible for JSON:API to go into core since it'd be calling a contrib module's API.

Perhaps the appropriate solution for now is to do this instead:

If my field doesn't have the right configuration it shouldn't show that I can request it.

This issue is about DER support minus the normalization support (that is covered by #3027430: Dynamic Entity Reference normalization support).

I am concerned that doing this makes it impossible for JSON:API to go into core since it'd be calling a contrib module's API.

I happy to have an interim fix in DER.

@jibran, does DER have any configurable constraints for the referenceable type? Or is it completely determined by the field value?

I'm just thinking about a future when JSON:API wants to have much better schema support and I'm curious if we'll be able to find out what types are potentially referenced in advance.

I made the connection to this issue in #3005274-17: [PP-1] Support for Paragraphs' ability to negate the entity reference selection.

#8 needs feedback from @jibran.

Postponing this on #3057545: ResourceTypeRepository wrongly assumes that all entity reference fields have the setting "target_type", see #3057545-7: ResourceTypeRepository wrongly assumes that all entity reference fields have the setting "target_type".

does DER have any configurable constraints for the referenceable type? Or is it completely determined by the field value?

There is a constraint \Drupal\dynamic_entity_reference\Plugin\Validation\Constraint\ValidDynamicReferenceConstraintValidator and it is using field settings to determine the valid reference.

Does it answer your question?

Been in PNMI for 4 years so safe to say it can be closed out I believe.

If still a valid feature request please reopen updating issue summary for how it pertains to D10

Thanks!

#3057545: ResourceTypeRepository wrongly assumes that all entity reference fields have the setting "target_type" has been committed.