Allow Duplicate Email for Members

[jasont0101]

Prerequisites

• I have added steps to test this contribution in the description below

Description

This is a redo of this PR #14784. That PR went stale and the Contrib branch advanced to v14, so this is work for v13.

Oddly have had two project in a row that the client had the business need to allow member to have duplicate email address. While there are other way to resolve this issue, want to add (re-add?) this feature to Umbraco so that it was easy to enable with out having to work out complicated alternative contact email options. So, added the option to allow member accounts to be created with duplicate emails.

The current default behavior is that members must have unique emails. While it was possible to override the ASP.NET Identity provider value for RequireUniqueEmail in startup.cs or program.cs, validators still checked if the email existed and prevented the member from being added if the email was a duplicate.

Add a new appsettings.json option to the Umbraco:CMS:Security section, RequireUniqueEmailForMembers with a default value of true. This now sets the value for options.User.RequireUniqueEmail in the ConfigureMemberIdentityOptions class.

Also added a new method to the MemberService, GetMembersByEmail.The GetByEmail method will only return FirstOrDefault. This new method allows for the retrieval of all member with the same email.

This option only allows duplicate emails for members and not users. Usernames must still be unique.

TEST

1. Start up a new solution.
2. Go to the Members section and create a new member.
3. Create a second new member using the same email as the one just created. Validation should prevent the creation of this member.
4. Stop the solution.
5. Add the new security option to the appsettings.json, Umbraco:CMS:Security:RequireUniqueEmailForMembers, set the value to true and save file
6. Start up a the solution, go to the Member section, and repeat step 3 - 4, Validation should still prevent the creation of the member.
7. Set RequireUniqueEmailForMembers to false and save file.
8. Start up a the solution, go to the Member section, and repeat step 3 - 4, the member should now be created.
9. Stop the solution.

[github-actions]

Hi there @jasont0101, thank you for this contribution! 👍

While we wait for one of the Core Collaborators team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:

• It's clear what problem this is solving, there's a connected issue or a description of what the changes do and how to test them
• The automated tests all pass (see "Checks" tab on this PR)
• The level of security for this contribution is the same or improved
• The level of performance for this contribution is the same or improved
• Avoids creating breaking changes; note that behavioral changes might also be perceived as breaking
• If this is a new feature, Umbraco HQ provided guidance on the implementation beforehand
• 💡 The contribution looks original and the contributor is presumably allowed to share it

Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution.

If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[georgebid]

Hey @jasont0101, thanks a lot for creating a second PR for this one, sorry it's taken so long to get it reviewed. Have you addressed all of @ronaldbarendse's comments on this PR? I just want to make sure we don't lose those conversations 😄 Someone on the core collabs team will review this soon!

[jasont0101]

@georgebid & @ronaldbarendse Yes, I incorporated Ronald's input from the prior PR (#14784).

[connectisl]

@jasont0101 I'm hoping you could answer a question that may help to unblock this issue for us. In your opening message for this pull request, you said: "While there are other way to resolve this issue...with out having to work out complicated alternative contact email options."

Did your alternative approach involve appending +1 to a member's email address or similar? I'm really keen to understand the other ways you've managed to overcome this issue. We're unlikely to be in a position to upgrade to v13 in the immediate future, so any information you can share would be useful. Feel free to drop me an email at seo@connect.org.uk to discuss.

[jasont0101]

@connectisl Sorry for the very slow reply. The only thing I can think of for handling this without being able to allow members to have duplicate emails is to add a new property to the member for a Contact Email, then make the email in the email field unique in some way. The email field would just be ignored in your code in favor of the new Contact Email field. This could be a fair bit of refactor work depending on your code.

One of our clients did something similar as they are also reluctant to upgrade to v13 as well. There upgrade to v10 from v8 was very painful. Having done a few v10 to v13 upgrades now I have found that they are fairly painless. The change over from .Net Framework to .Net Core as well as some of Umbraco's updates was the worst part. I am hoping v14 will turn out to not be that bad.

Being fearful of upgrades is a sign that there is an architectural issue with their project. Unfortunately, this is not an isolated issue and some of our clients whos sites, which we inherited, have gotten so complicated that they are fearful of upgrades. Over the years with Umbraco I have learned that upgrades are just part of the Umbraco life cycle and need to factored in to my designs. I will get off of my soap box now. :-)