Contrib.social

Drupal\push_framework\SourceItem::determineAndSetTasks() fails to set tasks

Open on Drupal.org →
Created on 6 June 2023, over 1 year ago
Updated 7 June 2023, over 1 year ago

Problem/Motivation

I'm evaluating danse/push_framework/pf_email modules for users to be able to subscribe to content/content types.

Having, via /admin:

- configured the content type to generate the danse CRUD events
- configured authenticated users to "Allow entity type subscription"/"Allow individual entity subscription"
- added the subscription field to the relevant content type, and configured to be displayed to the user
- enabled the pf_email module and left all settings as defaults

...the user can visit the relevant node and click the AJAX link and have a subscription stored in their user data.

If you then update the content via the node edit form and save, a DANSE event is triggered and visible in the list of all DANSE events.

This is all good.

It looks like though, when cron is next run, although there is a "Job" queued up, when it is processed, there is no email message sent for the generated event/notification.

Having debugged, it looks to me, with the context/configuration described above, like the first "if" condition in SourceItem::determineAndSetTasks() [1] always prevents (delivery) channels getting processed.

Looking further at the code history, it looks like changes [3] for this issue [2] may have affected things here.

Steps to reproduce

As per the steps laid out in the "Problem/Motivation" section

Proposed resolution

For me, again with the situation I described, if I change SourceItem::toArray() to return a "tasks" element value [4] of "$this->tasks ?? NULL" (instead of $this->tasks ?? []), things start working and emails get sent.

What I'm not sure of, being new to the module/code, is that this is the correct fix or may affect other situations (Ie when utilising the "push" functionality rather than subscription).

There seems to be another couple of possibilities to fix my situation:

Either:

1. SourceItem.php::determineAndSetTasks() needs to be dealing with an array and condition is: if (empty($this->tasks)) {
OR, 2. SourceItem.php::determineAndSetTasks() needs to be dealing with NULL and condition is: if (!isset($this->tasks)) {
OR 3. SourceItem.php::determineAndSetTasks() needs to deal with NULL and empty array if (!isset($this->tasks) || is_empty($this-tasks)) {

From the above, 2 is the current condition and the fix for my situation is to change [4] to 'tasks' => $this->tasks ?? NULL.

[1] https://git.drupalcode.org/project/push_framework/-/blob/2.2.x/src/Sourc...
[2] https://www.drupal.org/project/push_framework/issues/3331072 🐛 Access to uninitialized properties in SourceItem Fixed
[3] https://git.drupalcode.org/project/push_framework/-/commit/8bd3c5ed55a13...
[4] https://git.drupalcode.org/project/push_framework/-/blob/2.2.x/src/Sourc...

🐛 Bug report
Status

Fixed

Version

2.2

Component

Code

Created by

🇬🇧United Kingdom alex_sansom

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

Comments & Activities

  • Issue created by @alex_sansom
  • Comment over 1 year ago →
    System Message
    • jurgenhaas → committed a022ed00 on 2.2.x 
      Issue #3365086: Drupal\push_framework\SourceItem::determineAndSetTasks...
  • Status changed to Needs review over 1 year ago
  • Comment over 1 year ago →
    🇩🇪Germany jurgenhaas Gottmadingen

    Thanks you so much @alex_sansom for this bug report. I have to admit, this is one of the best bug reports in years. Amazing summary and analysis!!!

    You're absolutely right, that \Drupal\push_framework\SourceItem::toArray causes the issue and to fix this, I've taken even another approach: the local variable $task gets initialized to NULL, the \Drupal\push_framework\SourceItem::determineAndSetTasks checks for NULL and the \Drupal\push_framework\SourceItem::toArray now just uses $this->tasks again, as that variable will now always be initialized.

    Please give the latest dev release a try and set this issue to RTBC, if it's still working in your use case.

  • Comment over 1 year ago →
    🇬🇧United Kingdom alex_sansom

    As you suggested, I've just pulled the latest dev version @jurgen_haas and re-tested my scenario.

    All looks good to me, I see emails being generated where there were none before!

    Thank you very much for your efforts, especially speedy reply and fix.

  • Status changed to RTBC over 1 year ago
  • Comment over 1 year ago →
    🇬🇧United Kingdom alex_sansom
  • Status changed to Fixed over 1 year ago
  • Comment over 1 year ago →
    🇩🇪Germany jurgenhaas Gottmadingen

    Release 2.2.8 is on its way.

  • Comment over 1 year ago →
    System Message

    Automatically closed - issue fixed for 2 weeks with no activity.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024