Saving user without identities such as name or email and appending this 'Empty user' to the Groups

[sabina-talipova]

Description

User, with permission to create new users, can create new user without any specific fields as name / username or email. And also he can add "empty user" to the Groups, in Groups section, for example add to group of "Content Authors".
Creating a user without saving the name and other fields is not a problem in itself, but adding such a user to groups can become a problem in other modules where the group will be used, but the user of the group must have the correct data.
EXAMPLE: Content Review - you can add groups and all users in this group should get email. But if email is empty string, symfony/mime throws an error Email "" does not comply with addr-spec of RFC 2822.. Or SilverStripe\Control\Email\Email::setTo(): Argument #1 ($address) must be of type array|string, null given, called in /var/www/html/vendor/silverstripe/contentreview/src/Tasks/ContentReviewEmails.php

Probably, we should add additional validation for Email(other fields) if user added "empty user" to the Group and now is trying to 'Save'.

Steps to reproduce

• Go to "Security" section
• Click "Add Member" button
• Leave all fields empty
• Click "Create"
• I see "Saved Member " "" successful message
• Go back to "Users" list
• See blank row without first name, surname, email
• I still can delete empty record

AC's

[emteknetnz]

I'm not sure if this is a bug or not so I've marked it as an enhancement

We'd need to be careful with changing this behavior due to there being loads of unit tests that create Member's missing lots of fields

[michalkleiner]

I would also mark this as an enhancement and moved it to the contentreview module where this causes an issue.
I think we don't need to mandate email as a required field, username and ID are/should be required.

[GuySartorelli]

@michalkleiner This isn't only about the email address - it's also about the name, which arguably should be required as it's the only way to visually identify members in the CMS (without customisations).

The content review example was only one example of where this causes a problem, but anywhere that you need to select a member or send emails to a member is likely affected as well.

[mfendeksilverstripe]

@emteknetnz @GuySartorelli I think this is a bug - the form validator doesn't seem to work. This is likely a regression caused by CMS 5 upgrade. Likely related to the introduction of getCMSCompositeValidator().

Framework version: 5.2.22

Expected behaviour:

Actual behaviour:

Managed to fix it via extension though (code snippet below).

/**
 * Add member validator to the CMS form (member edit)
 *
 * @method Member|$this getOwner()
 */
class MemberValidatorExtension extends Extension
{
    /**
     * Extension point in @see Member::getCMSCompositeValidator()
     *
     * @param CompositeValidator $compositeValidator
     * @return void
     */
    public function updateCMSCompositeValidator(CompositeValidator $compositeValidator): void
    {
        $owner = $this->getOwner();
        $memberValidator = $owner->getValidator();

        $compositeValidator->addValidator($memberValidator);
    }
}

[GuySartorelli]

@mfendeksilverstripe Please raise that as a new issue - this issue is about changing which fields are required by default, not about customising the required fields through extensions or about whether the existing validation works.

[mfendeksilverstripe]

Raised #11357 for specifically member edit form issue.