Skip to content

GitHub import does not show all available namespaces

Summary

When importing a project from GitHub, the "To GitLab" namespace selection dropdown does not properly display projects where the user is a developer and the project is set to "maintainers and developers" can create projects.

The Import from GitHub documentation doesn't mention anything about specific permissions, so it's unclear whether this is intended or not.

Steps to reproduce

  1. Have some project in GitHub you don't have in GitLab. (You don't actually have to complete the import so it can be a fake / blank project)
  2. Create a group or subgroup in GitLab, or find one you've already got to test with.
  3. In Settings > General > Permissions, LFS, 2FA, make sure Allowed to create projects is set to "Developers + Maintainers"
  4. Add someone as a developer to your group (make sure they don't have higher permissions in a parent group, they must have developer level)
  5. Have that developer user go to New Project > Import > GitHub and pick an authentication method if not already connected. I tried with both access tokens and the OAuth integration and they both show the issue.
  6. Find your GitHub project in the list, and look at the dropdown to choose a namespace. "Groups" only shows groups where the user is a maintainer, and none of the ones where they can create projects with developer permission.

Example Project

N/A, it's the creating/importing of a project that's the problem

I did however replicate on GitLab.com using my basic team member permissions. I'm a developer of the /gitlab-com group as all GitLab team members are by default. I can select "New project" and choose to make a new random blank project in that namespace, but it does not appear in the dropdown if I want to import from GitHub. Only groups I am a maintainer of, such as the gitlab-com/support subgroup, were listed.

What is the current bug behavior?

Only groups where a user is a maintainer are listed in the dropdown when importing from GitHub. None of the groups where they are a developer, but project creation is set to "Developer + Maintainers" are available.

What is the expected correct behavior?

Projects that have "Developers + Maintainers" set to create projects where the user is a developer should be listed.

Relevant logs and/or screenshots

Expand for screenshots Here are my subgroup's settings, it's "subgroup-b" under "parent-group-a":

settings for "can create projects"

Here are my group's test user members, one a developer and one a maintainer.

members of "subgroup-b"

The maintainer is not a maintainer of any other groups. Here's our maintainer trying to import from GitHub, note the subgroup group shows up:

maintainer attempting to import

Here's the developer user trying to import the same project, only the personal namespace is available despite being a developer on two groups that allow developers to create projects:

developer attempting to import

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

Customer originally reported this on GitLab 13.8.4, I replicated on 13.8.2, and also on GitLab.com which /help says is 13.10.0-pre 6e05534f2ce at the time I'm testing and writing this issue.

Here's for my 13.8.2 test instance though, it's just Omnibus on Ubuntu:

Expand for output related to GitLab environment info 
System information
System:		Ubuntu 18.04
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	2.7.2p137
Gem Version:	3.1.4
Bundler Version:2.1.4
Rake Version:	13.0.3
Redis Version:	5.0.9
Git Version:	2.29.0
Sidekiq Version:5.2.9
Go Version:	unknown

GitLab information
Version:	13.8.2-ee
Revision:	e41f765f4b6
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	PostgreSQL
DB Version:	12.5
URL:		https://gitlarb.party
HTTP Clone URL:	https://gitlarb.party/some-group/some-project.git
SSH Clone URL:	git@gitlarb.party:some-group/some-project.git
Elasticsearch:	no
Geo:		no
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers:

GitLab Shell
Version:	13.15.0
Repository storage paths:
- default: 	/var/opt/gitlab/git-data/repositories
GitLab Shell path:		/opt/gitlab/embedded/service/gitlab-shell
Git:		/opt/gitlab/embedded/bin/git

Results of GitLab application Check

This is again for my own test Omnibus instance, running GitLab 13.8.2:

Expand for output related to GitLab environment info 
Checking GitLab subtasks ...

Checking GitLab Shell ...

GitLab Shell: ... GitLab Shell version >= 13.15.0 ? ... OK (13.15.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Gitaly ...

Gitaly: ... default ... OK

Checking Gitaly ... Finished

Checking Sidekiq ...

Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking Incoming Email ...

Incoming Email: ... Reply by email is disabled in config/gitlab.yml

Checking Incoming Email ... Finished

Checking LDAP ...

LDAP: ... LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab App ...

Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
Tommert / coolest-mountains ... yes
Pizza Eaters / Pizza Pictures ... yes
Parent Group A / Sub Group B / Project B ... yes
Templates-wow / No Master Default ... yes
Kaitlyn / woooooo ... yes
Kaitlyn / 152258 ... yes
Kaitlyn / Good Bugs ... yes
Templates-wow / its-really-cake ... yes
Kaitlyn / Jira Import Test ... yes
k8s testing / plainhtmlci ... yes
Kaitlyn / plainhtmlci ... yes
Pizza Eaters / Cheese Only / Best Cheeses ... yes
Kaitlyn / manual-mirror ... yes
Kaitlyn / ci-viz ... yes
Kaitlyn / Ci Viz2 ... yes
Kaitlyn / test-license-npm ... yes
Parent Group A / Sub Group B / Project B internal ... yes
Parent Group A / Project A internal ... yes
Parent Group A / Sub Group B / newprivateb ... yes
Parent Group A / Sub Group B / newprivate-locked ... yes
Parent Group A / Sub Group B / groupisprivate ... yes
Kaitlyn / node-test-cov ... yes
Redis version >= 4.0.0? ... yes
Ruby version >= 2.7.2 ? ... yes (2.7.2)
Git version >= 2.29.0 ? ... yes (2.29.0)
Git user has default SSH configuration? ... yes
Active users: ... 9
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Elasticsearch version 7.x (6.4 - 6.x deprecated to be removed in 13.8)? ... skipped (elasticsearch is disabled)

Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Possible fixes

When I was investigating whether this was a bug or just a setting I missed or something I noticed both a request in the browser to /import/available_namespaces and a request in the logs to an available namespaces controller:

gitlab-rails/production_json.log:{"method":"GET","path":"/import/available_namespaces","format":"json","controller":"Import::AvailableNamespacesController","action":"index","status":200,"time":"2021-02-22T13:46:45.208Z","params":[],"remote_ip":"73.13.242.253","user_id":4,"username":"kbooks","ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:85.0) Gecko/20100101 Firefox/85.0","correlation_id":"01EZ4ZW2HFP0DX8E93N0196BJF","meta.user":"kbooks","meta.caller_id":"Import::AvailableNamespacesController#index","meta.remote_ip":"73.13.242.253","meta.feature_category":"importers","redis_calls":1,"redis_duration_s":0.000407,"redis_read_bytes":280,"redis_write_bytes":872,"redis_shared_state_calls":1,"redis_shared_state_duration_s":0.000407,"redis_shared_state_read_bytes":280,"redis_shared_state_write_bytes":872,"db_count":3,"db_write_count":0,"db_cached_count":0,"queue_duration_s":0.013919,"cpu_s":0.03,"db_duration_s":0.00496,"view_duration_s":0.00024,"duration_s":0.01778}

For the maintainer user that does return groups where they are a maintainer. For the developer user it returned an empty array. So I figured okay, I'll look at that controller's code. It seems to be calling this managable groups with routes method in the user model. That method has an option to return the developer maintainer access groups, but it defaults to false, and the AvailableNamespacesController doesn't seem to be sending in any override or anything.

I confirmed in the rails console for my two test users that the one with maintainer access I can see the group by calling User.find_by(username: 'maintuser').manageable_groups_with_routes, but the developer I have to add the extra parameter to see it, so User.find_by(username: 'devuser').manageable_groups_with_routes(include_groups_with_developer_maintainer_access: true). Without the extra parameter it returns an empty array.

Is this intentional? Should we be checking for groups with maintainer developer access when importing?

  • If yes, we should check for those projects, then this is a bug and I think we just need to include that parameter.
  • If no, let me know and I can close this and update the docs to make sure that's clear!