RESOLVES SUP-185
**What**
The cart fields to be fetched for the promotion workflow was not including the sales_channel_id, making any rules being constraint to that fields not being validated against this property.
RESOLVES SUP-188
**What**
Two changes are happening here
- In the stripe payment provider, idempotent cancellation action, if not id is provided then return the existing data unchanged
- Payment module should not try to cancel a session that have failed to be created in the first place
FIXES CMRC-691
**What**
`Date` is something that get executed, since workflows are meant to compose the definition of what will be executed, the date where always having the same value as they was executed once during composition.
Instead wrap those into transformer that will be executed when needed and fix the Date issues
**What**
Currently, when setting a `belongsTo` relationship on the DML with the otherside being `hasMany` it result in a wrongly generated gql output making the belongs to being a collection of the relation instead of the relation directly. This pr fixes this issue
**What**
The values are wrongly set which can lead to infinite depth iteration
**Note**
This will change on how we manage those cases in the future but currently it fixes an issue
**What**
Currently, the API validation layer is broken in both responsibilities and validation itself.
This pr introduce the following fixes and patterns:
- Always create a `*Fields` schema that only takes care of defining the schema validation without `effect`
- Use the previous point into the API schema validator including `$and` and `$or` capabilities plus the recursive effects
- remove `normalizeArray` which does not have to exists since array are already treated as they should
- Add recursive transformation to take into account `$and` and `$or` as well or any other similar operators
- New util `applyAndAndOrOperators` to wrap the management of those operators and to be merged to an existing schema
Tasks
- [x] store domain
- [ ] admin domain
**What**
- Fix product category repository missing context passed to down level methods
- Ensure the base repository when getting the active manager returns a fresh one if possible instead of the global one in order to prevent shared entity map by mistake
* chore: Update modules providers configuration with 'identifier' and 'PROVIDER'
* update check
* fix tests
* type
* normalize auth provider
* emailpass
* providers
---------
Co-authored-by: Carlos R. L. Rodrigues <rodrigolr@gmail.com>
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
**Breaking changes**
The `outDir` has been deprecated and wont be used anymore, instead all the path are computed internally following these rules
- if admin is not `disabled` and the `build` command is run without the `--admin-only` flag, then the admin output dir will be `.medusa/server/public/admin` and it will be served from that same location from the medusa instance.
- if admin is not `disabled` and the `build` command is run with the `--admin-only` flag, then the admin output dir will be `.medusa/admin` with the purpose of deploying the admin separately. ⚠️ (expect to receive a warning log)
- if the admin is `disabled` and the `build` command is run with the `--admin-only` flag, then fallback to rule number 2
| admin enabled | medusa build --admin-only | output dir |
|---|---|---|
| true | true | `.medusa/admin` ⚠️ (expect to receive a warning log) |
| true | false | `.medusa/server/public/admin` |
| false | true | `.medusa/admin` |
| false | false | none |
```diff
// medusa-config.ts
{
// ...
admin: {
- outDir: 'some/path'
}
}
```
cc @kasperkristensen @sradevski @olivermrbl
**What**
When resolving the modules through an array, if the module does not have a joiner config to rely on (not `queryable`, not using the `Module` util), then the key should be provided to register the module in the container. Eventually, the module author should provide that key to be used.
The only exception is for the medusa modules where we have a map that allows us to resolve that key automatically from the path of the resolve value
**What**
The module service name case has changed and the hash generation was performed on the non lower cased version of it while after the hash generation everything is based on the lower case version of the generated table name form the service names leading to different hash computation. This pr update the link migration table to adjust the to/from module value with its new value as well as generating the hash from the lower case version of the computed table name
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
**What**
The extra serialization check hapen to break the serialization chain by reusing already serialized entities when they have been serialized from a different parents sequence
**What**
The `updateTaxLinesWorkflow` rely on the cart shipping method meaning that concurrent refresh of shipping method can impact tax lines therefore leading to wrong tax lines
**What**
Align the index engine API to be similar to the Query API
## Example
```ts
// Benefit from the same level of typing like the remote query
const { data, metadata } = await indexEngine.query<'product'>({
fields: [
"product.*",
"product.variants.*",
"product.variants.prices.*",
],
filters: {
product: {
variants: {
prices: {
amount: { $gt: 50 },
},
},
},
},
pagination: {
order: {
product: {
variants: {
prices: {
amount: "DESC",
},
},
},
},
},
})
```
**What**
When both sides of a many to many relationship do not define the mapped by option, it leads to misconfigured relations and a malformed SQL query. (ref. https://github.com/medusajs/medusa/issues/9075)
- When both mapped by are not defined, infer look up to try to identify the missing configuration if any
- Disallow defining many to many only on one side
RESOLVES FRMW-2110
RESOLVES FRMW-2095
**What**
- Fix notification module to not retain transactions open while sending notification
- Add support for notification status [success, pending, failure]
FIXES FRMW-2676
**What**
ref: https://discord.com/channels/876835651130097704/1023889804544458752/threads/1276979858781503528
Currently, when providing the following
```ts
const user1 = manager.create(User, {
username: "User 1",
team: {
name: "Team 1",
},
})
```
It would result in an error inserting into the database because the foreign key will be sent twice as part of the insert, one for the relation and one for the foreign key that both relate to the foreign key property.
To fix that and allow both approaches (providing the entity to cascade persist or just providing the foreign key in case of another side nullable relation) we need to handle it a bit differently.
now both approaches would be valid. the entities for the example might not be the best ones but it is just to illustrate
option 1 - we create both the user and the team:
```ts
const user1 = manager.create(User, {
username: "User 1",
team: {
name: "Team 1",
},
})
```
option 2 - the team already exists (for example the previous user have been detached from the team but we kept the team alive and assign a new user to that team) :
```ts
const user1 = manager.create(User, {
username: "User 1",
team_id: team.id
})
```
* chore: Treat internal event differently, primarely do not display info log for those events
* revert doc
* add few tests
* only set internal option if present
* revert to previous condition
* start including feedback after discussion
* include feedback
* fix modules integration tests
* fix modules integration tests
* fix event bus local
FIXES TRI-174
**What**
Currently, every time a Local workflow is being instantiated, it will grab the global workflow definition including the orchestrator instance. This leads to issues when we have concurrent running workflows which all register their event listeners to this single orchestrator instance which can lead to exhausting the listerners.
With this fix, every local workflow will have a copy of the global workflow definition plus a new instance (cloned) of the orchestrator meaning that from now on, every local workflow will have its own orchestrator.
Adrien de Peretti
