* chore: various DML improvements
* Check is something through static utils
* Check is something through static utils
* allow to define a schema with table name
* restrict searchable to text only
* rm searchable modifier
* extract constructor logic into separate function
**What**
Update the `MedusaService` class, factory and types to remove the concept of main modules. The idea being that all method will be explicitly named and suffixes to represent the object you are trying to manipulate.
This pr also includes various fixes in different modules
Co-authored-by: Stevche Radevski <4820812+sradevski@users.noreply.github.com>
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
**What**
Remove transaction decorator from the base medusa service method, the transaction will always be coming from the shared context. It fixes the issue that when you consume a base method directly it will return a proper tuple from the DB instead of the one from the entity map cc @VariableVic
**NOTE**
This pr also fix some categories issues in the product module which was preventing the tests from working. if @sradevski you could have a look later, in the mean time we can still merge it
FIXES CORE-2342
**What**
emit product tags events
**note**
Stil does not take into consideration non overriden method, delete and soft delete emits event under the hood and we will have to migrate that at the end
WIP, not ready to review
**what**
- add events
- integration tests of emitted events
- remove integration tests on auto generated services in favor of module method integration tests
**What**
- Return the updated/deleted/created entities from the upsert with replace according to the configuration
This will help to emit the events from the product module as it rely on this abstraction in many places
**What**
Add support for event emitting in the fulfillment module
**NOTE**
It does not include the review of the events for the abstract module factory if the method is not implemented in the module itself and rely on the default implementation
Remove the old handlers and definitions that does not work anymore or are not used anymore. This legacy was bothering a refactoring we have with @thetutlage
**What**
Update the module resources discovery to account to the source directory to look into.
example:
```ts
user: { resolve: 'user' }
```
The above config will load the resources from the resolved path looking from the node modules
```ts
user: { resolve: './modules/user' }
```
The above config will load the resources from the local directory under dist if not run with ts node and under src otherwise
**What**
Re integrate the transform query tests + missing features. It was originally mistekenly removed from one the team pr, also, I have adjusted the API and tests
**NOTE**
It does not include a full clean up of the typings and the backward compatibility remains for now
**What**
- remove medusa-core-utils
- dispatch the utils where they belongs
- update usage
**NOTE**
I have been wondering if the graceful class should go into the utils package or medusa package, I ve put it in the medusa package as it seems to be the best place I can see for now and is tight to the server as well. Also, I wanted to avoid the utils package to depends on http and net dependencies, happy to change that if you feel like it
**What**
Currently when a workflow fail it will throw an error which contains the messages of all error thrown durring the workflow lifetime. Therefore, in our cases we are always preventing workflow to throw and grab the first error that we then re throw.
This pr eliminate that need by throwing back the first error among the error thrown by a workflow as it is the main case. In case someone need a special handling they can still set the option throwOnError to false and handle the error the way they need
* fix(admin-next, utils, medusa): Handle db errors properly and fix form
* fix(admin-next, utils, medusa): Handle db errors properly and fix form
* fix(admin-next, utils, medusa): Handle db errors properly and fix form
* fix(admin-next, utils, medusa): Handle db errors properly and fix form
**what**
- Create return workflow partial implementation
- Update some order domain types
- create order fulfillment link
**NOTE**
this PR is partially done but can still be merged as is, it will require some discussions around the flow and some unknowns or uncertainty in regards to some data and some behaviour
**What**
- automatically build and consume connection and container loader if not exported by the module
- therefore load the services and repositories automatically, including baseRepository
- automatically build run and revert migrations if not provided
- cleaup modules to remove extra unnecessary bits and pieces
- remove the `initializeFactory` in favor of using `medusaApp`
Should drastically improve the module building DX by removing a lot of boilerplate to handle by the user, that plus the base entity should simplify quite a lot the flow cc @shahednasser
**Note**
I had to choose a way to identify connection and container loader from the exported loader from the module. I decided to go with named function `connectionLoader` and `containerLoader`, also, now the factories will return named function so if the user use the factories we are providing to build those loaders, the function will also be named and identified
**What**
Provide a new mikro orm base entity in order to abstract away the on init and on create which include the id auto generation if not provided. The main goal is to reduce complexity in entity definition
**What**
Add support for the following operations
- update rules from the update shipping options end point
- update rules from the batch update end point
Also added some improvements, that can be revisited later
- Add a rule value normalizer, jsonb will transform the input value to a [primitive](https://www.postgresql.org/docs/current/datatype-json.html#JSON-TYPE-MAPPING-TABLE) when possible meaning that passing `"true"` will result in storing `true` and not the string. The normalizer takes care of that
**What**
- Update the `updateShippingOptions` module service API to follow the newest convention
- Add upsert support for shipping options
- update shipping options workflow
- update shipping options api end point and validation
- update shipping options all integration tests
FIXES CORE-1926
**What**
- cleanup existing route on some aspects but not all
- add new create shipping options end point and types
- add set of integration tests
- cleanup existing fulfillment routes
- align existing integration tests
- transform old type to zod types and validators
- fix stock location route
**What**
- Create main workflow
- Update create pricing rule types step to be idempotent
- update remote joiner to support granular isList confguration on field aliases
- Add full workflow integration tests
**What**
- Add support for searchable entity properties to configure default free text search when providing a `q` filter
- `@Searchable` decorator to mark a property or relation to be searchable form the current entity
FIXES CORE-1910
**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
**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
**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
**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
**What**
- Update migration for backward compatibility. This does not take into account data migration and table cleanup (@olivermrbl do we have a general tasks for the modules on that subject)?
- Rename fulfillment provider id to provider id
- add integration tests to ensure the migration backward compatibility
- add new module type for the options to be used in the medusa config for example
FIXES CORE-1724
**What**
- Ensure soft delete works properly according to the soft delete configuration and validate all relation of the entire data model
- Add is_enabled to the providers in order to manage new providers to enabled or disabled
- include joiner config update
FIXES CORE-1853
FIXES CORE-1830
FIXES CORE-1719
Currently, if the v2 flag is not enabled it can lead to issues if the modules are part of the medusa config as they will get loaded anyway leading to issues if the migrations did not ran
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
**What**
- Create the fulfillment manual package with a first iteration API
- Create a new `AbstractFulfillmentProviderService` and `IFulfillmentProvider`
- Modify the module service interface to add new methods to manipulate the fulfillment and the communication with the external provider
- create (no bulk)
- cancel (no bulk)
- update (no bulk)
- list
- listAndCount
- retrieve
- Add new methods to the service provider service to include communication with the third party provider
- get options
- create
- cancel
- validate data
- validate option
- Update/create interfaces and DTO's
- fix repository serializer to allow non entity to be passed without throwing
- split module tests into multiple files to simplify navigation
- Add integration tests to validate fulfillments manipulation and external provider loading + communication
FIXES CORE-1729
FIXES CORE-1785
FIXES CORE-1784
FIXES CORE-1766
Adrien de Peretti
