Describe the bug
Two distinct bugs in UsersController.php prevent additional emails set by an admin via the Provisioning API from being automatically verified.
Technical Details
This isn't an area of code I'm too familiar with; I don't have time to address this fully at the moment, so I'm leaving the details here:
editUserMultiValue() line 859: getPropertyByValue($key) incorrectly looks up the old email (just removed) instead of the new $value. This always returns null, causing the code to skip setLocallyVerified(VERIFIED).editUser() lines 1130–1145: The COLLECTION_EMAIL case contains no auto-verify logic at all.
The $key / $value variable naming is somewhat confusing in this area of code, so these logic gaps weren't immediately obvious.
Impact
Admin-provisioned additional emails remain in a "not confirmed" state, which:
- Blocks them from being set as the primary email.
- Prevents their use for password resets and system notifications.
- Triggers unnecessary verification emails to the end user.
Expected behavior
Additional emails set by an administrator via the API should be marked as verified automatically.
Additional context
These bugs have likely gone unnoticed because the standard Admin UI does not expose additional email management for other users; the issue is currently limited to direct callers of the Provisioning API.
Describe the bug
Two distinct bugs in
UsersController.phpprevent additional emails set by an admin via the Provisioning API from being automatically verified.Technical Details
This isn't an area of code I'm too familiar with; I don't have time to address this fully at the moment, so I'm leaving the details here:
editUserMultiValue()line 859:getPropertyByValue($key)incorrectly looks up the old email (just removed) instead of the new$value. This always returnsnull, causing the code to skipsetLocallyVerified(VERIFIED).editUser()lines 1130–1145: TheCOLLECTION_EMAILcase contains no auto-verify logic at all.The
$key/$valuevariable naming is somewhat confusing in this area of code, so these logic gaps weren't immediately obvious.Impact
Admin-provisioned additional emails remain in a "not confirmed" state, which:
Expected behavior
Additional emails set by an administrator via the API should be marked as verified automatically.
Additional context
These bugs have likely gone unnoticed because the standard Admin UI does not expose additional email management for other users; the issue is currently limited to direct callers of the Provisioning API.