Skip to content

improve RequirePermission component #385

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

Closed
aslilac opened this issue Feb 18, 2025 · 1 comment · Fixed by coder/coder#16661
Closed

improve RequirePermission component #385

aslilac opened this issue Feb 18, 2025 · 1 comment · Fixed by coder/coder#16661
Assignees

Comments

@aslilac
Copy link
Member

aslilac commented Feb 18, 2025

Right now it just takes a boolean and redirects you to /dashboard if it's false. Not very helpful.

I think it'd be more helpful if we transformed this into a component like <Loader /> or <ErrorAlert />, something to be rendered when a user is missing permission to view a specific resource.

There are several places, especially in the organizations UI, that this could be used.

OrganizationSettingsPage.tsx is a good example of a page that should be showing a permission error, but is currently doing something worse/confusing. This could be a good test bed for developing the new component.

@aslilac
Copy link
Member Author

aslilac commented Feb 18, 2025

cc @brettkolodny since we talked about this last week

@brettkolodny brettkolodny self-assigned this Feb 21, 2025
brettkolodny added a commit to coder/coder that referenced this issue Feb 21, 2025
Closes [this issue](coder/internal#394).

At the moment this behavior can be a bit confusing, but after [this
issue is
closed](coder/internal#385 (comment))
it should be more obvious what's going on here.
brettkolodny added a commit to coder/coder that referenced this issue Feb 21, 2025
Closes [this
issue](coder/internal#385 (comment))

## New behavior

When a user ends up on a page they don't have permission to view instead
of being redirected back to _/workspaces_ they'll be met with the
un-closeable dialog below with a link to _/workspaces_.

This is similar to [this PR](#16644)
but IMO we should be making sure we are using `<RequirePermissions />`
wherever applicable and only relying on `<ErrorAlert />` as a fallback
in case there is some page we missed or endpoint we're accidentally
using.

![Screenshot 2025-02-21 at 4 50
58 PM](https://github.com/user-attachments/assets/1f986e28-d99b-425d-b67a-80bb08d5111f)
aslilac pushed a commit to coder/coder that referenced this issue Feb 27, 2025
Closes [this issue](coder/internal#394).

At the moment this behavior can be a bit confusing, but after [this
issue is
closed](coder/internal#385 (comment))
it should be more obvious what's going on here.
aslilac pushed a commit to coder/coder that referenced this issue Feb 27, 2025
Closes [this
issue](coder/internal#385 (comment))

## New behavior

When a user ends up on a page they don't have permission to view instead
of being redirected back to _/workspaces_ they'll be met with the
un-closeable dialog below with a link to _/workspaces_.

This is similar to [this PR](#16644)
but IMO we should be making sure we are using `<RequirePermissions />`
wherever applicable and only relying on `<ErrorAlert />` as a fallback
in case there is some page we missed or endpoint we're accidentally
using.

![Screenshot 2025-02-21 at 4 50
58 PM](https://github.com/user-attachments/assets/1f986e28-d99b-425d-b67a-80bb08d5111f)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants