Self-Managed Group Setting: Disable Personal Access Tokens

Summary

"Disable personal access tokens" setting appears in group settings on self-managed.

Group > Settings > General > Permissions and group features
Screenshot_2025-04-17_at_10.19.50_AM

The setting description states: "If enabled, enterprise user accounts will not be able to use personal access tokens." However, enterprise users are a feature exclusive to GitLab.com. It's function in self-managed is unclear and it's inclusion is potentially confusing.

Zd Link (internal)

Steps to reproduce

  1. Navigate to any group
  2. Go to Group > Settings > General > Permissions and group features
  3. Observe the "Disable personal access tokens" setting

What is the expected correct behavior?

  • Hide this setting on self-managed instances if it is non-functional
  • If this setting has a function then the description should be updated to clarify its relevance/function on self managed. Or
  • Extend the functionality to work meaningfully in self-managed contexts

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)
System information
System:         Ubuntu 20.04
Proxy:          no
Current User:   git
Using RVM:      no
Ruby Version:   3.2.5
Gem Version:    3.5.17
Bundler Version:2.5.11
Rake Version:   13.0.6
Redis Version:  7.0.15
Sidekiq Version:7.2.4
Go Version:     unknown

GitLab information
Version:        17.5.1-ee
Revision:       e4e13234b2d
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     PostgreSQL
DB Version:     14.11
Elasticsearch:  yes
Geo:            no
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers: 

GitLab Shell
Version:        14.39.0
Repository storages:
- default:      unix:/var/opt/gitlab/gitaly/gitaly.socket
GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell

Gitaly
- default Address:      unix:/var/opt/gitlab/gitaly/gitaly.socket
- default Version:      17.5.1
- default Git Version:  2.46.2

(For installations from source run and paste the output of:
`sudo -u 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 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
sudo gitlab-rake gitlab:check SANITIZE=true
Checking GitLab subtasks ...


Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 14.39.0 ? ... OK (14.39.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-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 ...


Database config exists? ... yes
Tables are truncated? ... skipped
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: ...
1/1 ... yes
3/2 ... yes
1/3 ... yes
3/4 ... yes
3/5 ... yes
3/6 ... yes
3/7 ... yes
19/8 ... yes
14/9 ... yes
16/10 ... yes
21/11 ... yes
24/12 ... yes
1/15 ... yes
31/16 ... yes
42/18 ... yes
31/19 ... yes
31/20 ... yes
31/21 ... yes
31/22 ... yes
31/23 ... yes
33/24 ... yes
35/29 ... yes
74/30 ... yes
42/31 ... yes
42/32 ... yes
42/33 ... yes
10/34 ... yes
83/35 ... yes
Redis version >= 6.2.14? ... yes
Ruby version >= 3.0.6 ? ... yes (3.2.5)
Git user has default SSH configuration? ... yes
Active users: ... 20
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 ... no ( Unknown)
For more information see:
doc/integration/advanced_search/elasticsearch.md
All migrations must be finished before doing a major upgrade ... no (You have 32 pending migrations.)
For more information see:
https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html#all-migrations-must-be-finished-before-doing-a-major-upgrade
Try fixing it:
Wait for all advanced search migrations to complete.
To list pending migrations, run sudo gitlab-rake gitlab:elastic:list_pending_migrations


Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)