Determining if Member is New in the MemberSavedNotification?

[mistyn8]

Umbraco 13.9.2

So although the documentation doesn't seem to contain this little gem for members.. (rather than the IRememberBeingDirty)

Testing it out I don't get it detecting isNew.. I think it's because we still have two events with one suppressed so even though on the face of it var isNew = member.CreateDate == member.UpdateDate; to the millisecond looks the same when looking at the ticks they are different??

perhaps var isNew = Math.Abs((entity.UpdateDate - entity.CreateDate).TotalSeconds) < 1; or some other arbitrary level of nearness?

We've resolved this via #18207 to be released in 13.8 and 15.3.

We decided against introducing PR with the MemberCreatedNotification - mainly for consistency reasons (we don't have them on all other entities, so it's a bit odd to have them just for member). But as others have said, thanks very much for your efforts on providing that @skttl and leading us to consider how best to tackle this.

Instead we've gone with adding an overload to supress specific notifications when saving members via the IMemberService. We then use that when creating members to ensure just one Saved notification is published.

The following notification handler shows how you can use this to respond to a member being saved, determining if they were created or updated in the save operation.

using Umbraco.Cms.Core.Events;
using Umbraco.Cms.Core.Models;
using Umbraco.Cms.Core.Notifications;

namespace Umbraco.Cms.Web.UI.Custom;

public class MemberSavedNotificationHandler : INotificationHandler<MemberSavedNotification>
{
    private readonly ILogger<MemberSavedNotificationHandler> _logger;

    public MemberSavedNotificationHandler(ILogger<MemberSavedNotificationHandler> logger) => _logger = logger;

    public void Handle(MemberSavedNotification notification)
    {
        foreach (IMember member in notification.SavedEntities)
        {
            var isNew = member.CreateDate == member.UpdateDate;
            _logger.LogInformation("Member {MemberId} {MemberName} was {Action}.", member.Id, member.Name, isNew ? "created" : "updated");
        }
    }
}

Originally posted by @AndyButland in #12673

---

This item has been added to our backlog AB#56362

[github-actions]

Hi there @mistyn8!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[bjarnef]

There is this example in docs although it is regarding SendingMemberNotification:
https://docs.umbraco.com/umbraco-cms/13.latest/reference/notifications/editormodel-notifications

In an older Umbraco 8 project, I noticed we had this:

public class SubscribeToSavingEventComponent : IComponent
{
    private readonly ILogger _logger;

    public SubscribeToSavingEventComponent(ILogger logger)
    {
        _logger = logger;
    }

    public void Initialize()
    {
        ContentService.Saving += ContentService_Saving;
    }

    public void Terminate()
    {
        //unsubscribe during shutdown
        ContentService.Saving -= ContentService_Saving;
    }

    private void ContentService_Saving(IContentService sender, ContentSavingEventArgs e)
    {
        foreach (IContent entity in e.SavedEntities)
        {
            if (entity.ContentType.Alias == "location")
            {
                bool isNew = entity.HasIdentity == false;

                if (isNew)
                {
                    // Do something with new member.
                }
                else
                {
                    var dirty = (ICanBeDirty)entity;

                    bool isDirty = 
                        dirty.IsPropertyDirty(ContentModels.BrandLocation.GetModelPropertyType(x => x.Title).Alias) ||
                        dirty.IsPropertyDirty(ContentModels.BrandLocation.GetModelPropertyType(x => x.Address).Alias) ||
                        dirty.IsPropertyDirty(ContentModels.BrandLocation.GetModelPropertyType(x => x.City).Alias)));

                    // No change then skip
                    if (isDirty == false)
                        return;

                    // Do something with existing member.
                }
            }
        }
    }
}

Perhaps it can help. I noticed back then it had issues deciding is properties were dirty: #11683

Perhaps you can use:

public void Handle(MemberSavedNotification notification)
{
    foreach (IMember member in notification.SavedEntities)
    {
        var isNew = member.HasIdentity == false;
        _logger.LogInformation("Member {MemberId} {MemberName} was {Action}.", member.Id, member.Name, isNew ? "created" : "updated");
    }
}

[mistyn8]

@bjarnef Thanks for the comment, but the use case is:

• Did I just create a member, then create corresponding nodes (content and media) that are stamped with the member guid.

Don't think I can do this with the SendingMemberNotification, as we don't have the concrete member guid/id at that point.. indeed that's how we know it's a new member, the absence of an id ;-)

As mentioned in the linked issue/pr with members the creation ends up doing two saves.. (the first being notification suppressed) so the saving/saved will always end up giving you member.HasIdentity = true as it was stamped as part of the suppressed initial member create workflow..

Which I can see is why the the issue mentions checking create vs update dates, and there's the rub these aren't ever equal in the first notification we get for a MemberSavedNotification as the create was supressed and the update we get notified about is a second save at a different time.

I guess I can always check to see on member save if the stamped member nodes are present and create as required, but seems that we should be able to know if a member just got created and only do it at that point.

[AndyButland]

I don't see the issue testing locally with the notification handler you quoted above @mistyn8 - rather I see the expected messages in the logs on create and update.

Comparing CreateDate and UpdateDate on the new member creation shows exactly the same date, even comparing ticks.

So I can't replicate, but even if I could I think the suggestion you have made as to how you would resolve it yourself in your notification handler would make sense.

I'll close, but please re-open with details if you think there's more we could do here.

[mistyn8]

@AndyButland thanks for the investigation.
As my implementation is also hooked into AAD2BC for the member store I can only surmise there's something different occurring there? Though not sure how I would track that down....

Having gone back to basics and a vanilla install of 13.10.0, I concur CreateDate/Update are identical when saving via the backoffice and via the MemberService.

    var guid = Guid.NewGuid().ToString();
    var member = memberService.CreateMemberWithIdentity(guid, $"{guid}@example.com", guid, cnv.MemberTypes.DefaultAlias);
    // Set password
    //memberManager.AddPasswordAsync(member, guid);
    // Approve member
    member.IsApproved = true;
    // Save member
    memberService.Save(member);

But have noticed, atomically creating a member via the following (seems nicer as a single initialiser for isApproved/password and only IMemberManager required) though this doesn't raise events, maybe by design?)

var newUser = new MemberIdentityUser()
{
    UserName = guid,
    Email = $"{guid}@example.com",
    MemberTypeAlias = cnv.MemberTypes.DefaultAlias,
    IsApproved = true
};

var result = await memberManager.CreateAsync(newUser, guid);

[AndyButland]

Not sure it's strictly by design, but just reviewing I can see it has come about because of the changes made to resolve the original issue with duplicate notifications. Via the backoffice, creating a member calls IMemberManager.CreateAsync but then makes another save, and for that reason the save in CreateAsync itself is supressed from firing notifications.

But if you call only this method from code, then you'll not get the Saved notification,

[mistyn8]

I guess that begs the question, what am I missing by using the MemberManager if I'm not replicating the backoffice.. (roles perhaps?)