Support for Repository.collaborators with permissions and affiliation. #730

AndreasBackx · 2017-09-16T15:24:43Z

Currently there is a Repository.collaborators method, but the User objects it returns do not use the added permissions key that the endpoint returns:

"permissions": {
  "pull": true,
  "push": true,
  "admin": false
}

What I would propose is to add repos/collaborator.py or remain to use users.py with a Collaborator class that inherits from _User and let _User use the permissions in _update_attributes:

self.permissions = self._get_attribute(user, 'permissions')

What I notice while writing this issue, is that _User does not user self._get_attribute. Maybe this can be added in the same commit, just for completeness sake so it's used everywhere as it was intended iirc.

We can also add the named parameter affiliation to Repository.collaborators(). It'll throw a ValueError when the value is not valid (not in ['outside', 'direct', 'all'], perhaps None as well based on the default value). Do we give affiliation the default value of None or the default value of 'all' like it is in the documentation? None would not pass anything and therefore if it were to get changed on GitHub's end, the result will be different. I'd go for 'all'.

I'm up for creating the PR once we agree on what needs to be changed.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

The text was updated successfully, but these errors were encountered:

…ion). See sigmavirus24#730 for some background information. This still fails 1 test because the cassette Repository_collaborators.json needs to be updated with the permissions as it somehow does not contain that information. The GitHub API does say that it should be there, but the recording is from 2014 so perhaps it wasn't returned back then. Note that I have currently put the named parameter `affiliation` at the front of the arguments in `Repository.collaborators`. I did this to be in line with the other similar iterators. This can be moved to the back, but I assume some backwards-incompatible changes are fine for 1.0.0? This uses separate classes for the specific User object uses as I understood the idea was from sigmavirus24#670.

…ion). See sigmavirus24#730 for some background information. Note that I have currently put the named parameter `affiliation` at the front of the arguments in `Repository.collaborators`. I did this to be in line with the other similar iterators. This can be moved to the back, but I assume some backwards-incompatible changes are fine for 1.0.0? This uses separate classes for the specific User object uses as I understood the idea was from sigmavirus24#670.

AndreasBackx mentioned this issue Sep 18, 2017

Added Collaborator, Contributor and Repository.collaborators(affiliation) #731

Merged

AndreasBackx closed this as completed Jun 16, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Support for Repository.collaborators with permissions and affiliation. #730

Support for Repository.collaborators with permissions and affiliation. #730

Support for Repository.collaborators with permissions and affiliation. #730

Support for Repository.collaborators with permissions and affiliation. #730

Comments

Uh oh!