This might be a followup of #2829762: Remove wrapping "data" element from the compound docs section.

When doing a POST of the relationship of a given entity, the data array that contains the ids is skipped in here:

id_list = array_column($relationship['data'], 'id');

After chatting with @pcambra, we realized that the problem is that JSON API is not throwing an error if the relationship object is not correctly formatted.

A relationship object contains one or more resource linkage objects. Those in turn contain a resource identifier object, that states that type and id are both mandatory.

We should throw an error if the incoming relationship is not spec compliant.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pcambra created an issue. See original summary.

pcambra’s picture

Status: Active » Needs review
FileSize
644 bytes

Status: Needs review » Needs work

The last submitted patch, 2: 2831035.patch, failed testing.

e0ipso’s picture

Title: When POSTing relationships ids are not calculated correctly » [BUGFIX] Throw an error when the input relationship is not formatted correctly
Issue summary: View changes

After chatting with @pcambra, we realized that the problem is that JSON API is not throwing an error if the relationship object is not correctly formatted.

A relationship object contains one or more resource linkage objects. Those in turn contain a resource identifier object, that states that type and id are both mandatory.

We should throw an error if the incoming relationship is not spec compliant.

e0ipso’s picture

Issue summary: View changes
ssemashka’s picture

I looked at the patch and it seems like it's quite outdated and cannot be applied to the latest codebase.
However, type check is already in the module based on the following code:

// ./src/Normalizer/JsonApiDocumentTopLevelNormalizer.php
$relationships = array_map(function ($relationship) {
        if (empty($relationship['data'])) {
          return [];
        }       
        $id_list = array_column($relationship['data'], 'id');
        if (empty($relationship['data'][0]['type'])) {
          throw new BadRequestHttpException("No type specified for related resource");
        }
// ...

So, I just added id check in the patch. If it's not necessary to throw an error on empty id, I'd suggest to claim this issue as fixed if no objections.

e0ipso’s picture

Status: Needs work » Needs review

Thanks @sergesemashko. Sorry I missed you on DrupalCon, when I came back to say bye you were already gone.

Kicking testbot.

  • e0ipso committed bd8fbfb on 8.x-1.x authored by sergesemashko
    fix(Spec): Throw an error when the input relationship is not formatted...
e0ipso’s picture

Status: Needs review » Fixed

Fixed.

Thank you all!

Wim Leers’s picture

+++ b/src/Normalizer/JsonApiDocumentTopLevelNormalizer.php
@@ -90,6 +90,9 @@ class JsonApiDocumentTopLevelNormalizer extends NormalizerBase implements Denorm
+          throw new BadRequestHttpException("No id specified for related resource");

Nit: s/id/ID/

e0ipso’s picture

Title: [BUGFIX] Throw an error when the input relationship is not formatted correctly » [STYLE] Fix string capitalization
Status: Fixed » Active
Issue tags: +Novice
rajeevk’s picture

Attaching patch with string capitalization changes as per comment.

Status: Needs review » Needs work

The last submitted patch, 12: string_capitalization--2831035-12.patch, failed testing.

e0ipso’s picture

@RajeevK for some reason the patch is failing to apply. Can you re-roll it?

rajeevk’s picture

Attaching another patch.

Status: Needs review » Needs work

The last submitted patch, 15: string_capitalization--2831035-14.patch, failed testing.

rajeevk’s picture

Status: Needs work » Needs review
FileSize
757 bytes

Re-rolling patch again after created from fresh instance.

  • e0ipso committed 08ddaa4 on 8.x-1.x authored by RajeevK
    style(Errors): Fix string capitalization (#2831035 by RajeevK, Wim Leers...
e0ipso’s picture

Status: Needs review » Fixed

Thanks @RajeevK!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.