Skip to content

Adds support for GET /repos/:owner/:repo/collaborators/:username/permission #534

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from

Conversation

alindeman
Copy link
Contributor

Copy link
Member

@dmitshur dmitshur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking good. A few questions.

// member has for a given repository.
type RepositoryPermissionLevel struct {
// Possible values: "admin", "write", "read", "none"
Permission string `json:"permission"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the reason you decided to use a string here instead of *string, as is commonly done in other structs?

// Possible values: "admin", "write", "read", "none"
Permission string `json:"permission"`

User *User `json:"user"`
Copy link
Member

@dmitshur dmitshur Jan 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was there a reason to omit ,omitempty option for both User and Permission, unlike all other structs we have?

@alindeman
Copy link
Contributor Author

This is looking good. A few questions.

@shurcooL Thinking back to the conversation we had over in #512, I thought that since--as far as I can tell--these attributes will always be returned from the API, we could specify them as non-pointer types.

Of course, that's assuming new API routes will not be added in the future that only return subsets of attributes. If you think it'd be better if they matched up with the typical convention of pointers and omitempty, I'm not opposed.

@dmitshur
Copy link
Member

dmitshur commented Jan 31, 2017

Thanks for answering. That makes sense. I wanted to discuss this a bit, and share some thoughts/findings.

My comment ended up being lengthy, so I decided to take it out from this PR and make it a separate issue, so that others can weigh in their opinions there, without derailing this PR.

Please see #537 (comment).

@alindeman
Copy link
Contributor Author

@shurcooL I've amended my commit based on the conclusion in #537

Copy link
Collaborator

@gmlewis gmlewis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, @alindeman and @shurcooL!
If you want to address a small change, you may, or we could leave it for #536. Either way is fine with me.

if err != nil {
return nil, resp, err
}
return rpl, resp, err
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are about to explicitly return nil when there is no error, so maybe you could start this practice:
return rpl, resp, nil
See #536.

Copy link
Member

@dmitshur dmitshur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shurcooL I've amended my commit based on the conclusion in #537

All right, sounds good.

LGTM from my side (but see @gmlewis's comment). Thanks @alindeman!

@alindeman
Copy link
Contributor Author

alindeman commented Jan 31, 2017

@gmlewis Sounds good. I thought the convention was a bit odd, but I admit to blindly following it for consistency. Fixed in the latest push.

@gmlewis
Copy link
Collaborator

gmlewis commented Jan 31, 2017

Thank you, @alindeman!
LGTM.
Merging.

@gmlewis gmlewis closed this in b61d23c Jan 31, 2017
bubg-dev pushed a commit to bubg-dev/go-github that referenced this pull request Jun 16, 2017
…ission

Closes google#534.

Change-Id: I851f803f931697aa1684ee4323d984bd80ffbbda
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants