search

twomice / com.joineryhq.jsumfields

Provides additional fields under the Summary Fields framework.
Other
1 stars 10 forks source link

jsumfields civicrm_mailing_event_delivered_after_update db trigger prevents email delivery from being recorded, causes mailings to be sent indefinitely, sending many duplicate emails #25

Closed agileware-justin closed 7 months ago

agileware-justin commented 7 months ago

jsumfields civicrm_mailing_event_delivered_after_update db trigger prevents email delivery from being recorded, causes mailings to be sent indefinitely, sending many duplicate emails.

This is because the Send Scheduled Mailings job does not complete. The Mailing is not marked as completed. The Send Scheduled Mailings then restarts the same mailing, sending the same email again. Repeats for every cron run.

In our case, this was because the table, civicrm_value_summary_field_4 was missing in the database. Tried to figure out how to re-create the table but in the end the issue of duplicate emails being sent outweighed fixing the database or jsumfields.

Reporting this here to help others.

Agileware Ref: CIVICRM-2231

twomice commented 7 months ago

Thanks for reporting this @agileware-justin

Could you help me clarify a couple of things?

  1. You were able to solve this problem simply by uninstalling the jsumfields extension? No other action was necessary?
  2. Were you able to observe whether the proble re-appears after reinstalling the extension?
  3. Can you suggest a set of steps whereby others could recreate this problem in a clean civicrm installation?

Thanks again!

agileware-justin commented 7 months ago

Could you help me clarify a couple of things?

Absolutely!

You were able to solve this problem simply by uninstalling the jsumfields extension? No other action was necessary?

Yes

Were you able to observe whether the proble re-appears after reinstalling the extension?

Yes. The reason being that it appears that the end user had deleted the custom field group, Summary Fields. That was ultimately the source of the problem.

Can you suggest a set of steps whereby others could recreate this problem in a clean civicrm installation?

Sure can. Install Summary Fields and More Summary Fields extensions. Configure the extensions, set up Mail Open Event trigger in the More Summary Fields and then delete the custom field group, Summary Fields. Send a Mailing.

agileware-justin commented 7 months ago

Consequently, I am increasingly of the view that the Delete option in CiviCRM should be removed from the UI. This is yet another example of where it's use has caused a major headache for the end user. And this is not a problem that is solvable by individual extensions like this one. Thanks for taking the time to review.

I've commented along the lines here, https://github.com/civicrm/civicrm-core/pull/29460#issuecomment-1955777984

Really think the "Remove Delete" is worth solving with a CiviCRM core PR.

twomice commented 7 months ago

@agileware-justin Got it -- thanks for the details!

This is actually a problem in the Summary Fields extension as well. You can repro it like so:

  1. Install Summary Fields.
  2. Enable any summary field (in this example I'll use Total Lifetime Contributions)
  3. Perform an action that will trigger a change on that summary field (e.g. create a new contribution), and observe that the summary field is behaving normally (e.g. is updated to reflect that new contribution)
  4. Manually delete the custom field (e.g. Summary Fields :: Total Lifetime Contributions.)
  5. Attempt to repeat the action in step 3 and observe a fatal error along the lines of "DB Error: No such field".

I was hopeful that this situation could be resolved by doing one or more of the following:

However, these steps don't resolve the problem, and indeed some of them (re-anabling Summary Fields after uninstalling it) are not possible because of fatal errors due to the missing custom fields/group.

I'm pretty sure the place to address this is in the Summary Fields extension, not here in jsumfields. Some possible solutions in that extension could be:

In any case, considering this same behavior is reproducible in the sumfields extension, I don't believe there's a reasonable solution to be made here in jsumfields.

As such, I'll close this as essentially "won't fix". Naturally happy to discuss more if you have a different view of things, in which case feel free to re-open for further discussion.

agileware-justin commented 7 months ago

@twomice fair enough mate.

You might want to close this one too for the same reasons, https://github.com/twomice/com.joineryhq.jsumfields/issues/16

twomice commented 7 months ago

One more note on a tedious set of steps to resolve this kind of situation:

  1. This solves the problem in which Summary Fields triggers (and thus, jsumfields triggers) are causing fatal errors because someone has deleted the relevant custom field and/or the entire Summary Fields custom group. If that's not the problem, this is not the solution.
  2. As far as possible, take note of all existing Summary Fields configurations at [drupal.example.org]/civicrm/admin/setting/sumfields
  3. Uninstall the sumfields extension (and thus, jsumfields extension if it exists)
  4. Examine the file [sumfields-extension-dir]/settings/sumfields.setting.php and note the names of all settings defined therein (e.g. active_fields)
  5. Via SQL, delete all rows in civicrm_settings where name is one of those keys.
  6. Re-enable the sumfields extension (and jusumfields extension if it's needed).
  7. Visit the Summary Fields configuration page at [drupal.example.org]/civicrm/admin/setting/sumfields and re-configure everything according to the original settings that you took note of in step 2.
  8. Everything should be working fine now.
twomice commented 7 months ago

I've created an issue in sumfields for this: https://github.com/progressivetech/net.ourpowerbase.sumfields/issues/105