Cancelled Emails are not suppressed

[yorkshirerose]

Drupal 7.92
CiviCRM 5.50.3

We've just run an update on the Drupal database and some CiviCRM extensions (e.g. Mosaico) and the Cancelled email has been triggered when using the 'Participant Status - change' action since the update.

I've created an alternative status (Class = Negative) and that does not trigger the email so we're using that temporarily.

[Fabian-SYSTOPIA]

Hi Rose, thanks for reporting. Could you check if the event(s) for which the emails were triggered have the option "Disable CiviCRM Default Messages" checked (in the event's communication tab). Also, could you let us know which version of the extension you are using and/or update to the latest release (currently 1.1beta3)

[yorkshirerose]

@Fabian-SYSTOPIA thanks for the quick reply. Yes to your first question, the option was definitely checked. For the second question, it's listed as '1.1-dev'. I did attempt to update it before reporting but I didn't use the beta3 release.

I'll update that and let you know if that resolves it.

[yorkshirerose]

@Fabian-SYSTOPIA just to get back to you, I have now updated CiviCRM and also this extension and tested, and the cancelled email was still triggered.

CiviCRM 5.55.2
Drupal 7.92
Event Messages 1.1-beta3

I book myself onto an event, then Find Participants > Search by event > Select Participant > Actions > Participant Status - change > Change to 'Cancelled'

Event Registration email is disabled by default, but the cancellation email is still sent.

[jensschuppe]

Can someone (@bjendres, @Fabian-SYSTOPIA, @yorkshirerose) confirm whether this might be a duplicate of #23?

[Fabian-SYSTOPIA]

I think the workflow Rose is describing is in the backend and not the "self-service-feature" described in #23

[bjendres]

I think the workflow Rose is describing is in the backend and not the "self-service-feature" described in #23

Yes, that sounds like it's the same issue. @yorkshirerose, could you check if the problem goes away with the version in https://github.com/systopia/de.systopia.eventmessages/tree/issue/23?

[yorkshirerose]

@bjendres Sorry, that's not fixed it. I can leave it installed if you want me to check anything else?

[bjendres]

@bjendres Sorry, that's not fixed it. I can leave it installed if you want me to check anything else?

Yes, that would be great! So, HERE's the code that looks into which mails to suppress. Could you get a stack trace at this point from a process where an email is sent and shouldn't have? If you could post that, we can adjust the filters accordingly.

[bjendres]

@bjendres Sorry, that's not fixed it. I can leave it installed if you want me to check anything else?

I have recently added some more the issue #23 branch. Could you check the latest version of https://github.com/systopia/de.systopia.eventmessages/tree/issue/23 again?

[bjendres]

@yorkshirerose Could you please check again with https://github.com/systopia/de.systopia.eventmessages/releases/tag/1.2.0? This should've been fixed with #23

[yorkshirerose]

@bjendres apologies for the slow reply, I've updated the extension but I'm still getting the same behaviour. Just to clarify:

• If I go to the list of Participants and select people, then choose ‘Cancel Participants’ in the Actions drop-down, this works fine (emails are surpressed)
• If I go to the Individual’s record and cancel it directly there, that’s also fine (emails are surpressed)
• However, if I go to the list of Participants and use the ‘Participant Status – Change’ and change someone to cancelled on that page, this does trigger the email

Thanks
Rose

[bjendres]

Hi Rose.

if I go to the list of Participants and use the ‘Participant Status – Change’ and change someone to cancelled on that page, this does trigger the email

Just to be sure: you mean your action triggers CiviCRM's default cancellation message to be sent, right? In addition to whatever rules you added to the rules of this extension?

[yorkshirerose]

Yes, that's right. The default event registration cancellation email is going out (we have surpressed all emails, it's an organisation that works with older people and is using events to track attendance at regular events for monitoring, so no self-service and we don't want any emails being triggered at all).

[bjendres]

don't want any emails being triggered at all

Ah, so you're basically using our extension to block CiviCRM's registration workflow emails, and are not using it to send alternative ones, correct?

I have to tell you, that the suppression of the CiviCRM's registration workflow emails has been quite a pain. We do this by analysing the stack trace of the call that trigger the email, but that is complicated and elusive (as the stack traces might change slightly with CiviCRM versions).

Wouldn't it be easier for you (and for us?) to base the suppression on URL rather than stack trace? Would you be open to an experiment?