Feat/shipping option types UI#1
Open
DhirenMhatre wants to merge 8 commits into
Open
Conversation
|
@codity review |
PR SummaryWhat Changed
Key Changes by AreaAPI Types: Created new SDK: Added Admin Dashboard: Added list view with data table, filters, and delete actions. Added create form with label, code, and description fields. Added routes under Bug Fix: Renamed mislabeled Files Changed
Review Focus Areas
ArchitectureDesign Decisions: Extracted shipping option types into a standalone domain to support independent management. Made Risks: The TODO in list table data fetching is an intentional placeholder. The shipping profiles row actions rename fixes a latent bug but touches shared component paths. Review for any missed references. Merge StatusNOT MERGEABLE — PR Score 23/100, below threshold (50)
|
Workflow DiagramsAutomatically generated sequence diagrams showing the workflows in this PR 1. Shipping Option Types CRUD WorkflowMedium complexity • Components: shipping-option-types API hooks, shipping-option-type-list table component, shipping-option-type-create form component sequenceDiagram
title Shipping Option Types CRUD Workflow
participant User
participant Router
participant ListView
participant CreateForm
participant RowActions
participant API_Hooks
participant SDK
participant QueryClient
Note over User,QueryClient: Navigation and List View
User->>Router: Navigate to /shipping-option-types
Router->>ListView: Render ShippingOptionTypeList
ListView->>API_Hooks: useShippingOptionTypes()
API_Hooks->>SDK: sdk.admin.shippingOptionType.list()
SDK-->>API_Hooks: Return shipping option types
API_Hooks-->>ListView: Display data in table
Note over User,QueryClient: Create New Shipping Option Type
User->>ListView: Click "Create" button
ListView->>Router: Navigate to /shipping-option-types/create
Router->>CreateForm: Render ShippingOptionTypeCreate
User->>CreateForm: Fill form (label, description, code)
CreateForm->>API_Hooks: useCreateShippingOptionType()
API_Hooks->>SDK: sdk.admin.shippingOptionType.create(payload)
SDK-->>API_Hooks: Return created type
API_Hooks->>QueryClient: invalidateQueries(lists)
QueryClient-->>ListView: Refresh list data
API_Hooks-->>CreateForm: onSuccess callback
CreateForm->>Router: Navigate back to list
Note over User,QueryClient: Delete Shipping Option Type
User->>ListView: Click actions menu on row
ListView->>RowActions: Render ShippingOptionsRowActions
User->>RowActions: Select "Delete"
RowActions->>RowActions: Show confirmation prompt
alt User confirms deletion
RowActions->>API_Hooks: useDeleteShippingOptionType(id)
API_Hooks->>SDK: sdk.admin.shippingOptionType.delete(id)
SDK-->>API_Hooks: Return delete response
API_Hooks->>QueryClient: invalidateQueries(detail + lists)
QueryClient-->>ListView: Refresh list data
API_Hooks-->>RowActions: Show success toast
else User cancels
RowActions-->>User: Close prompt, no action
end
Note: Diagrams show detected patterns only. Complex workflows may require manual review. |
![codity-chait[bot]](https://avatars.githubusercontent.com/u/228176587?s=60&v=4){kind=small}
Comment on lines
+23
to
+26
| const { shipping_option_types, count, isLoading, isError, error } = {} // TODO | ||
| // useShippingOptionTypes(searchParams, { | ||
| // placeholderData: keepPreviousData, | ||
| // }) |
There was a problem hiding this comment.
The data-fetching hook useShippingOptionTypes is commented out and replaced with an empty object destructure, causing all destructured variables to be undefined. This breaks the entire feature: the data table will never populate with shipping option types, pagination will fail due to missing count, loading and error states won't function, and the error boundary at line 40-41 will never trigger even if an error occurs. The component is effectively non-functional.
Suggested fix
const { shipping_option_types, count, isLoading, isError, error } = useShippingOptionTypes(searchParams, {
placeholderData: keepPreviousData,
})Prompt for AI assistance
Copy the prompt below and paste it into ChatGPT, Claude, or any LLM:
You are an expert bash developer with deep knowledge of security, performance, and best practices.
### Context
File: packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/shipping-option-type-list-table.tsx
Lines: 23-26
Issue Type: functional-critical
Severity: critical
Issue Description:
The data-fetching hook `useShippingOptionTypes` is commented out and replaced with an empty object destructure, causing all destructured variables to be `undefined`. This breaks the entire feature: the data table will never populate with shipping option types, pagination will fail due to missing `count`, loading and error states won't function, and the error boundary at line 40-41 will never trigger even if an error occurs. The component is effectively non-functional.
Current Code:
const { shipping_option_types, count, isLoading, isError, error } = {} // TODO
// useShippingOptionTypes(searchParams, {
// placeholderData: keepPreviousData,
// })
---
### Instructions
1. Fix the issue described above
2. Maintain the exact indentation and code style from the original
3. Follow bash best practices and language-specific idioms
4. Ensure the fix addresses the root cause, not just the symptoms
5. Add brief inline comments explaining the fix if needed
### Constraints
- Do not change functionality beyond fixing the identified issue
- Preserve existing variable names and function signatures unless they are part of the problem
- Ensure the fix is production-ready
---
| return await this.client.fetch<HttpTypes.AdminShippingOptionTypeResponse>( | ||
| `/admin/shipping-option-types`, | ||
| { | ||
| method: "POST", |
There was a problem hiding this comment.
The update method incorrectly uses HTTP POST instead of PATCH when updating a shipping option type. REST conventions dictate that PATCH should be used for partial updates, and the backend route likely only accepts PATCH requests. This causes update operations to fail at runtime with a 405 Method Not Allowed or similar error.
Suggested change
| method: "POST", | |
| method: "PATCH", |
Prompt for AI assistance
Copy the prompt below and paste it into ChatGPT, Claude, or any LLM:
You are an expert bash developer with deep knowledge of security, performance, and best practices.
### Context
File: packages/core/js-sdk/src/admin/shipping-option-type.ts
Lines: 20-20
Issue Type: functional-critical
Severity: critical
Issue Description:
The `update` method incorrectly uses HTTP POST instead of PATCH when updating a shipping option type. REST conventions dictate that PATCH should be used for partial updates, and the backend route likely only accepts PATCH requests. This causes update operations to fail at runtime with a 405 Method Not Allowed or similar error.
Current Code:
method: "POST",
---
### Instructions
1. Fix the issue described above
2. Maintain the exact indentation and code style from the original
3. Follow bash best practices and language-specific idioms
4. Ensure the fix addresses the root cause, not just the symptoms
5. Add brief inline comments explaining the fix if needed
### Constraints
- Do not change functionality beyond fixing the identified issue
- Preserve existing variable names and function signatures unless they are part of the problem
- Ensure the fix is production-ready
---
Comment on lines
+9
to
+13
| filters.push({ | ||
| key: "name", | ||
| label: t("fields.label"), | ||
| type: "string", | ||
| }) |
There was a problem hiding this comment.
The code filter has an incorrect key of 'name' instead of 'code', making it identical to the label filter. Both filters will send the same 'name' parameter to the API instead of their respective 'label' and 'code' parameters. This prevents users from filtering shipping option types by code, and causes the code filter to actually filter by name instead.
Also reported at: packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/use-shipping-option-type-table-filters.tsx L9–L13
Suggested fix
filters.push({
key: "code",
label: t("fields.code"),
type: "string",
})Prompt for AI assistance
Copy the prompt below and paste it into ChatGPT, Claude, or any LLM:
You are an expert bash developer with deep knowledge of security, performance, and best practices.
### Context
File: packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/use-shipping-option-type-table-filters.tsx
Lines: 9-13
Issue Type: functional-high
Severity: high
Issue Description:
The code filter has an incorrect key of 'name' instead of 'code', making it identical to the label filter. Both filters will send the same 'name' parameter to the API instead of their respective 'label' and 'code' parameters. This prevents users from filtering shipping option types by code, and causes the code filter to actually filter by name instead.
_Also reported at: `packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/use-shipping-option-type-table-filters.tsx` L9–L13_
Current Code:
filters.push({
key: "name",
label: t("fields.code"),
type: "string",
})
---
### Instructions
1. Fix the issue described above
2. Maintain the exact indentation and code style from the original
3. Follow bash best practices and language-specific idioms
4. Ensure the fix addresses the root cause, not just the symptoms
5. Add brief inline comments explaining the fix if needed
### Constraints
- Do not change functionality beyond fixing the identified issue
- Preserve existing variable names and function signatures unless they are part of the problem
- Ensure the fix is production-ready
---
Comment on lines
+5
to
+6
| import after from "virtual:medusa/widgets/shipping_profile/list/after" | ||
| import before from "virtual:medusa/widgets/shipping_profile/list/before" |
There was a problem hiding this comment.
The shipping option type list page imports widget slots from the wrong namespace (shipping_profile/list/ instead of shipping_option_type/list/), causing shipping profile widgets to render on the shipping option type list page instead of the correct widgets. This leads to incorrect UI components being displayed and confuses the extension/widget system. The fix requires changing the import paths to target the correct widget slot namespace.
Suggested fix
import after from "virtual:medusa/widgets/shipping_option_type/list/after"
import before from "virtual:medusa/widgets/shipping_option_type/list/before"Prompt for AI assistance
Copy the prompt below and paste it into ChatGPT, Claude, or any LLM:
You are an expert bash developer with deep knowledge of security, performance, and best practices.
### Context
File: packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/shipping-option-type-list.tsx
Lines: 5-6
Issue Type: functional-high
Severity: high
Issue Description:
The shipping option type list page imports widget slots from the wrong namespace (`shipping_profile/list/` instead of `shipping_option_type/list/`), causing shipping profile widgets to render on the shipping option type list page instead of the correct widgets. This leads to incorrect UI components being displayed and confuses the extension/widget system. The fix requires changing the import paths to target the correct widget slot namespace.
Current Code:
import after from "virtual:medusa/widgets/shipping_profile/list/after"
import before from "virtual:medusa/widgets/shipping_profile/list/before"
---
### Instructions
1. Fix the issue described above
2. Maintain the exact indentation and code style from the original
3. Follow bash best practices and language-specific idioms
4. Ensure the fix addresses the root cause, not just the symptoms
5. Add brief inline comments explaining the fix if needed
### Constraints
- Do not change functionality beyond fixing the identified issue
- Preserve existing variable names and function signatures unless they are part of the problem
- Ensure the fix is production-ready
---
Comment on lines
+51
to
+53
| handleSuccess( | ||
| `/settings/locations/shipping-option-types/${shipping_option_type.id}` | ||
| ) |
There was a problem hiding this comment.
After successfully creating a shipping option type, the code attempts to navigate to a detail page using the new resource's ID, but this route doesn't exist in the application's route map, resulting in a 404 or blank page being displayed to the user. This breaks the expected user flow after form submission and provides a poor user experience. The navigation should either go to a list view that exists, or the missing detail route needs to be implemented.
Suggested fix
handleSuccess(
`/settings/locations/shipping-option-types`
)Prompt for AI assistance
Copy the prompt below and paste it into ChatGPT, Claude, or any LLM:
You are an expert bash developer with deep knowledge of security, performance, and best practices.
### Context
File: packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-create/components/create-shipping-option-type-form/create-shipping-option-type-form.tsx
Lines: 51-53
Issue Type: functional-high
Severity: high
Issue Description:
After successfully creating a shipping option type, the code attempts to navigate to a detail page using the new resource's ID, but this route doesn't exist in the application's route map, resulting in a 404 or blank page being displayed to the user. This breaks the expected user flow after form submission and provides a poor user experience. The navigation should either go to a list view that exists, or the missing detail route needs to be implemented.
Current Code:
handleSuccess(
`/settings/locations/shipping-option-types/${shipping_option_type.id}`
)
---
### Instructions
1. Fix the issue described above
2. Maintain the exact indentation and code style from the original
3. Follow bash best practices and language-specific idioms
4. Ensure the fix addresses the root cause, not just the symptoms
5. Add brief inline comments explaining the fix if needed
### Constraints
- Do not change functionality beyond fixing the identified issue
- Preserve existing variable names and function signatures unless they are part of the problem
- Ensure the fix is production-ready
---
Comment on lines
21
to
22
| title: t("shippingProfile.delete.title"), | ||
| description: t("shippingProfile.delete.description", { |
There was a problem hiding this comment.
The delete confirmation dialog for shipping option types uses outdated translation keys from the shipping profile domain (shippingProfile.delete.title and shippingProfile.delete.description) instead of the new domain-specific keys (shippingOptionType.delete.title and shippingOptionType.delete.description). This causes users to see incorrect shipping profile-related text when attempting to delete a shipping option type, creating confusion about what they're actually deleting. The fix requires updating these two translation key references to match the new keys introduced in this PR.
Also reported at: packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/shipping-options-row-actions.tsx L38
Suggested fix
title: t("shippingOptionType.delete.title"),
description: t("shippingOptionType.delete.description", {Prompt for AI assistance
Copy the prompt below and paste it into ChatGPT, Claude, or any LLM:
You are an expert bash developer with deep knowledge of security, performance, and best practices.
### Context
File: packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/shipping-options-row-actions.tsx
Lines: 21-22
Issue Type: functional-medium
Severity: medium
Issue Description:
The delete confirmation dialog for shipping option types uses outdated translation keys from the shipping profile domain (`shippingProfile.delete.title` and `shippingProfile.delete.description`) instead of the new domain-specific keys (`shippingOptionType.delete.title` and `shippingOptionType.delete.description`). This causes users to see incorrect shipping profile-related text when attempting to delete a shipping option type, creating confusion about what they're actually deleting. The fix requires updating these two translation key references to match the new keys introduced in this PR.
_Also reported at: `packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/shipping-options-row-actions.tsx` L38_
Current Code:
title: t("shippingProfile.delete.title"),
description: t("shippingProfile.delete.description", {
---
### Instructions
1. Fix the issue described above
2. Maintain the exact indentation and code style from the original
3. Follow bash best practices and language-specific idioms
4. Ensure the fix addresses the root cause, not just the symptoms
5. Add brief inline comments explaining the fix if needed
### Constraints
- Do not change functionality beyond fixing the identified issue
- Preserve existing variable names and function signatures unless they are part of the problem
- Ensure the fix is production-ready
---
Security Scan Summary
No critical security issues detected Scan completed in 42.9sSecurity scan powered by Codity.ai |
License Compliance Scan
Weak copyleft licenses found - verify compatibility Some packages have unknown licenses - manual review required Medium Risk Licenses - 2 packagesMPL-2.0 (2 packages):
Unknown Licenses - 46 packages
...and 26 more Powered by Codity.ai · Docs |
Code Quality Report — test-org-codity/medusa · PR #1Scanned: 2026-06-06 17:38 UTC | Score: 38/100 | Provider: github Executive Summary
Top Findings[CQ-LLM-002]
|
| File | Critical | High | Medium | Low | Total |
|---|---|---|---|---|---|
packages/admin-next/dashboard/src/hooks/api/shipping-option-types.tsx |
0 | 0 | 1 | 0 | 1 |
packages/admin-next/dashboard/src/providers/router-provider/route-map.tsx |
0 | 0 | 0 | 6 | 6 |
packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-create/components/create-shipping-option-type-form/create-shipping-option-type-form.tsx |
0 | 1 | 2 | 35 | 38 |
packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/shipping-option-type-list-table.tsx |
0 | 0 | 0 | 1 | 1 |
packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/use-shipping-option-type-table-query.tsx |
0 | 0 | 0 | 1 | 1 |
Recommendations
- Resolve High severity issues, especially error handling gaps and performance bottlenecks.
- Run automated tests after applying fixes to verify no regressions.
|
@codity review |
PR SummaryWhat Changed
Key Changes by AreaAPI & Types
Admin Dashboard
Data Model
Files Changed
Review Focus Areas
ArchitectureDesign Decisions
Risks
Merge StatusNOT MERGEABLE — PR Score 25/100, below threshold (50)
|
Workflow DiagramsAutomatically generated sequence diagrams showing the workflows in this PR 1. Shipping Option Types Management FlowMedium complexity • Components: shipping-option-types API hooks, shipping-option-type-list table component, shipping-option-type-create form component sequenceDiagram
title: Shipping Option Types Management Workflow
participant User
participant UI as AdminDashboard
participant Router as RouteMap
participant ListComp as ShippingOptionTypeList
participant CreateComp as CreateShippingOptionTypeForm
participant RowActions as ShippingOptionsRowActions
participant Hooks as APIHooks
participant SDK as MedusaSDK
participant API as BackendAPI
participant Cache as QueryClient
User->>Router: Navigate to /settings/locations/shipping-option-types
Router->>ListComp: Render ShippingOptionTypeList component
ListComp->>Hooks: useShippingOptionTypes(query)
Hooks->>SDK: sdk.admin.shippingOptionType.list(query)
SDK->>API: GET /admin/shipping-option-types
API-->>SDK: ShippingOptionTypeListResponse
SDK-->>Hooks: Return data
Hooks-->>ListComp: Return { shipping_option_types, ...rest }
alt User creates new shipping option type
User->>ListComp: Click "Create" button
ListComp->>Router: Open /shipping-option-types/create modal
Router->>CreateComp: Render CreateShippingOptionTypeForm
User->>CreateComp: Fill form (label, description, code)
CreateComp->>Hooks: useCreateShippingOptionType()
Hooks->>SDK: sdk.admin.shippingOptionType.create(payload)
SDK->>API: POST /admin/shipping-option-types
API-->>SDK: AdminShippingOptionTypeResponse
SDK-->>Hooks: Return created type
Hooks->>Cache: invalidateQueries(lists)
Note over Hooks,Cache: Invalidate list cache to refresh data
Hooks-->>CreateComp: onSuccess callback
CreateComp->>Router: Close modal, redirect to list
Router->>ListComp: Re-render with fresh data
end
alt User deletes shipping option type
User->>RowActions: Click delete on table row
RowActions->>UI: Show confirmation prompt
UI-->>User: Display verification dialog
User->>UI: Confirm deletion
UI->>RowActions: Execute delete
RowActions->>Hooks: useDeleteShippingOptionType(id)
Hooks->>SDK: sdk.admin.shippingOptionType.delete(id)
SDK->>API: DELETE /admin/shipping-option-types/:id
API-->>SDK: AdminShippingOptionTypeDeleteResponse
SDK-->>Hooks: Return success
Hooks->>Cache: invalidateQueries(detail + lists)
Note over Hooks,Cache: Invalidate both detail and list caches
Hooks-->>RowActions: onSuccess callback
RowActions->>UI: Show success toast
UI->>ListComp: Refresh table data
end
Note: Diagrams show detected patterns only. Complex workflows may require manual review. |
Comment on lines
+23
to
+26
| const { shipping_option_types, count, isLoading, isError, error } = {} // TODO | ||
| // useShippingOptionTypes(searchParams, { | ||
| // placeholderData: keepPreviousData, | ||
| // }) |
There was a problem hiding this comment.
The useShippingOptionTypes hook call is commented out and replaced with an empty object destructure, causing all data fields (shipping_option_types, count, isLoading, isError, error) to be undefined. This breaks the shipping option types list page, rendering an empty table with no loading state or error handling.
Suggested fix
const { shipping_option_types, count, isLoading, isError, error } = useShippingOptionTypes(searchParams, {
placeholderData: keepPreviousData,
})Prompt for AI assistance
Copy the prompt below and paste it into ChatGPT, Claude, or any LLM:
You are an expert bash developer with deep knowledge of security, performance, and best practices.
### Context
File: packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/shipping-option-type-list-table.tsx
Lines: 23-26
Issue Type: functional-critical
Severity: critical
Issue Description:
The `useShippingOptionTypes` hook call is commented out and replaced with an empty object destructure, causing all data fields (`shipping_option_types`, `count`, `isLoading`, `isError`, `error`) to be undefined. This breaks the shipping option types list page, rendering an empty table with no loading state or error handling.
Current Code:
const { shipping_option_types, count, isLoading, isError, error } = {} // TODO
// useShippingOptionTypes(searchParams, {
// placeholderData: keepPreviousData,
// })
---
### Instructions
1. Fix the issue described above
2. Maintain the exact indentation and code style from the original
3. Follow bash best practices and language-specific idioms
4. Ensure the fix addresses the root cause, not just the symptoms
5. Add brief inline comments explaining the fix if needed
### Constraints
- Do not change functionality beyond fixing the identified issue
- Preserve existing variable names and function signatures unless they are part of the problem
- Ensure the fix is production-ready
---
Comment on lines
+9
to
+19
| filters.push({ | ||
| key: "name", | ||
| label: t("fields.label"), | ||
| type: "string", | ||
| }) | ||
|
|
||
| filters.push({ | ||
| key: "name", | ||
| label: t("fields.code"), | ||
| type: "string", | ||
| }) |
There was a problem hiding this comment.
The label and code filters both use the same key "name", causing the second filter to overwrite the first in the filter state. The keys should be "label" and "code" respectively to match the query parameters consumed by useShippingOptionTypeTableQuery, allowing these filters to function correctly.
Suggested fix
filters.push({
key: "label",
label: t("fields.label"),
type: "string",
})
filters.push({
key: "code",
label: t("fields.code"),
type: "string",
})Prompt for AI assistance
Copy the prompt below and paste it into ChatGPT, Claude, or any LLM:
You are an expert bash developer with deep knowledge of security, performance, and best practices.
### Context
File: packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/use-shipping-option-type-table-filters.tsx
Lines: 9-19
Issue Type: functional-high
Severity: high
Issue Description:
The label and code filters both use the same key "name", causing the second filter to overwrite the first in the filter state. The keys should be "label" and "code" respectively to match the query parameters consumed by useShippingOptionTypeTableQuery, allowing these filters to function correctly.
Current Code:
filters.push({
key: "name",
label: t("fields.label"),
type: "string",
})
filters.push({
key: "name",
label: t("fields.code"),
type: "string",
})
---
### Instructions
1. Fix the issue described above
2. Maintain the exact indentation and code style from the original
3. Follow bash best practices and language-specific idioms
4. Ensure the fix addresses the root cause, not just the symptoms
5. Add brief inline comments explaining the fix if needed
### Constraints
- Do not change functionality beyond fixing the identified issue
- Preserve existing variable names and function signatures unless they are part of the problem
- Ensure the fix is production-ready
---
Comment on lines
21
to
24
| title: t("shippingProfile.delete.title"), | ||
| description: t("shippingProfile.delete.description", { | ||
| name: profile.name, | ||
| name: optionType.label, | ||
| }), |
There was a problem hiding this comment.
The delete confirmation prompt for shipping option types uses incorrect i18n keys (shippingProfile.delete.title and shippingProfile.delete.description) instead of the correct keys (shippingOptionType.delete.title and shippingOptionType.delete.description) that were added to the translations. This causes the modal to display misleading shipping-profile-branded text when the user is actually deleting a shipping option type.
Suggested fix
title: t("shippingOptionType.delete.title"),
description: t("shippingOptionType.delete.description", {
name: optionType.label,
}),Prompt for AI assistance
Copy the prompt below and paste it into ChatGPT, Claude, or any LLM:
You are an expert bash developer with deep knowledge of security, performance, and best practices.
### Context
File: packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/shipping-options-row-actions.tsx
Lines: 21-24
Issue Type: functional-high
Severity: high
Issue Description:
The delete confirmation prompt for shipping option types uses incorrect i18n keys (`shippingProfile.delete.title` and `shippingProfile.delete.description`) instead of the correct keys (`shippingOptionType.delete.title` and `shippingOptionType.delete.description`) that were added to the translations. This causes the modal to display misleading shipping-profile-branded text when the user is actually deleting a shipping option type.
Current Code:
title: t("shippingProfile.delete.title"),
description: t("shippingProfile.delete.description", {
name: optionType.label,
}),
---
### Instructions
1. Fix the issue described above
2. Maintain the exact indentation and code style from the original
3. Follow bash best practices and language-specific idioms
4. Ensure the fix addresses the root cause, not just the symptoms
5. Add brief inline comments explaining the fix if needed
### Constraints
- Do not change functionality beyond fixing the identified issue
- Preserve existing variable names and function signatures unless they are part of the problem
- Ensure the fix is production-ready
---
Comment on lines
+5
to
+6
| import after from "virtual:medusa/widgets/shipping_profile/list/after" | ||
| import before from "virtual:medusa/widgets/shipping_profile/list/before" |
There was a problem hiding this comment.
The shipping option type list page imports widget injection slots for shipping_profile instead of its own shipping_option_type slot. This causes widgets registered for the shipping-profile list zone to appear incorrectly on the shipping-option-types page, while widgets intended for this page are never rendered.
Suggested fix
import after from "virtual:medusa/widgets/shipping_option_type/list/after"
import before from "virtual:medusa/widgets/shipping_option_type/list/before"Prompt for AI assistance
Copy the prompt below and paste it into ChatGPT, Claude, or any LLM:
You are an expert bash developer with deep knowledge of security, performance, and best practices.
### Context
File: packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/shipping-option-type-list.tsx
Lines: 5-6
Issue Type: functional-high
Severity: high
Issue Description:
The shipping option type list page imports widget injection slots for `shipping_profile` instead of its own `shipping_option_type` slot. This causes widgets registered for the shipping-profile list zone to appear incorrectly on the shipping-option-types page, while widgets intended for this page are never rendered.
Current Code:
import after from "virtual:medusa/widgets/shipping_profile/list/after"
import before from "virtual:medusa/widgets/shipping_profile/list/before"
---
### Instructions
1. Fix the issue described above
2. Maintain the exact indentation and code style from the original
3. Follow bash best practices and language-specific idioms
4. Ensure the fix addresses the root cause, not just the symptoms
5. Add brief inline comments explaining the fix if needed
### Constraints
- Do not change functionality beyond fixing the identified issue
- Preserve existing variable names and function signatures unless they are part of the problem
- Ensure the fix is production-ready
---
| return await this.client.fetch<HttpTypes.AdminShippingOptionTypeResponse>( | ||
| `/admin/shipping-option-types`, | ||
| { | ||
| method: "POST", |
There was a problem hiding this comment.
The update method uses HTTP POST instead of PATCH when updating a shipping option type at /admin/shipping-option-types/:id. This violates REST conventions where POST is for creation and PATCH is for updates, and conflicts with other SDK update methods that correctly use PATCH.
Suggested change
| method: "POST", | |
| method: "PATCH", |
Prompt for AI assistance
Copy the prompt below and paste it into ChatGPT, Claude, or any LLM:
You are an expert bash developer with deep knowledge of security, performance, and best practices.
### Context
File: packages/core/js-sdk/src/admin/shipping-option-type.ts
Lines: 20-20
Issue Type: functional-high
Severity: high
Issue Description:
The `update` method uses HTTP `POST` instead of `PATCH` when updating a shipping option type at `/admin/shipping-option-types/:id`. This violates REST conventions where `POST` is for creation and `PATCH` is for updates, and conflicts with other SDK update methods that correctly use `PATCH`.
Current Code:
method: "POST",
---
### Instructions
1. Fix the issue described above
2. Maintain the exact indentation and code style from the original
3. Follow bash best practices and language-specific idioms
4. Ensure the fix addresses the root cause, not just the symptoms
5. Add brief inline comments explaining the fix if needed
### Constraints
- Do not change functionality beyond fixing the identified issue
- Preserve existing variable names and function signatures unless they are part of the problem
- Ensure the fix is production-ready
---
Comment on lines
+51
to
+53
| handleSuccess( | ||
| `/settings/locations/shipping-option-types/${shipping_option_type.id}` | ||
| ) |
There was a problem hiding this comment.
After successfully creating a shipping option type, the code navigates to /settings/locations/shipping-option-types/${shipping_option_type.id}, but the route map does not define an /:id child route under shipping-option-types. This causes the navigation to fail with a 404 or match an unrelated route.
Suggested fix
handleSuccess(
`/settings/locations/shipping-option-types`
)Prompt for AI assistance
Copy the prompt below and paste it into ChatGPT, Claude, or any LLM:
You are an expert bash developer with deep knowledge of security, performance, and best practices.
### Context
File: packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-create/components/create-shipping-option-type-form/create-shipping-option-type-form.tsx
Lines: 51-53
Issue Type: functional-high
Severity: high
Issue Description:
After successfully creating a shipping option type, the code navigates to `/settings/locations/shipping-option-types/${shipping_option_type.id}`, but the route map does not define an `/:id` child route under `shipping-option-types`. This causes the navigation to fail with a 404 or match an unrelated route.
Current Code:
handleSuccess(
`/settings/locations/shipping-option-types/${shipping_option_type.id}`
)
---
### Instructions
1. Fix the issue described above
2. Maintain the exact indentation and code style from the original
3. Follow bash best practices and language-specific idioms
4. Ensure the fix addresses the root cause, not just the symptoms
5. Add brief inline comments explaining the fix if needed
### Constraints
- Do not change functionality beyond fixing the identified issue
- Preserve existing variable names and function signatures unless they are part of the problem
- Ensure the fix is production-ready
---
Comment on lines
38
to
40
| description: t("shippingProfile.delete.successToast", { | ||
| name: profile.name, | ||
| name: optionType.label, | ||
| }), |
There was a problem hiding this comment.
The success toast message after deleting a shipping option type uses the wrong i18n key shippingProfile.delete.successToast instead of shippingOptionType.delete.successToast. This causes users to see an incorrect success message that references shipping profiles rather than the appropriate shipping option type confirmation.
Suggested fix
description: t("shippingOptionType.delete.successToast", {
name: optionType.label,
}),Prompt for AI assistance
Copy the prompt below and paste it into ChatGPT, Claude, or any LLM:
You are an expert bash developer with deep knowledge of security, performance, and best practices.
### Context
File: packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/shipping-options-row-actions.tsx
Lines: 38-40
Issue Type: functional-medium
Severity: medium
Issue Description:
The success toast message after deleting a shipping option type uses the wrong i18n key `shippingProfile.delete.successToast` instead of `shippingOptionType.delete.successToast`. This causes users to see an incorrect success message that references shipping profiles rather than the appropriate shipping option type confirmation.
Current Code:
description: t("shippingProfile.delete.successToast", {
name: optionType.label,
}),
---
### Instructions
1. Fix the issue described above
2. Maintain the exact indentation and code style from the original
3. Follow bash best practices and language-specific idioms
4. Ensure the fix addresses the root cause, not just the symptoms
5. Add brief inline comments explaining the fix if needed
### Constraints
- Do not change functionality beyond fixing the identified issue
- Preserve existing variable names and function signatures unless they are part of the problem
- Ensure the fix is production-ready
---
Security Scan Summary
No critical security issues detected Scan completed in 41.1sSecurity scan powered by Codity.ai |
License Compliance Scan
Weak copyleft licenses found - verify compatibility Some packages have unknown licenses - manual review required Medium Risk Licenses - 2 packagesMPL-2.0 (2 packages):
Unknown Licenses - 45 packages
...and 25 more Powered by Codity.ai · Docs |
Code Quality Report — test-org-codity/medusa · PR #1Scanned: 2026-06-06 18:10 UTC | Score: 42/100 | Provider: github Executive Summary
Top Findings[CQ-LLM-001]
|
| File | Critical | High | Medium | Low | Total |
|---|---|---|---|---|---|
packages/admin-next/dashboard/src/hooks/api/shipping-option-types.tsx |
0 | 0 | 1 | 1 | 2 |
packages/admin-next/dashboard/src/providers/router-provider/route-map.tsx |
0 | 0 | 0 | 6 | 6 |
packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-create/components/create-shipping-option-type-form/create-shipping-option-type-form.tsx |
0 | 0 | 2 | 35 | 37 |
packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/shipping-option-type-list-table.tsx |
0 | 0 | 0 | 1 | 1 |
packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/use-shipping-option-type-table-query.tsx |
0 | 0 | 0 | 1 | 1 |
Recommendations
- Run automated tests after applying fixes to verify no regressions.
Author
|
@CodeAnt-AI: review |
|
CodeAnt AI is running the review. |
codeant-ai
Bot
added
the
size:XL
Sequence DiagramThis PR adds admin dashboard UI, hooks, and SDK support so administrators can create and delete shipping option types through the admin API. sequenceDiagram
participant AdminUser
participant AdminDashboard
participant AdminAPI
AdminUser->>AdminDashboard: Submit new shipping option type form
AdminDashboard->>AdminAPI: Create shipping option type
AdminAPI-->>AdminDashboard: Return created shipping option type
AdminDashboard-->>AdminUser: Show success message and navigate to detail view
AdminUser->>AdminDashboard: Confirm delete shipping option type
AdminDashboard->>AdminAPI: Delete shipping option type
AdminAPI-->>AdminDashboard: Confirm deletion
AdminDashboard-->>AdminUser: Show deletion success message and refresh list
Generated by CodeAnt AI |
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
Comment on lines
+23
to
+26
| const { shipping_option_types, count, isLoading, isError, error } = {} // TODO | ||
| // useShippingOptionTypes(searchParams, { | ||
| // placeholderData: keepPreviousData, | ||
| // }) |
There was a problem hiding this comment.
Suggestion: The list query is never executed because the hook call is replaced with destructuring from an empty object. This makes the page always render with no data and no real loading/error state, so shipping option types cannot be displayed. Restore the useShippingOptionTypes call and destructure from its result instead of {}. [incomplete implementation]
Severity Level: Critical 🚨
- ❌ `/settings/locations/shipping-option-types` always shows an empty list.
- ❌ No network request to list shipping option types is issued.
- ⚠️ Loading state skeleton never appears during data fetching.
- ⚠️ Query errors are never surfaced via `isError` or `error`.Steps of Reproduction ✅
1. Note the router configuration in
`packages/admin-next/dashboard/src/providers/router-provider/route-map.tsx:16-23` where
path `"shipping-option-types"` under locations lazily imports
`"../../routes/shipping-option-types/shipping-option-type-list"`, wiring the URL
`/settings/locations/shipping-option-types` to the shipping option types list route.
2. In
`packages/admin-next/dashboard/src/routes/locations/location-list/location-list.tsx:13-18`,
the `IconButton`'s `onClick` handler calls
`navigate("/settings/locations/shipping-option-types")`, so clicking this button from the
locations list navigates to the shipping option types list page.
3. The lazy-loaded module
`packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/index.ts:1`
re-exports `ShippingOptionTypeList` from `shipping-option-type-list.tsx`, and that
component at `shipping-option-type-list.tsx:8-19` renders `<ShippingOptionTypeListTable
/>` as the main table on the page.
4. The table component
`packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/shipping-option-type-list-table.tsx:19-26`
initializes list state with `const { shipping_option_types, count, isLoading, isError,
error } = {} // TODO` while the real data hook call `useShippingOptionTypes(searchParams,
{ placeholderData: keepPreviousData })` is commented out, so `shipping_option_types`,
`count`, `isLoading`, and `isError` are all `undefined`.
5. `useDataTable` is invoked in the same file at lines 31-38 with `data:
shipping_option_types` and `count`, but since `shipping_option_types` is `undefined`,
`useDataTable` (see `packages/admin-next/dashboard/src/hooks/use-data-table.tsx:33-37`)
defaults `data = []` and `count = 0`, causing the `DataTable` component
(`components/table/data-table/data-table.tsx:21-37`) to render with no rows and
`isLoading=false` (default), while no call to `useShippingOptionTypes` (defined in
`hooks/api/shipping-option-types.tsx:60-78` and responsible for calling
`sdk.admin.shippingOptionType.list`) is ever made. Visiting
`/settings/locations/shipping-option-types` therefore always shows an empty/non-loading
table regardless of backend data, and errors from the query can never set `isError` or
`error`.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/shipping-option-type-list-table.tsx
**Line:** 23:26
**Comment:**
*Incomplete Implementation: The list query is never executed because the hook call is replaced with destructuring from an empty object. This makes the page always render with no data and no real loading/error state, so shipping option types cannot be displayed. Restore the `useShippingOptionTypes` call and destructure from its result instead of `{}`.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Comment on lines
+9
to
+13
| filters.push({ | ||
| key: "name", | ||
| label: t("fields.label"), | ||
| type: "string", | ||
| }) |
There was a problem hiding this comment.
Suggestion: The label filter is wired to name, but this list query reads label for shipping option types. As written, filtering by label will send an unsupported/ignored parameter and produce incorrect results. Change this filter key to label so it matches the table query and API contract. [api mismatch]
Severity Level: Major ⚠️
- ⚠️ Shipping option types cannot be filtered by label.
- ⚠️ URL query uses unsupported name parameter for filtering.
- ⚠️ Admin users see filters that have no effect.Steps of Reproduction ✅
1. Navigate to the admin dashboard route defined in
`packages/admin-next/dashboard/src/providers/router-provider/route-map.tsx:6-13` where
path `"shipping-option-types"` lazily imports
`"../../routes/shipping-option-types/shipping-option-type-list"`.
2. The imported component `ShippingOptionTypeList` in
`packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/shipping-option-type-list.tsx:3-8`
renders `<ShippingOptionTypeListTable />`, which in turn renders a `DataTable` in
`shipping-option-type-list-table.tsx:54-66`.
3. `ShippingOptionTypeListTable` obtains its filters from
`useShippingOptionTypeTableFilters()` at `shipping-option-type-list-table.tsx:28-29`,
which defines the "Label" filter with `key: "name"` in
`use-shipping-option-type-table-filters.tsx:9-13` instead of `key: "label"`.
4. The `DataTable` component passes these filters into `DataTableFilter`
(`data-table.tsx:73-78`), and `DataTableFilter` uses `filter.key` as the URL query
parameter key (see `data-table-filter.tsx:71-75` and `257-30`); meanwhile,
`useShippingOptionTypeTableQuery` reads `label` from the query string and maps it to
`searchParams.label` (`use-shipping-option-type-table-query.tsx:10-12,22-24`). As a
result, using the "Label" filter writes a `name` query param that
`useShippingOptionTypeTableQuery` ignores, so the backend list query (via
`useShippingOptionTypes` in `hooks/api/shipping-option-types.tsx:60-78`) never receives a
`label` filter and label-based filtering does not work.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/use-shipping-option-type-table-filters.tsx
**Line:** 9:13
**Comment:**
*Api Mismatch: The label filter is wired to `name`, but this list query reads `label` for shipping option types. As written, filtering by label will send an unsupported/ignored parameter and produce incorrect results. Change this filter key to `label` so it matches the table query and API contract.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Comment on lines
+15
to
+19
| filters.push({ | ||
| key: "name", | ||
| label: t("fields.code"), | ||
| type: "string", | ||
| }) |
There was a problem hiding this comment.
Suggestion: The code filter also uses name instead of code, which means the UI cannot send a real code-specific filter and duplicates the same key as the previous filter. Update this key to code so the filter maps to the correct API field. [api mismatch]
Severity Level: Major ⚠️
- ⚠️ Shipping option types cannot be filtered by code.
- ⚠️ Duplicate name key makes filters semantically ambiguous.
- ⚠️ Backend list query never receives code filter value.Steps of Reproduction ✅
1. From the route map at
`packages/admin-next/dashboard/src/providers/router-provider/route-map.tsx:6-13`, open the
`"shipping-option-types"` route which loads `shipping-option-type-list.tsx` and renders
`ShippingOptionTypeList`.
2. `ShippingOptionTypeList` (`shipping-option-type-list.tsx:3-8`) renders
`ShippingOptionTypeListTable`, which wires filters into `DataTable` by calling
`useShippingOptionTypeTableFilters()` at `shipping-option-type-list-table.tsx:28-29`.
3. In `use-shipping-option-type-table-filters.tsx:15-19`, the "Code" filter is defined
with `key: "name"` while its label is `t("fields.code")`, so both "Label" and "Code"
filters share the same key `"name"` instead of using `"label"` and `"code"` respectively.
4. `DataTableFilter` uses each filter's key as the URL/query key
(`data-table-filter.tsx:71-75, 257-30`), but `useShippingOptionTypeTableQuery` only reads
`created_at`, `updated_at`, `label`, and `code` as typed query params
(`use-shipping-option-type-table-query.tsx:10-12,20-24`). When a user adds a "Code" filter
in the UI, only a `name` query parameter is written; `raw.code` remains undefined, so
`searchParams.code` is never set and the SDK list call in `useShippingOptionTypes`
(`hooks/api/shipping-option-types.tsx:60-78`) cannot filter by code.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/use-shipping-option-type-table-filters.tsx
**Line:** 15:19
**Comment:**
*Api Mismatch: The code filter also uses `name` instead of `code`, which means the UI cannot send a real code-specific filter and duplicates the same key as the previous filter. Update this key to `code` so the filter maps to the correct API field.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Comment on lines
+5
to
+6
| import after from "virtual:medusa/widgets/shipping_profile/list/after" | ||
| import before from "virtual:medusa/widgets/shipping_profile/list/before" |
There was a problem hiding this comment.
Suggestion: This page imports shipping-profile widget slots instead of shipping-option-type slots, so shipping-profile list widgets will render on the wrong route and option-type-specific widgets cannot be targeted. Use the shipping-option-type widget namespace for this route's before/after slots. [logic error]
Severity Level: Major ⚠️
- ⚠️ Shipping profile widgets also render on option types page.
- ⚠️ Plugins cannot target shipping option types list specifically.
- ⚠️ UI customization for profiles leaks into unrelated route.Steps of Reproduction ✅
1. In `packages/admin-next/dashboard/src/providers/router-provider/route-map.tsx:6-13`,
the `"shipping-option-types"` route is configured to lazily import
`"../../routes/shipping-option-types/shipping-option-type-list"`, making
`ShippingOptionTypeList` the entry component for that page.
2. `ShippingOptionTypeList` (`shipping-option-type-list.tsx:3-8`) imports widget slots
from `virtual:medusa/widgets/shipping_profile/list/after` and
`virtual:medusa/widgets/shipping_profile/list/before` at lines 5-6 and renders
`before.widgets` and `after.widgets` around `<ShippingOptionTypeListTable />` at lines
11-25.
3. The shipping profiles list route
`packages/admin-next/dashboard/src/routes/shipping-profiles/shipping-profiles-list/shipping-profile-list.tsx:3-8`
uses the exact same widget namespace imports
(`virtual:medusa/widgets/shipping_profile/list/after` and `/before`) for the actual
shipping profiles list page.
4. Because both the shipping profiles list and shipping option types list consume the same
`shipping_profile/list` before/after widget slots, any plugin or customization targeting
`shipping_profile/list` (as seen via `virtual:medusa/widgets/shipping_profile/` usages in
`Grep`) will render on both pages, causing cross-page widget injection on the shipping
option types route and preventing plugins from distinguishing between these two distinct
list views.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-list/shipping-option-type-list.tsx
**Line:** 5:6
**Comment:**
*Logic Error: This page imports shipping-profile widget slots instead of shipping-option-type slots, so shipping-profile list widgets will render on the wrong route and option-type-specific widgets cannot be targeted. Use the shipping-option-type widget namespace for this route's before/after slots.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Comment on lines
+51
to
+53
| handleSuccess( | ||
| `/settings/locations/shipping-option-types/${shipping_option_type.id}` | ||
| ) |
There was a problem hiding this comment.
Suggestion: The success redirect points to a shipping-option-type detail URL, but this PR only registers shipping-option-types/create and does not register a shipping-option-types/:id route. After a successful create, users will be navigated to a non-matching route (404/blank state). Redirect to an existing route (e.g. the list page) or add the missing :id route. [api mismatch]
Severity Level: Critical 🚨
- ❌ Creating a shipping option type ends on a 404 route.
- ❌ Users cannot view newly created shipping option type details.
- ⚠️ Locations & Shipping settings UX becomes confusing and inconsistent.
- ⚠️ DataTable row navigation to `row.id` also lacks a matching route.Steps of Reproduction ✅
1. From the locations overview page at
`packages/admin-next/dashboard/src/routes/locations/location-list/location-list.tsx:23-31`,
click the "Shipping Option Types" card action, which calls
`navigate('/settings/locations/shipping-option-types')`. This hits the `settings ->
locations -> shipping-option-types` route configured in
`src/providers/router-provider/route-map.tsx:64-73`.
2. On the shipping option types list page (`ShippingOptionTypeListTable` in
`src/routes/shipping-option-types/shipping-option-type-list/components/shipping-profile-list-table/shipping-option-type-list-table.tsx:45-52`),
click the "Create" button, which is a `<Link to="create">` and navigates to
`/settings/locations/shipping-option-types/create`.
3. The `/settings/locations/shipping-option-types/create` route is wired in
`route-map.tsx:66-82` as a child `{ path: "create", lazy: () =>
import("../../routes/shipping-option-types/shipping-option-type-create") }`, which renders
`ShippingOptionTypeCreate` and inside it the `CreateShippingOptionTypeForm` component
(`src/routes/shipping-option-types/shipping-option-type-create/shipping-option-type-create.tsx:4-8`).
4. Fill out the form in `CreateShippingOptionTypeForm`
(`create-shipping-option-type-form.tsx:20-63`) so that the API call
`useCreateShippingOptionType().mutateAsync` succeeds. In the `onSuccess` handler at lines
43-53,
`handleSuccess(`/settings/locations/shipping-option-types/${shipping_option_type.id}`)` is
called, which, via `RouteModalProvider.handleSuccess` in
`src/components/modals/route-modal-provider/route-provider.tsx:15-18`, calls `navigate(to,
{ replace: true, state: { isSubmitSuccessful: true } })` to
`/settings/locations/shipping-option-types/<new-id>`.
5. The router configuration under `settings -> locations` in `route-map.tsx:64-83` defines
only `path: "shipping-option-types"` (list) with a single child `path: "create"` and
**no** `path: ":id"` route. As a result, navigating to
`/settings/locations/shipping-option-types/<new-id>` does not match any child route and
will fall through to the no-match handling (404/blank) rather than showing a detail view
or returning to the list.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** packages/admin-next/dashboard/src/routes/shipping-option-types/shipping-option-type-create/components/create-shipping-option-type-form/create-shipping-option-type-form.tsx
**Line:** 51:53
**Comment:**
*Api Mismatch: The success redirect points to a shipping-option-type detail URL, but this PR only registers `shipping-option-types/create` and does not register a `shipping-option-types/:id` route. After a successful create, users will be navigated to a non-matching route (404/blank state). Redirect to an existing route (e.g. the list page) or add the missing `:id` route.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Comment on lines
+17
to
+25
| return await this.client.fetch<HttpTypes.AdminShippingOptionTypeResponse>( | ||
| `/admin/shipping-option-types`, | ||
| { | ||
| method: "POST", | ||
| headers, | ||
| body, | ||
| query, | ||
| } | ||
| ) |
There was a problem hiding this comment.
Suggestion: The new SDK resource is wired to /admin/shipping-option-types, but this repository does not expose matching admin routes (there is no shipping-option-types API handler under packages/medusa/src/api/admin). Calls through this client will therefore fail at runtime with 404s; align the SDK path with existing backend routes or add the missing backend endpoints before exposing this client. [api mismatch]
Severity Level: Critical 🚨
- ❌ Creating shipping option types in admin always returns 404.
- ❌ Listing shipping option types via SDK fails with 404.
- ⚠️ Shipping option types UI in dashboard appears broken.Steps of Reproduction ✅
1. Start the Medusa backend from `packages/medusa` so that admin API routes under
`packages/medusa/src/api/admin` are mounted; the admin routes present include
`shipping-options` but **no** `shipping-option-types` directory (confirmed by
`packages/medusa/src/api/admin` listing showing `shipping-options` only).
2. Note that the only implemented shipping-related admin route for options is
`/admin/shipping-options`, handled by
`packages/medusa/src/api/admin/shipping-options/route.ts:17-60`, which exposes `GET` and
`POST` for `shipping-options` but defines nothing for `shipping-option-types`.
3. On the client side, the JS SDK admin resource `ShippingOptionType` in
`packages/core/js-sdk/src/admin/shipping-option-type.ts:12-26` defines `create()` to call
`this.client.fetch` against the path ``/admin/shipping-option-types`` with method `POST`
(line 17-20), and similar paths for `list`, `retrieve`, `update`, and `delete`.
4. The admin dashboard uses this SDK resource via the React Query hook
`useCreateShippingOptionType` in
`packages/admin-next/dashboard/src/hooks/api/shipping-option-types.tsx:21-38`, which calls
`sdk.admin.shippingOptionType.create(payload)`; when you navigate to the shipping option
type create UI and submit the form, the browser issues `POST /admin/shipping-option-types`
to the backend, which has no matching route, resulting in an HTTP 404 Not Found instead of
creating the shipping option type.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** packages/core/js-sdk/src/admin/shipping-option-type.ts
**Line:** 17:25
**Comment:**
*Api Mismatch: The new SDK resource is wired to `/admin/shipping-option-types`, but this repository does not expose matching admin routes (there is no `shipping-option-types` API handler under `packages/medusa/src/api/admin`). Calls through this client will therefore fail at runtime with 404s; align the SDK path with existing backend routes or add the missing backend endpoints before exposing this client.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
|
CodeAnt AI finished running the review. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
User description
Summary
What — What changes are introduced in this PR?
Please provide answer here
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.
// Example usageChecklist
Please ensure the following before requesting a review:
yarn changesetand follow the promptsAdditional Context
Add any additional context, related issues, or references that might help the reviewer understand this PR.
CodeAnt-AI Description
Add shipping option type management in the admin UI
What Changed
Impact
✅ Create shipping option types from the admin✅ Remove shipping option types with confirmation✅ Browse and filter shipping option types in one place💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.