-
Notifications
You must be signed in to change notification settings - Fork 883
fix: ensure user admins can always see users table #15226
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
Conversation
@@ -116,7 +126,6 @@ export const permissionsToCheck = { | |||
[checks.viewAnyGroup]: { | |||
object: { | |||
resource_type: "group", | |||
org_id: "any", |
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.
Ended up deleting this because the property wasn't compatible. It also didn't seem to be used anywhere
@Emyrk Not sure if we should update the types so that this can be added back
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.
Can you delete this unused check then?
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.
Oh, sorry – I meant that the org_id
property specifically didn't seem to be used anywhere
type ManagementSettingsValue = Readonly<{ | ||
deploymentValues: DeploymentConfig | undefined; | ||
}>; |
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.
Removed most of the properties for two reasons:
- The
Sidebar
component depended on the context provider. So it was impossible to show the sidebar at all times, because if you moved it outside the provider, it would blow up - It's duplicate state that was already accessible via other hooks. Felt better to beef those up, because then other pages would be able to benefit, too
@@ -130,10 +126,11 @@ const DeploymentSettingsNavigation: FC<DeploymentSettingsNavigationProps> = ({ | |||
{permissions.viewDeploymentValues && ( | |||
<SidebarNavSubItem href="network">Network</SidebarNavSubItem> | |||
)} | |||
{/* All users can view workspace regions. */} |
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 actually wasn't true, so Steven and I had to put this behind a condition
site/src/router.tsx
Outdated
{/** | ||
* @todo 2024-10-24 - MES - The current deployment page is | ||
* almost empty, which isn't great for two reasons: | ||
* | ||
* 1. Even though none of our links lead to the page, the | ||
* user is still able to navigate straight there by | ||
* accident. | ||
* 2. If the user has access to some deployment pages, but | ||
* tries accessing one that they shouldn't be able to | ||
* access, we have to reroute them somewhere. The base | ||
* deployment route is the only safe option, because not | ||
* even the general page is accessible by everyone. | ||
* | ||
* Should update the base /deployment page so that there's | ||
* something there, but that will require coordination with | ||
* the design team. | ||
*/} |
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.
I really wish I could've added some content here, but it felt really out of scope. At the very least, better a janky experience over a broken one
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.
Maybe something to think together with @chrifro
Will look into the failing E2E tests first thing tomorrow morning |
@@ -3,18 +3,20 @@ import { Navigate } from "react-router-dom"; | |||
|
|||
export interface RequirePermissionProps { | |||
children?: ReactNode; | |||
isFeatureVisible: boolean; | |||
permitted: boolean; | |||
unpermittedRedirect?: `/${string}`; |
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.
Nit: Maybe redirectOnFailure
?
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.
I didn’t find any concerns, so I’m approving it. It would be good to have someone else do a second check and QA.
@aslilac Would you be able to do a second glance-over for this PR? Like a third of the total lines of code is just a new unit test file; there weren't huge swashes of changes |
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.
Permissions LG. @Parkreiner and I did them in discord together 👍
pls don't merge yet, I'm still reviewing |
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.
I'm not a fan of moving state that can be localized up to a global provider where it will never be useful. I agree that the state currently being handled by ManagementSettingsLayout
needs to be split back into two separate providers, but we shouldn't do it by misusing an existing provider, we should just reintroduce a DeploymentSettingsProvider
.
if (!isFeatureVisible) { | ||
return <Navigate to="/workspaces" />; | ||
if (!permitted) { | ||
return <Navigate to={unpermittedRedirect} replace />; |
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.
I kinda feel like this is a bad abstraction. The user has to pass is the condition and the URL to navigate to, so why would we not want to just do
if (!allowedToSeeThing) {
return <Navigate to="/some/place" replace />
}
...at the origin?
I don't think redirects like this should really be the job of this component–especially since I think it's a better user story to show an error page if they wound up somewhere they shouldn't be instead of just shoving them somewhere they didn't expect to go with no explaination
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.
No, that's a really fair call. I wouldn't be opposed to ripping this out, since the abstraction is so shallow
import { selectFeatureVisibility } from "./entitlements"; | ||
|
||
export interface DashboardValue { | ||
entitlements: Entitlements; | ||
experiments: Experiments; | ||
appearance: AppearanceConfig; | ||
organizations: readonly Organization[]; | ||
activeOrganization: Organization | undefined; |
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 value is already provided by ManagementSettingsLayout
, and the concept of a "current organization" is only relevant inside that context. no need to add this.
site/jest.setup.ts
Outdated
getRandomValues: function (buffer: Buffer) { | ||
return crypto.randomFillSync(buffer); | ||
}, | ||
getRandomValues: (b: NodeJS.ArrayBufferView) => crypto.randomFillSync(b), |
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.
you could even take this a step further and just say...
getRandomValues: (b: NodeJS.ArrayBufferView) => crypto.randomFillSync(b), | |
getRandomValues: crypto.randomFillSync, |
viewNotificationTemplate: "viewNotificationTemplate", | ||
} as const satisfies Record<string, string>; | ||
|
||
type PermissionType = keyof typeof checks; |
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 is technically incorrect, and only working because all of the key value pairs are symmetrical. what you really want is...
type PermissionType = keyof typeof checks; | |
type PermissionType = typeof checks[keyof typeof checks]; |
@@ -48,61 +47,134 @@ export const canEditOrganization = ( | |||
); | |||
}; | |||
|
|||
export const isManagementRoutePermitted = ( |
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.
yeah, this feels like total overkill to me, especially for a quick patch this is a huge departure from how we handle this sort of thing everywhere else in the app
@aslilac This should be good to go, but I got sloppy with the branch merging compared to the one I did for your draft branch. Let me know if you'd rather just reopen that draft PR, just to be on the super-safe side I'll be looking at GitHub later tonight to try getting either one of the PRs merged in. If you do choose to go with your draft PR, you can review it as normal, and then I can approve it if you do |
|
||
const ready = !!(templatesByGroup.data && dispatchMethods.data); |
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.
nit: prefer Boolean(…)
over !!(…)
, it makes it much clearer that you want a boolean cast
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.
So do I, but for some reason, when I tried to change things, it wasn't doing anything with type narrowing
Closes #15212
Changes made
/deployment
and/organizations
routes, and updated layout logic forManagementSettingsLayout
layout component. This ensures the sidebar is always visible, even if request errors happenuseAuthenticated
hookpermissions.tsx
file, to give more granularity, and added missing type-checkingRequirePermissions
component to let it redirect users anywhere