Problem/Motivation

When building a constraint violation, it's possible to specify a code.

The UnprocessableHttpEntityExceptionNormalizer doesn't currently support returning the "code" passed to the violation;

CommentFileSizeAuthor
#2 3274805-2.patch870 bytesjsacksick

Comments

jsacksick created an issue. See original summary.

jsacksick’s picture

jsacksick commented
Status: Active » Needs review
StatusFileSize
new 3274805-2.patch870 bytes

This probably requires tests coverage, but just submitting the patch to see if the JSON API maintainers would like to see this happen first.

Status: Needs review » Needs work

The last submitted patch, 2: 3274805-2.patch, failed testing. View results

bbrala’s picture

bbrala
Location Netherlands
commented

What would that code field contain? When i look at the tests it seems like its the uuid of the resource, which you know anyhow. This feels rather redundant. If its a relevant errorcode, it feel more helpfull. But how consistent is it is the next question then. A field that sometimes appears is not something i'd prefer.

Could you perhaps explain a little more about the usecase?

jsacksick’s picture

jsacksick commented

@bbrala: Commerce defines a service for checking the availability of a purchasable entity (the AvailabilityManager).
The availability manager invokes logic from "availability checkers" which are tagged services.

The availability manager is invoked via a constraint validator attached to the "purchased_entity" field (which is on the order item). Currently availability checkers can return an AvaillabilityResult and specify a reason why a given purchasable entity isn't available.

I recently opened #3274829: Allow availability results to return a "code" to allow availability checkers to return a "code" alongside the availability result.

This Drupal core patch allows me returning the code alongside the response.

Does that answer your question?

bbrala’s picture

bbrala
Location Netherlands
commented

Yes thank you for your explaination, will have look soon :)

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.