When creating a member via the umbraco backend, is it possible to prevent selecting more than 1 member group? I'm using a INotificationHandler but cannot figure out how the check the groups of the saved entity.

public class MemberGroupLimitHandler : INotificationHandler<MemberSavingNotification>
{
    public void Handle(MemberSavingNotification notification)
    {
        foreach (var member in notification.SavedEntities)
        {
            // how get member.Groups()??
        }
    }
}

Thanks for any help.

Hey @BC Digi, I just had a look at the code and it doesn't seem possible to do this. The Saving/Saved Notifications are part of the Umbraco domain logic that gets triggered inside the services/repositories. The manipulation of a member's groups is really a manipulation of the MemberIdentityUser (asp.net identity). There is some collection and comparing of the data before it is handed off to the Identity system. In v13 that logic is still inside a massive controller and It would be really hard to alter to incorporate the Notifications pattern. In v14, that logic has been moved into the service level and we maybe could add a new Notification to manipulate the groups right before we let Identity handle them. I don't think we can (at least easily) piggyback on the current notification as there is some rather annoying timing logic to keep the updated member and the MemberIdentityUser in sync regarding passwords/names/other important things. Looking trough this, I might also have discovered a scenario where a partial save might occur which would not be a good thing to have 😦. So thank you for bringing this to my attention 😉. I will have a talk with the team about all of this somewhere in January when I am back from vacation. If you could, in the meantime, create a discussion on the issue tracker stating what functionality (being able to manipulate member groups on a member before actually saving/applying them) together with the use cases you have for this new functionality without going into the possible solution to much. This way other users of the CMS can vote on the issue and our Product manager can prioritize it accordingly.