**What**
When a discount is deleted from a cart, the line item adjustments must be refreshed. Now, the cart service `removeDiscount` includes updating the adjustments.
**Tests**
**Add a new integration test which:**
- create a cart with a discount
- add a line item
- validate the adjustments
- remove the discount
- check that the adjustments are not present anymore
**Update unit tests**
The actual tests cases now check that the adjustments repository is called when needed
FIXES CORE-890
### What
Leverage yarn workspaces and Turborepo for integration-tests in order to accelerate development and reduce DevX complexity.
### Why
The current solution for running integration tests requires using `medusa-dev-cli` in order to publish packages to a local npm repository. The package where the command is executed will have its package.json altered for any known medusa dependency in order to install from the local npm. The process is taxing on the host machine resources and prevents rapid iterations when working with integration tests.
For more information, see documentation: f0cc1b324c/docs/content/usage/local-development.md (run-api-integration-tests)
### How
By declaring `integeration-tests/**/*` as a workspace, Turborepo can now be leveraged to build and run integration test as if there were packages. The build process will take care of interdependency between package in order to ensure local dependency are met.
In addition, within each integration-tests "packages", we can declare local dependencies as "*" which will translate to using the one that is part of the current build, regardless of the dependency's version number. No more fiddling with version numbers.
Github actions pertaining to integration-tests have been streamlined to use the new behavior.
The integration-tests packages have been marked as `private:true` in order to avoid publishing them to the public npm registry.
### Testing
```
cd root-of-medusajs-medusa-repo/
yarn install
yarn build
yarn test:integration:api
yarn test:integration:plugins
```
After a code change, `yarn build` must be run before re-running an integration test, which is the same procedure as for unit tests.
Resolves: CORE-845
**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
* 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**
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
**What**
- add error handling when loading project config
**How**
- Add error parameter to get-medusa-config result if an error was thrown (previously we returned an empty config)
- Discussion:
A different, but equally valid approach could be just throwing the error rather than creating an error parameter. This causes a more ugly output without warnings and changes the api a bit but it would force error handling. wdyt?
**Why**
- cli would fail with database error `databaseMissingDriverError` if config was invalid, ex. missing a comma
### example (missing `,` in config)
**old output**
```
Successfully compiled 2 files with Babel (143ms).
[medusa-config] ⚠️ redis_url not found. A fake redis instance will be used.
[medusa-config] ⚠️ database_type not found. fallback to default sqlite.
info: Using flag MEDUSA_FF_ORDER_EDITING from environment with value true
info: Using flag MEDUSA_FF_SALES_CHANNELS from environment with value true
info: Using flag MEDUSA_FF_TAX_INCLUSIVE_PRICING from environment with value true
info: Using fake Redis
✔ Models initialized – 13ms
✔ Plugin models initialized – 0ms
✔ Repositories initialized – 17ms
⠋ Initializing databaseMissingDriverError: Wrong driver: "undefined" given. Supported drivers are: "aurora-data-api", "aurora-data-api-pg", "better-sqlite3", "capacitor", "cockroachdb", "cordova", "expo", "mariadb", "mongodb", "mssql", "mysql", "nativescript", "oracle", "postgres", "react-native", "sap", "sqlite", "sqljs".
```
**new output**
```
Successfully compiled 2 files with Babel (185ms).
error: Error in loading config: Unexpected identifier
error: /Users/phko/projects/community/my-medusa-store/medusa-config.js:129
plugins,
^^^^^^^
SyntaxError: Unexpected identifier
at compileFunction (<anonymous>)
at Object.compileFunction (node:vm:352:18)
at wrapSafe (node:internal/modules/cjs/loader:1033:15)
at Module._compile (node:internal/modules/cjs/loader:1069:27)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
at Module.load (node:internal/modules/cjs/loader:981:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
at Module.require (node:internal/modules/cjs/loader:1005:19)
at require (node:internal/modules/cjs/helpers:102:18)
at getConfigFile (/Users/phko/projects/community/my-medusa-store/node_modules/medusa-core-utils/dist/get-config-file.js:26:20)
```
**What**
- Adds new entity AnalyticsConfig
- Adds new service AnalyticsConfigService
- Adds new repository AnalyticsConfigRepository
- Adds new endpoints to get, create, update, and delete analytics configs
**Why**
As we begin gathering usage insights to help us improve Medusa, we want to give each individual users the ability to control what data they share with us, or not share any data with us at all. The AnalyticsConfig holds information that is used to check if the user wishes for their data to be anonymized or if they have opted out of sharing usage data.
The entire feature can be disabled on a store level by setting the feature flag `MEDUSA_FF_ANALYTICS=false` in their environment variables, the feature is enabled by default.
**Testing**
Adds integration test for each of the new endpoints
Resolves CORE-656, CORE-655, CORE-654
Also resolves CORE-574
**What**
Create a data structure that facilitate the addition of new column descriptor for both export and import and ensure that the column name is shared between bother import and export to facilitate the import with an exported file.
**Tests**
Add an additional integration tests that export a file, update the data, and re import the same file
FIXES CORE-716
FIXES CORE-713
**what**
- Add support to remove resources by batch on discount conditions
- Add support on medusa-js and medusa-react
**Tests**
- Add integration tests to validate that the resources have been deleted and the length is the one expected
- Add unit tests on medusa react
FIXES CORE-609
* feat(medusa): Allow to add items to a discount condition by batch + cleanup of discounts and discount conditions end points
* style(medusa): cleanup catch and log
* feat(medusa-react, medusa-js): Add support to add item batch to discount condition
* cleanup
* cleanup
* rename items to resources
* fix(medusa-js): url
* Create fast-suns-repair.md
* update naming
* tests(integration): Update tests to reflect API changes
* feat(medusa): Delete a condition should be idempotent on discount and condition
* revert
**What**
- Adds the use of price selection strategy to the endpoint `GET /admin/variants`
- Updates medusa-js to reflect this change (expanding the parameters).
**Testing**
- Adds a new integration test validating that returned variants are now of type PricedVariant, with the expected fields: original_price, calculated_price, etc.
**Why**
- Our current RMA flows (in our admin dashboard) relied heavily on simply using `order.tax_rate` to calculate variant prices in the different RMA menus. As taxes in Medusa, have become feature complete this approach had become very naive and has several potential issues. Moving the responsibility for calculating the correct prices guarantees that we always show the correct prices to admins.
**What**
- Fixes `GET /products` in both admin and store API so they no longer accept the param `type?: string`, but instead accept `type_id?: string[]`
**Why**
- Filtering by type would never return any products as `ptyp_:id` !== `ProductType`.
**Testing**
- Added an integration test for each endpoint.
Closes CORE-695
**What**
- allow the product type field to be null
**How**
- in case the type is `null`, pass `undefined` as the value of type prop to product create/update services, otherwise pass an object with `{value}` which will be upserted
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
**What**
- when deleting an OE cloned items are deleted, this would fail if there were changes associated with the OE since line items were referenced from the item changes and couldn't be deleted
**How**
- when deleting an order edit also remove it's item changes
Fixes CORE-689
