(dev/core#2947) Tokens - Auto-enable {event.*} if participantId is present
#22046
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
(Standard links)
|
|
thanks @totten - I'll give a spin once tests pass on the demo site & then merge if r-run passes there |
The prior commit means that `$context['participantId']` will activate `{event.*}` tokens - in contexts
that use `TokenProcessor`. And the `TokenProcessor` is *somewhat* matched to the older functions.
This twiddles the match-up:
* Provide continuity for the deprecated `CRM_Core_SelectValues::participantTokens()` - so it still
only returns `{participant.*}` tokens. Borrow the technique which excludes `{domain.*}` tokens.
This should ensure better continuity for any callers that actually use `CRM_Utils_Token`.
* Update the assertions for the `TokenProcessor` to show that the `{event.*}` tokens are presented in
participant-related contexts.
|
Jenkins re test this please |
|
I just did an r-run on 5.43 & it worked |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
This patch addresses bug report https://lab.civicrm.org/dev/core/-/issues/2947 by revisiting some elements #21821.
CC @eileenmcnaughton @magnolia61
Before
{event.*}tokens don't work.{event.*}and{participant.*}tokens key off of independent inputs ($context['eventId']and$context['participantId']). OnlyparticipantIdis supplied for the PDF.After
{event.*}tokens do work.{event.*}and{participant.*}tokens may key off of independent inputs ($context['eventId']and$context['participantId']). However, ifeventIdis omitted, it will be filled automatically based onparticipantId.Technical Details
This is roughly similar to how participant PDFs worked in some of the 5.43.alpha1 revisions (ie before #21821), although the implementation is slightly different. To my reading, it's a bit more thorough... e.g. it fills
eventIdduring bothcivi.token.listandcivi.token.eval; e.g. it supplies theeventIdas part of thecontextso that it's available to any other listeners that consumeeventId.Adds test coverage.