What:
- `Dirent` class from `NodeJS` has different properties in different versions, causing issues in our loaders.
- Util `readDirRecursive` was introduced, avoiding old node versions to break
FIXES: https://github.com/medusajs/medusa/issues/8419
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.
**What**
- add request order transfer workflow
- add admin endpoint for transferring an order to a customer
- accept order transfer storefront endpoint
- accept transfer workflow
- changes in the order module to introduce new change and action types
---
**Note**
- we return 400 instead 409 currently if there is already an active order edit, I will revisit this in a followup
- endpoint for requesting order transfer from the storefront will be added in a separate PR
---
RESOLVES CMRC-701
RESOLVES CMRC-703
RESOLVES CMRC-704
RESOLVES CMRC-705
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
**What**
- Adds Breadcrumb component to all routes that needs breadcrumbs.
- The Breadcrumb components use a combination of loader data and useQuery to ensure that the displayed value is kept up to date if the underlying data is changed via a mutation.
- Also fixes a couple of places where the breadcrumb was not setup correctly.
Resolves CMRC-688
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
Initially I thought that we will have to add special checks to allow relationships referencing itself. However, it turned out that not to be the case. Instead, it had more to do with how self relationships are defined in Mikro ORM.
In case of `belongsTo` relationship we have to define the other side as well either as a `hasMany` or `hasOne`. For example:
**❌ The following code will fail, because no children are defined for the parent**
```ts
const user = model.define("user", {
id: model.number(),
username: model.text(),
parent: model.belongsTo(() => user)
})
```
**✅ Addition of children relationship will make things work**
```ts
const user = model.define("user", {
id: model.number(),
username: model.text(),
parent: model.belongsTo(() => user, { mappedBy: "children" }),
children: model.hasMany(() => user, { mappedBy: "parent" }),
})
```
We can see the similar setup here with our `ProductCategory` MikroORM entity. https://github.com/medusajs/medusa/blob/develop/packages/modules/product/src/models/product-category.ts#L87-L94
@adrien2p Correct me if I am wrong. But I have added the tests for now so that we know the behavior of self relationships
Adrien de Peretti
Oli Juhl
Frane Polić
Riqwan Thamir
mStenz
420coupe
Carlos R. L. Rodrigues
Shahed Nasser
Harminder Virk
Sebastian Rindom
Mehmet Erturk
Kasper Fabricius Kristensen
Furman