Skip to content

Add effective fleet and silo role to /v1/me response #8515

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

david-crespo
Copy link
Contributor

This is a weird idea I had a few months ago. I decided to polish it up because we might actually need it now that we have some silo admin-specific operations like #8479 or #8214.

Right now, when the web console wants to know whether a user is a fleet viewer in order to decide whether to show them the fleet-level side of the UI, we try to hit a fleet-viewer only GET endpoint and see if it 200s or not (see console source for that). That is silly but has worked fine for a long time. However, other roles there is no obvious way to do that, plus it gets extra silly if you're hitting 5 different endpoints to figure something out that the API could just tell you.

So here, I add some plumbing that lets us add

fleet_role: Option<String>,
silo_role: Option<String>,

to the /v1/me response, which heretofore only includes user ID, user display name, silo ID, and silo name. The plumbing is definitely hacked in, especially the role ordering, but based on my tests, it does seem to work.

"collaborator" => 2,
"admin" => 3,
_ => 0,
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is the worst part

Copy link
Contributor Author

@david-crespo david-crespo Jul 3, 2025

Choose a reason for hiding this comment

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

My other random PR #7477 is relevant here, especially the suggestion of representing roles as an enum rather than a string (now that we know roles don't need to be free-form), which would make this a lot less hacky.

@david-crespo david-crespo force-pushed the me-resp-includes-roles branch from 4228292 to ec80f33 Compare July 3, 2025 17:55
@david-crespo david-crespo force-pushed the me-resp-includes-roles branch from ec80f33 to 1b7b3b9 Compare July 3, 2025 18:55
@david-crespo david-crespo marked this pull request as ready for review July 3, 2025 19:07
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.

1 participant