Contrib.social

order_number should not be marked required

Open on Drupal.org →
Created on 24 June 2019, about 6 years ago
Updated 12 September 2024, 11 months ago

While trying to create an Order through JSON:API I got an error pushing me to provide the order_number as part of the request.
After some discussion with mikelutz and mglaman on Slack, the suggested solution was to make the order_number not required for draft orders and then add a custom validation constraint which marks it required for the other states.

The expectation would be to have the same behavior as if an Order is placed through the site where the order_number is set by the EventSubscriber to be the same as the order_id.

Extract of the body of JSON:API POST request:

{
  "data": {
    "type": "commerce_order--default",
    "attributes": {
    "mail": "dscl@example.com",
    "state": "draft"
  },
  (...)
}

Extract of the JSON:API error:

(...)
"title": "Unprocessable Entity",
"status": "422",
"detail": "order_number: This value should not be null.",
"source": {
  "file": "/var/www/devbrains/pubfactory-d9/web/core/modules/jsonapi/src/Entity/EntityValidationTrait.php",
  "line": 59,
  "pointer": "/data/attributes/order_number"
},
(...)
🐛 Bug report
Status

Active

Version

2.0

Component

Order

Created by

🇦🇺Australia dscl Melbourne, VIC

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 11 months ago →
    🇮🇳India vinay.p

    vinay.p → made their first commit to this issue’s fork.

  • Merge request !334Add validation constraint to make order_number not required only in the draft state → (Open) created by vinay.p
  • Pipeline finished with Failed
    11 months ago
    Total: 405s
    #281167
  • Pipeline finished with Failed
    11 months ago
    Total: 450s
    #281224
  • Status changed to Needs review 11 months ago
  • Comment 11 months ago →
    🇮🇳India vinay.p
  • Pipeline finished with Failed
    10 months ago
    Total: 553s
    #319990
  • Pipeline finished with Failed
    10 months ago
    Total: 609s
    #319997
  • Pipeline finished with Failed
    10 months ago
    Total: 1195s
    #320020
  • Pipeline finished with Success
    10 months ago
    Total: 695s
    #320053
  • Pipeline finished with Failed
    10 months ago
    Total: 591s
    #320986
  • Pipeline finished with Success
    10 months ago
    Total: 986s
    #320993
  • Pipeline finished with Success
    10 months ago
    Total: 718s
    #322240
  • Pipeline finished with Success
    10 months ago
    Total: 948s
    #322247
  • Pipeline finished with Failed
    8 months ago
    Total: 185s
    #366620
  • Pipeline finished with Failed
    8 months ago
    Total: 157s
    #366624
  • Pipeline finished with Success
    8 months ago
    Total: 288s
    #366635
  • Pipeline finished with Canceled
    8 months ago
    Total: 75s
    #366640
  • Pipeline finished with Success
    8 months ago
    Total: 157s
    #366650
  • Pipeline finished with Success
    8 months ago
    Total: 260s
    #366702
  • Pipeline finished with Success
    8 months ago
    Total: 158s
    #366707
  • Pipeline finished with Success
    8 months ago
    Total: 2777s
    #374065
  • Pipeline finished with Skipped
    8 months ago
    #374109
  • Comment 6 months ago →
    🇺🇸United States morbus iff
  • Comment about 2 months ago →
    🇮🇱Israel jsacksick

    Do we really have to load the order afresh from the DB? This can be quite expensive in terms of performance... I'd prefer to avoid that if possible...

  • Comment about 18 hours ago →
    🇮🇳India vinay.p

    OrderVersion constraint already loads unchanged entity anyways. If it caches it (does it?) then doing the same in OrderNumber constraint might be harmless.

    Unrelated to the patch:
    I looked into it again and it seems like if we set order_number to FALSE, it does accept it for some reason. I tried step debugging all the way through and found the probable culprit in NotNullConstraintValidator and specifically in the isEmpty method of StringItemBase. It doesn't seem to consider FALSE as an empty string value.

    Passing FALSE in order_number does feel a bit awkward and kind of a hack, even though it does seem to end up as an empty string afterwards. Thoughts?

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024