Description
Preconditions (*)
1.Magento2.4.0
2.GraphQL
Steps to reproduce (*)
1.Create a new Module HelloWorld.
2.Create a schema.graphqls in HelloWorld/Sales/etc/ folder to extend the CustomerOrderFilterInput.
Put following codes in this file:
input CustomerOrdersFilterInput @doc(description: "Identifies the filter to use for filtering orders.") {
created_at: FilterRangeTypeInput @doc(description: "Filters by created at.")
}
input FilterRangeTypeInput @doc(description: "Defines a filter that matches a range of values, such as prices or dates.") {
from: String @doc(description: "The beginning of the range")
to: String @doc(description: "The end of the range")
}
3.Use the following payload and {{your URL}}/graphql to query the customer token.
mutation {
generateCustomerToken(email: "{{your email address}}", password: "{{your password}}") {
token
}
}
4.Put above token in Postman Headers Authorization with Bearer {{your token}}.
5.Use following payload to query the above customer's sales orders.
query {
customer {
orders(filter: {
created_at: {
from: "2021-01-02"
to: "2021-01-04"
}}) {
items {
number
created_at
}
}
}
}
6.The above query will get the result of all orders from 2021-01-02 or to 2021-01-04, not between 2021-01-02 and 2021-01-04.
Expected result (*)
1.What I expect is that the orders between 2021-01-02 and 2021-01-04.
Actual result (*)
1.The actual result is that the orders from 2021-01-02 or to 2021-01-04.
2.OrderFilter.php file makes filter conditions in the same filterGroups item and the relationship is OR. Maybe it is not a bug, but generally every condition should be in a separate filterGroups which relationship is AND. More ideally, in graphQL payload, some style like and: "true" can be provided to make a different logic combination.
Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.
- Severity: S0 - Affects critical data or functionality and leaves users without workaround.
- [*] Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
- Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
- Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
- Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status