broadleaf:
cartoperation:
sensitive-data-removal:
enabled: true
url-patterns:
- /cart/*
- /checkout/*
- ... etc.
fields-to-remove:
- baseCost # default
- v1.0.0-latest-prod
|
Tip
|
The 2.x versions are Spring Boot 3 compatible. |
|
Tip
|
Since Cart Operation Service 2.3.0, Release Train 2.3.0 |
This release includes support for Fees, which is a new domain addition to Pricing Services. See Pricing Services 2.2.0 Release Notes for more information on the domain.
There is also relevant documentation that catalogs the updates to Cart Operations Pricing, such as the changes made to the Pricing Provider, Cart Pricing Service, and the new Fee Pricing Service.
Implemented Fee calculation logic when a Cart is being priced.
Created the FeePricingService that handles fee retrieval, calculation, and applying the matching fee items onto the cart.
Fees are fetched by Application (retrieved via the ContextInfo) from the Pricing Service and are cached by application to facilitate easier retrieval and eliminate redundant calls to the Pricing Service.
Created CartOperationCacheAutoConfiguration and CartOperationCacheProperties to enable caching for the Cart Operation Service and to be able to cache Fees by Application
Added more CartItemAttributeConstants that are applicable for Fee-type CartItems
ITEM_TYPE = The type of the cart item, which is typically a DefaultCartItemTypes enum
FEE_CODE = The code of the fee that the cart item represents
IS_FEE_REFUNDABLE = Whether this cart item that represents a fee is refundable
Added new domains and enum types
Added Fee domain to represent the fees to be applied onto a Cart
Added enum types DefaultFeeCalculationMethod which represents the calculation method to be used when applying the fee to a cart and DefaultFeeCalculationOperation which represents the operation to be used when calculating the fee to be applied to a cart
Resolved an issue that limited quantity validation to ItemChoice-dependent cart items. All dependent items are now validated correctly.
Tax Handling
Introduced clear separation in the DefaultDelegatingTaxService between COD Fees and Extra (e.g., service) Fees.
Create a separate TaxCalculationGroup for extra fees by default.
By default for tax purposes, extra fees the address of the first fulfillment group on the cart
See DefaultDelegatingTaxService#mapFulfillmentGroupsToExtraFees to control how fees are related to fulfillment groups
Protected methods removed and replaced for code and usage correctness:
addFeeItemsTaxCalculationGroup: Renamed includeFeesInTaxRequest
findTaxAddressSourceHandlerForFeeTaxCalculation: Renamed findTaxAddressSourceHandlerForCODFeeTaxCalculation
The ProductDetailsRequest now (Catalog Service 2.3.0) supports specifying variantIds to fetch, not just Product IDs and URIs, in order to make add-to-cart more efficient.
In support of this, ExternalCatalogProvider#retrieveCatalogItems will now include the IDs of Variants in the collection of CatalogItemRequests as parameters if present.
The variant ID will be used in place of the product ID in these cases as the parent product can be retrieved by Catalog Service once the Variant is resolved automatically.
Additionally, #retrieveCatalogItems will specify to hydrate none of the Product’s other variants.
The protected methods #getRetrieveProductsUrl(Collection<String>) and #getRetrieveProductsUrl(Collection<String>, ContextInfo) have been replaced with #getRetrieveProductsUrl(Collection<CatalogItemRequest>, ContextInfo) to provide more information and greater flexibility when build the URL with various parameters.
Added protected method #customizeRetrieveProductsUrl(UriComponentsBuilder, Collection<CatalogItemRequest>, ContextInfo) to provide a clear hookpoint for custom parameters without having to copy the base method that produces a stringified URL.
Variants are never hydrated by default.
Use broadleaf.cartoperation.catalogprovider.variant-hydration-behavior to modify this behavior.
This takes values of NONE (new default), ALL (old behavior), or DEFAULT_ONLY (i.e., return the Product with its default Variant hydrated only).
It is not expected that any but NONE will be needed since only a specific variant is ever added to the cart.
|
Tip
|
Since Cart Operation Service 2.3.0, Release Train 2.3.0 |
This release includes support for fulfillment callbacks initiated from a payment gateway. This feature was added with an implementation for PayPal server-side shipping callbacks as part of our updates to PayPal Complete Payment (PPCP). See PayPal Payment Library 3.0.3 Release Notes for more information on the Complete Payment updates.
Added a new endpoint for payment gateway-initiated fulfillment callbacks
Calls Payment Transaction Services to understand the payload from the Payment Gateway and validate the callback
Updates the fulfillment information and reprices the Cart
Calls Payment Transaction Services to build the response payload to return back to the Payment Gateway
Added support for Retail Delivery Fees from the Avalara Tax Module
Updated DefaultDelegatingTaxService to build RETAIL_DELIVERY_FEE type CartItems from the RDF tax infos returned on the TaxResponse.
Ensures that the applicable fulfillment groups have an attribute set to track any RDF cart items.
Ensures that for a given RDF, it is only applied one time to the cart as a fee item, regardless of the number of fulfillment groups.
Added checkout validation for RDF cart items to ensure that if a fulfillment group is expecting an RDF item, then that RDF cart item exists on the cart.
Marked the RDF cart items as non-removable from the cart, excluded the RDF cart items from stale cart item removal considerations, and ensured the RDF items were not added as fulfillment items.
Ensured the RDF cart items are not included in the calls to Catalog, Offer, or Pricing services.
Clears RDF cart items before applying tax response to get the latest retail delivery fees supplied by the tax provider.
For details on the Avalara RDF implementation, see Avalara Retail Delivery Fees documentation.
See the CatalogBrowse-counterpart of this mechanism in Catalog Browse Services 2.2.0 Release Notes.
Introduced an OncePerRequest filter guarded by configured URIs patterns that will remove the baseCost property from the Cart response payloads.
This mechanism can be configured by the following properties and is enabled by default (see CartOperationSensitiveDataRemovalProperties):
broadleaf:
cartoperation:
sensitive-data-removal:
enabled: true
url-patterns:
- /cart/*
- /checkout/*
- ... etc.
fields-to-remove:
- baseCost # defaultUpdated ExternalCatalogProvider to now include a skipInventory=true request parameter in the request to retrieve products.
This parameter became available in CatalogBrowseServices 2.2.0.
This reduces unnecessary load on the system and improves performance, as CartOps does not ever use the availabilitySummary information returned by CatalogBrowse.
Any inventory related checks are done via separate, intentional inventory check/reserve calls during the add-to-cart flows.
In order to support OMS consolidated refunds, the TransactionExecutionRequest and similar DTOs have been modified to support multiple source entity IDs.
Extracted duplicate logic from DefaultCartItemCatalogInformationService#populatePricingInfo and DefaultCartPricingService#applyPricesToCart for setting price infos in Cart Item attributes from Products and Variants into CartItemPricingUtils#populatePricingInfoForItem
Also extracted #cleanPriceInfo and #getPricingKey into CartItemPricingUtils as public methods.
Support for subscription payment validation during checkout
Updated the validation for the subscription payments during checkout. See Subscription Payment Validation
DefaultInventoryAvailabilityService.getRequestedQuantitiesPerSku was indiscriminately including dependent cart items in availability checks during add-to-cart flows.
Now, inventory checks will only be performed for dependent items if their inventoryCheckStrategy is ADD_TO_CART, making it consistent with the behavior in place for top-level cart items.
Fixed an issue where CartItemValidationActivity was not leveraging CartOperationServiceProperties#isVariantIdUsedToIdentifyCatalogItemRequests to identify duplicate CatalogItemRequests, and so would be removing cart items during checkout if multiple variants of the same Product were in a cart.
Part of the solution was to consolidate the logic to identify duplicate CatalogItemRequests into a new CartItemConfigurationService#catalogItemRequestAlreadyExists method that can be used across the service.