CiviCRM Scheduled Reminders, adds support for Participant fields and Participant Custom Fields as Tokens in Scheduled Reminders

[agileware-justin]

Overview

Adds support for Participant fields and Participant Custom Fields as Tokens in Scheduled Reminders.

Solves this Gitlab Feature Request, Custom Participant tokens not working in scheduled reminders
https://lab.civicrm.org/dev/core/-/issues/348

Before

Cannot use Participant fields or Participant Custom Fields as Tokens in Scheduled Reminders, which is sad 😢

After

Now able to use Participant fields or Participant Custom Fields as Tokens in Scheduled Reminders 😀

Technical Details

Includes commits from PR #20334 as the two are dependant on a change to the getCustomFieldTokens function.

Comments

Ping @mattwire

Agileware Ref: CIVICRM-1731

[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).

[eileenmcnaughton]

@totten probably best if you review this one once you get to that part of the message template work - it does extend our TokenProcessor surface & I want to be really clear about our test cover and about how we want to represent pseudoconstants etc before we extend our surface area on this

[magnolia61]

Thanks a lot for submitting this PR :-) I opened up an issue about this exact matter a while ago: https://lab.civicrm.org/dev/core/-/issues/348

I have been successful in testing this wonderful pr, except for custom date fields.
When I include a custom participant date field token in a reminder mail, it will stop all tokens from being processed.
Update: A custom event date field does work as expected. It's only the participant date fields.

Also the participant ID would be very very helpful if possible (for constructing links etc)

If you need help with further testing, I would be glad to do so. Cheers, Richard

[agileware-justin]

@magnolia61 glad you appreciate the work and thanks for testing too 😃

Update: A custom event date field does work as expected. It's only the participant date fields.

I've tested this by creating two additional date fields in the Participant, custom field set. This is working when I tested this using CiviCRM 5.37.

Would you mind providing a few screenshots:

1. Custom field configuration
2. Scheduled reminder template
3. Email or Activity that was generated

My test results are below.

1. Custom field configuration

2. Scheduled reminder template

3. Activity that was generated

[agileware-justin]

Also the participant ID would be very very helpful if possible (for constructing links etc)

@magnolia61 and I've added the Participant ID token, too. You're right this is useful.

[agileware-justin]

@magnolia61 ready for testing again :)

[totten]

I was chatting a bit with @eileenmcnaughton about this. (You may remember she'd spent a chunk of time on testing/comparing tokens for #19806.) She raised the point that we ought to have some test-coverage.

It can be a bit daunting to write a first test for this, but I think there's a good example at https://github.com/civicrm/civicrm-core/blob/5.38/tests/phpunit/CRM/Mailing/TokensTest.php#L6. It's really just the two functions -- getExampleTokens() and testTokensWithMailingId().

[agileware-justin]

@totten

(You may remember she'd spent a chunk of time on testing/comparing tokens for #19806.) She raised the point that we ought to have some test-coverage.

Not on my radar at all, thanks for pointing out

It's really just the two functions -- getExampleTokens() and testTokensWithMailingId().

Thanks for the tip. Will see what we can do here. Might be worthwhile to submit that as a follow-up PR because this one is a bit of a PITA to update already each time.

[MegaphoneJon]

Scheduled Reminders can also go to an "Additional Contact", and those contacts don't have to have a participant record. When doing manual testing, we should make sure that participant tokens handle the lack of a participant gracefully (which I think means returning NULL).

[agileware-justin]

@magnolia61 or @MegaphoneJon would either of you have time to do a follow-up PR with the unit tests for this PR?

[petednz]

or @jitendrapurohit

[agileware-justin]

Thanks @petednz

[magnolia61]

I am (technically) not able to write a test. @petednz are you suggesting that @jitendrapurohit would be able to do so?

[petednz]

technically he can, in terms of when he can get to it with our current workload is an open-ended question. it is not high on our list, just there as 'help the community' task when we can