fix: restrict edit schedule access #2698
Conversation
|
I need some help to reproduce this flow where a user has read access to another workspace but no update access, so I can properly test it. |
0acd837 to
73cbad7
Compare
| } | ||
|
|
||
| // Theoretically impossible - log and bail |
There was a problem hiding this comment.
Potentially unpopular opinion up for debate: I think I'd rather the user run into an error state here so I know we've reached the 'theoretically impossible' state and we have a bug on their hands.
There was a problem hiding this comment.
I think we should still provide our users a way to get out of the error state. For example, in this case we are just redirecting to /. Maybe we can show them a generic error like "This should not have happened. Go to workspaces."
There was a problem hiding this comment.
Additionally, we can also show them the Report an issue link opening in new tab.
|
This looks good to me! I also am not sure how to test. Snapshots look good, though, so I'll approve. |
73cbad7 to
8870ae3
Compare
|
I was able to test this flow by editing the permissions for // rbac/builtin.go#L145
{
ResourceType: ResourceWorkspace.Type,
ResourceID: "*",
Action: ActionRead,
}, |
bd64519 to
2233bdc
Compare
f566375 to
2d2522d
Compare
This PR restricts the link to editing workspace schedule and the actual page access to users with update access to the workspace.
Subtasks
Edit schedulelink for users without update access.Fixes #2655
Screenshots