This PR is replaced by #6615

Signed-off-by: Sujith mail.sujithvn@gmail.com

Resolves #6471
Impact: breaking
Type: feature

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 (02 fulfillment-type-impacted-plugins)

PR Details in order

feat/fulfillment-types
 | 
 | __ 01 fulfillment base #6570 
 |        | __ 01-01 fulfillment-type-shipping       #6579
 |        | __ 01-02 fulfillment-type-pickup.    #6577 
 |__02 fulfillment-type-impacted-plugins. [carts, products, orders, catalogs]        <--- This PR #6582 
 |__03 placeOrder refactor #6583 

Existing PRs based on the #6480 (to be updated to point to #6570)

We shall change the base branch of the 3 existing PRs (i18n #6545, dataMigration #6544, setDefaultFFtype #6543) to point to 01 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.