I think we could pass some extra data with the extra key when we publish the event here:

We could add there e.g. extra: { force_email: true } and then detect it properly within the EmailNotificationGenerator that is being edited in this PR. I.e. when we have this key within the "extra" data, send the email regardless of the user's notification settings.

So regarding this, few questions to @arusa :

1. Would you like to do this change with your PR?
2. Could you also include regression tests with your PRs so that we will not reintroduce such bugs when we do refactoring on the codebase?
3. Could you fill in the PR template please?

Let us know, so we know how to proceed with this.

As a side effect, I think the user might receive the welcome notification twice, once as the initial email and once with the daily/weekly digest email but I would see this acceptable tradeoff just to fix this issue at hand. Otherwise we would need to change the notification email to be an individual email outside of the event context + do also some changes in the event notification programming API to support preventing sending some particular emails. The suggested approach would be much simpler to implement.

@arusa , please see @ahukkanen's comment.

As this PR didn't have any much activity since a couple of months, I went ahead and fixed the original problem on #10991.

Thanks for the report @arusa and thanks for the explanation on how to fix this @ahukkanen

I'm closing this issue as its already handled on #10991