Using GraphQL API, when trying to get collaborators for all repositories in my organization, for one repository that was archived I get the error: “Must have push access to view repository collaborators.”. Since the repository is private and has proprietary code I still want to see users within our organization who have access to the repository and can see the code (direct access or external collaborators, not through Team membership). Is there a way to get the list through the API?
Hi hi @bskidan
Collaborators are users added to the repository by an admin and this information is only available to the admin via the repository’s settings page or those with push access via the API.
Is it possible that
contributors are what you might want to identify?
Let us know if this is useful information.
Thanks for replying. The link you’ve posted points to the REST API, I’m actually using GraphQL version (v4), since I need to know the detailed permissions, like “MAINTAIN”, which are only available in v4. I couldn’t find ‘contributors’ in the GraphQL API, and I’m pretty sure that ‘collaborators’ is what I’m after. Here is what I’m trying to do:
I want to audit all access to all of the repositories in my organization by all users (direct access, via teams, or outside collaborators) in one report. I want to see the same information as in the repository’s settings page, but in one place for all repos.
I use admin user to query the API, which has access to all the repositories, and I can see everything that I need except the collaborators on the archived repositories, even though my user has admin access to those repositories. I believe that the reason is that the archived repository is ‘read-only’ thus there is no push access, even though my user has admin permissions to the repo. However I do need to know users who can see my code.
So I guess the question is:
- Can the “push access” requirement be relieved?
- Or is there another way to see (via GraphQL API) who has access to my archived repositories?
Hey @bskidan – thanks so much for restating your use case.
The reason I linked to v3, is because the same is not available in GraphQL.
Though, the archived behavior is more clearly the concern than how I originally perceived your post. Basically, I misread what you wrote and thanks again for rephrasing.
Let me see if I can dig around for a better answer for you!
Hey again @bskidan … wow… it happens every now and then, but it’s happened this time. Not only is this something that GitHub has been aware of, it’s something I’ve been aware of.
I have no excuse as to why I didn’t catch this in my initial response, but I’m reporting it now.
We have an open internal issue, on this exact behavior. It is not expected, and I’ve made sure to add this post to our issue for continued tracking.
Right now, I have no ETA on a fix, but you should be able to leverage REST:
…as a temporary workaround.
Though I certainly understand that if v4/GraphQL is the preferred option in your tooling, that it is less than helpful.
At the moment, this is where we are and I thank you or your patience, and for reporting this in our Community.
@nethgato thank for finding this out, I’ll use both APIs simultaneously until this is resolved