Go-github: Support preview Organization Project Permissions API

[gmlewis]

GitHub Developer API announcement:
https://developer.github.com/changes/2018-03-28-organization-project-permissions/

This would be a great PR for any new contributor to this repo or a new Go developer.
All contributions are greatly appreciated!

Feel free to volunteer for any issue, and we can send you an invite to contribute to the repo (which you then accept after you enable two-factor authentication) and the issue can be assigned to you so that others don't attempt to duplicate the work.

Please check out our CONTRIBUTING.md guide to get started.

Thank you!

[ganeshmannamal]

hello @gmlewis I would like to contribute to this issue. Thanks

[gmlewis]

Thank you, @ganeshmannamal! I've sent you an invite.

[ganeshmannamal]

thanks @gmlewis accepted

[palash25]

@gmlewis I see some PRs referenced here, has this been implemented? If not then I would like to take this up.

[gmlewis]

Thanks, @palash25. I'm assigning this issue to you. If, during your investigation of this PR, you find there is nothing left to do, please report back with your findings.

[palash25]

@gmlewis need a little help, I am confused about in which files to write the code for this issue. For the
Organization project collaborators endpoints (which use projects endpoint) should the code reside in orgs_projects.go or projects.go.

I have the same confusion with Organization projects on teams endpoints would the code go int teams.go or orgs_projects.go

[palash25]

I was thinking about putting them in projects.go and teams.go respectively. Would that be correct?

[gmlewis]

Hi @palash25, sure.

But first, can you please elaborate on which exact endpoints need to be written?
Part of resolving this issue is to investigate and determine which ones we still need.

We attempt to keep the code in this package organized as closely as possible to the GitHub Developer API documentation.

So, for example, you can see the endpoints in orgs_projects.go, projects.go, and teams.go we currently have:

$ grep fmt.Sprintf github/orgs_projects.go
    u := fmt.Sprintf("orgs/%v/projects", org)
    u := fmt.Sprintf("orgs/%v/projects", org)
$ grep fmt.Sprintf github/projects.go
    u := fmt.Sprintf("projects/%v", id)
    u := fmt.Sprintf("projects/%v", id)
    u := fmt.Sprintf("projects/%v", id)
    u := fmt.Sprintf("projects/%v/columns", projectID)
    u := fmt.Sprintf("projects/columns/%v", id)
    u := fmt.Sprintf("projects/%v/columns", projectID)
    u := fmt.Sprintf("projects/columns/%v", columnID)
    u := fmt.Sprintf("projects/columns/%v", columnID)
    u := fmt.Sprintf("projects/columns/%v/moves", columnID)
    u := fmt.Sprintf("projects/columns/%v/cards", columnID)
    u := fmt.Sprintf("projects/columns/cards/%v", columnID)
    u := fmt.Sprintf("projects/columns/%v/cards", columnID)
    u := fmt.Sprintf("projects/columns/cards/%v", cardID)
    u := fmt.Sprintf("projects/columns/cards/%v", cardID)
    u := fmt.Sprintf("projects/columns/cards/%v/moves", cardID)
$ grep fmt.Sprintf github/teams.go
    u := fmt.Sprintf("orgs/%v/teams", org)
    u := fmt.Sprintf("teams/%v", team)
    u := fmt.Sprintf("orgs/%v/teams", org)
    u := fmt.Sprintf("teams/%v", id)
    u := fmt.Sprintf("teams/%v", team)
    u := fmt.Sprintf("teams/%v/teams", teamID)
    u := fmt.Sprintf("teams/%v/repos", team)
    u := fmt.Sprintf("teams/%v/repos/%v/%v", team, owner, repo)
    u := fmt.Sprintf("teams/%v/repos/%v/%v", team, owner, repo)
    u := fmt.Sprintf("teams/%v/repos/%v/%v", team, owner, repo)

Then, depending upon the endpoints that still need to be written, we should be able to decide more easily where to put them.

Does that make sense?

[palash25]

@gmlewis These are the endpoints that I was talking about

/projects/:project_id/collaborators/:username
/teams/:team_id/projects/:project_id

I didn't find these endpoints implemented in the codebase.

[gmlewis]

OK, great. Thank you for the details.

The next thing I do is check where in the GitHub Developer API (V3) documentation these endpoints are found. In this case, we have:

/projects/:project_id/collaborators/:username on
https://developer.github.com/v3/projects/collaborators/

and
/teams/:team_id/projects/:project_id on
https://developer.github.com/v3/teams/

So it makes perfect sense to me to implement these in projects*.go and teams*.go, respectively.
The next step I take is to see if these files have been split out into sub-topics, like so:

$ ls projects*.go teams*.go
projects.go                   teams_discussion_comments_test.go  teams.go               teams_test.go
projects_test.go              teams_discussions.go               teams_members.go
teams_discussion_comments.go  teams_discussions_test.go          teams_members_test.go

and it doesn't look like we have projects_collaborators.go or a teams_projects.go... and since each one has just one single new endpoint, I don't think it is worth creating a new file for these.

Therefore, I think you are exactly right... these two new endpoints should be implemented in projects.go and teams.go, respectively.

I know you don't need all this excruciating detail... but I took the time to write all this out for future maintainers and contributors of this package once my tenure is up. :smile:

Thank you, @palash25!