-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
chore(rbac): user link and utils #14320
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: feat/rbac-module
Are you sure you want to change the base?
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 8 Skipped Deployments
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good, I know it's probably not done, but I gave it a read 😄
| * Validates that a user has access to all the policies they are trying to assign. | ||
| * A user can only create roles and add policies that they themselves have access to. | ||
| */ | ||
| export const validateUserPermissionsStep = createStep( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thought(non-blocking): realistically, the flow would probably be that certain users, e.g. admins, have the manage:roles and manage:policies permissions and are therefore the only ones capable of assigning user roles ... don't you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, but even these can only assign permissions that they have themselves.
…into chore/rbac-user
…into chore/rbac-user
…into chore/rbac-user
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR is being reviewed by Cursor Bugbot
Details
Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.
To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.
packages/core/core-flows/src/rbac/workflows/update-rbac-roles.ts
Outdated
Show resolved
Hide resolved
| `Cannot update role parent relationship: this would create a circular dependency (role_id: ${role_id}, parent_id: ${parent_id})` | ||
| ) | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Circular dependency check fails when role_id omitted in update
In updateRbacRoleParents, when an update payload contains only parent_id without role_id, the destructured role_id is undefined. This causes the self-reference check (role_id === parent_id) to always pass, and checkForCycle(undefined, parent_id, ...) is called with an undefined roleId. The SQL query then looks for id = NULL which never matches, so the cycle check incorrectly returns false. To properly validate, the method needs to fetch the existing record's role_id when it's not provided in the update payload.
| allPolicies.push({ | ||
| role_id: role.id, | ||
| scope_id: policy_id, | ||
| policy_id: policyId, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update workflow adds policies instead of replacing them
The update workflow uses createRbacRolePoliciesStep for policy_ids, which only adds new policy associations. This is inconsistent with parent_ids, which uses setRoleParentStep to fully replace existing parents. When updating a role with policy_ids that overlap with existing associations, the unique index on (role_id, policy_id) causes a database constraint violation. The workflow needs a "set" operation for policies similar to how parents are handled, to delete removed policies and only create new ones.
Defining Policies with
definePolicyCustom policies are defined using the
definePolicyhelper, which registers them globally for use in roles and permission checks.In Medusa projects, place policy definition files inside a policies folder (e.g., src/policies/my-policy.ts). These are automatically discovered and loaded during application startup, similar to links, workflows, and other modular components. Registered policies are synced to the database on start.
Example 1: Single policy
Example 2: Multiple policies in one file
Example 3: Policy for a custom resource
hasPermissionfunction checks if the provided role(s) grant permission for the specified action(s).Example 1: Single role and single action
Example 2: Multiple roles and multiple actions
Note
Introduces RBAC feature flag with policy discovery/registry and sync, migrates role inheritance to role parents and
policy_idassociations, adds permission checks and JWT role embedding, updates workflows/APIs, and adds link/types generation with comprehensive tests.rbacand module wiring; enable/disable via env.definePolicy,Policy/Resource/Operation) with directory discovery and DB sync on app start; generatepolicy-bindings.d.ts.rbac_role_parent), and switch role-policy associations fromscope_idtopolicy_id.hasPermissionutil for role-based action checks.resource/operationto lowercase.parent_idsandpolicy_idand validate user permissions.rbac_role_parent; updaterbac_role_policyschema/indices.policy_id; delete handled directly via service.policiesLoader; load policies from project/plugins;medusa startgenerates container, GraphQL, and policy types.UserRbacRolelink and expose roles onuserentity.Written by Cursor Bugbot for commit 5d3d54b. This will update automatically on new commits. Configure here.