Problem/Motivation

The ResourceTestBase::getNestedIncludePaths can create broken include paths.

product_id.variations.product_id.commerce_product_variation_type

In Commerce Products reference their Variations, and the Variation has a backreference to its Product.

Steps to reproduce

Discovered when working on #3128322: Filtering variations over JSON:API is always access false.

Proposed resolution

TBD

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

CommentFileSizeAuthor
#2 resourceresponsetest-3163590-2.patch1008 bytesmglaman

Comments

mglaman created an issue. See original summary.

mglaman’s picture

Status: Active » Needs work
StatusFileSize
new1008 bytes

In doing this fix, it broke on the include for uid.roles for the owner field.

mglaman’s picture

This error is caused when it tries to find the public field name for commerce_product_variation_type.

      foreach ($field_names as $key => $public_field_name) {
        $resource_type = $this->container->get('jsonapi.resource_type.repository')->get($entity->getEntityTypeId(), $entity->bundle());
        $field_name = $resource_type->getInternalName($public_field_name);

By this time the entity has turned into the product and is no longer the variation.

mglaman’s picture

Title: ResourceResponseTestTrait::getExpectedIncludedResourceResponse overwrites $entity variable in loop » ResourceTestBase::getNestedIncludePaths can break with back references
Issue summary: View changes

Okay, so I was wrong about this and misunderstood how getExpectedIncludedResourceResponse works.

Upon further investigation I saw the include path which caused errors was:

product_id.variations.product_id.commerce_product_variation_type

In Commerce Products reference their Variations, and the Variation has a backreference to its Product.

I don't know how it ended up with commerce_product_variation_type instead of commerce_product_type (the proper public field name.)

mglaman’s picture

Title: ResourceTestBase::getNestedIncludePaths can break with back references » ResourceTestBase uses incorrect resource type throughout itself

Gabe helped rubber duck this with me. The problem is JSON:API auto alaises type to {entity_type_id}_type because type is a reserved word in the spec.

Drupal core doesn't have multiple entities that regularly reference themselves where "bundle" => "type". But Commerce does. In fact all of our entities have their bundle key as type.

          // @todo this is where it gets weird.
          // variation -> type (bundle ref)
          // product -> type (bundle ref)
          // store -> type (bundle ref)
          // jsonapi auto aliases `type` to `{entity_type_id}_type`
          $internal_field_name = $resource_type->getInternalName($field_name);

Throughout ResourceTestBase the $this->resourceType resource type is invoked to get an internal field name for a public field. The problem is that the entity being inspected is changing and not of that resource type.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.