Things that remain to be done:
1. Handle product and variant updates
2. Add tests for the workflows independently
3. Align the endpoints to the new code conventions we defined
4. Finish up the update/upsert endpoints for variants
All of those can be done in a separate PR, as this is quite large already.
**What**
- Admin sales channels API routes
- Workflows for creating, updating, and deleting sales channels
- Align `ISalesChannelModuleService` interface with update + upsert conventions
- Integrate v2 tests into v1 sales channels integration test suite
- Add metadata to sales channel entity
Sales channel <> Product management will come in a follow-up PR.
On the integration tests, creating, updating, and deleting are passing with the V2 flag enabled. You'll have to take my word for it (or run them yourself), as they are not included in the CI.
**What**
Update all transform middleware to support the new API
- deprecate `defaultRelations`
- deprecate `allowedRelations`
- Add `defaults` and `allowed` in replacement for `defaultFields` and `allowedFields` respectively
- in the `defaults` it is possible to specify a field such as `*variants` in order to be recognized as a relation only without specifying any property
- add support for `remoteQueryConfig` assigned to req like we have for `listConfig` and `retrieveConfig`
- add support to override `allowed|allowedFields` if a previous middleware have set it up on the req.allowed
- The api now accepts `fields` as the only accepted fields to manage the requested props and relations, the `expand` property have been deprecated. New supported symbols have been added in complement of the fields
- `+` (e.g `/store/products?fields=+description`) to specify that description should be added as part of the returned data among the other defined fields
- `-` (e.g `/store/products?fields=-description`) to specify that description should be removed as part of the returned data
- `*` (e.g `/store/products?fields=*variants`) to specify that the variants relations should be added as part of the returned data among the other defined fields without having to specify which property of the variants should be returned. In the `defaults` config of the transform middleware it is also possible to use this symbol
- In the case no symbol is provided, it will replace the default fields and mean that only the specified fields must be returned
About the allowed validation, all fields in the `defaults` configuration must be present in the `allowed` configuration.
In case the `defaults` contains full relation selection (e.g `*product.variants`) it should be present in the `allowed` as `product.variants`. In case in the `defaults` you add `product.variants.id`, it will be allowed if the `allowed` configuration includes either `product.variants.id` as full match or `product.variants` as it means that we allow all properties from `product.variants`
Also, support for `*` selection on the remote query/joiner have been added
**Note**
All v2 end points refactoring can be done separately
The changes in this PR are:
1. Change how product options are created and stored. The relationship changed from
`options --> option values <-- variants`
to
`options --> option values --> variant options <-- variants`
Now we can enforce non-duplicate option values, easier creation and updates of options, and more.
2. Refactors the product module. The product module did a lot of things in a non-ideal approach, and this is a step towards a more consistent usage of the base repository and methods exposed by a module. There is still work left to improve the module, but a large chunk of the changes are included in this PR
Things to do as a follow-up:
1. Remove many-to-many relationships if an empty list is passed in the base repository.
2. Improve the typings of the module
3. Further cleanup and improvements (there are few questions that I need answered before I can improve the API)
The 2 bigger remaining tasks are:
1. handling prices for variants
2. Handling options (breaking change)
After that all tests should pass on both v1 and v2
In this PR:
1. I added upsert support for the product
2. I updated the create and update signatures to match the latest interface standards
3. Small changes to make the v1 and v2 APIs compatible (WIP)
Few things to keep in mind:
1. You need to set MEDUSA_FF_MEDUSA_V2 to true before running the tests to run with the v2 API
2. You can use the `breaking` function to differentiate between v1 and v2 differences. This can help us identify what was breaking pretty quickly afterwards
3. You will need to run specific tests for now instead of all if you want to target v2. I think that's fine though, as we don't really need these to run on every PR until we have feature parity (and by then, all tests would be both v1 and v2 compatible)
**note: Adrien**
- add a new way to load modules only to run their loaders comparable to the way to run the migrations only
- improve tests runner to cleanup the data properly as well as re running all loaders and core defaults
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
What:
Workflow Engine API.
Endpoints for:
- List workflow executions
- Run a workflow
- Set async steps as success or failure
- Retrieve the details of a workflow run
**What**
- ensure that an error is raised properly if the requested product doesn't exist and a publishable-key header is set
**Why**
- previously endpoints would hang if the product didn't exist and requests would time out
closes#5724
* Expose item tax total and shipping tax total in order totals
* Added changeset
* Fixes to tests
* Fixes to integration tests
* Fixes to integration tests
* Fixes to integration tests
* Change changeset to patch
* fix for merging line items and quantity prices
* add changeset
* fix draft order unit_price calculation
* update test to reflect only quantity change
* fix unit tests
* update conditional
* initial code push
* update metadata and only merge if the existing line item allows merging
* update should_merge check
* undo changes to taxrate service
* update results with unit pricing corresponding to the db values after update
* add should_merge property to line_item creation
* add should_merge property to line_item creation
* fix unit tests
* undo adding "should_merge" to create-line-item
* undo change to "addOrUpdateLineItem"
* :wqh_merge from generate method
* undo changes to unit tests
* revert to adding pricing in updateLineItem method
* update cart service test
* Create funny-radios-juggle.md
---------
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
Fix for the problems identified in issue #4892
Bugfix: admin-ui order summary no longer uses gift card total from order when displaying how much has been withdrawn from each giftcard.
Bugfix(?): no longer keep applying gift cards (at 0 value) when sufficient balance has been reached
Feature: multiple giftcards are now applied in ordered fashion. First by end_date (supports null), then by remaining balance. In order to ensure that customers ends up with as long lasting and few remaining gift cards as possible after the transaction.
Looks like during an earlier refactor, some of the categories logic wasn't ported over to the handler that works with q params.
what:
- adds a fix that allows queries to be made on category_id when q param is passed.
Fixes https://github.com/medusajs/medusa/issues/4885
**What**
Integration tests to validate the workflow compensation.
Also, fix the transaction state when the workflow is compensating and some steps does not have any compensation
