LoggerMockDataCreator: hardcoded Email 'user_xyz@test.com.net.org' fails orgs with email domain restrictions

[bobbywhitesfdc]

Summary

LoggerMockDataCreator.createUser() hardcodes Email = 'user_xyz@test.com.net.org' (line 437). On orgs that enforce an email domain allowlist (Setup → Security Controls → Login Settings → Allowed Email Domains), every test that internally calls createUser() fails at the insert User DML with:

System.DmlException: Insert failed. First exception on row 0; first error:
FIELD_INTEGRITY_EXCEPTION, Invalid Email Address: Must be in domain(s) <allowed-domains>: [Email]

Affected tests

Any test class that calls LoggerMockDataCreator.createUser() or a helper that delegates to it:

• LogBatchPurgeController_Tests
• LogEntryEventBuilder_Tests
• LogEntryEventHandler_Tests
• LogHandler_Tests

Root cause

test.com.net.org is not a real domain and fails org-level email domain validation when that restriction is configured. The unique string already generated on line 434 is not carried through to the Email field, so every mock user gets the same non-compliant address regardless of the uniqueString suffix.

// LoggerMockDataCreator.cls lines 434-437 (approximate)
String uniqueString = Logger.getTransactionId() + (userMockUsernameCount++) + '@test.com';
...
Alias = 'user_xyz',
Email = 'user_xyz@test.com.net.org',   // ← hardcoded, fails domain restriction

Suggested fix

Derive the email from the already-unique uniqueString, using an IANA-reserved test domain:

String uniqueString = Logger.getTransactionId() + (userMockUsernameCount++);
...
Alias = 'usr' + userMockUsernameCount,
Email = uniqueString + '@example.com',

example.com is reserved by IANA for documentation and testing (RFC 2606) and is extremely unlikely to appear in any org's domain allowlist. Alternatively, exposing the test email domain as a configurable LoggerParameter__mdt record would give org admins full control.

Environment context

• Salesforce org with email domain restriction enabled — affects sandboxes hardened for security
• Tests pass on orgs without the restriction (e.g., fresh Developer Edition orgs, unrestricted production orgs)
• No workaround is available to consumers without modifying the package source