+
Skip to content

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

Merged
merged 21 commits into from
May 18, 2023

Conversation

sujithvn
Copy link
Contributor

@sujithvn sujithvn commented Nov 3, 2022

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

feat/fulfillment-types
 | 
 | __ 00 fulfillment base #6610 
 |        | __ new-fulfillment-type-shipping      #6614
 |        | __ new-fulfillment-type-pickup.    #6613 
 |__ new-fulfillment-impacted-plugins. [carts, products, orders, catalogs]  <--- This PR #6615 
 |__ new-placeOrder refactor validateOrder #6616 

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
  • New field - cartVersion in the cart to identify the new carts. Old carts will not have this field
  • New field - selectedFulfillmentType: This field allows UI to send the fulfillment-type selected by user for the product while adding to the cart. This is optional and if not selected the item would default to undecided fulfillment group.
  • New field - supportedFulfillmentTypes: This field was supposed to be existing but was missing. Added now (bug fix).
  • New Mutation - setFulfillmentTypeForItems: Accepts an array of itemIds and a selected fulfillment type along with cart details. This mutation would move all the provided items to the requested fulfillment group depending on conditions like FFtype is supported by product, FFtype is active etc.
  • Exported ShippingMethod & Shipment from SimpleSchema - these schemas will be extended in the api-plugin-fulfillment plugin to have the allowedValues changed from the hard coded "shipping" to dynamic array containing all the installed FFTypes
  • New field - fulfillmentMethod - This is field will be non-editable and used for matching the fulfillment method from other functions/calls. Matching on existing fields like 'name' which are user-input in flat-rate method is not reliable.
  • New field - displayMessageMethod - This new field will hold any string to be displayed along the FF Method in the UI, example store pickup requesting user to come in only after 24hrs of ordering.
  • New field - methodAdditionalData: This could be fulfillment specific information used for processing in the system. Example Store may provide store details.
  • updateCartFulfillmentGroups: logic updated - when new item is added to cart, if "selectedFulfillmentType" is provided, we add to that group, else the item goes to "Undecided" group.
CATALOGS
  • supportedFulfillmentTypes - this field will be extended in the api-plugin-fulfillment plugin to have the allowedValues changed from the hard coded "shipping" to dynamic array containing all the installed FFTypes
PRODUCTS
  • supportedFulfillmentTypes - this field will be extended in the api-plugin-fulfillment plugin to have the allowedValues changed from the hard coded "shipping" to dynamic array containing all the installed FFTypes
ORDERS
  • Exported CommonOrder, orderFulfillmentGroupInputSchema, SelectedFulfillmentOption - these schemas will be extended in the api-plugin-fulfillment plugin to have the allowedValues changed from the hard coded "shipping" to dynamic array containing all the installed FFTypes
  • New field - methodAdditionalData: This could be fulfillment specific information used for processing in the system. Example Store may provide store details.
    (above 2 changes are spread across multiple files)
Integration Tests updated
  • Updated the integration tests to match the changes in plugins.

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.

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>
@changeset-bot
Copy link

changeset-bot bot commented Nov 3, 2022

⚠️ No Changeset found

Latest commit: 761bd13

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link
Contributor

@aldeed aldeed left a 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"
},
Copy link
Contributor

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
Copy link
Contributor

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.

@sujithvn sujithvn removed the request for review from tedraykov January 9, 2023 04:16
sujithvn added 12 commits March 10, 2023 23:58
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>
@sujithvn sujithvn merged commit 5fed7d5 into 00-fulfillment-base May 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
点击 这是indexloc提供的php浏览器服务,不要输入任何密码和下载