[LukeShu]

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

[megamorf]

That's actually incorrect. Check out this query: 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]

If they've fixed it in the last 5 months, then hooray.

[sigio]

Having 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]

> 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".