Add API endpoint for customer returns

[seand7565]

THIS PR SPONSORED BY Super Good Software

Description

Adds an API endpoint that allows you to manage customer returns. Also adds a test suite for this new API endpoint, adds associated jbuilder files, adds customer_return.number to ransackable attributes, and creates a connection between order and customer_return for easier referencing.

Just like return_items, when you create the customer_return you'll also need to add attributes for the return_items associated with the return.

Quick note: The way I'm referencing customer returns from the order is a bit convoluted, because there's no order_id on customer_returns. I think there should be, as it would simplify this a bit (and it makes sense that customer returns would be connected to the order like return authorizations are) - but it felt like it was outside of the scope of this PR.

Ref #3566

Checklist:

• I have followed Pull Request guidelines
• I have added a detailed description into each commit message
• I have updated Guides and README accordingly to this change (if needed)
• I have added tests to cover this change (if needed)
• I have attached screenshots to this PR for visual changes (if needed)

[kennyadsl]

That's great @seand7565, thanks! And also thanks @jarednorman!

I think we need to squash these two commits and add some API documentation as well. Feel free to ask if you need help with that.

[seand7565]

@kennyadsl Squashed & documented! I added to the stoplight documentation, let me know how it looks. Thanks!

[kennyadsl]

Thanks Sean!

[ccarruitero]

Thanks @seand7565 for the PR.

In admin workflow, in order to create a CustomerReturn, you need to create a ReturnAuthorization first.
https://guides.solidus.io/developers/returns/overview.html
https://guides.solidus.io/developers/returns/customer-returns.html

Until I understand, that is because you have to accept or not the return, and setup the ReturnReason and ReimbursementType for the ReturnItem

And after generate the CustomerReturn, you associate the ReturnItems that you will receive.

So, I think we should receive a return_authorization_id and list of ReturnItems parameters for create a CustomerReturn. Then, we should validate that the ReturnAuthorization is accepted for generate the new CustomerReturn and associate the given return items with the generated CustomerReturn.

Also, we should need to generate a Reimbursement for the items that the customer return

[seand7565]

Hey @ccarruitero, thanks for the review!

On requiring RMAs - I tried to model the API the same way the backend works. Currently, an RMA is NOT required for creating a Customer Return. You can create a customer return with no RMA, and it will create the customer return successfully. However, it will generate an “acceptance error” of {:rma_required=>"Return item requires an RMA”} - this does not prevent you from saving the Customer Return, nor will it prevent you from “receiving” it - it will toss the Customer Return into the “Rejected” column though, and will not create a reimbursement.

While I don’t like the way this is handled (there are a lot of Return Item statuses that don’t make sense with RMAs like “given to customer” or “lost in transit” - you wouldn’t be expecting a return in those situations but might still want a reimbursement), changing the functionality of how this works is another issue - one that I might tackle very shortly, but outside of the scope of this PR.

Reimbursements AFAIK are handled by return_item state changes - setting the reception status of the customer return should trigger the reimbursement handler.

I’ll take a look at your comments on the code a bit later - thanks for the input!

[kennyadsl]

Thanks @seand7565 and @ccarruitero for the review!

The "RMA required" part is a bit tricky. By default, you need to have a RMA to create valid Return Items and Customer Returns.

This depends on a specific validator set here that can be changed depending on the needs.

For now, I'll keep it as in admin even if it's not ideal.