Don't show add/edit role UI to non-admins

[david-crespo]

If you don't have permission to update the policy on a resource, you can currently still see the add, edit, and delete buttons and open and submit the corresponding forms (you get 403s back from the API). We should check the user's role and not show them that stuff unless they're an admin. I believe viewers can still see the policy, however.

So: show the policy, but not the edit button.

[david-crespo]

This is pretty easy to do, so we may move it into MVP even though the console isn't broken without it.

[benjaminleonard]

Isn't this page only visible to admins anyway?

[david-crespo]

I need to go make sure, but I don't think that's true. I think in general the idea is that if you have the view permission on a resource, you also have the view policy permission.

[david-crespo]

Confirmed on https://oxide-no-fleet.sys.r3.oxide-preview.com where we have collaborator but not silo admin that the page is visible, and attempts to change anything 403 as expected. I think we should still do this. UI rework issues like #1358 are orthogonal as far as I can tell — they still have add/edit buttons.

I'm not sure the best way to tell the current user's role on the silo or project. We can fetch policy_view, which is the silo policy, but whether the current user has a given effective role depends on their group memberships and we probably shouldn't be resolving that on the client. You could imagine /me including effective role on the current silo alongside display name and silo name, but that wouldn't solve the problem for the project.

I also noticed something weird about project policy permissions. In theory I have silo collaborator only, as I am not in the preview-support group here. And yet I can add a role on the project through the form. That seems like an API bug.

[david-crespo]

Another use case for this came up in #2915 on the system update page. Fleet viewers can view the update status and list TUF repos, but only a fleet admin can set them (permissions snapshot). the target release. Right now we don't indicate that in the UI at all and the user would have to attempt it and then get the 403 back from the API in order to find out that they can't do it.

That's tolerable, but might be nice to disable parts of the UI if we know they're not a fleet admin. Right now the current user response only has fleetViewer and siloAdmin fields. We'd have to add a fleetAdmin field. Another wrinkle here is that these role checks are not as literal as they sound (as indicated by the permissions snapshot) — really there a bunch of individual authz resources with their own logic, and the high-level roles tend to confer permissions in predictable ways, but it is not guaranteed and not always fully consistent.

It would be better if, for a given set of actions, we could just ask the API if the current user can do them. Unfortunately even that is difficult to imagine because often permissions are not governed solely by the category of the resource, but by the particular identity of the resource. So, for example, things could be set up so that one TUF repo is available to a user to set as the target release and another TUF repo is not. And in order to find out about what the user can do, we would have to ask about every single one, not "can I set target releases?" in general.