**What**
- Add workflow + step for detaching sales channels from pub API keys
- Tweak linking error message to be more helpful
- Add `removeRemoteLink` step to delete API key workflow
There are several things done in this PR, namely:
Unify the service endpoints API to always work with a model rather than allowing to pass both ID and model (eg. both type_id and type being available in the request to create).
Start using upsertWithReplace to simplify the code and fix some deassociation bugs
Apply some changes to tests to deal with the pricing breaking changes
Correctly define the model relationships (with both ID and entity fields available)
All tests for the product are passing, which should bring us back to a great baseline.
What
- Add link between API key and sales channels
- Add API route for batch adding sales channels to a publishable API key
- Clean up API key API routes responses
- Move API key test suite from `integration-tests/modules` to `integration-tests/api`
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 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"
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)
