feat(medusa, core-flows, fulfillment): calculate SO price endpoint #10532
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
5 Skipped Deployments
|
|
packages/medusa/src/api/admin/shipping-options/[id]/calculate/route.ts
Outdated
Show resolved
Hide resolved
fPolic
force-pushed
the
feat/calculate-so-price-endpoint
branch
from
2fbd99d to
5d36c2c
Compare
fPolic
changed the base branch from
feat/create-so-calculated-prices
to
develop
| /** | ||
| * The calculation context needed for the associated fulfillment provider to calculate the price of a shipping option. | ||
| */ | ||
| context: { |
There was a problem hiding this comment.
q: is it enough to pass the cart id and the rest of what is needed can be fetched by the provider or should we pass specific customer info, address info etc. (if, for example, a calculated option is used in an RMA flow)
There was a problem hiding this comment.
Think we will need more, such as items to calculate prices on product/inventory item dimensions. To be consistent with other providers, we don't want to delegate the responsibility of fetching data from core modules to the provider (yet). This should be a preliminary step and passed to the provider.
Just looping in @srindom – he might have an idea about what we could start with
There was a problem hiding this comment.
@fPolic to unblock the PR, here's what I think we will definitely need:
- Items, e.g. package dimensions and weight
- Shipping address, e.g. distance from origin to destination
We can add these now and expand in the future in case we need more.
packages/modules/providers/fulfillment-manual/src/services/manual-fulfillment.ts
Outdated
Show resolved
Hide resolved
| @@ -53,7 +53,6 @@ export interface IFulfillmentProvider { | |||
| */ | |||
| calculatePrice( | |||
| optionData: Record<string, unknown>, | |||
There was a problem hiding this comment.
thought: think we still need data – I believe the current naming is cause for confusion.
optionData – data that was populated when creating the shipping option, e.g. requires_drop_point.
data – data that is populated when you create the shipping method, e.g. drop_point_id: 1
For requests that are made prior to adding the shipping method to a cart, the data might be empty.
For example:
POST /store/shipping-options/:id/calculate
However, when adding the shipping method to cart and the price is calculated, you might need the data for the calculation.
For example:
POST /store/carts/:id/shipping-methods
{ option_id: "so_1234", data: { drop_point_id: 1 } }
In your implementation of calculatePrice, the calculated price might depend on the drop point ID (maybe a farfetched example):
// pseudo code
calculatePrice() {
if (drop_point_id) {
const acceptPackageSizes = await this.fetchDropPointPackageSizes(drop_point_id)
const price = // one of those package sizes
return price
}
}There was a problem hiding this comment.
ahh ok, thanks for clarifying - will revert the changes
packages/modules/providers/fulfillment-manual/src/services/manual-fulfillment.ts
Outdated
Show resolved
Hide resolved
| /** | ||
| * The calculation context needed for the associated fulfillment provider to calculate the price of a shipping option. | ||
| */ | ||
| context: { |
There was a problem hiding this comment.
Think we will need more, such as items to calculate prices on product/inventory item dimensions. To be consistent with other providers, we don't want to delegate the responsibility of fetching data from core modules to the provider (yet). This should be a preliminary step and passed to the provider.
Just looping in @srindom – he might have an idea about what we could start with
packages/medusa/src/api/store/shipping-options/[id]/calculate/route.ts
Outdated
Show resolved
Hide resolved
packages/medusa/src/api/store/shipping-options/[id]/calculate/route.ts
Outdated
Show resolved
Hide resolved
…edusajs#10532) **What** - endpoint + flow for fetching calculated price for a shipping option --- CLOSES CMRC-777
What
CLOSES CMRC-777