## 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
* 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**
- adding `categories` to `fields` param would return 404 for an existing product if the product was not associated with a category
---
CLOSES CMRC-1046
** What
- Allow auto-loaded Medusa files to export a config object.
- Currently supports isDisabled to control loading.
- new instance `FeatureFlag` exported by `@medusajs/framework/utils`
- `feature-flags` is now a supported folder for medusa projects, modules, providers and plugins. They will be loaded and added to `FeatureFlag`
** Why
- Enables conditional loading of routes, migrations, jobs, subscribers, workflows, and other files based on feature flags.
```ts
// /src/feature-flags
import { FlagSettings } from "@medusajs/framework/feature-flags"
const CustomFeatureFlag: FlagSettings = {
key: "custom_feature",
default_val: false,
env_key: "FF_MY_CUSTOM_FEATURE",
description: "Enable xyz",
}
export default CustomFeatureFlag
```
```ts
// /src/modules/my-custom-module/migration/Migration20250822135845.ts
import { FeatureFlag } from "@medusajs/framework/utils"
export class Migration20250822135845 extends Migration {
override async up(){ }
override async down(){ }
}
defineFileConfig({
isDisabled: () => !FeatureFlag.isFeatureEnabled("custom_feature")
})
```
* feat(dashboard, core-flows): allow associating shipping option type to a shipping option
* edit as well
* fix translation schema
* fix some tests
* changeset
* add new test to update shipping option type
* add new test to create shipping option with shipping option type
* pr comments
* pr comments
* rename variable
* make zod great again
This is part of a set of stacked PRs to add support for view configurations, which will allow users to customize the columns shown in admin tables.
The functionality in this PR is behind the view_configuration feature flag.
**What**
- Adds an API to introspect the remote query schema and extract columns that users can add to their table views.
**Notes**
- This is a brute forced approach to get the functionality in place and I expect it to evolve to something more elegant over time. Some ideas for things we might want to consider:
- Compute the entity columns during build time and store as static data the API can serve quickly.
- Offer developers more control over how their data can be exposed in this API with additional decorators in the DML.
* feat: add view_configurations feature flag
- Add feature flag provider and hooks to admin dashboard
- Add backend API endpoint for feature flags
- Create view_configurations feature flag (disabled by default)
- Update order list table to use legacy version when flag is disabled
- Can be enabled with MEDUSA_FF_VIEW_CONFIGURATIONS=true env var
* fix: naming
* fix: feature flags unauthenticated
* fix: add test
* feat: add settings module
* fix: deps
* fix: cleanup
* fix: add more tetsts
* fix: rm changelog
* fix: deps
* fix: add settings module to default modules list
* feat(api): add view configuration API routes
- Add CRUD endpoints for view configurations
- Add active view configuration management endpoints
- Add feature flag middleware for view config routes
- Add comprehensive integration tests
- Add HTTP types for view configuration payloads and responses
- Support system defaults and user-specific configurations
- Enable setting views as active during create/update operations
* fix: test
* fix: test
* fix: test
* fix: change view configuration path
* fix: tests
* fix: remove manual settings module config from integration tests
* fix: container typing
* fix: workflows
* feat: add view_configurations feature flag
- Add feature flag provider and hooks to admin dashboard
- Add backend API endpoint for feature flags
- Create view_configurations feature flag (disabled by default)
- Update order list table to use legacy version when flag is disabled
- Can be enabled with MEDUSA_FF_VIEW_CONFIGURATIONS=true env var
* fix: naming
* fix: feature flags unauthenticated
* fix: add test
* chore(types, api): support shipping option type api endpoints
* core flows
* api
* typos
* compiler errors
* integration tests
* remove metadata
* changeset
* modify test
* upsert
* change remote query
* minor to patch
* description optional
* description optional
* woops my bad
* my bad again
---------
Co-authored-by: william bouchard <williambouchard@williams-MacBook-Pro.local>
* 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>
