* 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>
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
* feat(dashboard,core,modules): free shipping promotion in dashboard
* self-review
* adapt for edit to work
* changeset
* integration tests
* across for each
* remove only from tests
* remove console log
* revert to across
* update wording for shipping promotions
* modify changeset
* suggestion frane
* fix i18n schema
* fix(utils): fix promotion case of each allocation not applying its amount
* chore: fixed tests
---------
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
Changed the In operator to actually work like an In instead of being same logic as Equals. This means that in promotions you can add a rule to apply when a product is in a category or multiple different. Before the logic had to match all the products categories to apply, which doesnt really make sense when you have nested category structure on products. The logic also applies to tags where you can make a rule apply based on a tag before it also had to match all tags on a product to apply.
Issue:
https://github.com/medusajs/medusa/issues/12669
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
* Move from total to original_total to resolve edge case in adjustment calculation
* Added changeset
* Added test case for correction
---------
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
* This fixes the discount_ calculation logic
* This fixes the adjustment to be handled as a subtotal value in every calculation and applies the tax inclusive logic on the promotion value itself
* Added some testcases and revoked some changes to improve testing output
* Fixed a test case based on feedback
* Corrected promotion/admin test cases
* Corrected cart/store test case
* Improved cart/store test cases for more robust promotion testing considering tax inclusion flags
* Remove unnessary changes as adjustments now automatically are subtotals and therefore the tax inclusive flag does not need to be applied again
* Remove adjustments->is_tax_inclusive usage everywhere
* Migration script to remove is_tax_inclusive in cart line item adjustment
* Forgot to adjust one more testcase
* Corrections based on fPolic feedback
* Refactored PR to consider feedback from oliver
* Added more testcases for promotion in cart
---------
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
**What**
- Fix missing `ON DELETE CASCADE` constraint on order credit lines
- Fix `receiveReturn` miss usage
- Make all order integration tests to run and rename them all to `*.spec.ts`
- Fix package.json typo
**What**
Reduce database queries when possible and use proper data structure and aggregation when possible in order to reduce performance decrease overall
what:
- scopes uniqueness index to only non deleted records
- explicit sorting of buy get promotions
- This error popped up as we removed the uniqueness constraint which seems to have kept a specific order.
RESOLVES https://github.com/medusajs/medusa/issues/11606
FIXES FRMW-2878
**What**
Currently, the `one-to-one` unique constraints does not account for deleted record. This prevents from inserting a new record wth the same fk if another one is deleted.
**Caveat**
`hasOne` with FK option is meant to be a special case, for example a many to one - one to many without defining the other side of the relation. In that case we don't handle this behaviour and keep it as it is
