**What:**
Introduces a store endpoint to retrieve a list of product categories
**Why:**
This is part of a greater goal of allowing products to be added to multiple categories.
**How:**
- Creates an endpoint in store routes
RESOLVES CORE-968
What:
Introduces a store endpoint to retrieve a product category
Why:
This is part of a greater goal of allowing products to be added to multiple categories.
How:
- Creates an endpoint in store routes
RESOLVES CORE-967
What:
Introduces an admin endpoint that allows a user to update a product category
Why:
This is part of a greater goal of allowing products to be added to multiple categories.
How:
- Creates a route on the admin scope to update category
- Creates a method in product category services to update a category
RESOLVES CORE-956
What:
Introduces an admin endpoint that allows a user to create a product category
Why:
This is part of a greater goal of allowing products to be added to multiple categories.
How:
- Creates a route on the admin scope to create category
- Creates a method in product category services to create a category
RESOLVES CORE-958
**What:**
Introduces an admin endpoint that allows a user to delete a product category, given an ID.
Why:
This is part of a greater goal of allowing products to be added to multiple categories.
How:
- Creates a route on the admin scope to delete category
- Creates a method in product category services to delete a category
RESOLVES CORE-957
* chore: added get route for admin categories API
* chore: add tree method to mock repository
* chore: added changeset to the PR
* chore: rename id to productCategoryId in service
* chore: switch cli option to string
* chore: lint fixes, tests for parent category
* chore: move Nested Categories behind feature flag
* chore: use transformQuery hook in api
* chore: add feature flag in migrations
* chore: remove migration FF, fix FF name
* chore: add free text search + count repo function
* chore: added list endpoint for admin
* chore: added changeset for feature
* chore: address pr review comments
* chore: change oas comment
* chore: add nullable parent category filter + test
**What**
The order cancelation does not include the refunds relation. It means that the check of the length of the refund is never true and therefore no errors are thrown if the order contains the refunds.
**How**
Add the refunds relation and tests
FIXES CORE-976
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
* remove duplicate key from oas
* changeset
* initial suggestion for adding locations to fulfillments
* update migration
* re-add functionality for removing entire reservations
* fix tests
* add location when adjusting reserved inventory of a line_item
* add changest
* handle multiple reservations for a product in the same channel
* confirm inventory in stock location previous to creating the fulfillment
* fix tests after updating create-fulfillment to confirm inventory prior to creating fulfillment
* remove bugged code
* initial validation
* initial changes for review
* chekcpoint
* update validate inventory at location
* redo some unwanted changes
* typing
* update snapshots
* redo change for eslintrc
* add eslint disable
* re-order methods in interface
* assert no_notification
* iterate one time less
* add test for validation of correct inventory adjustments in case of no inventory service installation
* ensure correct adjustments for order cancellations
* remove comment
* fix tests
* fix but with coalescing
* remove location id from confirm inventory
* don't throw when adjusting reservations for a line item without reservations
* move reservation adjustments to the api
* add multiplication for updating a reservation quantity
* move inventory adjustments from the service layer to the api
* delete reservation if quantity is adjusted to 0
* rename updateReservation to updateReservationItem
* update dto fields
* reference the correct fields
* update with transaction
* add jsdocs
* force boolean cast
* context-ize cancel and create fulfillment transaction methods
* undo notification cast
* update with changes
* refactor withTransaction to variable
* use maps
* fix service mocks
**What:**
Introduces a new folder under which repository specs will be placed.
Why:
We don't currently have a good place to test ORM logic or custom queries against the database. The repository folder tests are a place for just exactly that.
How:
Creates an internal package similar to other integration tests - api and plugins.
CORE-965
**What**
- Add integration test suite for database options
- Expose integration tests DB to additional options
- Add test for `idle_in_transaction_session_timeout`
* add mw feature flag
* add services
* add types
* add module interfaces
* add interface export
* add models for mw
* to be ammended
* remove featureflag
* use correct count
* update cart completion strategy
* swap service conversion
* update return service
* update order service
* update claim service
* add exception to claim item
* update cart service
* add indicies
* add changeset
* nullable changes in store
* store model update
* fix unit tests
* remove old inventory service
* format integration test
* update snapshots
* remove old inventory service tests
* update snapshots
* remove old code
* option updates
* naming
* add jsdoc to pv inventory service
* rename class variables
* pr feedback
* rename option to context
* if(variant_id) instead of if(typeof varia...)
* update tests
* add jsdoc
* go for custom
* update code for readability
* add support for customer first- and last names and phone
* test for querying customer first_name, last_name and phone
* add customer as prop for querying orders
* polishing before pr
* changeset
**What**
Move to transformQuery which adds a default ordering and also allows to order the product list from the store API
**How**
Among other things, fix the product repo to allow ordering by either a key from the product or a key from a relation
FIXES CORE-911
FIXES CORE-901
* chore: tax_rate is added to giftcards
* chore: minor
* chore: update gift card tax calculations to look at giftCard.tax_rate
* chore: gift card transactions use tax rate from gift card for legacy
* fix: gift cart total check for transaction should check the length
* chore: use tax exclusive cost + use giftcard tax rate for gctransactions + refactor
* chore: fix integration test
* chore: address issues brought up in comments
* chore: move gift card creation as a part of order service on order placed
* chore: add type handling for gift card creation
* chore: fix specs
* chore: use taxLines to calculate tax of a gift card
* chore: specs for line items containing gift cards and without
* chore: add integration specs + fix tax rate bug
* chore: round totaling + add GC application specs
* chore: cleanup trialables
* chore: write migration script to backfill gift cards with null tax_rate
* chore: update legacy totals service for gift cards
* chore: add changeset
* chore: address PR review changes
* chore: fix tests based on new totals calc
* chore: address review comments
Co-authored-by: adrien2p <adrien.deperetti@gmail.com>
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
**what**
The goal of that PR is to first refactor the payment provider and payment plugin to support the new API that removes the data mutation from within the plugin to be done by the core instead. In any case, this pr does not include the steps of the deeper refactoring. The last part will come in later pr.
**How**
- The payment plugin is now capable to handle both the deprecated and new API and the plugin works the same as it use to works.
- The mutation made by the plugin have been moved into the core as well as the subscriber
- The tests have been updated to reflect the changed
- Remove all new methods introduced by the payment collections
- Mutualise types
- Update provider and payment collection services
- cleanup around all those refactoring including cleanup of the payment collection
- refactor stripe payment plugin
FIXES CORE-887
* test subtotals on draft order operations
* fetch cart with subtotals when doing draft order operations
* write test for updating discounts seeing changes in totals
* formatting
* udpate test
* force taxes
* missing select
* add import
* rm force_taxes
**What**
- enable to filter sales channels of a Publishable API Key with a free text search param
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
**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>
