Jira "GitLab for Jira" app (self-hosted & cloud) fails to link namespace with "The Jira user is not a site administrator." error
Summary
Connecting Jira cloud to a fresh self-hosted GitLab CE 14.7.0 using the "Gitlab for Jira" setup steps outlined on https://docs.gitlab.com/ee/integration/jira/connect-app.html#install-the-gitlabcom-for-jira-cloud-app-for-self-managed-instances fails with "The Jira user is not a site administrator." at the "Add namespace" step after selecting a Gitlab group, even when the Gitlab user is admin and group owner.
per comments this also happens using the normal "Gitlab.com for Jira" app, the data in this bugreport are gathered from a self-hosted omnibus release.
Steps to reproduce
- setup fresh gitlab omnibus instance on debian
- create a sample group & project
- setup a jira cloud instance
- follow https://docs.gitlab.com/ee/integration/jira/connect-app.html to install the "GitLab for Jira" app in jira (both the upload & private marketplace option fail)
- try linking the namespace in the jira app (see screenshots further below)
Example Project
What is the current bug behavior?
when clicking on the "Link" button in the "Gitlab for Jira" "Add namespace" window, the action fails with "The Jira user is not a site administrator."
What is the expected correct behavior?
when clicking on the "Link" button in the "Gitlab for Jira" "Add namespace" window, the namespace should be linked
Relevant logs and/or screenshots
the request to gitlab fails with a 403:
this issue was observed by different people on different versions: https://community.atlassian.com/t5/Jira-Software-questions/When-i-try-to-connect-Jira-with-GitLab-i-got-an-error/qaq-p/1871176
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
System information System: Debian 11 Current User: git Using RVM: no Ruby Version: 2.7.5p203 Gem Version: 3.1.4 Bundler Version:2.1.4 Rake Version: 13.0.6 Redis Version: 6.0.16 Git Version: 2.33.1. Sidekiq Version:6.3.1 Go Version: unknown GitLab information Version: 14.7.0 Revision: abbf44bd6cf Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 12.7 URL: https://gitlab.mydomain.com HTTP Clone URL: https://gitlab.mydomain.com/some-group/some-project.git SSH Clone URL: git@gitlab.mydomain.com:some-group/some-project.git Using LDAP: no Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 13.22.2 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
Expand for output related to the GitLab application check
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: ... 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 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: ... 24/7 ... yes 10/8 ... yes 10/9 ... yes 10/10 ... yes 11/11 ... yes 10/12 ... yes 9/13 ... yes 8/14 ... yes Redis version >= 5.0.0? ... yes Ruby version >= 2.7.2 ? ... yes (2.7.5) Git version >= 2.33.0 ? ... yes (2.33.1) Git user has default SSH configuration? ... yes Active users: ... 13 Is authorized keys file accessible? ... yes GitLab configured to store new projects in hashed storage? ... yes All projects are in hashed storage? ... yes
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished
Workarounds
In at least some cases, this is caused by the Browse users and groups
permission being disabled on the Jira instance.
This permission needs to be granted to either the jira-core-users
or jira-software-users
group at https://yourjirainstance.atlassian.net/secure/admin/GlobalPermissions!default.jspa.
Possible fixes
To work around this we can try the proposal by @jewalky in #351442 (comment 960411528):
It would be nice to at least change the error message on the front-end, because the current one is heavily misleading
😄 Also, I think GitLab could use this API instead:
/rest/api/3/myself?expand=groups
It does not require any special permissions: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-myself/#api-rest-api-3-myself-get
Implementation notes:
- Implement the OAuth flow from https://developer.atlassian.com/cloud/jira/platform/user-impersonation-for-connect-apps/#request-an-oauth-2-0-access-token to get an access token (also see #351442 (comment 995815768))
- Change the endpoint from
api/3/user
toapi/3/myself
inAtlassian::JiraConnect::Client#user_info
- Stop passing
account_id
to this method, which is already the current user. - Also improve error handling so we return a message like "Couldn't fetch Jira user information", instead of the misleading "The Jira user is not a site administrator."
- Try to reproduce the bug on a Jira Cloud instance to verify the fix.