macder / medusa-fulfillment-shippo Goto Github PK

query /store/shippo/live-rates/:cart_id using cart with complete address minus provice/state field

{
    "type": "invalid_data",
    "message": "\"province\" is not allowed to be empty",
    "date": "2022-06-18T02:58:09.615Z"
}

Certain countries do not have a province or state in addresses

if cart is missing shipping address, a query to /store/shippo/live-rates/:cart_id responds with:

{
    "type": "invalid_data",
    "message": "\"value\" must be of type object",
    "date": "2022-06-18T02:48:32.648Z"
}

The error message is confusing as it doesnt provide any context

This got introduced after the refactor. flatten the json - remove 'response' field

Affected endpoints:

• /admin/fulfillments/:id/shippo/order
• /admin/fulfillments/:id/shippo/packingslip

endpoint to retrieve shippo shipment objects using medusa fulfillment id or order id

/admin/shippo/shipments/:fulfillment_id
/admin/shippo/shipments/:order_id

new file structure should look like:

-api
  -middlewares
  -routes
    -store
    -admin

sku
barcode
ean
upc
hs_code
mid_code

eliminate the manual step of changing the config reference (standalone localhost vs medusa package)

when creating shippo order, use fromOrder.display_id instead of fulfillment.id to make it more human friendly...

too much going on in 1 file...

at the very least move all shippo api calls into /utils/client

order totals missing:
total_price
subtotal_price
currency

line_items have totals, this is for the whole order

endpoint /store/shippo/ive-rates responds with empty json string when the cart has multiple types of products

i.e., so we dont mess around with ones that dont belong to this plugin

replace static json data mocks with dynamic generators. utilize fakerjs...

introduce unit and implementation testing

jest

The composeFullfillmentOptions method is getting invoked in the constructor when setting it to property

Super inefficient and expensive...

Assign it as a reference so it only invokes when called

add and config .eslint

POST http://localhost:9000/admin/shipping-options

Response:

{
    "type": "invalid_data",
    "message": "The fulfillment provider cannot calculate prices for this option"
}

it makes more sense to have utils/client as a class instantiated on a property of ShippoFulfillmentService so it can be easily accessed, i.e in routes...

webhook to mark fulfillment as shipped when a label is purchased in shippo

certain calls dont need wrappers, and it can be useful for devs using the plugin...

put it on useClient property of shippoFulfillmentService

creating new fulfillment should get and save the shippo order id if the request was successful

/store/carts/:ID/shippo/rates GET shippo live-rates
/store/shipping-options/:cart_id/shippo/rates/ POST calculated shipping-option(s)
/admin/fulfillments/:fulfillment_id/shippo/order GET shippo order
/admin/fulfillments/:fulfillment_id/shippo/packingslip GET shippo packing slip

api/routes
├── admin
│   ├── fulfillment-order.js
│   ├── fulfillment-packingslip.js
│   └── index.js
└── store
    ├── carts-rates.js
    ├── index.js
    └── shipping-options-rates.js

bin packer seems to get it right most of the time, but thats just an anecdote

create unit tests to measure accuracy.

When an admin creates an order fulfillment, the fulfillment id should be in the request object sent to Shippo.

This will allow to match a Shippo order to the order fulfillment in admin

bin packer is calling a synchronous function splitItems during an async execution...

service groups in shippo have 3 types (live-rate, free, flat)

implement support for "free" type

This is high priority now.

0.8.0 and 0.8.1 had preventable issues that got caught post release...

Currently /store/shippo/live-rates only uses the default parcel template when retrieving shipping cost estimates.

This can be improved by adding more parcel templates and then do some dimensional weight calculations to pick a parcel

Considering that calculating parcel dimensions for mutiple items of various sizes is a computational NP-Hard problem, this doesnt need to be highly sophisticated. The idea is to improve the estimates as much as possible using some simple algorithm

implement this: https://goshippo.com/docs/orders/#create-order-packing-slip

The error message in the response disaperared... just returns empty json when requesting live rate with no address

currently there is a mix of error handling. implement MedusaError for all errors

Set a supported order_status value when creating a shippo order

see: https://goshippo.com/docs/orders/#order-order-status

expose new endpoint for retrieving the shippo parcel template that was used to get a live-rate during checkout

it should accept an order_id or fulfillment_id and return the parcel template

The cancelFulfillment method is missing

At minimum declare the method.

Logic can be implemented later, for now just declaring it will pass it to the core fulfillmentServiceProvider