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)
Apologies for the giant PR in advance, but most of these are removing of files and migrations from old workflows and routes to new.
What:
- Adds CRUD endpoints for price lists
- Migrate workflows from old sdk to new
- Added missing updatePriceListPrices method to pricing module
**What**
- Adds draft order details page
- Adds Shipping and Billing address forms to both draft order and order pages
- Adds Email form to both draft order and order pages
- Adds transfer ownership form to draft order, order and customer pages
- Update Combobox component allowing it to work with async data (`useInfiniteQuery`)
**@medusajs/medusa**
- Include country as a default relation of draft order addresses
what:
- adds fulfillment shipping option rules batch endpoint
- remove fulfillment shipping option rules batch endpoint
- breaks my British based education to not call it fulfilment with a single "l"
**What**
- Runs loadMedusaV2 when v2 flag is enabled.
- V2 loader loads only project-level framework features. E.g., project APIs, subscribers, jobs, and workflows.
- No plugin support yet.
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
**What**
- Initial work on pricing domain.
- List page
- Details page
- Partial edit form
- Fixes admin/price-lists/:id/products endpoint to allow filtering products by multiple ids.
**Note**
Pushing this now as the current design need a bit of tweaking so we display all relevant data to users. Future PR will include completed Edit moda, Create modal, Edit prices modal and Add prices modal.
**What**
- Adds list page for reservations and inventory items
- Adds new String filter type, that allows users to filter by a string, eg. "material === 'metal'"
- Adds new Number filter type, that allows users to filter by a number or numerical comparator, eg. quantity === 10 / quantity is gt 10 and lt 50.
**What**
- v1 of executions domain
**TODO in follow up PR**
I think it might be a good idea for Carlos or Adrien to go over the design with Ludvig, and make sure we are displaying what is relevant to developers, and how things should be displayed. So this PR is just the initial implementation, and does not handle displaying things like compensation steps (not part of the current design), step input (not supported by the API but part of the design), etc.
Closes CORE-1751, CORE-1755
**What**
- Adds pages for managing tax settings and tax rates for regions.
- Fixes `list` tax rates endpoint, which was missing pagination, search, order, and filters.
**Note**
The fix to the tax rate list endpoint is very rough, as I have had to reimplement most of the logic from our transformQuery middleware. This is because this endpoints does not follow normal convention for fields and expand and uses string arrays instead of strings separated by commas. Our middleware does not support this, and changing the endpoint to align with other endpoints on the expand and fields params would be a breaking change. Since this is very temporary until 2.0 I think it's okay for the time being.
CLOSES CORE-1654
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>
new wrapper for medusa integration tests.
for now it is only applied to the modules directory, but it could be used in the api integration tests or any other integrations that requires a db and a server up and running.
It is not perfect, but I wanted to have something working and centralised before improving it, also avoiding too many conflicts with other prs
This implementation obviously lacks a lot of things, and there are a lot of TODOs. However, there are already a lot of questions I'd rather get answered soon, so I figured it's much easier to do the implementation in steps.
I wrote down all breaking changes, suggested changes, and new additions with comments (TODO and Note).
In a follow-up PR I will:
Add the remaining/missing models
Make the workflows handle all interactions between the different models/modules
Add integration tests
Oli Juhl
github-actions[bot]
Sebastian Rindom
Stevche Radevski
Philip Korsholm
Riqwan Thamir
Adrien de Peretti
Kasper Fabricius Kristensen
pepijn-vanvlaanderen
Mads Jensen