A discount should always be associated to atleast 1 region - we validate it against the region in the cart service.
Adding a request parameter validation to pass in atleast one regionID in an array of regions will ensure that regionID will be validated as a part of the discount service and fail if its not a valid region ID.
**What**
I have created a new method on the cart service which is `addLineItems`, allowing a user to add one or multiple items in an optimized way. Also updated the `generate` method from the line item service which now also accept a object data or a collection of data which. Various places have been optimized and cache support has been added to the price selection strategy.
The overall optimization allows to reach another 9000% improvement in the response time as a median (Creating a cart with 6 items):
| | Min (ms) | Median (ms) | Max (ms) | Median Improvement (%)
|---|:-:|---|---|---|
| Before optimisation | 1200 | 9999 | 12698 | N/A
| After optimisation | 63 | 252 | 500 | 39x
| After re optimisation | 56 | 82 | 399 | 121x
| After including addressed feedback | 65 | 202 | 495 | 49x
FIXES CORE-722
**What**
- add/ remove sales channels to/from PublishableApiKey in batch
- associate created cart with SC defined by PK
- filter products if PK with SC association is present
- retrieve a list of sales channels for a PK
- implement 3 new middleware
- `extendRequestParams`
- _extend req object with PK scopes (a list of sales channels) if a publishable key is present in the header of the request_
- `validateProductSalesChannelAssociation`
- _validate if the passed product id belongs to a SC from the PK's scope_
- `validateSalesChannelParam`
- _validate that passed SC ids in the req body/query are within the scope of the PK_
**How**
- The general idea was to reuse existing logic in the controller layer which expects `sales_channel_id` array to be passed. The middleware sets associated SC ids in the request context if a PK is present. These ids are then merged in the controller and passed to the service layer.
**TODO**
- filter response from the search endpoint (CORE-824)
**Testing**
- _integration tests_
- add sales channels to the publishable API key scope
- remove sales channels from the publishable API key scope
- returns products from a specific channel associated with a publishable key
- returns products from multiples sales channels associated with a publishable key
- returns all products if PK is not passed
- returns all products if passed PK doesn't have associated channels
- should assign sales channel to order on cart completion if PK is present in the header
- list sales channels from the publishable api key
- throws because sales channel in query/body is not in the scope of passed PK
---
**Discussion**
- what about the other endpoints (e.g. GET /store/product/:id - do we return 404 if the product is not in the SC associated with passed PK)
- what about products search route
- what about `/admin/products` & `/admin/orders` routes (do we add the middleware there as well)
---
RESOLVES CORE-792
RESOLVES CORE-793
RESOLVES CORE-816
### What
OAS: Explicitly declare type:object on schemas with properties.
### Why
While not officially required, schemas with properties should have their type explicitly declared as "object". Omitting the type translates to type: any with properties XYZ. The ambiguity can lead to issues when using code generators.
### How
Multiple regex searches to identify schemas missing type: object. Manually edit each schema. Spot check generated OAS.
### Testing
- Ran OAS validator.
- Ran docs build script
### Proof
RESOLVES CORE-847
**What**
Allow DraftOrders to be created with an IdempotencyKey.
Note this doesn't implement idempotency for the DraftOrder create endpoint but allows the service layer to ingest the key and store it in the database. This is a preliminary step to being able to support an idempotent API request.
* use correct authentication middleware
* remove guard from get-session since it's guarded by middleware doing the same check
* Add integration tests
* Create lazy-swans-agree.md
Co-authored-by: olivermrbl <oliver@mrbltech.com>
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
**What**
- register a publishable API key through `medusa-js` i.e. define the key that will be sent with each request
**How**
- introduce KeyManager class which is used to share keys between medusa-js objects.
**Usage**
1. Set the key through the `Medusa` config
2. Set the key through `KeyManager` dynamically:
```ts
import { KeyManager } from "medusa-js"
KeyManager.registerPublishableApiKey("pk_123")
```
---
RESOLVES CORE-794
**What**
Fix system error (500) with DraftOrder create operation when payload includes discount in a tax-inclusive context.
**How**
* Ensure newly created cart contains all required relation in order to calculate line item tax-inclusive pricing with discounts.
* Add resilience to TotalsService.getLineDiscounts()
* Ensure newly generate line items have variant relation loaded.
* fix TotalsService.getLineItemTotals to use the passed lineItem instead of relying on cartOrOrder.items.
**Test**
* Unit:
* TotalsService.getLineDiscounts - coverage
* Integration:
* Admin API draft-order - coverage
* Admin API draft-order create w/ discount in tax-inclusive
Resolves: CORE-771
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
**What**
- update PK endpoint
- medusa-js/react implementation
- add a title property to the entity
- update the migration file
- pass a title on create
- list PKs by title
- update the client libs with new param signatures
- change id prefix to: "pk_"
**What**
If `total` or `subtotal` are selected then get the line item totals and assign them to the items.
I also had to remove the totals from the cart update service since they are not used and that by having them the items get the tax lines attached and since the update is performed by passing the entire cart, it is trying to insert the tax lines with the cart update
**Tests**
Add an integration tests to validate that the items includes the totals in the order and draft order
FIXES CORE-687
**What**
- Ensure that swaps can be created for orders with discounts in tax inclusive regions
**How**
- Retrieve cart with discounts and region before creating adjustments for line items in cart.
- In `discountService.calculateDiscountForLineItem` we used the method `totalsService.getLineItemTotals` if a line-item is tax inclusive. This method uses some fields from the cart that aren't populated on cart creation (such a `items` which caused the original error).
**Testing**
- add integration test `swaps > tax inclusive > "Complete swap flow with discount"` that creates a swap in the following environment
- tax inclusive region
- tax inclusive line item to be swapped
- fixed type discount with allocation: total
Fixes CORE-748
**What**
- validate shipping option requirements including tax if the shipping option is tax inclusive
**Testing**
- " given a cart with total above min-threshold and subtotal below min-threshold shipping option with tax inclusive pricing is available and can be applied"
- "given a cart with total above max-threshold and subtotal below max-threshold shipping option with tax inclusive pricing is not available"
Fixes CORE-752
