* Add preprocess to version param to validate as number
* Add changeset
* Use the first version of the order as the starting node of activity to show correct total
* Add changeset
* Fetch first order version only if it's not the current version
* Remove conditionally rendered hook, use enable config
## Summary
**What** — What changes are introduced in this PR?
Use correct HTTP type parameter for the get claim API route
**Why** — Why are these changes relevant or necessary?
*Please provide answer here*
**How** — How have these changes been implemented?
*Please provide answer here*
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
*Please provide answer here*
---
## 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
// Example usage
```
---
## Checklist
Please ensure the following before requesting a review:
- [ ] 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
- [ ] The changes are covered by relevant **tests**
- [ ] 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.
## Summary
**What** — What changes are introduced in this PR?
Allow users to delete other users and prevent them from deleting themselves.
**Why** — Why are these changes relevant or necessary?
Inability to delete other users causes old users that maybe don't work anymore with the business to have access still.
**How** — How have these changes been implemented?
Inverted the check in the admin delete user endpoint, to allow users deleting other users but themselves.
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Integration tests
---
## 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
// Example usage
```
---
## 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
- [x] 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.
closes OPS-97
---
> [!NOTE]
> Enables deleting other users via admin DELETE endpoint while blocking self-deletion, with corresponding integration tests and changeset.
>
> - **Backend**
> - Update `DELETE /admin/users/:id` in `packages/medusa/src/api/admin/users/[id]/route.ts`:
> - Disallow self-deletion when `actor_id === id` with `NOT_ALLOWED` error.
> - Execute `removeUserAccountWorkflow` and return standard delete response.
> - **Tests**
> - Expand `integration-tests/http/__tests__/user/admin/user.spec.ts`:
> - Create a second admin user; delete it and verify auth identity `app_metadata` no longer includes `user_id`.
> - Confirm token still authenticates but access is revoked (401 on `/admin/users/me`).
> - Assert self-deletion returns 400 with message `"A user cannot delete itself"`.
> - **Changeset**
> - Add `.changeset/dull-plants-create.md` (patch for `@medusajs/medusa`).
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit f1f8252b91593b8a8fb03dc9d26460d09a10cfaa. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
## Summary
**What** — What changes are introduced in this PR?
- Fix validators of delete item action for exchanges and claims to not include filter fields (their routes don't use these filters, and it doesn't make sense to have them)
- Fix query parameter type argument of the create reservation route to the correct HTTP type.
- Fix the HTTP type used for listing products and shipping options in the storefront to not include the `with_deleted` (It's also not supported by their validators)
**Why** — Why are these changes relevant or necessary?
*Please provide answer here*
**How** — How have these changes been implemented?
*Please provide answer here*
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
*Please provide answer here*
---
## 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
// Example usage
```
---
## Checklist
Please ensure the following before requesting a review:
- [ ] 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
- [ ] The changes are covered by relevant **tests**
- [ ] 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.
* feat(index): Add support to trigger sync manually
* feat(index): Add API route to interact with
* feat(index): Add API route to interact with
* feat(index): Add API route to interact with
* test(): Add http integration tests
* Create weak-elephants-reply.md
## Summary
**What** — What changes are introduced in this PR?
This PR is part of a series of PRs to fix HTTP and request type arguments.
This is the last PR in the series. It includes a changeset for the changes made.
**Why** — Why are these changes relevant or necessary?
These types impact the outputted OAS which we show on the API reference. By fixing up the types, we ensure accurate request parameters in the API reference.
**How** — How have these changes been implemented?
Made changes to HTTP types and request type arguments
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
-
---
## Examples
-
---
## Checklist
Please ensure the following before requesting a review:
- [ ] 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
- [ ] The changes are covered by relevant **tests**
- [ ] I have verified the code works as intended locally
- [ ] I have linked the related issue(s) if applicable
---
## Additional Context
-
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**
- 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>
**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>
RESOLVES CORE-1153
**What**
- This pr mainly lay the foundation the caching layer. It comes with a modules (built in memory cache) and a redis provider.
- Apply caching to few touch point to test
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
cc @willbouch since you asked to be tagged if I opened this PR.
The /store/shipping-options is one of only 2 store endpoints to not allow custom `fields` to be passed(other one is /store/returns if you guys want to add it to the backlog). This PR fixes that so that custom linked models can also be retrieved.
Note: This fix reveals a bug in the next.js starter
eac359cc8d/src/lib/data/fulfillment.ts (L23-L24)
`fields` was previously ignored, now it errors since it tries to parse the misspelled "fulfllment"(the i is missing). It worked before since both fields are already defined by default inside the workflow. So the `fields` line is totally redundant and should be removed(ideally before merging this).
Maybe in the next release notes it should also warn users to remove it for those that already have a modified copy of the starter.
* 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
* feat(core-flows): add hook to set shipping option context when listing them
* changeset
* add integration test
* add it to other workflow
* missing hook in workflow response
* rework workflow
* rework workflow
* typing issue
* comment from oli
* cursor the goat
* tests
* save lines
* move code around
* missing additional params in many places
* smal fix
* smal fix
**What**
- ensure unique promotion changes are displayed in the activity section
- check linked promotions by id and not code
- list promotions - add id param
- make address payload fields nullish
- Add items view UI tweaks
---
CLOSES SUP-2400
