Add "allow bypass of placeholder user confirmation" admin setting
What does this MR do and why?
This MR adds a new application setting bypass_placeholder_user_reassignment_confirmation behind an existing feature flag, importer_user_mapping_allow_bypass_of_confirmation. bypass_placeholder_user_reassignment_confirmation will allow placeholders to be reassigned without confirmation from the reassigned user. It will also allow placeholder users to be reassigned to blocked users, however, the implementation of these features will be done in other MRs. Since blocked users on the destination have no way of logging in to confirm their reassignment, it makes the most sense to put both features under one setting rather than two separate settings.
The issue noted that we should consider expiring as suggested on the group setting issue. I opted not to because this application setting must be toggled by an admin, so it isn't an option on .com and it's limited to the most trusted users.
References
- Resolves Add "allow bypass of placeholder user confirmat... (#534330 - closed)
- Unblocks [Admin bypass] Skip confirmation when "allow by... (#534648 - closed) and Allow Admin to reassign user contributions and ... (#523260 - closed)
- Related issue: BE [Group owner bypass] Add "allow bypass of pl... (#534329 - closed) for Premium/Ultimate GitLab.com users
Screenshots or screen recordings
| Before | After |
|---|---|
![]() |
With feature flag enabled:
|
Without flag enabled:
|
How to set up and validate locally
- Pull down this branch.
- Run database migrations.
- View the import admin settings. Ensure the new admin setting is not visible when the
bypass_placeholder_user_confirmationfeature flag is not enabled. - Enable
importer_user_mapping_allow_bypass_of_confirmation. - Verify the new admin setting is visible and can be enabled. No other features are tied to it as of this MR.
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Related to #534330 (closed)


