Problem/Motivation

There is an interface change coming from jsonapi module that is planned in #2992833: Add a version negotiation to revisionable resource types. With the patch from there applied, this module breaks - all resources that are have been exposed by the module will be exposed with no fields attached, due to __construct interface mismatch / misuse.

The case is described in this comment:

This is how jsonapi_extras is creating resource types from the repository. As they are not overwriting the constructor, the base class one is invoked and for the place that you see here $field_mapping, in the jsonapi with this patch the signature is expecting $is_versionable, and the actual list fields falls back to empty list, due to a default argument :(.

// Create subclassed ResourceType object with the same parameters as the
// parent implementation.
$resource_type = new ConfigurableResourceType(
$entity_type->id(),
$bundle,
$entity_type->getClass(),
$entity_type->isInternal() || (bool) $resource_config->get('disabled'),
static::isLocatableResourceType($entity_type, $bundle),
TRUE,
$field_mapping
);
As there are no additional arguments - this is passing empty list for fields_mapping resulting in empty responses (no attributes in the objects...).

Either way jsonapi_extras will need a follow-up once this is in... Should I create one and patch the case I am trying to describe?

Proposed resolution

Extend the creation method, so we are passing the is_versionable flag during the ResourceType creation.

Remaining tasks

discussion, patch, etc.

User interface changes

None...

API changes

New argument in ConfigurableResourceType class, inherited from jsonapi module.

Data model changes

Nothing big - just one more flag...

Release notes snippet

TBD.

CommentFileSizeAuthor
#3 3020112-3.patch649 bytesndobromirov

Comments

ndobromirov created an issue. See original summary.

ndobromirov’s picture

ndobromirov commented
Parent issue: » #2992833: Add a version negotiation to revisionable resource types
ndobromirov’s picture

ndobromirov commented
Status: Active » Needs review
StatusFileSize
new 3020112-3.patch649 bytes

Here is the patch that made both work for me.

Status: Needs review » Needs work

The last submitted patch, 3: 3020112-3.patch, failed testing. View results

ndobromirov’s picture

ndobromirov commented
Title: API change in jsonapi module. » [Regression] API change in jsonapi module.
Category: Feature request » Bug report
Status: Needs work » Postponed
Issue tags: +Needs manual testing, +API-First Initiative

Postponing based on the parent issue status.
Adding API-First tag, due to the parent issue being marked as such.
Needs manual testing as it needs the patched version of jsonapi to show the issue and this patch to resolve it.

ndobromirov’s picture

ndobromirov commented

This is fixing some of it. On further testing it seems that relationships are not having fields as well... Researching...

ndobromirov’s picture

ndobromirov commented

The issue is coming from this return statement in jsonapi_extras...

  protected function overrideFieldMapping(JsonapiResourceConfig $resource_config) {
    if ($resource_config instanceof NullJsonapiResourceConfig) {
      return [];
    }
    // This is not ideal, but we cannot load the resource type to get the entity
    // type object. That is because this is used during the creation of the
    // ResourceType.
    list($entity_type_id, $bundle) = explode('--', $resource_config->getOriginalId());

For some reason NULL configs are not using default settings for fields list etc so in my case only 10 out of 130 configs are overwritten.
The issue even if same might not be related...

The issue is that the old default behavior is failing, so anything that has not overwritten configs in jsonapi_extras will get an empty fields list, as it's always going in the above scenario.

ndobromirov’s picture

ndobromirov commented
Related issues: +#3020237: [Regression] Broken with latest jsonapi 2.0-rc3

I've opened a separate issue for the one described in #7: #3020237: [Regression] Broken with latest jsonapi 2.0-rc3

ndobromirov’s picture

ndobromirov commented
Status: Postponed » Closed (outdated)

This is not needed anymore as JSON:API and JSON:API Extras have included revisions support and the two latest stable versions are working correctly.