PARTIALLY RESOLVES CORE-1156
**What**
Improve upsertWithReplace to batch as much as possible what can be batched. Performance of this method will be much greater specially for cases with maybe entities and batch (e.g we seen many cases where they bulk product with hundreds variants and options etc)
for example let take the following object:
- entity 1
- entity 2 []
- entity 3 []
- entity 2 []
- entity 3 []
here all entity 3 will be batched and all entity 2 will be batched
I ve also added a pretty detail test that check all the stage and what is batched or not with many comments so that it is less harder to consume and remember in the future
Also includes:
- mikro orm upgade (issues found and fixes)
- order module hooks fixes
**NOTE**
It was easier for now to do this instead of rewriting the different areas where it is being used, also, maybe it means that we will have closer performance to what we would expect to have natively
**NOTE 2**
Also fix the fact that integration tests of the core packages never ran 😂
CLOSES CORE-1209
This PR just adds the stuff necessary to support refund reasons in the dashboard. It adds the option in the settings tab and allows viewing, creating, editing and deleting refund reasons. I hate to open such a big PR but most of it is copy pasted from the return reasons. Major difference is only the fact that refund reasons don't have a `value` field
This PR fixes the issue #13518 where product category descendants were not retrieved when
filtering by handle with the include_descendants_tree flag. The handle filter was not
being correctly removed before the descendant tree query was executed.
RESOLVES CORE-1206
**What**
Instead of removing cleaner repeatable job and risk to remove it while other instances are still up, we always create it, since the id of a job is unique and we give one to the job, if already present it wont get added
* fix(utils,core-flows): subtotal calculation and returns location
* changeset
* fix test
* var
* rm extra field from test
* fix original total
* fix partial refunds and pending difference
* fix test
* fix test
* test
* extract to util
* original total and update payment when receive return
* original_subtotal
* default fields
* test
* calculate pending difference
* revert claims test
* pending difference
* creadit line fix
* if
* test(): test dynamic max workers
* test(): test dynamic max workers
* test(): test dynamic max workers
* test(): test dynamic max workers
* test(): test dynamic max workers
* test(): test dynamic max workers
* test(): test dynamic max workers
* test(): test dynamic max workers
* test(): test dynamic max workers
* test(): test dynamic max workers
* test(): test dynamic max workers
* test(): test dynamic max workers
* test(): test dynamic max workers
* test(): test dynamic max workers
* test(): test dynamic max workers
* test(): test dynamic max workers
* Clarify test description and improve CI
**What**
- Remove overserialization withing transaction and rely more on internal service or protected method instead which does not serialize and work with Infered entity type
- Slightly rework loop complexity
Overall, this gives a good spare of resources and time spent for serialization
* chore(): Upgrade mikro orm
* handle 'null' value for big number props
* 6.5.2
* remove only
* fix pricing module rule value
* switch select in strategy for balances
* revert to select in strategy for order module
* fix defining DML ManyToOne
* fix define relationship
* test fix
* more fixes
* change order strategy to balanced
* change order strategy to balanced
* prevent unnecessary manager fork
* revert generated www changes
* remove unnecessary changes
* Create real-cobras-deny.md
* address feedback
---------
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
RESOLVES CORE-1163
RESOLVES CORE-1164
**What**
### Add support for non auto retryable steps.
When marking a step with `maxRetries`, when it will fail it will be marked as temporary failure and then retry itself automatically. Thats the default behaviour, if you now add `autoRetry: false`, when the step will fail it will be marked as temporary failure but not retry automatically. you can now call the workflow engine run to resume the workflow from the failing step to be retried.
### Add support for `maxAwaitingRetries`
When setting `retyIntervalAwaiting` a step that is awaiting will be retried after the specified interval without maximun retry. Now you can set `maxAwaitingRetries` to force a maximum awaiting retry number
### Add support to manually retry an awaiting step
In some scenario, either a machine dies while a step is executing or a step is taking longer than expected, you can now call `retryStep` on the workflow engine to force a retry of the step that is supposedly stucked
* chore(): only execute race execution checks for async workflows
* chore(): workflow redis publish only for async flows
* Create cyan-gorillas-poke.md
* chore(): workflow redis publish only for async flows
* fix negative check
---------
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
* feat(dashboard,types,utils): refine order details summary
* fix tests
* changeset
* ui corrections
* tests again
* weird tests failing
* revert update to subtotal
* revert http tests too
* comments
* move credit lines so it makes more sense
* remove currency codes and add bold prices
* add new properties in default for storefront
* minor to patch
* remove bold on things that should be
* olis comment about taxes
* remove bold from shipping
what:
Introduces 2 new features to promotion module:
1. Introduce max quantity limit to promotion application - This will limit the application of the promotion based on the quantity of the target products in the cart.
2. When applying buy get promotions, we will now apply buyget promotion until eligible items are exhausted or max quantity is reached.
```
- Buy 2 t-shirts, Get 1 sweater
- Max quantity -> 1
This means you can add two t-shirts, and get 1 sweaters for free. However, if you add four t-shirts, you only get one sweater for free.
```
```
- Buy 2 t-shirts, Get 1 sweater
- Max quantity -> 3
This means you can add six t-shirts, and get three sweaters for free. However, if you add eight t-shirts, you only get three sweaters for free
```
```
- Buy 4 t-shirts, Get 2 sweater
- Max quantity -> 1
This should throw on creation, as the max quantity should as a minimum be the same value as the target rule quantity
```
RESOLVES SUP-2357 / https://github.com/medusajs/medusa/issues/13265
* fix(orchestration): Use the step definition max retries on set step failure
* Create sweet-turkeys-wait.md
* allow to force permanent failure
* update changeset
* chore(fulfillment): cleanup old auto-generatred shipping type
* changeset
* integrationt ests
* random id
* wrong code
* switch steps around
---------
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
**What**
- adding `categories` to `fields` param would return 404 for an existing product if the product was not associated with a category
---
CLOSES CMRC-1046
