* feat(product): return parents tree
* query mpath with IN
* more tests
* remove where filters
* revert where
* naming
---------
Co-authored-by: Riqwan Thamir <rmthamir@gmail.com>
**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
The only thing remaining is modifying `upsertWithReplace` to handle many-to-many constraints correctly and not cascade updates to them. This is something that we should do separately though.
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.
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)
I replaced the custom test setup with the test runner. This should make migrating to mikroorm 6 a lot easier once we do it.
There are few more modules to be done, but I thought the PR is super big already so we can tackle them separately.
Note that there are no or very little test changes, it is mostly the setup around the tests.
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)
**What**
Default ordering. By default, only the top level entity ordering is applied using the primary keys, the relations are default ordered by the foreign keys.
It include tests fixing for deterministic data ordering
What:
- Event Aggregator Util
- Preparation for normalizing event in a new format (backward compatible with the current format)
- GQL Schema to joiner config and some Entities configured
- Link modules emmiting events
**What**
- Remove services that do not have any custom business and replace them with a simple interfaces
- Abstract module service provide the following base implementation
- retrieve
- list
- listAndCount
- delete
- softDelete
- restore
The above methods are created for the main model and also for each other models for which a config is provided
all method such as list, listAndCount, delete, softDelete and restore are pluralized with the model it refers to
**Migration**
- [x] product
- [x] pricing
- [x] promotion
- [x] cart
- [x] auth
- [x] customer
- [x] payment
- [x] Sales channel
- [x] Workflow-*
**Usage**
**Module**
The module service can now extend the ` ModulesSdkUtils.abstractModuleServiceFactory` which returns a class with the default implementation for each method and each model following the standard naming convention mentioned above.
This factory have 3 template arguments being the container, the main model DTO and an object representing the other model with a config object that contains at list the DTO and optionally a singular and plural property in case it needs to be set manually. It looks like the following:
```ts
export default class PricingModuleService</* ... */>
extends ModulesSdkUtils.abstractModuleServiceFactory<
InjectedDependencies,
PricingTypes.PriceSetDTO,
{
Currency: { dto: PricingTypes.CurrencyDTO }
MoneyAmount: { dto: PricingTypes.MoneyAmountDTO }
PriceSetMoneyAmount: { dto: PricingTypes.PriceSetMoneyAmountDTO }
PriceSetMoneyAmountRules: {
dto: PricingTypes.PriceSetMoneyAmountRulesDTO
}
PriceRule: { dto: PricingTypes.PriceRuleDTO }
RuleType: { dto: PricingTypes.RuleTypeDTO }
PriceList: { dto: PricingTypes.PriceListDTO }
PriceListRule: { dto: PricingTypes.PriceListRuleDTO }
}
>(PriceSet, generateMethodForModels, entityNameToLinkableKeysMap)
implements PricingTypes.IPricingModuleService
{
// ...
}
```
In the above, the singular and plural can be inferred as there is no tricky naming. Also, the default implementation does not remove the fact that you need to provides all the overloads etc in your module service interface. The above will provide a default implementation following the interface `AbstractModuleService` which is also auto generated, hence you will have the following methods available:
**for the main model**
- list
- retrieve
- listAndCount
- delete
- softDelete
- restore
**for the other models**
- list**MyModels**
- retrieve**MyModel**
- listAndCount**MyModels**
- delete**MyModels**
- softDelete**MyModels**
- restore**MyModels**
**Internal module service**
The internal module service can now extend `ModulesSdkUtils.internalModuleServiceFactory` which takes only one template argument which is the container type.
All internal services provides a default implementation for all retrieve, list, listAndCount, create, update, delete, softDelete, restore methods which follow the following interface `ModulesSdkTypes.InternalModuleService`:
```ts
export interface InternalModuleService<
TEntity extends {},
TContainer extends object = object
> {
get __container__(): TContainer
retrieve(
idOrObject: string,
config?: FindConfig<any>,
sharedContext?: Context
): Promise<TEntity>
retrieve(
idOrObject: object,
config?: FindConfig<any>,
sharedContext?: Context
): Promise<TEntity>
list(
filters?: FilterQuery<any> | BaseFilterable<FilterQuery<any>>,
config?: FindConfig<any>,
sharedContext?: Context
): Promise<TEntity[]>
listAndCount(
filters?: FilterQuery<any> | BaseFilterable<FilterQuery<any>>,
config?: FindConfig<any>,
sharedContext?: Context
): Promise<[TEntity[], number]>
create(data: any[], sharedContext?: Context): Promise<TEntity[]>
create(data: any, sharedContext?: Context): Promise<TEntity>
update(data: any[], sharedContext?: Context): Promise<TEntity[]>
update(data: any, sharedContext?: Context): Promise<TEntity>
update(
selectorAndData: {
selector: FilterQuery<any> | BaseFilterable<FilterQuery<any>>
data: any
},
sharedContext?: Context
): Promise<TEntity[]>
update(
selectorAndData: {
selector: FilterQuery<any> | BaseFilterable<FilterQuery<any>>
data: any
}[],
sharedContext?: Context
): Promise<TEntity[]>
delete(idOrSelector: string, sharedContext?: Context): Promise<void>
delete(idOrSelector: string[], sharedContext?: Context): Promise<void>
delete(idOrSelector: object, sharedContext?: Context): Promise<void>
delete(idOrSelector: object[], sharedContext?: Context): Promise<void>
delete(
idOrSelector: {
selector: FilterQuery<any> | BaseFilterable<FilterQuery<any>>
},
sharedContext?: Context
): Promise<void>
softDelete(
idsOrFilter: string[] | InternalFilterQuery,
sharedContext?: Context
): Promise<[TEntity[], Record<string, unknown[]>]>
restore(
idsOrFilter: string[] | InternalFilterQuery,
sharedContext?: Context
): Promise<[TEntity[], Record<string, unknown[]>]>
upsert(data: any[], sharedContext?: Context): Promise<TEntity[]>
upsert(data: any, sharedContext?: Context): Promise<TEntity>
}
```
When a service is auto generated you can use that interface to type your class property representing the expected internal service.
**Repositories**
The repositories can now extend `DALUtils.mikroOrmBaseRepositoryFactory` which takes one template argument being the entity or the template entity and provides all the default implementation. If the repository is auto generated you can type it using the `RepositoryService` interface. Here is the new interface typings.
```ts
export interface RepositoryService<T = any> extends BaseRepositoryService<T> {
find(options?: FindOptions<T>, context?: Context): Promise<T[]>
findAndCount(
options?: FindOptions<T>,
context?: Context
): Promise<[T[], number]>
create(data: any[], context?: Context): Promise<T[]>
// Becareful here, if you have a custom internal service, the update data should never be the entity otherwise
// both entity and update will point to the same ref and create issues with mikro orm
update(data: { entity; update }[], context?: Context): Promise<T[]>
delete(
idsOrPKs: FilterQuery<T> & BaseFilterable<FilterQuery<T>>,
context?: Context
): Promise<void>
/**
* Soft delete entities and cascade to related entities if configured.
*
* @param idsOrFilter
* @param context
*
* @returns [T[], Record<string, string[]>] the second value being the map of the entity names and ids that were soft deleted
*/
softDelete(
idsOrFilter: string[] | InternalFilterQuery,
context?: Context
): Promise<[T[], Record<string, unknown[]>]>
restore(
idsOrFilter: string[] | InternalFilterQuery,
context?: Context
): Promise<[T[], Record<string, unknown[]>]>
upsert(data: any[], context?: Context): Promise<T[]>
}
```
What:
- When calling a module's method inside a Local Workflow the MedusaContext is passed as the last argument to the method if not provided
- Add `requestId` to req
- A couple of fixes on Remote Joiner and the data fetcher for internal services
Why:
- The context used to initialize the workflow has to be shared with all modules. properties like transactionId will be used to emit events and requestId to trace logs for example.
**What**
Create a service abstraction for the modules internal service layer. The objective is to reduce the effort of building new modules when the logic is the same or otherwise allow to override the default behavior.
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
**What**
Reduce the work effort to create repositories when building new modules by abstracting the most common cases into the base class default implementation returned by a factory
- [x] Migrate all modules
Co-authored-by: Riqwan Thamir <5105988+riqwan@users.noreply.github.com>
* remove defaults
* take 2
* works now
* add changeset
* pricing module and pricing service list take null updates
* update handlers
* update product module service with take:null where relevant
* no spread
* note to self:default offset should be 0, not 15
**What**
- Fix issues with update-variant workflow:
- other variants than the updated variant are no longer removed
- options are updated properly
Co-authored-by: Riqwan Thamir <5105988+riqwan@users.noreply.github.com>
* fix(product): when running migrations, prevent exploding on isolated case
* chore: remove try catch block
* chore: added variant test fixes
* chore: update name of var
**What**
- includes some type fixes in the DAL layer
- List products including their prices and filtered by the sales channel as well as q parameter and category scope and all other filters
- Assign shipping profile
- ordering
- Add missing columns in the product module
- update product module migrations
**Comment**
- In regards to the fields, we can pass whatever we want the module will only return the one that exists (default behavior), but on the other hand, that is not possible for the relations.
**question**
- To simplify usage, should we expose the fields/relations available from the module to simplify building a query for the user and be aware of what the module provides
**todo**
- Add back the support for the user to ask for fields/relations
* chore: allow scoping products by collection_id
* chore: scope money amounts by currency code + change category_ids to category_id
* chore: add an extra product to test without collection
---------
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
Oli Juhl
Stevche Radevski
Carlos R. L. Rodrigues
Adrien de Peretti
Philip Korsholm
Riqwan Thamir
Frane Polić