**What**
- Better error handling and error message
- update deps management and dynamic import/require
- Pass a new flag to the modules loaders for the module loaders to be able to act depending on it. In that case, the module can determine what should be run or not. e.g in the workflow engine redis, when we are only partially loading the module, we do not want to set the Distributed transaction storage
This PR achieves the following
- Remove dependency on internals for seeding the tests (more work left, but major work done)
- Adds the workflow for updating variant's price
I will do a follow-up PR to further clean up the tests and remove all internal dependencies
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.
* feat: Modify the abstract repository upsert method to handle subresources correctly
* fix: Preserve the upsertWithResponse order in the response, and return all the data
* fix: Create integration tests folder for mikro orm utils that run against the DB
* fix: Remove many-to-one creation and additional changes based on PR review
## What
Adds an AI generator to the docblock tool that uses OpenAI.
The generator at the moment only generates examples for functions when the `--generate-examples` option is provided.
## Note
I've included the generated examples of the `IOrderModuleService` as a reference of the type of result provided by the AI generator, with minor tweeks I've made. I haven't made any changes to descriptions in that file.
- Added new documentation page for Medusa Worker.
- Updated Railway deployment guide with details on Medusa Worker.
- Small adjustments to the `worker_mode` option's TSDocs.
**What**
- Adds support for starting a Medusa process with a worker mode.
- The worker modes supported are "shared", "worker", "server"
- In "worker" mode, API routes are not registered and modules that need to run workers (e.g., event bus redis) can use the flag to conditionally start workers.
- In "server" mode, API routes are registered and workers are not started.
- In "shared" mode, API routes are registered and workers are started. This is great for development.
what:
when you provide an optional create_dto or update_dto to the model factory types, the abstract service will generate a simple service method for the public services of the modules.
```
MoneyAmount: {
dto: PricingTypes.MoneyAmountDTO
create_dto: PricingTypes.CreateMoneyAmountDTO
}
```
In the above example, only a create method will be generated, but the update will be skipped.
**What**
This pr includes some cleanup and refactoring around the abstract event emitter method for the module service to not rely on a named class property but instead on resolution naming.
Includes fulfillment set events on creation.
The idea is that if that pr allows us to align and agreed on the approach as well as including the cleanup for other pr to use, If this gets merged I ll continue with another pr to do the rest of the event management
partially fix CORE-1735
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**
- Add method to validate fulfillment option from the provider
- Separate list/list and count from context rules validation and add listShippingOptionsForContext
FIXES CORE-1861
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"
