-
Notifications
You must be signed in to change notification settings - Fork 474
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add save, update_tracking, and cancel actions to FulfillmentOrderFulfillment resource #639
Add save, update_tracking, and cancel actions to FulfillmentOrderFulfillment resource #639
Conversation
7f5e63c
to
90ab4b6
Compare
43505f9
to
797e348
Compare
366a1e8
to
4ce57df
Compare
797e348
to
130deca
Compare
130deca
to
d1fd0c8
Compare
8c5ddaf
to
41b60d0
Compare
d1fd0c8
to
0c557e7
Compare
0c557e7
to
a82a554
Compare
f1da843
to
46935ea
Compare
a82a554
to
1c3b49d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not finished reviewing this yet, will finish up tomorrow. Here are some of my existing thoughts.
@@ -6,8 +6,32 @@ def order_id | |||
@prefix_options[:order_id] | |||
end | |||
|
|||
def cancel; load_attributes_from_response(post(:cancel, {}, only_id)); end | |||
def cancel(using_fulfillment_orders: false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new cancel endpoint does functionally the same thing as the old one. So why don't we just leave the original cancel method as is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we had decided on this, everyone can use the existing endpoint.
def complete; load_attributes_from_response(post(:complete, {}, only_id)); end | ||
def open; load_attributes_from_response(post(:open, {}, only_id)); end | ||
|
||
def create |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm unsure what's provided by ActiveResource::Base
but is this intended to override self.create
the class method instead of the instance method? What about .save
? We still need to support both POST /admin/api/2020-01/orders/#{order_id}/fulfillments.json
and POST /admin/api/2020-01/fulfillments.json
no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, that makes sense, I forgot about save
being used for create.
46935ea
to
225ad9f
Compare
1c3b49d
to
744ef60
Compare
@@ -9,5 +9,26 @@ def order_id | |||
def cancel; load_attributes_from_response(post(:cancel, {}, only_id)); end | |||
def complete; load_attributes_from_response(post(:complete, {}, only_id)); end | |||
def open; load_attributes_from_response(post(:open, {}, only_id)); end | |||
|
|||
def self.create(attributes = {}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think self.create
is synonymous to calling new
then save
. https://api.rubyonrails.org/v3.2.6/classes/ActiveResource/Base.html#method-c-create so we should be good by just overriding save.
fulfillment | ||
end | ||
|
||
def save |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fc57449
to
c5e8b3b
Compare
744ef60
to
6fc2312
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! I only have one question about `attributes.delete(:order_id).
@@ -9,5 +9,41 @@ def order_id | |||
def cancel; load_attributes_from_response(post(:cancel, {}, only_id)); end | |||
def complete; load_attributes_from_response(post(:complete, {}, only_id)); end | |||
def open; load_attributes_from_response(post(:open, {}, only_id)); end | |||
|
|||
def order_id=(order_id) | |||
binding.pry |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to be removed.
|
||
def order_id=(order_id) | ||
binding.pry | ||
attributes.delete('order_id') || attributes.delete(:order_id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it calling delete
twice? I am a bit confused here 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Normally the attributes
contains string keys. When I was refactoring this, some versions ended up with symbol keys :order_id
. Finally in the end, neither is needed as the prefix_options
are set explicitly by client code and not inferred from attributes
so removing this.
e34a461
to
a615ff8
Compare
a615ff8
to
4842030
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wondering why you are doing one thing
end | ||
|
||
fulfillmentV2 = FulfillmentV2.new(attributes) | ||
result = fulfillmentV2.save |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a way of migrating fulfillments? Why are you doing this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do this not for any sort of migration but because we have different endpoints with different supported operations. We have this situation because the backend has two REST paths for fulfillments, the existing pre-FulfillmentOrder one at /order/#/fulfillments
and the new FulfillmentOrder based one at /fulfillments
. To make them interoperable we use the Fulfillment
resource which routes to the FulfillmentV2
resource when we need to use the /fulfillments
path for an operation. Whenever reading a response, we always convert FulfillmentV2 back to Fulfillment.
cc1307d
into
fulfillment-orders-fulfillment-cancellation-request
This PR adds the following POST requests:
POST fulfillments (via FulfillmentOrderFulfillment.save)
POST fulfillments/:fulfillment_id/update_tracking
POST fulfillments/:fulfillment_id/cancel
GET requests are in PR #633
FulfillmentOrder actions move, cancel, close are in PR #635
FulfillmentOrder actions fulfillment_request (+ accept/reject), cancellation_request (+ accept/reject) are in PR #637
Subsequent PRs will add other fulfillment order related requests to relevant resources.
Since all that's really needed is the
fulfillment_id
, if it's known you can do (rather than querying it first):Notes to reviewer:
Fulfillment
resource which I haven't yet determined is the same/compatible with FO fulfillments so created a new resource FulfillmentOrderFulfillment