Fixes#13735
### What
This Pull Request introduces new database migrations to remove multiple redundant indexes across several core modules, including product, cart, order, customer, and inventory.
### Why
As detailed in issue #13735, a fresh Medusa installation produces numerous "Duplicate Index" warnings. These legacy indexes add unnecessary write overhead and provide no performance benefit. This PR cleans up the schema to resolve these warnings and improve database health.
### How
I have added one new, reversible migration file for each of the five affected modules:
- `@medusajs/product`
- `@medusajs/cart`
- `@medusajs/order`
- `@medusajs/customer`
- `@medusajs/inventory`
Each migration's `up()` method safely drops the older, redundant index, and its `down()` method re-creates it, ensuring the change is fully reversible and non-destructive.
### Testing
I have tested these migrations by following the local development workflow outlined in the `CONTRIBUTING.md` guide.
1. **Setup:**
* Cloned my forked Medusa repository locally .
* Created a separate, fresh test project using `npx create-medusa-app@latest my-medusa-store`.
* The test project's PostgreSQL database, which already contained the schema with the duplicate indexes.
2. **Linking Local Source Code:**
* In the test project's `package.json`, I modified all `@medusajs/*` dependencies and resolutions to point to the local packages in my forked repository (e.g., `"@medusajs/product": "file:../medusa/packages/modules/product"`).
* From the test project's directory, I ran `yarn install` to link the local, modified Medusa source code into its `node_modules`.
3. **Build & Migration:**
* Inside my forked Medusa repository, I ran `yarn build` to compile the new TypeScript migration files.
* From the root of the **test project**, I then executed the migration command: `npx medusa migration run`.
4. **Verification:**
* The command successfully identified and ran only the new migration files I had created.
* I also confirmed via direct SQL queries that the old, redundant indexes were correctly dropped from all affected tables (`product_collection`, `customer_group`, etc.).
## Summary
**What** — What changes are introduced in this PR?
Add a method in the Tax Module's servie to retrieve a provider by its ID.
**Why** — Why are these changes relevant or necessary?
The Tax Module Provider could be used for use cases other than calculating tax lines. For example, Avalara supports importing products to manage product-specific taxes. However, it's not possible right now to listen to the `product.created` event and create the product in Avalara with its provider. Instead, you'll have to create a separate module that also connects to Avalara and resolve it in the subsriber.
This also matches the pattern in the Analytics Module, which allows retrieving the underlying provider.
**How** — How have these changes been implemented?
Add a `getProvider` method to the Tax Module's service and its interface.
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Added integration test for the method.
---
## Examples
Provide examples or code snippets that demonstrate how this feature works, or how it can be used in practice.
This helps with documentation and ensures maintainers can quickly understand and verify the change.
```ts
const avalaraProvider = taxModuleService.getProvider("tp_avalara_avalara")
```
---
## Checklist
Please ensure the following before requesting a review:
- [x] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [x] The changes are covered by relevant **tests**
- [x] I have verified the code works as intended locally
- [ ] I have linked the related issue(s) if applicable
---
## Additional Context
Add any additional context, related issues, or references that might help the reviewer understand this PR.
This pull request enhances the entity column generation logic in the admin views by adding support for including fields from additional GraphQL types, specifically for the `orders` entity. The changes allow more flexible and comprehensive column definitions by pulling in fields from related types (like `OrderDetail`) and updating the filtering and type resolution logic accordingly.
**This adding payment_status & fulfillment_status from OrderDetail in view configuration feature**
**Entity column generation enhancements:**
* Added the `ADDITIONAL_ENTITY_TYPES` mapping to specify extra GraphQL types whose fields should be included for certain entities (currently, `OrderDetail` for `orders`). ([packages/medusa/src/api/admin/views/[entity]/columns/helpers.tsR260-R263](diffhunk://#diff-ce197feb4e4d1273d9ee19126e284b65fdb4367f0871774a75add5c8cd749d02R260-R263))
* Updated the column generation process to collect fields from both the main entity type and any additional types, while properly filtering out arrays and excluded fields. ([packages/medusa/src/api/admin/views/[entity]/columns/helpers.tsR340-R345](diffhunk://#diff-ce197feb4e4d1273d9ee19126e284b65fdb4367f0871774a75add5c8cd749d02R340-R345), [packages/medusa/src/api/admin/views/[entity]/columns/helpers.tsR373-R414](diffhunk://#diff-ce197feb4e4d1273d9ee19126e284b65fdb4367f0871774a75add5c8cd749d02R373-R414))
* Changed field lookup logic to use a unified `entityFields` object and a new `additionalFieldDefinitions` map for extra fields, ensuring correct type info resolution for all columns. ([packages/medusa/src/api/admin/views/[entity]/columns/helpers.tsL344-R354](diffhunk://#diff-ce197feb4e4d1273d9ee19126e284b65fdb4367f0871774a75add5c8cd749d02L344-R354), [packages/medusa/src/api/admin/views/[entity]/columns/helpers.tsL411-R463](diffhunk://#diff-ce197feb4e4d1273d9ee19126e284b65fdb4367f0871774a75add5c8cd749d02L411-R463))
### What
Add a new `once` allocation strategy to promotions that limits application to a maximum number of items across the entire cart, rather than per line item.
### Why
Merchants want to create promotions that apply to a limited number of items across the entire cart. For example:
- "Get $10 off, applied to one item only"
- "20% off up to 2 items in your cart"
Current allocation strategies:
- `each`: Applies to each line item independently (respects `max_quantity` per item)
- `across`: Distributes proportionally across all items
Neither supports limiting total applications across the entire cart.
### How
Add `once` to the `ApplicationMethodAllocation` enum.
Behavior:
- Applies promotion to maximum `max_quantity` items across entire cart
- Always prioritizes lowest-priced eligible items first
- Distributes sequentially across items until quota exhausted
- Requires `max_quantity` field to be set
### Example Usage
**Scenario 1: Fixed discount**
```javascript
{
type: "fixed",
allocation: "once",
value: 10, // $10 off
max_quantity: 2 // Apply to 2 items max across cart
}
Cart:
- Item A: 3 units @ $100/unit
- Item B: 5 units @ $50/unit (lowest price)
Result: $20 discount on Item B (2 units × $10)
```
**Scenario 2: Distribution across items**
```javascript
{
type: "fixed",
allocation: "once",
value: 5,
max_quantity: 4
}
Cart:
- Item A: 2 units @ $50/unit
- Item B: 3 units @ $60/unit
Result:
- Item A: $10 discount (2 units × $5)
- Item B: $10 discount (2 units × $5, remaining quota)
```
**Scenario 3: Percentage discount - single item**
```javascript
{
type: "percentage",
allocation: "once",
value: 20, // 20% off
max_quantity: 3 // Apply to 3 items max
}
Cart:
- Item A: 5 units @ $100/unit
- Item B: 4 units @ $50/unit (lowest price)
Result: $30 discount on Item B (3 units × $50 × 20% = $30)
```
**Scenario 4: Percentage discount - distributed across items**
```javascript
{
type: "percentage",
allocation: "once",
value: 15, // 15% off
max_quantity: 5
}
Cart:
- Item A: 2 units @ $40/unit (lowest price)
- Item B: 4 units @ $80/unit
Result:
- Item A: $12 discount (2 units × $40 × 15% = $12)
- Item B: $36 discount (3 units × $80 × 15% = $36, remaining quota)
Total: $48 discount
```
**Scenario 5: Percentage with max_quantity = 1**
```javascript
{
type: "percentage",
allocation: "once",
value: 25, // 25% off
max_quantity: 1 // Only one item
}
Cart:
- Item A: 3 units @ $60/unit
- Item B: 2 units @ $30/unit (lowest price)
Result: $7.50 discount on Item B (1 unit × $30 × 25%)
```
* wip
* chore: prepare for PR
* move to end
* Change order of operations in refundPaymentWorkflow
Updated the order of operations in the refundPaymentWorkflow.
* chore: Add validation
When starting the Medusa application i see the following in the console:
```
update-order-tax-lines: "when" name should be defined. A random one will be assigned to it, which is not recommended for production.
({ input }) => {
return input.item_ids?.length > 0;
}
update-order-tax-lines: "when" name should be defined. A random one will be assigned to it, which is not recommended for production.
({ input }) => {
return input.shipping_method_ids?.length > 0;
}
```
This PR fixes the issue by passing a step name as a first parameter to the `when` usages in `updateOrderTaxLinesWorkflow`
* fix: replace CountrySelect fallback with Medusa Select
* Country Select Component Fix to use Medusa UI Select Component
* added Change set
* using the props supported by the Select
* value should be lowercased if passed from the pareant component
* fix province Select with medusa UI select and added change set
* bug fix the province with providing
---------
Co-authored-by: Aryan Patel <21cs038@charusat.edu.in>
Co-authored-by: William Bouchard <46496014+willbouch@users.noreply.github.com>
**What**
- implement promotion usage limits per customer/email
- fix registering spend usage over the limit
- fix type errors in promotion module tests
**How**
- introduce a new type of campaign budget that can be defined by an attribute such as customer id or email
- add `CampaignBudgetUsage` entity to keep track of the number of uses per attribute value
- update `registerUsage` and `computeActions` in the promotion module to work with the new type
- update `core-flows` to pass context needed for usage calculation to the promotion module
**Breaking**
- registering promotion usage now throws (and cart complete fails) if the budget limit is exceeded or if the cart completion would result in a breached limit
---
CLOSES CORE-1172
CLOSES CORE-1173
CLOSES CORE-1174
CLOSES CORE-1175
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
I added a lock in all workflows of the draft order. I don't think there are drawbacks and it will make sure we don't run into concurrency issues in with draft orders. I don't see why we would not add this in the order workflows, let me know and I can add it too.
I also didn't see any workflow that is long enough to justify adding a timeout of more than 2 seconds, but let me know if you think otherwise, we can discuss adjustments :)
CLOSES-1228
**What**
After lot of investigation, we finally found one of our performance regerssion point (see [here](https://github.com/mikro-orm/mikro-orm/issues/6905)), this pr downgrade mikro orm and move the strategy back to select in where needed
**What**
Return provider specific user_metadata in jwt token returned by auth/[actor_type]/[auth_provider] routes.
**Why**
When implementing thrid party auth flows, to create the Medusa entity representing the actor type, you will need information obtained from the callback after the user consents. For google for example, you need the email, which so far is stored in the provider user_metadata property but is never returned in the http response.
This causes one to circumvent around this issue by creating an additional http route which gets the auth_identity from the auth_context object, to access the providers array and then look for the specific element matching the current auth_provider route.
**How**
Pass the auth_provider obtained from the route path param and pass it down to `generateJwtTokenForAuthIdentity` and inside it, find the provider matching the auth provider passed from route handler inside the auth identity `provider_identities` property. If found, assign its `user_metadata` value to the property of the same name in the payload of the token to be generated.
Now the user has the user_metadata property included in the obtained token and can use it's information to create the corresponding Medusa entity for the actor type in context. In the case of google and customer actor type, they would use `user_metadata.email` to call the create customer api endpoint.
**Testing**
Haven't found anywhere in the codebase where the http layer of /auth functionality is tested, but tested locally with debugger and test storefront to guarantee the user_metadata is returned as expected, all working correctly.
Fixes#13584
CLOSES CORE-437
---
> [!NOTE]
> Propagates auth provider to JWT generation and embeds provider-specific user_metadata in tokens returned by auth routes.
>
> - **Auth JWT Payload**:
> - `generateJwtTokenForAuthIdentity` now accepts optional `authProvider` and injects matching provider `user_metadata` into JWT payload.
> - **Auth Routes** (`auth/[actor_type]/[auth_provider]/*`):
> - Pass `authProvider` from route params to JWT generator in `authenticate`, `register`, and `callback` handlers.
> - **Release**:
> - Changeset adds patch for `@medusajs/medusa`.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 4833faf84533ce7438bc37c15bd572f991988e69. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
**What**
It seems that for some reason the weak map fail in some scenario, but after investigation, the usage of map would not have a bad impact as it will be released after the Distributed transaction if finished. Therefore, falling back to Map instead
FIXES https://github.com/medusajs/medusa/issues/13654
NOTE: Waiting for the user feedback as he is also using node 18. We also use the exact same pattern in all our core flows without issues 🤔
Fixes#13625
---
> [!NOTE]
> Ensure `reserved_quantity` is adjusted when deleting reservation items via `deleteReservationItems`, with new integration tests covering deletion and inventory updates.
>
> - **Inventory Module Service (`packages/modules/inventory/src/services/inventory-module.ts`)**:
> - Add `deleteReservationItems` API (and transactional `_` variant) that hard-deletes reservations, then updates related inventory levels via `adjustInventoryLevelsForReservationsDeletion`.
> - Wire through event emission/manager decorators consistent with existing patterns.
> - **Integration Tests (`packages/modules/inventory/integration-tests/__tests__/inventory-module-service.spec.ts`)**:
> - Add tests for `deleteReservationItems` to verify deletion by id and `reserved_quantity` adjustments on inventory levels.
> - Minor import update to include `ReservationItemDTO`.
> - **Changeset**:
> - Patch release note for `@medusajs/inventory` documenting the fix.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit ac6641a9ec9543115504407f708f81bd427c3444. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
Closes#13163
I have a few questions about expected behaviour, since this currently breaks some tests:
- Many tests use the productModule to create products, with default status == "draft", and use the addToCart workflow which now throws. Should I change all breaking tests to specify status == "published" whne creating the product? The alternative would be to check the status in the store API route before the workflow but 1. it would be an extra query and 2. the addToCart workflow is only used in the store currently, and even if it was to be used admin-side, it still doesn't make sense to add a draft product to cart
- After this PR an unpublished product would give the same error as a variant that doesn't exist. While imho this is correct, the thrown error (for both) is "Items do not have a price" which doesn't make much sense(i believe the workflows goes through with an empty variants list and then errors at the price check point). Should I throw a different error when a variant doesn't exists/isn't published?
---
> [!NOTE]
> Enforces that only variants from published products can be added to carts, adds status fetching, refines errors, and updates tests to use ProductStatus.PUBLISHED.
>
> - **Core Flows**:
> - addToCart: Validate variants exist and belong to `product.status = PUBLISHED`; throw clear `INVALID_DATA` when not found/unpublished.
> - Data fetching: Include `product.status` in `cart` and `order` variant field selections.
> - **Tests/Fixtures**:
> - Update integration tests to set `status: ProductStatus.PUBLISHED` when creating products and import `ProductStatus` where needed.
> - Add cases for unpublished products and non-existent variants producing the new error message.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit ca72532e957964d2d8e6bcecbb0905054c677ded. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
Currently the plugin:db:generate command panics if one of the modules doesn't define any data models. This makes it impossible to generate migrations if you have a mix of modules with and without data models.
I added a simple check to skip these modules when creating the migrations.
Steps to repro:
```
npx create-medusa-app --plugin
cd my-medusa-plugin
# create a module with an empty service and no data models
npx medusa db:plugin:generate
```
Full error:
```
info: Generating migrations...
info: Generating migrations for module postmarkModuleService...
info: ----------------------------------------------------------------------------
error: defineMikroOrmCliConfig failed with: entities is required
Error: defineMikroOrmCliConfig failed with: entities is required
at defineMikroOrmCliConfig (/Users/leonardo/dev/medusa-plugin-postmark/node_modules/@medusajs/utils/src/modules-sdk/mikro-orm-cli-config-builder.ts:41:11)
at generateMigrations (/Users/leonardo/dev/medusa-plugin-postmark/node_modules/@medusajs/medusa/src/commands/plugin/db/generate.ts:124:26)
at main (/Users/leonardo/dev/medusa-plugin-postmark/node_modules/@medusajs/medusa/src/commands/plugin/db/generate.ts:49:11)
at processTicksAndRejections (node:internal/process/task_queues:105:5)
```
I didnt bother with writing an issue since I had the fix ready and it's very small, but lmk if I should in the future
