Repository navigation
Selectively display visibility options during repo create #2106
Description
Activity
Hey! Can you just check how the user is authenticated first of all, like if the user is authenticated with GitHub.com then do not show the Internal option, if he or she is authenticated with a GitHub Enterprise Server, then only show the Internal option (during
gh repo create)Yup, that's what the true intention is actually. The only point is that we need to see if that's possible through the Github API.
The only point is that we need to see if that's possible through the Github API.
@ShubhankarKG Please tell me, can we know this through the authentication method used while using
gh auth login? If yes, then why GitHub API is preferred? Is there any security vulnerabilities or what? (Just I'm curious 😃 )@shrihanDev Unfortunately the auth information is not enough to determine if a user has permission to create an internal repo. Internal repos can be created on both GitHub.com and GHES instances. These permissions are actually controlled at the organization and/or enterprise account level where the repository is to be created.
@samcoe Thank you for that! And sorry for that question, I'm completely new to GitHub.
@samcoe @shrihanDev I also got a bit curious about this issue. What do you guys think about just mutating the error and displaying information related to what is the expected behavior from the user, what I can gather from the issue that is affecting the flow is that the user receive the
GraphQLerror. If instead of throwing the error the user can see just a message saying something likeHey you are not using Enterprise to use the Internal option, can you switch to Xor something like that. Could that work as a initial step?@cored I see that being a good potential solution to the problem. One issue that might arise from going down that path is how to determining if the GraphQL error that we receive is one resulting from choosing internal repo versus another type of GraphQL error. They can be notoriously difficult to decipher at times.
Reacted by Rafael GeorgeThanks for the discussion, all! I've reclassified this as a bug, since in the CLI we offer users an option that will result in an error if selected. I also don't know if we can determine from the API if INTERNAL visibility is supported, but it's worth an exploration. 👍
Poking around the /orgs api, this seems doable:
gh api /orgs/:owner
{ "members_can_create_repositories": true, "members_can_create_public_repositories": true, "members_can_create_private_repositories": true, "members_can_create_internal_repositories": false, }Info also appears to be available via GraphQL: https://developer.github.com/changes/2019-12-03-internal-visibility-changes/
@mislav What do you think about something like the following. This is basically punting the issue when creating personal repos (IIRC, you can create personal, internal repos in GHE Server), but it would handle org-owned repos.
Alternately, y'all could ask if they would add
can_create_*_repositoriesfields to the/userendpoint 😄 .// Helper to be used before prompting for visibility, // or to validate input when non-interactive. func validVisibilities(repo ghrepo.Interface) ([]string, error) { allVisibilities := []string{"Public", "Private", "Internal"} if repo.RepoOwner() == "" { return allVisibilities, nil } owner, err := resolveOwner(client, hostname, repo.RepoOwner()) if err != nil { return nil, err } if !owner.IsOrganization() { return allVisibilities, nil } // resolveOrg would hit /orgs/${owner} org, _ := resolveOrg(client, hostname, owner) if err != nil { return nil, err } visibilities := []string{} if org.CanCreatePublic { visibilities = append(visibilities, "Public") } if org.CanCreatePrivate { visibilities = append(visibilities, "Private") } if org.CanCreateInternal { visibilities = append(visibilities, "Internal") } return visibilities, nil } // returned by resolveOrg type orgResponse struct { CanCreatePublic bool `json:"members_can_create_public_repositories"` CanCreatePrivate bool `json:"members_can_create_private_repositories"` CanCreateInternal bool `json:"members_can_create_internal_repositories"` }
Describe the feature or problem you’d like to solve
As a primitive user who is new to visibilities, during
gh repo create, he/she is given the option of an INTERNAL visibility, available only to Enterprise accounts. It may not be appropriate to show this visibility to someone who isn't at all associated with an Enterprise account.Proposed solution
If we can somehow know whether the current user is associated with an Enterprise org or not, we can show the Internal visibility selectively.
How will it benefit CLI and its users?
For someone who is not at all associated with enterprise orgs, it is trivial to show a visibility that he/she cannot use.
Additional context
Originally posted by @samcoe in #2101 (comment)