Confusing behavior when trying to create Group access token with Minimal Access role
Summary
Group access token creation with "Minimal Access" role results in confusing behavior.
Steps to reproduce
- Create an Ultimate or Premium top-level group on GitLab.com.
- Go to Settings > Access Tokens > Add new token.
- Create a new token with Minimal Access role.
Example Project
https://gitlab.com/groups/atanayno_ultimate_group/
What is the current bug behavior?
The screen will refresh, and there is an impression that group access token was created. However, new token will not be shown in the list of tokens, but there will be a new member with Minimal Access in this group, and it will not be possible to remove this member neither from UI, nor via API.
What is the expected correct behavior?
Group access token should be created successfully.
Relevant logs and/or screenshots
500 error is shown in the browser console. The error is:
"exception.message": "undefined method `human_access' for nil:NilClass\n\n \"Created #
{resource_type} access token with token_id: #{token.id} with scopes: #{token.scopes} and #
{resource.member(token.user).human_access} access level.\"\n
...
"exception.backtrace": [
"ee/app/services/ee/resource_access_tokens/create_service.rb:23:in `success_message'",
"ee/app/services/ee/resource_access_tokens/create_service.rb:31:in `audit_event_service'",
"ee/app/services/ee/resource_access_tokens/create_service.rb:10:in `block in execute'",
"<internal:kernel>:90:in `tap'",
"ee/app/services/ee/resource_access_tokens/create_service.rb:9:in `execute'",
"app/controllers/concerns/access_tokens_actions.rb:28:in `create'",
"actionpack (7.0.8.4) lib/action_controller/metal/basic_implicit_render.rb:6:in `send_action'",
"actionpack (7.0.8.4) lib/abstract_controller/base.rb:215:in `process_action'",
"actionpack (7.0.8.4) lib/action_controller/metal/rendering.rb:165:in `process_action'",
"actionpack (7.0.8.4) lib/abstract_controller/callbacks.rb:234:in `block in process_action'",
"activesupport (7.0.8.4) lib/active_support/callbacks.rb:118:in `block in run_callbacks'",
"lib/gitlab/ip_address_state.rb:11:in `with'",
"ee/app/controllers/ee/application_controller.rb:45:in `set_current_ip_address'",
"activesupport (7.0.8.4) lib/active_support/callbacks.rb:127:in `block in run_callbacks'",
"app/controllers/application_controller.rb:468:in `set_current_admin'",
"activesupport (7.0.8.4) lib/active_support/callbacks.rb:127:in `block in run_callbacks'",
"lib/gitlab/session.rb:11:in `with_session'",
"app/controllers/application_controller.rb:459:in `set_session_storage'",
"activesupport (7.0.8.4) lib/active_support/callbacks.rb:127:in `block in run_callbacks'",
"lib/gitlab/i18n.rb:114:in `with_locale'",
"lib/gitlab/i18n.rb:120:in `with_user_locale'",
"app/controllers/application_controller.rb:450:in `set_locale'",
"activesupport (7.0.8.4) lib/active_support/callbacks.rb:127:in `block in run_callbacks'",
"marginalia (1.11.1) lib/marginalia.rb:109:in `record_query_comment'",
"activesupport (7.0.8.4) lib/active_support/callbacks.rb:127:in `block in run_callbacks'",
...
Output of checks
This bug happens on GitLab.com, also reproduced on a self-managed instance with GitLab 17.0.
Additional information
When checking the Rails console on a self-managed instance, I can see that group access tokens were actually created:
PersonalAccessToken.project_access_token.all.find_each do |token|
token.user.members.each do |member|
type = member.is_a?(GroupMember) ? 'Group' : 'Project'
puts "#{type} access token in #{type} ID #{member.source_id}, Token ID: #{token.id}, Name: #{token.name}, Scopes: #{token.scopes}, Last used: #{token.last_used_at}"
end
end
The issue was likely introduced in the MR !142880 (merged), although on GitLab 16.10 it also did not work correctly:
- Token is created, and the value is shown in the UI, there's no error in the logs.
- The created token is not visible in the list of tokens.