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
**What**
Added German language json file.
**Why**
To be able to choose german language.
**How**
The File is translated with Google Translate, some human checks and corrections. I'm sure it's not perfect, but it is a good starting point. First the en.json was duplicated (as de.json) to be able to see the changes made and if the structure is still the same.
**Testing**
As mentioned in How, i checked if the structure is still the same.
Co-authored-by: Kasper Fabricius Kristensen <45367945+kasperkristensen@users.noreply.github.com>
What:
When `autocapture` is enabled, the webhook is processed before the order was created.
The payment processing workflows were merged into a single one
FIXES: SUP-118, SUP-9
https://github.com/medusajs/medusa/issues/9998
What:
- copy data before saving checkpoint
- removed unused data format function
- properly handle registerStepFailure to not throw
- emit onFinish event even when execution failed
**What**
- Fixes Edit Variant form so it properly loads the product variant
- Fixes the query key for product details to prevent the cache from being shared between queries for the same ID but with different params.
Resolves CMRC-685
Co-authored-by: Frane Polić <16856471+fPolic@users.noreply.github.com>
**What**
- fix prefix for table search which caused the other table rendered on the page to fire query
- additionally, fix a typo in js SDK and only format the file
---
FIXES SUP-112
CLOSES https://github.com/medusajs/medusa/issues/9968
Fixes bug introduced by https://github.com/medusajs/medusa/pull/9912
By default the Node.js server listens on the `0.0.0.0` host. However, the related PR changes the host to `localhost` and hence resulted in an unwanted breaking change. This PR reverts the default value assignment and let Node.js decide the host when not explicitly specified.
### What
Include `region_id` when retrieving shipping options for a cart
### Why
Otherwise, region-specific prices will never show in the Store API
Closes CMRC-655 https://github.com/medusajs/medusa/issues/9906
Fixes: FRMW-2762
This PR fixes the error reporting to include the original error message and the error cause when logging it using the JSON formatter of Winston.
> Side note: There is still a lot of room for improvements in our logging. But that require a overhaul cleanup in multiple places and will require dedicated loggers for commands and APP and special treatment for pretty printing errors.
## Error output in JSON format
**Before**
**After**
**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**
- Adds a test that validates that en.json and $schema.json matches, this will help us catch missing translations, and prevent us from forgetting to update the schema when we delete/add new keys.
- Adds a script for validating translations against the translation schema. This can be used to validate that community PRs for i18n contain all the required keys. To use the script you can run `yarn i18n:validate <file name>` e.g. `yarn i18n:validate da.json` which will look for a da.json file in the translation folder, and validate it against the schema. We handle this with a script as we don't want to do so through a test. Doing it with a test would mean that if we update the schema, we would also have to update all translations files that we don't maintain ourselves. The purpose of the script is just to allow us to easily review community PRs and also as a tool for people opening PR's to check their translations agains the schema, as it will print missing/additional keys.
- Also adds a script to generate a schema from the en.json file. After adding/deleting keys to en.json you should run `yarn i18n:generate`.
