Add user as a collaborator with permission parameter

[snadon]

Should we be able to set permissions when adding a collaborator to a repository?

The GitHub API supports it:
https://developer.github.com/v3/repos/collaborators/#add-user-as-a-collaborator

But Octokit.Net does not:
https://github.com/octokit/octokit.net/blob/master/Octokit%2FClients%2FIRepoCollaboratorsClient.cs#L44

[haacked]

Yeah, that looks like an oversight on our part. It think we should add an overload that accepts an enum with the available permission options.

[haacked]

Want to submit a PR?

[M-Zuber]

And here I was talking bad about you.

Please accept my apologies 😄

[haacked]

Please accept my apologies

LOLOLOL! No apologies necessary. You're usually correct. I happen to be taking a break to try and respond to all the OSS projects I maintain so the timing was lucky.

[ryangribble]

Just a question on this out of interest...

I think we should add an overload that accepts an enum with the available permission options.

Are you saying @haacked that this body parameter should actually be explicitly in the overloaded function, or should it be what appears to be the "usual" Octokit way where a Request object is passed in?

Just trying to get a feel for the octokit.net conventions, most I had come across seem to use the request object approach, so was surprised to see you mention adding an overload directly taking the enum paramter (unless i misunderstood)

Enum directly in Ad function

enum CollaboratorPermission { Read, Write, Admin }

Task Add(string owner, string repo, string user, CollaboratorPermission permission);

vs

Using a request object

enum CollaboratorPermission { Read, Write, Admin }

public class CollaboratorUpdate
{
   public CollaboratorPermission Permission { get; set; }
}

Task Add(string owner, string repo, string user, CollaboratorUpdate update);

[haacked]

@ryangribble you're exactly right, it should be a request object. I was being lazy with my words. 😄

[ryangribble]

Sweet, my understanding remains intact 😁

[ryangribble]

Also note that as part of this GitHub API change, they indicated that the permission parameter when creating and editing Teams is deprecated. So potentially on our NewTeam and UpdateTeam request model classes, we should mark that field as Obsolete

[shiftkey]

So potentially on our NewTeam and UpdateTeam request model classes, we should mark that field as Obsolete

👍

[ryangribble]

This was implemented in #1410 but I will raise a new issue to cover this other comment:

Also note that as part of this GitHub API change, they indicated that the permission parameter when creating and editing Teams is deprecated. So potentially on our NewTeam and UpdateTeam request model classes, we should mark that field as Obsolete