Problem/Motivation

The resource URL for a content entity bundle shows possible values for fields which are lists:

                "my_field": {
                    "type": "string",
                    "title": "Type",
                    "oneOf": [
                        {
                            "const": "one",
                            "title": "One"
                        },
                        {
                            "const": "two",
                            "title": "Two"
                        }
                    ]
                }

However, if a config entity uses a data type which has options (if the DataType plugin implements OptionsProviderInterface), then that doesn't show in the schema.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork jsonapi_schema-3332360

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

joachim created an issue. See original summary.

joachim opened merge request !6

joachim’s picture

joachim commented

Aha! The reason it doesn't work is because of this:

    if (!is_object($property) && !in_array($property['type'], static::JSON_TYPES)) {

and in my scenario, it's a custom data type.

If I create a simple normaliser service in the custom module that declares the data type, and have that declare that it handles my data type, like this:

<?php

namespace Drupal\mymodule\Normalizer;

use Drupal\Core\TypedData\DataDefinitionInterface;
use Drupal\jsonapi_schema\Normalizer\DataDefinitionNormalizer;

/**
 * Data definition normalizer.
 */
class DataDefinitionTestSuiteNormalizer extends DataDefinitionNormalizer {

  /**
   * {@inheritdoc}
   */
  protected $supportedDataTypes = ['my_data_type'];

  /**
   * {@inheritdoc}
   */
  protected function extractPropertyData(DataDefinitionInterface $property, array $context = []) {
    $value = parent::extractPropertyData($property);
    $value['type'] = 'string';
    return $value;
  }

}

then it all works!

joachim’s picture

joachim commented
Status: Active » Needs review
m.stenta’s picture

m.stenta
he/him
Primary language English
commented

I wanted to bring attention to this new issue I just opened, which aims to improve the current allowed_values logic so that it supports any field that implements OptionsProviderInterface.

#3397275: Use OptionsProviderInterface::getPossibleOptions() for allowed field values (anyOf / oneOf)

While working on that, I came across this issue, which I noticed also uses getPossibleOptions(), but for a different case.

I'm not sure if it would be possible to merge our logic together somehow, to cover all cases where getPossibleOptions() is needed. But I figured I would at least start by cross-linking the issues so everyone is aware of both. :-)

m.stenta’s picture

m.stenta
he/him
Primary language English
commented
Status: Needs review » Postponed (maintainer needs more info)

I tried replicating this in the new automated tests, but wasn't able to get the code in the MR to trigger, so I think we would need to add more test coverage for this case.

Chatted briefly with @joachim in Slack:

@joachim: Sorry, it’s so long ago I don’t remember
@joachim: My issue came up with a custom data type, not a field type

I'm going to postpone this as "maintainer needs more info" for now. If anyone else runs into this and can provide a failing test to demonstrate it then we can reopen and work on adding support.