26. User Roles & Permissions
[← Audit & Change History]/25-audit-and-change-history/ · [Index]/00-index/
26. User Roles & Permissions
Verified against: settings-layout.tsx (source-read directly — found the real, gated
Roles/Policies settings entries), and a search of medusa-config.ts / .env / .env.example
for any feature-flag configuration (none found).
Today’s reality
One undifferentiated admin login per environment — already established in [Section 1]/01-getting-started/#admin-roles and [Section 2]/02-admin-dashboard/#dashboard-overview. Anyone with a login can do anything an admin can do. There is no per-user restriction of any kind in use today.
A real capability was found — correcting the premise of this section
IMPORTANT — this changes the shape of what “proposed roles” should mean. While verifying the Settings sidebar for [Section 2]/02-admin-dashboard/#settings, the dashboard’s own source revealed that Medusa v2 has real Roles and Policies settings screens already built into this exact version of the admin (
/settings/roles,/settings/policies) — gated behind a feature flag (useFeatureFlag("rbac")) and a permission check (hasPermission("rbac_role:read")). This is not a hypothetical future Medusa feature — it’s present in the@medusajs/dashboard2.18.0 package this project already depends on.What wasn’t confirmed: whether this feature flag is actually turned on for this project. A search of
medusa-config.ts, the local.env, and.env.examplefound no reference to an RBAC or feature-flag setting at all — meaning it’s very likely off (unconfigured), but the exact mechanism for turning it on was not determined as part of this wiki. That would need a developer to check Medusa’s own feature-flag documentation.
This matters because it changes the real recommendation: before designing a bespoke roles system from scratch, check whether enabling Medusa’s own built-in RBAC gets this business most of the way there. That may be far less work than it looks.
Roles — still proposed, not real, either way
Whether or not RBAC gets enabled, no actual roles or policies have been defined for this business. The list below (carried over from the original wiki brief) is marked [PROPOSED] — a suggested starting point, not a decided structure:
| Proposed role | Should be able to modify (based on this wiki’s real module boundaries) |
|---|---|
| Super Admin | Everything, including Settings |
| Admin | Everything except system-level Settings (Regions, Tax Regions, API Keys) |
| Inventory Manager | [Inventory]/05-inventory-management/, [Stock Audit]/06-stock-audit/ — not Pricing or Status |
| Order Manager | [Orders]/08-order-management/, [Refunds & Returns]/15-refunds-and-returns/ — not Product data |
| Content Manager | [Product Editing]/19-product-editing/‘s “safe changes” only (description, images) — explicitly not Price/SKU/Inventory/HSN ([Section 19]/19-product-editing/#sensitive-changes) |
| Customer Support | [Customer Management]/10-customer-management/, read-only on Orders |
| Read Only | View everything, change nothing |
[PROPOSED] — none of this is enforced by the system today, regardless of which path (enabling built-in RBAC vs. custom development) the business eventually takes.
What each role should NOT be able to modify — the genuinely sensitive set
Cross-referencing what this wiki has already flagged as consequential:
- Price, SKU, Inventory, HSN/GST metadata — [Section 19]/19-product-editing/#sensitive-changes
- GST_SELLER_GSTIN and other seller config — [Section 16]/16-invoicing/#system-capability-vs-businesslegal-configuration
- Region/Tax Region settings — flagged as store-wide-impact in [Section 2]/02-admin-dashboard/#settings
- Refund/Cancel actions — real money and real GST credit-note consequences ([Section 15]/15-refunds-and-returns/)
Any real permission design should start by restricting these, even before a full role matrix exists.
[← Audit & Change History]/25-audit-and-change-history/ · [Index]/00-index/ · [Next: Glossary →]/27-glossary/