Allow assignment of non-enterprise users to placeholder users when enterprise users exist in namespace

Problem

Currently, when a top-level group has at least one enterprise user, the placeholder user reassignment feature only allows reassignment to enterprise users within the organization. This restriction applies to both the UI and API/CSV methods.

While this behavior was intentionally implemented in GitLab 18.0 to prevent accidental reassignment to users outside the organization, it creates limitations for organizations that have legitimate users with different email domains who are not enterprise users but should still be able to receive placeholder assignments. Doing these assignments via rails console is risky, especially on GitLab.com. Given this, users have no real solution to do assignments if they are unable to add a second authorized email domain to the namespace.

Current Behavior

• Only enterprise users appear in the placeholder reassignment UI dropdown
• API and CSV reassignment methods also enforce the enterprise user restriction
• Non-enterprise users in the same namespace cannot be assigned to placeholders, even if they are legitimate members

Proposed Solution

Provide a mechanism for group owners or administrators to assign placeholder users to non-enterprise users within their namespace, while maintaining security controls to prevent accidental external assignments.

Potential approaches:

1. Enhanced UI with confirmation: Show non-enterprise users in the dropdown but require additional confirmation for non-enterprise assignments
2. Permission-based override: Allow group owners/admins to override the enterprise-only restriction with appropriate warnings
3. Namespace-scoped allowlist: Enable configuration to allow specific email domains or users for placeholder assignment
4. API-only bypass: Provide API methods that allow non-enterprise assignments with explicit confirmation parameters

Use Cases

• Organizations with multiple subsidiaries using different email domains
• Companies that cannot manage all email domains under their enterprise configuration
• Legitimate internal users who need historical contribution attribution but aren't enterprise users

Security Considerations

Any solution should:

• Maintain protection against accidental external assignments
• Require explicit confirmation or elevated permissions
• Provide clear warnings about non-enterprise user assignments
• Log assignment actions for audit purposes