Separate UI and API checks for user impersonation
What does this MR do and why?
Related to #480910 (closed)
This merge request fixes the impersonation availability button behaviour, based on the admin's chosen state of their Gitlab instance. It addresses an issue where disabling impersonation tokens, personal access tokens along with a few others also unintentionally disabled user impersonation via the web UI.
The "Impersonate" button now remains available in the web UI even when PATs are disabled, while API impersonation tokens are restricted.
Replication Of The Problem & Solution
Before | After |
---|---|
vid | vid2 |
How to set up and validate locally
Requires an EE license to test on GDK since this feature is only available in the premium/ultimate tiers. Follow the videos above for a visual guide
- GDK Home -> Admin Button -> General -> Visibility and access controls -> Personal access tokens -> Disable personal access tokens
- Go back to the admin page
- Find and open a random user
- At the top right of the user page, the
Impersonate
button should be visible.
Concerns
Although unrelated to the changes made in this MR, I've noticed that disabling/enabling PATs and their associated impersonation tokens occasionally requires a manual refresh for the changes to take effect. I confirmed this behavior while testing on both the master and MR branches.
Initially, I suspected it might be a caching issue, so I tested disabling the cache in chrome Devtools & in Ruby but, it did not make a difference (only increased latency).
before_action :no_cache_headers, only[:verify_impersonation_enabled!]
Is this behaviour a cause for concern, or normal?
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.