Update Collaborator Permission #24738
-
Is there any way to update a collaborators permission on an organization repository via the v3 (or even v4) API? I cannot find any way to do this and it would very much help me enforce assignment deadlines in GitHub Classroom, since Classroom does not do anything in terms of deadline enforcement. I can make the switch for student collaborators from Write to Read permissions just fine on the website but would be quite cumbersome to do that for 70+ repositories. |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 1 reply
-
Okay, so this turns out to be an API documentation issue because: https://developer.github.com/v3/repos/collaborators/#add-user-as-a-collaborator Nowhere in the docs here is it mentioned that this endpoint can also update the permissions on existing collaborators, although it is mentioned in the Octokit library docs: https://github.com/octokit/octokit.rb/blob/14bb1a1d4fec8d2250dc6f6b9cb2d446a0332d58/lib/octokit/client/repositories.rb#L337 But, even more confusingly, the given permission levels do not match the levels shown on the GitHub website. There are actually five permission levels, not three: Read, Triage, Write, Maintain, Admin. Even worse , when hitting the endpoint using the permissions “Triage”, “Maintain” or “Admin”, they successfully modify the existing collaborator permissions. But, when using what you would might expect to work (“Read” or “Write”) it will fail. You need to use the permissions “Pull” (which is read-only access or “Read” permissions on the website) or “Push” (which is “Write” permissions on the website) for this to work properly. So either the permission names on the GitHub website need to be changed, or the documentation for the API needs to updated to explain that:
Though, it would be really awesome to allow “Read” and “Write” on this endpoint as alises for the currently established names (according to the API anyways) to maybe save someone down the line a huge, hours-long headache. |
Beta Was this translation helpful? Give feedback.
-
This was very useful. Working with the API to add collaborators I have found that setting the initial permission level doesn’t work. Have you seen and/or solved that issue. permission=pull doesn’t set the initial level to Read in my experience. Thanks |
Beta Was this translation helpful? Give feedback.
-
I haven’t been able to assign “pull” access. Not initially, and not with later calls. Push access works fine. Haven’t tried any others. |
Beta Was this translation helpful? Give feedback.
-
It’s a bit confusing. If you look at the documentation it says: See the So instead of specifying
If you do that, the newly added collaborator will get the Read role. |
Beta Was this translation helpful? Give feedback.
-
It is very confusing. Different semantics are used for the website UI but the API is also inconsistent: When POST'ing a new team permission with permission 'maintain' to |
Beta Was this translation helpful? Give feedback.
Okay, so this turns out to be an API documentation issue because: https://developer.github.com/v3/repos/collaborators/#add-user-as-a-collaborator
Nowhere in the docs here is it mentioned that this endpoint can also update the permissions on existing collaborators, although it is mentioned in the Octokit library docs: https://github.com/octokit/octokit.rb/blob/14bb1a1d4fec8d2250dc6f6b9cb2d446a0332d58/lib/octokit/client/repositories.rb#L337
But, even more confusingly, the given permission levels do not match the levels shown on the GitHub website. There are actually five permission levels, not three: Read, Triage, Write, Maintain, Admin.
Even worse , when hitting the endpoint using the perm…