Skip to content

Conversation

@charliepark
Copy link
Contributor

Once oxidecomputer/omicron#9299 is merged to Omicron, we'll want to use the new permissions in the web console as well. This PR bumps Omicron (will want to bump again before merging this) and also redesigns the access forms to use radio buttons, which allow us to show all options on the screen, with descriptions of what each role enables.

Screenshot 2025-10-31 at 1 06 09 PM

@vercel
Copy link

vercel bot commented Oct 31, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Updated (UTC)
console Ready Ready Preview Nov 3, 2025 4:30pm

the div wrapping the radios was messing up the way RadioFieldDyn passes
checked state to its child radios because they're expected to be direct
children
@benjaminleonard
Copy link
Contributor

This should be a regular modal rather than a side modal, since it's a single input / action.

Spacing seems inconsistent here, not sure why.
image

I can take a quick look at the design now.

@charliepark
Copy link
Contributor Author

This should be a regular modal rather than a side modal, since it's a single input / action.

Okay; just for clarity, does the "Add user" modal remain a side modal, because you have to enter the name and select the role, or is it conceptually a single input and should be a regular modal?

@benjaminleonard
Copy link
Contributor

I could go either way, my initial designs had it as a side modal but that's because I had the ability to add multiple users in one go. It's sort of a fuzzy rule based on length.

Also, I could see the edit role being part of a side modal but only if it was part of a broader edit user / user view modal.

image

Let's use a regular modal for both for now.

@charliepark
Copy link
Contributor Author

Current state, though open to tweaks on spacing, etc.
Screenshot 2025-11-03 at 6 12 00 AM

name="roleName"
label={`${scope} role`}
required
control={control as Control<AddUserValues>}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this doesn't work without the cast: RadioFieldProps has this too-clever parseValue thing and then RadioFieldDynProps omits parseValue. I think this may be a TS bug. Here's a repro of the issue stripped down to two lines: https://tsplay.dev/ND13Om

I have two workarounds, one of which is to turn parseValue into a regular optional, the other is to inline theRadioFieldDyn call in the RoleRadioField call sites. I think I prefer the latter. I'll figure it out.

} & (PathValue<TFieldValues, TName> extends string // this is wild lmao
? { parseValue?: never }
: {
/**
* Radio field values are always strings internally, but sometimes we
* want them to represent something else, like a number. `parseValue` is
* required if and only if the value type does not extend `string`.
*/
parseValue: (str: string) => PathValue<TFieldValues, TName>
})

export type RadioFieldDynProps<
TFieldValues extends FieldValues,
TName extends FieldPath<TFieldValues>,
> = Omit<RadioFieldProps<TFieldValues, TName>, 'parseValue' | 'items'> & {
children: RadioElt | RadioElt[]
}

@benjaminleonard
Copy link
Contributor

The spacing bug seems to be that the checkbox component needs shrink-0 so it doesn't get pushed with the longer label and description

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 this pull request may close these issues.

4 participants