chore: implement databased backend for custom roles #13295
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
a75d657 to
2187c33
Compare
2187c33 to
1674885
Compare
4060c07 to
c58a6fd
Compare
3b8ae70 to
65ec798
Compare
88ca559 to
96d1527
Compare
| -- name is globally unique. Org scoped roles have their orgid appended | ||
| -- like: "name":"organization-admin:bbe8c156-c61e-4d36-b91e-697c6b1477e8" | ||
| name text primary key, |
There was a problem hiding this comment.
What's the benefit of squashing the OrgID into the name?
Will this not make it more difficult if we want to filter roles by org?
Why not have it as a separate column?
There was a problem hiding this comment.
I was thinking about this, and I'm not 100% sure at present. Maybe another column is better.
This PR only addresses site wide permissions, and once multi-org is a bit farther, I will add org permissions. When I get to that step 2, I feel I'll be able to make a better judgement call.
Regardless, the name will likely include the org id even if there is an org column. Because that is the name of the role. Even our builtins have the org appended, and the ui just ignores it.
| ActionDelete: actDef("ability to unassign roles"), | ||
| ActionCreate: actDef("ability to create/delete/edit custom roles"), |
There was a problem hiding this comment.
Suggestion, probably out of scope: should we have a separate RBAC resource UserRoleAssignment instead?
There was a problem hiding this comment.
I think we can have 1 resource for site role assignment and create, and 1 resource for org assignment and create. But I am going to push this until I do the UX imo
| Name: "CreateCustomRole", | ||
| Actions: []policy.Action{policy.ActionCreate}, | ||
| Resource: rbac.ResourceAssignRole, | ||
| AuthorizeMap: map[bool][]authSubject{ | ||
| true: {owner}, | ||
| false: {userAdmin, orgAdmin, orgMemberMe, otherOrgAdmin, otherOrgMember, memberMe, templateAdmin}, | ||
| }, |
There was a problem hiding this comment.
👍 This is fine for now, but I can potentially see folks wanting to allow UserAdmins / OrgAdmins some level of control in future...
...maybe they just need to make a custom role? 😄
There was a problem hiding this comment.
Lol, yea I'm going to push this until I get to the UX. For this PR stack, I'm just getting custom roles to work.
Once I start building UX, I will revist who exactly should have this permission. But it could just be a custom role too as you said 🤷♂️
96d1527 to
992c845
Compare
Includes db schema and dbauthz layer for upserting custom roles.
For now, only owners can assign custom roles
992c845 to
a6996f6
Compare
Includes db schema and dbauthz layer for upserting custom roles. Unit test in
customroles_test.goverify against escalating permissions through this feature.