Fixed customerOrders GraphQL queries containing sub-resolvers requiring 'model'

[bgorski]

Description (*)

This PR fixes the customerOrders GraphQL query containing arguments that require $value['model'] to be filled with the order object. Although the query itself is deprecated already and the data can be retrieved by a customer query (which works well) with appropriate arguments, I think that we should support customerOrders for as long as it's not removed from the codebase.

Related Pull Requests

Fixed Issues (if relevant)

Manual testing scenarios (*)

1. Register a customer and place an order in the admin panel for that customer
2. Generate an invoice for that order
3. Use the following GraphQL mutation to generate the customer token:

mutation {
  generateCustomerToken(
    email: "your.customer@email.here"
    password: "your-password"
  ) {
    token
  }
}

4. Use the token from from the previous mutation to authorize the following query:

query {
  customerOrders {
    items {
      order_number
      grand_total
      status
      invoices {
          id
          items {
              id
              discounts {
                  amount {
                    value
                  }
              }
          }
      }
    }
  }
}

This will trigger the faulty behavior.

Questions or comments

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• All automated tests passed successfully (all builds are green)

Resolved issues:

1. resolves [Issue] Fixed customerOrders GraphQL queries containing sub-resolvers requiring 'model' #36829: Fixed customerOrders GraphQL queries containing sub-resolvers requiring 'model'

[m2-assistant]

Hi @bgorski. Thank you for your contribution
Here are some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

• @magento give me test instance - deploy test instance based on PR changes
• @magento give me 2.4-develop instance - deploy vanilla Magento instance

❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names. Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE,
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here

ℹ️ Please run only needed test builds instead of all when developing. Please run all test builds before sending your PR for review.

For more details, please, review the Magento Contributor Guide documentation.

⚠️ According to the Magento Contribution requirements, all Pull Requests must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

🕙 You can find the schedule on the Magento Community Calendar page.

📞 The triage of Pull Requests happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

🎥 You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[bgorski]

@magento run all tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[bgorski]

@magento run Functional Tests B2B, Functional Tests EE , Functional Tests CE, WebAPI Tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[bgorski]

@magento run Functional Tests B2B, Functional Tests EE, Functional Tests CE

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[bgorski]

@magento run Functional Tests B2B, Functional Tests EE, Functional Tests CE

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[bgorski]

@magento run Functional Tests EE

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[sdzhepa]

Hello @bgorski

Could you please provide more details on the scenario and problem?
e.g. Actual and expected results

It is not clear

This will trigger the faulty behavior.

Thank you in advance!

[sidolov]

@bgorski do you have any updates? Thanks!

[sdzhepa]

Closed due to no activities and no response on #33805 (comment) #33805 (comment)

[bgorski]

@sdzhepa sorry, missed your comment. The scenario involves using the customerOrders query to get (among any other data you might want to get) invoices with invoice items. That will make the system use the Magento\SalesGraphQl\Model\Resolver\Invoice\InvoiceItems resolver class, which contains a language-level error. The base64_encode($invoiceItem->getEntityId()) function that will then get triggered in the getInvoiceItemData method expects to get string and it's provided with an int (an actual int, not just a string containing a number). Because strict types are declared in the InvoiceItems class, this will result in a TypeError. That's the faulty behavior mentioned in my initial report.

[bgorski]

@magento run all tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[bgorski]

@magento run WebAPI Tests, Functional Tests CE

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[bgorski]

@magento run WebAPI Tests, Functional Tests CE

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[engcom-Alfa]

@magento create issue

[engcom-Alfa]

hey @bgorski

Thanks for reporting this ticket,

request you to please help us share some more information about the ticket regarding the actual and expected result before we retest it. hence marking it as need update.

[engcom-Hotel]

@magento run all tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[bgorski]

@magento run Functional Tests EE

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please message the #magento-devops slack channel if they don't show in a reasonable amount of time and a representative will look into any issues.