Add explanation for built-in user - #3259
Conversation
A little more involved than it needs to be, but I think it's nice to be more explicit about how we're coming to conclusions on names.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| const aGroup = Number(a.identityType === 'silo_group') | ||
| const bGroup = Number(b.identityType === 'silo_group') | ||
| return bGroup - aGroup || a.name.localeCompare(b.name) | ||
| return bGroup - aGroup || displayUserName(a.name).localeCompare(displayUserName(b.name)) |
There was a problem hiding this comment.
we could use this opportunity to push uuid & built-in user names to the bottom (or top?) but for now i figured i'd leave it be
| )) | ||
| .with({ kind: 'built-in' }, () => ( | ||
| <TipIcon> | ||
| This is a system account for bootstrapping before configuring your |
There was a problem hiding this comment.
my "day 2 at this company" understanding of the test user!
|
Good start. We'll need to work on the copy. As of oxidecomputer/omicron#10064, I think there should be no deleterious effect of the user deleting the role assignment on this built-in user, so (assuming we confirm that) we may actually want to encourage them to do that. |
|
current state is that i'm pretty darn confident you can delete the role assignment, but that a nexus restart is just going to reintroduce it, so the message isn't too useful, unless we change nexus to stop populating it on startup. although, perhaps that's not reasonable to do until built-in silo users are fully unnecessary, since it seems quite possible that even after setting up a silo with an idp, you could remove it and once again need the built-in user? |
2 participants
This PR tries to enrich the "name" field on users/groups a little bit to distinguish between the two reasons you'd find a nameless user: