When importing project from Bitbucket Server, the dropdown searchable list of Gitlab groups is not showing any groups, only the user's personal group (issue turned up between 15.6.4 and 15.7.3)
Summary
After upgrading to 15.7.3 from 15.6.4, there is a problem when importing a Bitbucket repository. The list of groups available to select from is only the current user's group, and it should display all the groups that the user has access to. This worked fine in 15.6.4, and we downgraded back to that version to confirm the behavior.
Steps to reproduce
Click New Project | Import project | Bitbucket Server | authenticate to BB server
View all the repositories available to import. In the second column labeled "To GitLab", the drop down box with the list of all projects and subprojects only shows the current user's group. It should show all the groups available.
Workaround:
Click New Project | Import project | Repository by URL
In the "pick a group or namespace" box, it correctly shows ALL the groups available.
Example Project
Not enough permissions to reproduce this on gitlab.com
What is the current bug behavior?
Drop down box doesn't show groups
What is the expected correct behavior?
Drop down box should show groups
Relevant logs and/or screenshots
This is the problem, from the Import from Bitbucket screen:
Works fine when doing import from repository url:
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
System information System: Proxy: no Current User: git Using RVM: no Ruby Version: 2.7.7p221 Gem Version: 3.1.6 Bundler Version:2.3.15 Rake Version: 13.0.6 Redis Version: 6.2.8 Sidekiq Version:6.5.7 Go Version: unknown GitLab information Version: 15.7.3-ee Revision: 53f88b5d807 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 13.8 URL: https://gitlab.ctsi.mcw.edu HTTP Clone URL: https://gitlab.ctsi.mcw.edu/some-group/some-project.git SSH Clone URL: git@gitlab.ctsi.mcw.edu:some-group/some-project.git Elasticsearch: no Geo: no Using LDAP: yes Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 14.14.0 Repository storages: - default: unix:/var/opt/gitlab/gitaly/gitaly.socket GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shellu git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 14.14.0 ? ... OK (14.14.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 (cluster/worker) ... 1/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: ... Server: ldapmain LDAP authentication... Success LDAP users with access to your GitLab server (only showing the first 100 results) User output sanitized. Found 100 users of 100 limit.
Checking LDAP ... Finished
Checking GitLab App ...
Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Cable config exists? ... yes Resque config exists? ... 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 Systemd unit files or init script exist? ... skipped (omnibus-gitlab has neither init script nor systemd units) Systemd unit files or init script up-to-date? ... skipped (omnibus-gitlab has neither init script nor systemd units) Projects have namespace: ... 2/1 ... yes 7/2 ... yes 71/3 ... yes 32/4 ... yes 33/6 ... yes 43/8 ... yes 28/9 ... yes 45/10 ... yes 45/11 ... yes 71/12 ... yes 59/13 ... yes 45/14 ... yes 78/15 ... yes 36/16 ... yes Redis version >= 6.0.0? ... yes Ruby version >= 2.7.2 ? ... yes (2.7.7) Git user has default SSH configuration? ... yes Active users: ... 14 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-8.x or OpenSearch version 1.x ... skipped (Advanced Search is disabled)
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished
(we will only investigate if the tests are passing)
Possible fixes
No idea, I checked the browser inspector network traffic and there are no failed requests. Only workaround I've found is to import the repository via URL, and to not use the Bitbucket import feature at all.
trying to add a label: ~bug