-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New fulfillment impacted plugins #6615
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
New fulfillment impacted plugins #6615
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>
|
packages/api-plugin-carts/src/util/updateCartFulfillmentGroups.js
Outdated
Show resolved
Hide resolved
packages/api-plugin-carts/src/util/updateCartFulfillmentGroups.js
Outdated
Show resolved
Hide resolved
packages/api-plugin-carts/src/util/updateCartFulfillmentGroups.js
Outdated
Show resolved
Hide resolved
packages/api-plugin-carts/src/util/updateCartFulfillmentGroups.js
Outdated
Show resolved
Hide resolved
packages/api-plugin-carts/src/util/updateCartFulfillmentGroups.js
Outdated
Show resolved
Hide resolved
packages/api-plugin-carts/src/util/updateCartFulfillmentGroups.js
Outdated
Show resolved
Hide resolved
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.
See a few suggestions, but overall this seems on the right track. I am not sure I like the "undecided" group. What if someone registers a fulfillment type plugin with the name "undecided"? If this ability is necessary, you could make the group.type
field optional and have null
mean undecided. But it seems like the best approach would be to have a required shop default and use that.
type: String, | ||
optional: true, | ||
label: "Display message to show in UI for this Method" | ||
}, |
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 believe fulfillmentMethod
is sort of a subtype, corresponding with the providing package (e.g. flat rate vs dynamic rate, but both are "shipping" type). The problem is that the project already uses the term "method" for individual methods, so it seems confusing. I think some other ecommerce platforms use fulfillmentProvider
, and that makes more sense to me. @zenweasel
@@ -733,6 +744,19 @@ export const CartItem = new SimpleSchema({ | |||
blackbox: true | |||
}, | |||
"updatedAt": Date, | |||
"selectedFulfillmentType": { | |||
type: String, | |||
allowedValues: ["undecided"], // extended with dynamic values in fulfillment plugin startup |
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.
Another option would be to have fulfillment plugins include an array in their plugin registration options:
{
fulfillmentTypes: ["shipping"]
}
Then use registerPluginHandler
in this cart plugin to read all of the plugin.fulfillmentTypes
and add them all to allowedValues
in the schema. That way all cart schema changes will happen in the cart plugin, which makes the most sense to me.
Something similar is how payment methods, address validation methods, etc. are registered from individual plugins.
packages/api-plugin-carts/src/util/updateCartFulfillmentGroups.js
Outdated
Show resolved
Hide resolved
Signed-off-by: Sujith <mail.sujithvn@gmail.com>
…lugins 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>
…acted-plugins 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>
…ction into 00-fulfillment-base 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 #6582
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 4th entry (new-fulfillment-impacted-plugins)
PR Details in order
Existing PRs 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 #6544, setDefaultFFtype #6543) to point to 00 fulfillment base
Changes in detail:
CARTS
CATALOGS
PRODUCTS
ORDERS
(above 2 changes are spread across multiple files)
Integration Tests updated
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.