(dev/core#2673) Email Tokens - Custom tokens in subject block similar tokens in body

[twomice]

Overview

In an email, a token from an extension in a subject will inhibits the same token group in the email body.

Original ticket and proposed fix here: twomice/com.joineryhq.reltoken#15 and https://lab.civicrm.org/dev/core/-/issues/2673

Before

In an email, if I put a custom token {custom.name} in the subject and another custom token in the email body and then send the email, I will only receive the value of the {custom.name} that's in the subject. The other custom token in the email body will be blank. Example:

Subject: {custom.name}

Email Body
Name: {custom.name}
Age: {custom.age}
Gender: {custom.gender}

In the email, the {custom.name} is populated in subject and in body, but tokens {custom.age} and {custom.gender} are blank in body, even if they actually have values.

After

Tokens in body are correctly populated regardless of which tokens are used in the subject.

Technical Details

See ticket OP for technical analysis.

Comments

[none]

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[twomice]

Note +1 from end user at https://lab.civicrm.org/dev/core/-/issues/2673#note_62139

[totten]

Change looks conceptually simple/good, and the discussion thread seems to indicate it works (r-run) for 3 people.

r-maint: Ordinarily, for a bug like this, a unit-test would be pretty tempting. You could expect similar issues in other code that follows the CRM_Utils_Token patterns. But there's really no sensible way to target such code with a test... CRM_Utils_Token patterns are too spread-out/diffuse. Really, more of the token-mechanics should be shared (e.g. more code should use TokenProcessor instead of CRM_Utils_Token).

I've added a tangential test in #21090. If one is looking for a place to train some unit-testing muscles, they could potentially make a test for #21080 by borrowing bits from tests/phpunit/CRM/Activity/BAO/ActivityTest.php and #21090. But it's not critical in this context.

+1 for merge ready