Hi,

Actually, SaveCatalogAssociation raises (assocation) updating, updated and deleted events. If you want to listen to those event, you can implement a class for ICatalogEventListener and register it. I would say this is not a bug.

Regards.

/Q

Yes, I saw this events, that is actually what I gonna do:) Thank you.

But, in general, we have two different approaches, two different "event message flows".  My point here is uniformity.

ICatalogEventListener is also being used by other events, they should have same "event message flows". Actually Commerce is using the Framework Events to handle that, so it must be the same - I don't know why you observe the difference.

Regards.

/Q

I'm taking about two different kind of "events"

1. Mediachase.Commerce.Catalog.EventContext (A)

2. EPiServer.Events.ChangeNotification.IChangeNotificationManager (B)

Second one IChangeNotificationManager.NotifyChanges is called if you change any "part" of product except associations. And I can't find reason for this.

For instance:

Mediachase.Commerce.Catalog.Impl.CatalogContextImpl.SaveCatalogEntry(CatalogEntryDto) does following:

- triggers A event:

        TransactionScope.OnCommit(delegate {
            CatalogCache.Clear();
            eventContext.RaiseEntryUpdatedEvent(dataset, new EntryEventArgs("updated"));
            foreach (DeletedEntryEventArgs args in deletes)
            {
                eventContext.RaiseEntryDeletedEvent(null, args);
            }
        });

- triggers B event

TransactionScope.OnCommit(() => this._changeManager.NotifyChanges<CatalogEntryChange>(changes));

That is ok.

My concern that Mediachase.Commerce.Catalog.Impl.CatalogContextImpl.SaveCatalogAssociation(CatalogAssociationDto) does trigger only A event.

And that should be unified with other CatalogContextImpl methods.

Yeah, you're correct - _changeManager.NotifyChanges was missing when saving CatalogAssociationDto. This should be considered as a bug.

Thank you.

/Q