Contrib.social

Possibly incorrect "silent" flag?

Open on Drupal.org →
Created on 31 May 2024, 6 months ago
Updated 1 June 2024, 6 months ago

Problem/Motivation

I'm not sure whether this is a bug or expected behavior so I'll just file it as a support request.

Problem: Under at least this one set of conditions, notifications are not created for an event when both "create" and "publish" events are checked on /admin/structure/types/manage/CONTENTTYPE.

Steps to reproduce

  1. A node is created by a user who does not have publish permission. Either it is published manually by user 1, or it is published by an ECA model that publishes the node when full payment is recorder. I've tried it both ways.
  2. Nobody has active notifications on the update event.
  3. Three users have active notifications on the publish event.

As nearly as I can tell, the problem arises in the getSubscriptionReferences function of modules/content/src/Payload.php (line 78). Although I guess it may really be in the subscriptionKey plugin, which is called by that function. Or maybe it's whatever sets the "silent" flag.

Specifically, when all boxes in the "create event" row are checked (Create Update Delete Publish Unpublish Comment) on admin/structure/types/manage/CONTENTTYPE:

  $references (line 78 of modules/content/src/Payload.php):
    Array
    (
        [0] => content-node-job_advertisement-0-update
    )
  $subscribers (line 245 of src/PluginBase.php):
    Array
    (
    )

(Remember, no one is subscribed to updates.)

Here's the relevant data:

  INSERT INTO `danse_event` (`id`, `uuid`, `plugin`, `topic`, `reference`, `label`, `payload`, `push`, `force`, `silent`, `processed`, `created`, `changed`, `uid`) VALUES
(120528, 'ea9d542b-30a4-4ba2-926d-482693b7481c', 'content', 'publish', 'node-271596', 'test20, test20 (Full-time, test20)', '{\"entity\":{\"type\":\"node\",\"bundle\":\"job_advertisement\",\"id\":\"271596\",\"label\":\"test20, test20 (Full-time, test20)\"},\"class\":\"Drupal\\\\danse_content\\\\Payload\"}', 1, 0, 1, 1, 1717113079, 1717113079, 1),
(120527, 'aa1262df-a79f-4ee1-a33d-1b87b7bd8b13', 'content', 'update', 'node-271596', 'test20, test20 (Full-time, test20)', '{\"entity\":{\"type\":\"node\",\"bundle\":\"job_advertisement\",\"id\":\"271596\",\"label\":\"test20, test20 (Full-time, test20)\"},\"class\":\"Drupal\\\\danse_content\\\\Payload\"}', 1, 0, 0, 1, 1717113079, 1717113098, 1),
(120526, 'a9f6f48c-5cda-4961-9274-f201d9606428', 'content', 'update', 'node-271596', 'test20, test20 (Full-time, test20)', '{\"entity\":{\"type\":\"node\",\"bundle\":\"job_advertisement\",\"id\":\"271596\",\"label\":\"test20, test20 (Full-time, test20)\"},\"class\":\"Drupal\\\\danse_content\\\\Payload\"}', 1, 0, 0, 1, 1717113022, 1717113098, 12495);

The "publish" event is there, but it's silent. The update event(s) are not silent, but no one is subscribed to them. Thus no one gets notifications. That doesn't seem right.

Now, when all boxes except Update in the "create event" row are checked:

  $references (line 78 of modules/content/src/Payload.php):
    Array
    (
        [0] => content-node-job_advertisement-0-publish
    )
  $subscribers (line 245 of src/PluginBase.php):
    Array
    (
        [0] => 1
        [1] => 7
        [2] => 1848
    )

And the data:

  INSERT INTO `danse_event` (`id`, `uuid`, `plugin`, `topic`, `reference`, `label`, `payload`, `push`, `force`, `silent`, `processed`, `created`, `changed`, `uid`) VALUES
(120529, '67ed6b60-1a4c-4fa8-a60c-0ee0acadef61', 'content', 'publish', 'node-271597', 'test21, test21 (Full-time, test21)', '{\"entity\":{\"type\":\"node\",\"bundle\":\"job_advertisement\",\"id\":\"271597\",\"label\":\"test21, test21 (Full-time, test21)\"},\"class\":\"Drupal\\\\danse_content\\\\Payload\"}', 1, 0, 0, 1, 1717113613, 1717113627, 1);

The notifications go out as expected.

I hope that makes sense. I'm just going to turn off the Update event for now so no urgency.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

💬 Support request
Status

Active

Version

2.3

Component

Code

Created by

🇺🇸United States rclemings

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @rclemings
  • Comment 6 months ago →
    🇩🇪Germany jurgenhaas Gottmadingen

    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.

  • Comment 6 months ago →
    🇺🇸United States rclemings

    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.

  • Comment 6 months ago →
    🇩🇪Germany jurgenhaas Gottmadingen

    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.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024