Added listing outside collaborators for an organization#538
Added listing outside collaborators for an organization#538glapul wants to merge 4 commits intogoogle:masterfrom
Conversation
2fa_disabled filter is supported too.
|
Why not extend the already-existing It currently already handles the As an added bonus, it already has all the |
|
@gmlewis, that's a good idea to consider. However, I see that GitHub API really lists this as a separate endpoint. Compare:
Additionally, removing an outside collaborator is also different than removing a normal member:
Our current method for removing organization members does not take an options struct: https://godoc.org/github.com/google/go-github/github#OrganizationsService.RemoveMember So we would be forced to have a different method for removal (or add an options struct). You can also "convert member to outside collaborator". It suggests to me these things are different enough that listing them via different endpoints makes sense. While the idea of merging the listing endpoints makes sense now, I worry that future changes/additions to the API that further diverge outside collaborators and members may cause trouble for our API. What do you think? |
|
OK, I'm fine with keeping it separate then, @shurcooL. |
| @@ -0,0 +1,51 @@ | |||
| // Copyright 2016 The go-github AUTHORS. All rights reserved. | |||
| } | ||
|
|
||
| req, err := s.client.NewRequest("GET", u, nil) | ||
|
|
There was a problem hiding this comment.
nix blank line between API call and err check
| // TODO: remove custom Accept header when this API fully launches. | ||
| req.Header.Set("Accept", mediaTypeOrgMembershipPreview) | ||
|
|
||
| members := new([]*User) |
There was a problem hiding this comment.
var members []*User
resp, err := s.client.Do(req, &members)
if err != nil {
return nil, resp, err
}
return members, resp, nilThere was a problem hiding this comment.
I don't see these changes... do you need to push them?
| @@ -0,0 +1,46 @@ | |||
| // Copyright 2016 The go-github AUTHORS. All rights reserved. | |||
| defer teardown() | ||
|
|
||
| mux.HandleFunc("/orgs/o/outside_collaborators", func(w http.ResponseWriter, r *http.Request) { | ||
| testMethod(t, r, "GET") |
There was a problem hiding this comment.
please add test for preview header... see other examples in repo
| // Warning: The API may change without advance notice during the preview period. | ||
| // Preview features are not supported for production use. | ||
| // | ||
| // GitHub API docs: https://developer.github.com/v3/orgs/outside_collaborators/ |
There was a problem hiding this comment.
|
Done. |
| } | ||
|
|
||
| return *members, resp, err | ||
| return members, resp, err |
|
Awaiting second LGTM. |
| // user is an owner of the organization. | ||
| // | ||
| // Warning: The API may change without advance notice during the preview period. | ||
| // Preview features are not supported for production use. |
There was a problem hiding this comment.
We don't usually include this warning in all other similar situations. Should we start doing it here?
It'll create more work and might get out of date. We have the // TODO: remove custom Accept header when this API fully launches. comments in code, and GitHub API itself is a good source for knowing which endpoints are stable or not.
I'm not against it, just a thought, because this is the first comment of its kind.
There was a problem hiding this comment.
It's not the first one, I copied it from another file using the same Accept header. (and thought that's the convention). I'll find the file when I'll get back home.
There was a problem hiding this comment.
Oh okay, keeping it is perfectly fine then. Thanks!
|
|
||
| // ListOutsideCollaborators lists outside collaborators of organization's repositories. | ||
| // This will only work if the authenticated | ||
| // user is an owner of the organization. |
There was a problem hiding this comment.
Nitpick, the sentence "This will only work if the authenticated user is an owner of the organization." can probably fit on a single line, instead of being split into two lines of lengths 40 and 37 characaters.
Also, question, what's the source of this statement? I don't see it mentioned in https://developer.github.com/v3/orgs/outside_collaborators/#list-outside-collaborators.
There was a problem hiding this comment.
While trying to use the API by hand I was informed (with an error) that only the owner can do this.
|
It looks like this was ready to merge and I think I dropped the ball by not getting it in before the context changes. I'm thinking that while I'm rebasing, that I could add a commit before squashing that adds context. Does that sound reasonable to you, @shurcooL, or do you have an alternative proposal? |
|
Yes, this PR is just 1 logical commit + 3 adjustments based on review comments. I think you should rebase them, add context support and squash everything into one commit before merging into master.
You can also do that. |
|
SGTM. Adjusting and merging. |
|
Integrated in 93f95bf |
2fa_disabled filter is supported too. Closes google#538. Change-Id: I7513435eebd2a20d2392cdb375818b3c8e80accd
2fa_disabled filter is supported too.
I created a new file [orgs_outside_collaborators.go], but I'm not sure whether it wouldn't be better to rename [orgs_members.go] to something like [orgs_members_and_outside_collaborators.go] as it's not clear to me where would the function that converts a member to an outside collaborator fit best.
[orgs_outside_collaborators_test.go] contains tests that are basically recycled from [orgs_members_test.go].
I thought about adding an integration test, but I think that setting up a test scenario is either very hard or straight impossible right now (as we would have to be able to create an organisation and users, which I think is impossible without an Github Enterprise account).
So I fell back to testing it a bit by hand, and those tests passed.
By the way, it's not clear to me why only the organisation's owner can list the organisation's outside collaborators (that's the response API gave me when I tried listing google's). It seems that this is inferrable by just going through all the organisation's repositories, so being a member should suffice. Or am I missing something?