-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New fulfillment type shipping #6614
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
Conversation
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
|
// We do not have validatePermissions in context during this startup stage, hence commenting below | ||
// await context.validatePermissions("reaction:legacy:fulfillmentTypes", "read", { shopId }); | ||
|
||
const insertSuccess = await checkAndCreateFulfillmentType(context, shopId); |
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.
When we create an entity, isn't it implied that we check the prerequisite conditions anyway? The checkAnd
part of the function name seems a bit overexplicit.
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.
Inside the checkAndCreateFulfillmentType
we have the call to the original createFulfillmentType
mutation.
Although the mutation call is explicitly making the call to the one defined in context, I thought I could make this a bit explicit to avoid any quick confusion.
|
||
shippingRateDocs.map(async (doc) => { | ||
const carrier = doc.provider.label; | ||
const currentPluginMethods = doc.methods.filter((method) => ((method.fulfillmentMethod === (fulfillmentMethodName)) && (method.enabled))); |
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 the reasoning behind persisting the fulfillment method for a dynamic method? If the rates for are method are dynamically calculated on every fulfillmentMethodQuotes
by calling an external API I don't see much point in having a method with predefined rates here. It can be dynamically constructed on every get quotes request. The only reasoning I can think of is i we allow the method to be enabled or not. But in that case we should check that before pushing the newly calculated rate. The same goes of all other method plugins.
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 sure if I completely understood your point. The idea is that we are showing a placeholder function here which could be replaced by an actual API invoking function to collect the dynamic rate. The placeholder function is a dummy and currently returning some hard-coded values. It is expected to collect the actual dynamic quote/rate each time. Now the call to fulfillmentMethodQuotes
will be placed to all ff-methods defined under the specific fulfillment-type (like all shipping or all pickup) and this is collected and presented to the user to select one of them as the preferred method via the selectFulfillmentOptionForGroup
call.
We can have a quick call if I got your question wrong.
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
...fillment-method-shipping-dynamic-rate/src/fulfillmentMethodsWithQuotesShippingDynamicRate.js
Outdated
Show resolved
Hide resolved
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
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.
Similar comments as in the pickup PR and my comments about "type" vs. "method" vs. "provider" in another PR.
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
…ction into 00-fulfillment-base
conflict resolved: pnpm-lock Signed-off-by: Sujith <mail.sujithvn@gmail.com>
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
Signed-off-by: Sujith mail.sujithvn@gmail.com
Resolves #6471
Impact: breaking
Type: feature
This PR replaces #6579
Issue
In the current system, the only way for order fulfillment is via shipping which is hardcoded into the system. We need to introduce the flexibility for users to add their own fulfillment types via plugins.
Solution
We are creating a base fulfillment plugin which would enable other fulfillment types (like shipping, pickup, digital) to be introduced via plugins. Each of the newly introduced fulfillment type plugin would need to have the specific fulfillment methods also to be added as separate plugins. Example, fulfillment type 'pickup' could have fulfillment methods like 'store pickup' and 'curb-side pickup'.
This PR is for 2nd entry new-fulfillment-type-shipping
PR Details in order
Existing PRs originally based on the #6480 (to be updated to point to #6610)
We shall change the base branch of the 3 existing PRs (i18n #6545, dataMigration #6633 , setDefaultFFtype #6543) to point to 00 fulfillment base
API-PLUGIN-FULFILLMENT-TYPE-SHIPPING
API-PLUGIN-FULFILLMENT-METHOD-SHIPPING-FLAT-RATE
API-PLUGIN-FULFILLMENT-METHOD-SHIPPING-DYNAMIC-RATE
Breaking changes
Since this is the new way of handling fulfillment, the existing shipment plugins would not work along with this. User would need to migrate the data (migration script will be developed) and remove the shipment plugins (api-plugin-shipments and api-plugin-shipments-flat-rate).
Testing
All this is new code and at this stage this is not integrated to reaction, meaning the plugins.json is not updated to include this plugin. Hence proper testing can be carried out only after merging in the remaining PRs.