3 ms·
IME, the problem with the GraphQL API is that it does a poor job of indicating where permissions came from, and you have to fall back to bad heuristics. For ex
by LukeShu 4y ago
IME, the problem with the GraphQL API is that it does a poor job of indicating where permissions came from, and you have to fall back to bad heuristics.
For example, if team="company" has "READ", and team="company/dev" has "WRITE", and Bob is in team="company/dev" but not team="company", then Bob will have both "READ" and "WRITE" because of his membership in team="company/dev"; the API will give no indication that the "READ" indirectly came from team="company".
Also, the permissions that the PAT needs in order for GraphQL to even list those things is excessive.
Anyway, here's my audit script for such things: https://github.com/datawire/collaborators https://github.com/datawire/collaborators
- megamorf 4y agoThat's actually incorrect. Check out this query: https://gist.github.com/megamorf/9c105ac9cc13a93b5449a7b683dc9ae4 https://gist.github.com/megamorf/9c105ac9cc13a93b5449a7b683d... I have added two output examples. One for when you only want to find users that have been directly assigned to a repo (DIRECT) and one that shows how their roles and team memberships decide what permissions they have on a repo.
- LukeShu 4y agoIf they've fixed it in the last 5 months, then hooray.
- sigio 4y agoHaving write already implies that you have read, it't not something related to being in a team with read, it's just that write always gives you read. The permission levels are pull(read), triage(read+issues/pr's), push(read+write), maintain, and admin
- LukeShu 4y ago> Having write already implies that you have read Yes, but if it's just being implied then it won't list "READ" separately in the "permissionSources", it will just list "WRITE".