4 ms·

Unfortunately, it leaves a lot to be desired. I've actually had to do a fair bit of GH access reporting myself recently and I can recommend the GraphQL API as i

Unfortunately, it leaves a lot to be desired. I've actually had to do a fair bit of GH access reporting myself recently and I can recommend the GraphQL API as it allows you to properly list direct and indirect permissions on repositories (org + team + direct collaborator) that are alot harder to do with the REST API due to its inconsistent permissions model.

benfrancom 4y ago
Nice, do you have anything you can share?
pquerna 4y ago
i've also been working on a similar tool -- working towards open sourcing it too. would you be interested in taking a look? paul.quenra at conductorone com
- kataklasm 4y ago
  I believe you might have a typo in your mail? Just making sure you're not missing out on something useful :)
  - pquerna 4y ago
    thank you -- can't edit it anymore, but paul.querna (spelled my own name wrong)
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 ago
  That'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 ago
    If they've fixed it in the last 5 months, then hooray.
- sigio 4y ago
  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 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".

benfrancom 4y ago

Nice, do you have anything you can share?

pquerna 4y ago

i've also been working on a similar tool -- working towards open sourcing it too. would you be interested in taking a look? paul.quenra at conductorone com

kataklasm 4y ago
I believe you might have a typo in your mail? Just making sure you're not missing out on something useful :)
- pquerna 4y ago
  thank you -- can't edit it anymore, but paul.querna (spelled my own name wrong)

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 ago
That'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 ago
  If they've fixed it in the last 5 months, then hooray.
sigio 4y ago
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 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".