Possibly incorrect "silent" flag?

There are some deliberate "force silent" scenarios:

\Drupal\danse_content\Plugin\Danse\Content::createContent

If a new and published entity gets saved, there are 2 events: create and publish. As we want to avoid double-notifications, the create event is enforced to silent.

\Drupal\danse_content\Plugin\Danse\Content::updateContent

If an existing entity gets updated and by the same time either gets published or unpublished, there are also 2 events: either update and publish or update and unpublish. Again, to avoid double-notifications, the publish or unpublish events are enforced to silent.

\Drupal\danse_content\Plugin\Danse\Content::deleteContent

If an existing entity gets deleted, there are 2 events: unpublish and delete. As above, 1 of those (here: unpublish) in enforced to silent.

While the intention to not double-notify still seems to be appropriate, I can see how notifications may be missing for those who subscribed to the silenced event and not the other. Not sure, if and how this can be resolved to satisfy both intentions, open for discussions.

I thought it might be something like that. Sorry I didn't dig deeper into the code first. It was getting late.

The only thing I would question is whether publish shouldn't force update to silent, instead of the other way around. Publish seems like the more important event to me, but maybe that's just because of my use case. (Same for unpublish.)

Trying to think this through ... if content is published, that's an update in itself (right?) so in that case, it's the update event that is superfluous.

Of course, there might be an additional update before the publish event, and the notification for that would be silenced if the content is then published before the next cron. How important is that? Beyond that, how many non-admins are going to request update notifications anyway?

On createContent and deleteContent, I think the existing design makes sense.

Trying to think this through ... if content is published, that's an update in itself (right?) so in that case, it's the update event that is superfluous.

I wouldn't agree to that. Yes, published in an update in itself, but that's why published could be recognized as redundant. The thinking behind that is that the published state is just another field (value: 0 or 1) like many others in entities as well.

Maybe we need to go to the stretch of finding out if the status field was the only change during an entity update. If so, we silence the update event; otherwise, we silence the publish/unpublish event.

Additionally, we could offer a global setting to disable the auto-silencing completely.

Circling back on this because it's still an issue for me. Let me see if I understand this correctly.

If "update" and "publish" are both checked in the DANSE content type tab, only the "update" notification will be sent, even if only one user has an "update" subscription and 100 have a "publish" subscription.

That seems to be the case for me. I unchecked "update" on the content type tab, and now all of the "publish" notifications are being sent.

What would happen if I changed the default value for "Force push even if this creates duplicate notification" and checked both "update" and "publish" on the content type tab? Would the one "update" subscriber get his "update" notification and the 100 "publish" subscribers all get their notifications?

Alternatively, what you suggest in #4 would work as well, as far as I can tell. I could take a look at it if that is your preferred approach, but I can't promise I'll have the time or skills to tackle it right away. My own thinking is that the best solution would be to silence the duplicate notifications only for subscribers who are receiving both notifications. If that's possible.

Maybe we need to go to the stretch of finding out if the status field was the only change during an entity update. If so, we silence the update event; otherwise, we silence the publish/unpublish event.

What would happen if I changed the default value for "Force push even if this creates duplicate notification" and checked both "update" and "publish" on the content type tab? Would the one "update" subscriber get his "update" notification and the 100 "publish" subscribers all get their notifications?

To answer that, I first need to explain what's a duplicate event: an event is then a duplicate of another event, if the same topic (create, update, publish, etc.) happens on the same entity.

Example: an entity A gets published, then unpublished and then published again. The sequence of events for that example is:

1. A updated
2. A published
3. A updated
4. A unpublished
5. A updated
6. A published

The events 1, 3 and 5 are duplicates. And also the events 2 and 6 are duplicates. To avoid duplicate notifications for users, the events 3, 5 and 6 will not be notified if the user hasn't seen 1 and 2 yet.

When you enable force notifications when you publish that entitiy for the second time, then the events will be notified to users even if they haven't seen the previous notifications yet. So, that's not really the use case we're having here.

In the example, 1 and 2, 3 and 4, 5 and 6 are happening together, but they are not duplicates of each other. But as they happen together, we've implemented that silencing mechanism.

I's say, as step 1, we should introduce a global setting that turns this silencing mechanism off.