You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 12, 2019. It is now read-only.
We have some heuristic to create a default filter on clients in the client inspector...
I suggest we make a checkbox "show clients you can manage" (or some better wording).
But it being so that it uses the scopes you have to determine which clientIds you can modify, and only shows you those clients... This requires the inspector to understand scopes used by taskcluster-auth.
I don't object, in principle, to tools modeling the scope requirements for API calls. I like the idea of a button, too.
Currenty we don't ever look at the user's scopes and adjust the UI on that basis [*] -- we just blindly make the API call and show the resulting error. I think our users would appreciate changing that behavior, but if we do so we should do it consistently through all of the tools, so users are not forced to remember where scopes are accounted for and where they are not.
I think @eliperelman is considering changing this in the refactor?
[*] actually, I think private artfacts are an exception..
We have some heuristic to create a default filter on clients in the client inspector...
I suggest we make a checkbox "show clients you can manage" (or some better wording).
But it being so that it uses the scopes you have to determine which clientIds you can modify, and only shows you those clients... This requires the inspector to understand scopes used by taskcluster-auth.
Note, there is a proposal to simplify these scopes in: taskcluster/taskcluster-rfcs#99
The text was updated successfully, but these errors were encountered: