>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3267304. --> Reported by: [guypaddock](https://www.drupal.org/user/156932) Related to !7 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>As described in the Paragraphs issue queue in <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-1"><a href="https://www.drupal.org/project/paragraphs/issues/3092936" title="Status: Active">#3092936: Unable to save paragraph reference field in a node through JSONAPI</a></span>, right now when updating Paragraphs fields through JSON:API, the caller has to have the exact revision ID of the target entity in order to do anything with an ERR field. It would be preferable to instead allow the consumer to use the default revision of the target entity just by specifying its UUID. </p> <p>In fact, if a UUID is provided that does not match the target revision ID, the UUID is disregarded and the response ends up containing the revision ID and UUID of the entity having the given revision ID (i.e. the revision ID is more authoritative than the UUID). This seems broken. I would assume that <code>\Drupal\entity_reference_revisions\Plugin\Field\FieldType\EntityReferenceRevisionsItem::onChange()</code> and/or <code>\Drupal\entity_reference_revisions\Plugin\DataType\EntityReferenceRevisions::setValue()</code> would be smart enough to fill-in the default revision ID given just the target entity ID, but they do not.</p> <p>I saw the patch for <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/entity_reference_revisions/-/work_items/2913713" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/entity_reference_revisions/-/work_items/2913713</a></span> but that normalization change has no effect on JSON:API or other APIs that are manipulating field values directly through the Entity API.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <ol> <li>Create a Paragraphs type.</li> <li>Create a Node type containing a multi-valued Paragraphs field that references the Paragraphs type.</li> <li>Programmatically create two Paragraphs entities through the Entity API (e.g., using Devel PHP or a hook in a module).</li> <li>Using JSON:API, make a POST request that references both of the Paragraph entities in the paragraphs field, but references them only by their UUID, ommitting the <code>meta.target_revision_id</code> value for each.</li> <li>Programmatically create two additional Paragraphs entities through the Entity API (e.g., using Devel PHP or a hook in a module) and take note of their revision IDs.</li> <li>Using JSON:API, make a POST request that references both of the Paragraph entities in the paragraphs field, referencing the UUIDs of the wrong paragraphs (the ones from step 3), while including <code>meta.target_revision_id</code> values that match the revision IDs from step 5.</li> </ol> <p>The expected result is that:</p> <ol> <li>At step 4, the node gets created with references to the default revisions of each Paragraph.</li> <li>At step 6, an error should appear that indicates that the target ID and revision ID do not match.</li> </ol> <p>The actual result is that:</p> <ol> <li>At step 4, the node gets created with an empty reference in the Paragraphs field.</li> <li>At step 6, the node gets associated with the Paragraphs from step 3 instead of step 5, based on the revision IDs.</li> </ol> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>If the values array only contains a target ID, it should be used to fill-in the revision ID automatically so that the records can be associated properly.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <h3 id="summary-ui-changes">User interface changes</h3> <h3 id="summary-api-changes">API changes</h3> <h3 id="summary-data-model-changes">Data model changes</h3>