Add updateOrder mutation #5019
Add updateOrder mutation #5019
Conversation
Signed-off-by: Eric Dobbertin <eric@dairystatedesigns.com> Signed-off-by: Erik Kieckhafer <ek@ato.la>
Signed-off-by: Eric Dobbertin <eric@dairystatedesigns.com> Signed-off-by: Erik Kieckhafer <ek@ato.la>
Signed-off-by: Erik Kieckhafer <ek@ato.la>
Signed-off-by: Erik Kieckhafer <ek@ato.la>
kieckhafer
force-pushed
the
feat-aldeed-update-order-mutation
branch
from
e564101
to
d961a13
Compare
There was a problem hiding this comment.
Made two commits with what I think are "fixes" to some commenting, looks like it just wasn't updated from being copied over from the move mutation, but please confirm my changes are OK.
Also fixed conflicts in a few files, most were straightforward but inside imports/plugins/core/orders/server/no-meteor/schemas/schema.graphql just want to make sure it looks ok.
Also a couple questions...
| * @param {Object} parentResult - unused | ||
| * @param {Object} args.input - an object of all mutation arguments that were sent by the client | ||
| * @param {Object} [args.input.customFields] - Updated custom fields | ||
| * @param {String} [args.input.email] - Set this as the order email |
There was a problem hiding this comment.
Should any of these, aside from customFields, be inside an array in the docs?
There was a problem hiding this comment.
Are you referring to the [] around them? That means optional in jsdoc and they are in fact all optional except orderId. Ideally you would provide as least one thing to update, but if you don't, I just have it return the un-updated order without throwing an error.
There was a problem hiding this comment.
Got it... Yes that is what I was referring to.
| @@ -0,0 +1,12 @@ | |||
| mutation ($email: String, $orderId: ID!, $status: String) { | |||
There was a problem hiding this comment.
Does customFields need to be added in the mutation here, or is that going to ben an extension in its' own package?
There was a problem hiding this comment.
It will need to be added if used because we don't know what the schema should be.
| @@ -401,6 +406,30 @@ input PlaceOrderInput { | |||
| payments: [PaymentInput] | |||
| } | |||
|
|
|||
| "Input for the updateOrder mutation" | |||
| input UpdateOrderInput { | |||
There was a problem hiding this comment.
Does customFields need to be added in the mutation here, or is that going to ben an extension in its' own package?
There was a problem hiding this comment.
It will need to be added if used because we don't know what the schema should be.
There was a problem hiding this comment.
Do you think there should be some sort of list somewhere that is an array of allowed workflow statuses? Maybe something that goes along with the orderStatusLabels that I was working on.
I see the argument that it's on the user / the client / somewhere else, outside the API, to be checking this data, but I can add anything I want to the workflow and there isn't really any consequence to it:
|
Works as described. Can update order only from A few comments, but overall good to go. |
…-order-mutation # Conflicts: # imports/plugins/core/orders/server/no-meteor/mutations/index.js # imports/plugins/core/orders/server/no-meteor/resolvers/Mutation/index.js # imports/plugins/core/orders/server/no-meteor/schemas/schema.graphql
|
@kieckhafer I do think eventually we should check against a status list, but we'll soon have to do some work to make that list configurable. I thought about adding a check now with a hard-coded array but it seems low risk to leave it wide open for now, and I don't know for sure that people aren't already storing custom statuses that would not be valid according to our list. |
|
Also, @kieckhafer all of your commits and conflict fixes LGTM. Thanks! |
Part of #4999
Impact: minor
Type: feature
Changes
A new
updateOrdermutation allows you to change theemail,status, orcustomFieldsof an order after it has been placed. (SavingcustomFieldsis not enabled by default. See https://docs.reactioncommerce.com/docs/how-to-store-custom-order-fields)The operator UI does not yet implement this.
updateOrdercan be called internally to synchronize from an external system by settingcontext.isInternalCalltotrueupdateOrdercan be called through GraphQL by any user with "orders" permission for the shop that owns the orderBreaking changes
None
Testing
Note: Do not worry about testing the
customFieldsupdate since it requires customization to opt in.