CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-01-15T11:27:07Zhttps://lab.civicrm.org/dev/core/-/issues/4876Email greeting config crashes on some smarty `if` statements if quotes are in...2024-01-15T11:27:07ZDaveDEmail greeting config crashes on some smarty `if` statements if quotes are involvedI don't think this is recent, but in message templates I remember there was some handling so that you could do e.g. `{if '{token.something}' == ''}aaa{else}bbb{/if}`, and if `{token.something}`'s value contained apostrophes it would stil...I don't think this is recent, but in message templates I remember there was some handling so that you could do e.g. `{if '{token.something}' == ''}aaa{else}bbb{/if}`, and if `{token.something}`'s value contained apostrophes it would still work. I haven't checked if that's still working but if you do the same in an email greeting it will crash. Example:
1. Create a new contact with first name `D'Andre`.
2. Down in communication prefs choose customized for the email greeting and put `Dear {if '{contact.first_name}' == ''}Friend{else}{contact.first_name}{/if}`.
3. When you save it crashes because the apostrophe confuses it.
4. It's not related to choosing "customized". It happens if this is your normal config at admin - communications - email greetings.
5. It also happens if you try double-quotes and then the name contains a double-quote.
I can work around it with `Dear {if {contact.first_name|boolean}}{contact.first_name}{else}Friend{/if}`, but if I wanted to compare to an actual value that wouldn't help.https://lab.civicrm.org/dev/core/-/issues/4436Contact prefix not shown in mailing labels2023-07-18T17:56:58ZschorschiiContact prefix not shown in mailing labels## Overview
I tried to insert the contact prefix into the mailing label format. So I selected the "Individual Prefix" from the right drop-down menu and it inserts `{contact.prefix_id:label}` into the mailing label format textbox. However...## Overview
I tried to insert the contact prefix into the mailing label format. So I selected the "Individual Prefix" from the right drop-down menu and it inserts `{contact.prefix_id:label}` into the mailing label format textbox. However, this placeholder is never filled, i.e. it is always empty when creating mailing labels.
## Reproduction steps
1. Administer -> Localization -> Address Settings -> insert "Individual Prefix"/`{contact.prefix_id:label}` into textbox
2. Search contacts, select some from the result list, choose "Mailing labels - print" from the actions menu
## Current behaviour
The contact prefix is never shown on the mailing labels.
## Expected behaviour
The contact prefix should be shown on the mailing label PDF.
## Environment information
CiviCRM version 5.63.1 under WordPress, German language packhttps://lab.civicrm.org/dev/core/-/issues/4428Membership Fee token error in automatic membership renewal messages2023-09-24T22:49:30ZbwheelerMembership Fee token error in automatic membership renewal messagesOverview
----------------------------------------
This is related to another issue, https://lab.civicrm.org/dev/core/-/issues/3805 which was posted in https://civicrm.stackexchange.com/questions/42438/error-on-membership-fee-token-when-u...Overview
----------------------------------------
This is related to another issue, https://lab.civicrm.org/dev/core/-/issues/3805 which was posted in https://civicrm.stackexchange.com/questions/42438/error-on-membership-fee-token-when-using-print-merge-document/42443#42443
Reproduction steps
----------------------------------------
The original ticket has these reproduction steps:
I did a short test on the demo sandbox.
Selected "Find Membership" and selected one record. I then choose Print/Merge Document and added 2 tokens, {membership.id} and {membership.fee} Then clicked "Preview" to see the pdf outcome.
If I use only the token {membership.id} I do not get any error message and the preview is created.
Adding {membership.fee} I get the following error message below.
You can also reproduce the issue by creating an automatic membership renewal message with {membership.fee} in it and trying to send the renewal message.
Current behaviour
----------------------------------------
In the current version of Civi, the code will run but it will show 0.00 for the membership fee instead of the actual membership fee.
Expected behaviour
----------------------------------------
It should show the correct membership fee.
We propose fixing this with the following code. This won't match exactly the latest version of Civi because we're working off 5.58.1 but if it looks good, we'll submit a review with the latest version of Civi.
```diff
+++ b/sites/all/modules/civicrm/CRM/Member/Tokens.php
@@ -61,8 +61,17 @@ class CRM_Member_Tokens extends CRM_Core_EntityTokens {
*/
public function evaluateToken(\Civi\Token\TokenRow $row, $entity, $field, $prefetch = NULL) {
if ($field === 'fee') {
- $membershipType = CRM_Member_BAO_MembershipType::getMembershipType($this->getFieldValue($row, 'membership_type_id'));
- $row->tokens($entity, $field, \CRM_Utils_Money::formatLocaleNumericRoundedForDefaultCurrency($membershipType['minimum_fee']));
+ $membershipTypeId = $this->getFieldValue($row, 'membership_type_id');
+ if (empty($membershipTypeId) && isset($row->context['membershipId'])) {
+ $membership = CRM_Member_BAO_Membership::findById($row->context['membershipId']);
+ $membershipTypeId = $membership->membership_type_id;
+ }
+ $membershipType = CRM_Member_BAO_MembershipType::getMembershipType($membershipTypeId);
+ $minimumFee = 0;
+ if ($membershipType) {
+ $minimumFee = $membershipType['minimum_fee'];
+ }
+ $row->tokens($entity, $field, \CRM_Utils_Money::formatLocaleNumericRoundedForDefaultCurrency($minimumFee));
}
```https://lab.civicrm.org/dev/core/-/issues/4395Token support to allow us to migrate sort_name, display_name, address formats...2023-06-28T07:10:08ZeileenToken support to allow us to migrate sort_name, display_name, address formats to tokensWe have a goal to get sort_name, display_name and address formats to resolve using the standard token system, at the same time as the greetings are resolved.
Unfortunately there are some things they support at the moment that our tokens...We have a goal to get sort_name, display_name and address formats to resolve using the standard token system, at the same time as the greetings are resolved.
Unfortunately there are some things they support at the moment that our tokens don't. Our tokens DO support the default filter
`{contact.first_name|default:"donor"}`
and they support the magic space - ie
`{contact.first_name}{ }{contact.last_name}`
which resolves a space in the above, but not if there is no last name.
However, in sort name there is a variant on the magic space we don't currently support in tokens - - ie
`{contact.last_name}{, }{contact.first_name}`
The regex that supports that actually removes the whole `{}` contents if the following tag is empty or renders the contents otherwise.
This is pretty hard to make compatible with smarty :-(, which is a requirement to standardise. So ideally we would
1) make the magic syntax support know usages (within reason) which so far are the magic space, the magic comma and this variant
`{contact.first_name}{ ~ }{contact.nick_name}{ ~ }{contact.last_name}`
2) add a system-check to highlight notify using variations of the magic syntax other than the 3 on our radar that they may not work in future upgrades if we don't add support & direct them to this ticket to comment & explain the use case
3) depending on the variations that come out of 2 add 'micro-conditional support'
Note micro-conditionals was an idea @totten came up with when we were spit-balling this - I've pasted his thoughts below
---------------------------------------------------------------------------------------------------------------------
micro-conditionals: special tokens that conditionally display a handful of symbols
```
---------
{contact.first_name} {contact.last_name} { ~ } {contact.nick_name}
{contact.last_name}{ }{contact.first_name}
{contact.last_name}{, }{contact.first_name}
{contact.first_name}{ (}{contact.nick_name}{) }{contact.last_name}
Dear {contact.first_name}{?friend},
----------
{contact.first_name contact.last_name " ~ " contact.nick_name}
{contact.last_name " " contact.first_name}
{contact.last_name ", " contact.first_name}
{contact.first_name " (" contact.nick_name ") " contact.last_name}
Dear {contact.first_name ?friend},
----------
{{{contact.first_name contact.last_name ~ contact.nick_name}}}
{{{contact.last_name contact.first_name}}}
{{{contact.last_name, contact.first_name}}}
{{{contact.first_name (contact.nick_name) contact.last_name}}}
Dear {{{contact.first_name??"friend"}}},
-------------
```
Also note - first draft of appropriate test https://github.com/civicrm/civicrm-core/pull/26637/files#diff-a5d237ba4e392d0e8ad764a535315f0b1101cc5ca61c39b4e572de42f5c6b4bchttps://lab.civicrm.org/dev/core/-/issues/4379Preview support for event online template2023-06-20T13:20:13ZeileenPreview support for event online templateWe have preview support for the event offline template - but it doesn't cover additional participants - focussing for now on the line items I'm documenting what to expect
1) We will assign the same variables as other financial templates...We have preview support for the event offline template - but it doesn't cover additional participants - focussing for now on the line items I'm documenting what to expect
1) We will assign the same variables as other financial templates (taxRateBreakdown, lineItems)
2) I think we should also assign a participant specific version of the above & then toggle whether to show all or not based on whether the participant is primary.
I'm gonna add screen shots to what happens now during an online flow because I know there are existing inconsistencies and that is considered correct
Also refer https://github.com/civicrm/civicrm-core/pull/23098 for thoughts about 'right behaviour' and
https://lab.civicrm.org/dev/core/-/issues/224https://lab.civicrm.org/dev/core/-/issues/4366Vcards - tokens & other rendering2023-06-20T13:19:14ZeileenVcards - tokens & other renderingIt turns out we render html vcards for event locations in our emails - eg.
<div class="location vcard"><span class="adr"><span class="street-address">8 Baker Street</span><br />
<span class="extended-address">Upstairs</span><br />
<span...It turns out we render html vcards for event locations in our emails - eg.
<div class="location vcard"><span class="adr"><span class="street-address">8 Baker Street</span><br />
<span class="extended-address">Upstairs</span><br />
<span class="locality">London</span>,<br />
</span></div>
I'm not sure if this is
a) good - it's super helpful or
b) bad - it's copy & paste from our front end pages & lands us in the spam folder
I am hoping people will weigh in on the question of whether vcard html in email is desirable or not because making code do something silly more effectively is about 78 on my list of priorities.
If the former then I think we want to do it in a more standardised way than the dragon-code that currently does it.
I found a library https://github.com/jeroendesloovere/vcard
@colemanw also suggested an api calculated field (similar to contribution.paid_amount) although it could be tricky - see https://github.com/civicrm/civicrm-core/pull/26296#issuecomment-1561001040
We would want it to be an option for the token - ie regardless of whether there is a use case for the vcard in emails there is a use case for use to format addresses with line breaks.https://lab.civicrm.org/dev/core/-/issues/4291Smarty variable tokens not correctly processed in message subject2023-09-24T22:40:26Zmagnolia61Smarty variable tokens not correctly processed in message subjectOverview
----------------------------------------
Smarty variable tokens are not processed in message subject
Reproduction steps
----------------------------------------
1. In a message template body html we have for instance {capture a...Overview
----------------------------------------
Smarty variable tokens are not processed in message subject
Reproduction steps
----------------------------------------
1. In a message template body html we have for instance {capture assign="firstname"}{contact.first_name}{/capture}
2. We use {$firstname} in the body.
3. We use {$firstname} in the subject.
4. When sending a email manually the subject token gets replaced.
5. When sending via scheduled reminders or civirules the subject token does not get replaced.
6. Worse: our automatic birthday mail batch (civirules) got firstnames of the previous contact (only in the subject)
Current behaviour
----------------------------------------
smart variables are sometimes not correctly replaced as a token in the message subject
Expected behaviour
----------------------------------------
smart variables are sometimes always correctly replaced as a token in the message subject
Environment information
----------------------------------------
- CiviCRM: 5.61.2
- CMS: Drupal 7.97
- PHP: 7.4.33 (fpm-fcgi)
- Database: 10.5.19-MariaDB-0+deb11u2-log engine: InnoDB 10 row format: Dynamic
- Webserver: Apache/2.4.56 (Debian)
- OS: Linux
Comments
----------------------------------------
I will doublecheck if this is only the case with civirules or also with the scheduled remindershttps://lab.civicrm.org/dev/core/-/issues/4137Possible issue with Token processor and Smarty2023-03-03T20:07:08ZGuillaumeSorelPossible issue with Token processor and SmartyWhen using smarty logic with custom fields they don't get considered as numeric values any more so no calculation operation can be processed.
Sent as a 'normal' token, the token get merged. Nothing in the configuration changed. The custo...When using smarty logic with custom fields they don't get considered as numeric values any more so no calculation operation can be processed.
Sent as a 'normal' token, the token get merged. Nothing in the configuration changed. The custom are still declared as numeric.
If combined with smarty, they become simple 'text' values and in our situation nothing happens, when it should be.
This process was working since months until upgrading to 5.58.1 (on WP 6.1.1 and php 7.4) and was used many times to edit invoices:
```
{if $contact.custom_147==0}{else}- {contact.custom_147} Licences assurances annuelles = {$contact.custom_147*20}€{/if}
{if $contact.custom_154==0}{else}- {contact.custom_154} Licences assurances occasionnelles = {$contact.custom_154*15}€{/if}
{if $contact.custom_155==0}{else}- {contact.custom_155} Frais de gestion pour membre stagiaire en formation secourisme = {$contact.custom_155*10}€{/if}
{if $contact.custom_156==0}{else}- {contact.custom_156} Frais d'affiliation = {$contact.custom_156*150}€{/if}
Total réglé = {math equation="(op1*20)+(op2*15)+(op3*10)+(op4*150)" op1=$contact.custom_147 op2=$contact.custom_154 op3=$contact.custom_155 op4=$contact.custom_156}€
```
and this should show something like
- 2 Licences assurances annuelles = 40€
- 3 Frais de gestion pour membre stagiaire en formation secourisme = 30€
Total réglé = 70€https://lab.civicrm.org/dev/core/-/issues/3860{event.location} token in scheduled reminders doesn't include supplemental lines2022-09-23T15:32:31ZDaveD{event.location} token in scheduled reminders doesn't include supplemental linesWhen composing a scheduled reminder for events there's a choice of token `{event.location}`. If your event location uses the supplemental address lines they are not included in this token.
It's the same in 5.44 so not a recent change.When composing a scheduled reminder for events there's a choice of token `{event.location}`. If your event location uses the supplemental address lines they are not included in this token.
It's the same in 5.44 so not a recent change.https://lab.civicrm.org/dev/core/-/issues/3830API4 naming for custom field tokens (:name / :label)2022-09-09T10:15:16Zmagnolia61API4 naming for custom field tokens (:name / :label)Overview
----------------------------------------
With all the work on standardization of token processing we have come a long way. One missing element I think is the availability of api4 naming of the custom field tokens. In https://lab...Overview
----------------------------------------
With all the work on standardization of token processing we have come a long way. One missing element I think is the availability of api4 naming of the custom field tokens. In https://lab.civicrm.org/dev/core/-/issues/2650 this is out of scope. I would like to get this on the radar. Maybe it is an easy improvement.
Current behaviour
----------------------------------------
For core tokens :label and :name are supported to provide the raw value of label of the field. (eg. `{contact.communication_style_id:name} / | {contact.communication_style_id:label}`)
For custom fields this is not available:
`{contact.custom_1173:name} / {contact.custom_1173:name} `
The label of the field/token could be: "This is a long label" and the value: "long")
Proposed behaviour
----------------------------------------
For consistency and for easy usage in smarty conditionals it would be great if api4 naming availability for custom field tokens would be supported.
Comments
----------------------------------------
I can help test and sometimes I can code something myself if it an easy needle and I know where to look in the haystack
The overall token issue can be found here : https://lab.civicrm.org/dev/core/-/issues/2864https://lab.civicrm.org/dev/core/-/issues/2864Meta - token usage 5.43 standardisation effort2022-09-02T01:38:26ZeileenMeta - token usage 5.43 standardisation effortWe are doing a big token standardisation in 5.43 to solve multiple issues and blockers. By getting all these changes into 1 release we can also encourage people to specifically test that rc and any changes that they may need to make can ...We are doing a big token standardisation in 5.43 to solve multiple issues and blockers. By getting all these changes into 1 release we can also encourage people to specifically test that rc and any changes that they may need to make can be around the one release - documentation is [here](https://lab.civicrm.org/-/ide/project/documentation/docs/sysadmin/tree/case/-/docs/upgrade/version-specific.md/)
The goal is to consolidate such that
1. All token rendering is done through the token processor, token hooks are redundant and deprecated
2. All functions on CRM_Utils_Token are unused in core and deprecated except for those in the legacy BAO mailing classes.
3. We freeze, deprecate and phase out in legacy BAO classes in favour of flexmailer
4. All core classes that render tokens do so using consistent token naming & output conventions (rather than dates being formatted in various ways and fields sometimes outputting labels and other times values or name fields https://lab.civicrm.org/dev/core/-/issues/2650)
5. As much as possible we render via tokens rather than smarty in workflow message templates (that couples them with the entity rather than any form flow)
6. pdf & email & scheduled reminder tasks consistently offer the same entity-specific, contact & domain tokens
7. We can start to define obvious missing tokens such as `{domain.now}` (done), `{contribution.balance}` and formatted addresses
Task list / streams - this gives some idea of where things are progressing or blocked
- [x] standardise contact tokens to support/ advertise label style (e.g `{contact.prefix_id:label}`
- [x] make Contact tokens work with partial contact inputs - currently they only work with no contact array passed in, or an array with all possible values - currently blocked on a caching bug https://github.com/civicrm/civicrm-core/pull/21790
- [x] split contact tokens into own class & extend entity tokens like the other classes(blocked on stdise contact tokens)
- [x] switch contact tokens to use apiv4
- [x] work through standardising location token loading (this could go further - ie I had thought about adding loading for billing
- [x] date formatting standardisation [documentation](https://docs.civicrm.org/user/en/latest/common-workflows/tokens-and-mail-merge/#date) https://lab.civicrm.org/dev/core/-/issues/2746
- [x] locale sensitive standardised money formatting https://lab.civicrm.org/dev/core/-/issues/2638 & [pr](https://github.com/civicrm/civicrm-core/pull/21783)
- [x] switch badge tokens to use token processor
- [x] event tokens cleanup & loading fixes + remove unindexed query, move the `fee_amount` and `balance` tokens to the participant tokens class, fix event class to listen to either 'participantId' or 'eventId'. Participant class should run first & load eventId if required. Events should be cached in a static cache as it would be very rare to message thousands of events in one run.
- [x] Recurring contribution tokens work (currently availble in only the recurring_edit template with a pr to extend to cancelled recurring https://test.civicrm.org/job/CiviCRM-Core-PR/44632/
- [x] pdf letter is sane (https://lab.civicrm.org/dev/core/-/issues/2790) enough to extend to deliver tokens for other entities (participant https://lab.civicrm.org/dev/core/-/issues/780)
- [x] email letter extend to deliver tokens for other entities (membership & participant) (https://lab.civicrm.org/dev/core/-/issues/2862)
- [x] scheduled reminders supports participant tokens https://lab.civicrm.org/dev/core/-/issues/779
- [x] domain tokens are consistently available & render https://lab.civicrm.org/dev/core/-/issues/2838 - done but a gap on case tasks as they prioritise being able to filter tokens by case type
- [x] install flexmailer on new installs https://lab.civicrm.org/dev/core/-/issues/2836
- [ ] fix remaining places that process tokens other than via the payment processor
- [x] eliminate replaceGreeting - currently [blocked on apiv4 caching bug](https://github.com/civicrm/civicrm-core/pull/21790)
- [ ] fix CRM_Contact_BAO_Contact_Utils::updateGreeting to not call `getTokenDetails`
- [ ] confirm civicrm_api3_mailing_preview is replaced by flexmailer
- [x] remove getTokenDetails call from CRM_Contribute_Form_Task_PDFLetter - note this appears to be an expensive way to call the contact api & tokens are unused https://github.com/civicrm/civicrm-core/pull/21805
- [x] remove extra rendering in BAO_Pledge https://github.com/civicrm/civicrm-core/pull/21789
- [x] removed getTokenDetails from updatePledgeStatus https://github.com/civicrm/civicrm-core/pull/21847
- [x] remove getTokenDetails from transitionParticipants
- [ ] remove getTokenDetails from sendCancellation & cancelParticipant in selfsvc flow
- [ ] deliverGroup - replaced by flexmailer?
- [ ] MailingPage::preview - replaced by flexmailer?
- [ ] remove hook:;tokenValues from label task
- [ ] getAnonymousTokenDetails ???
- [ ] confirm BAO_Mailing::compose is only via flexmailer
- [x] communicate rc status via dev list
- [x] communicate changes via blog
- [ ] upgrade message https://lab.civicrm.org/dev/core/-/issues/2871
- [ ] docs update to these instructions / check it can still all be done https://docs.civicrm.org/dev/en/latest/step-by-step/create-custom-case-token/
**Currenly out of scope**
- [ ] Token.getlist api - until we have this we have an issue with audience-filtering and with switching tokens depending on the schema. Also case tasks still have to render tokens weirdly without this because they currently filter by case type with partial success https://lab.civicrm.org/dev/core/-/issues/2788
- [ ] Clarify how extensions should render tokens https://lab.civicrm.org/dev/core/-/issues/2863
- [ ] encourage flexmailer with status checks on existing installs https://lab.civicrm.org/dev/core/-/issues/2836
Analysis of current token rendering it core:
Method | Used in | Status
-- | -- | --
Use the token processor | scheduled reminders, civimail with flexmailer in use, activity pdf task | This is the method we are consolidating all paths to use.
Use the functions in CRM_Utils_Token | PDF tasks other than activity | Migrated (PRs on [membership](https://github.com/civicrm/civicrm-core/pull/21521) and [contribution](https://github.com/civicrm/civicrm-core/pull/21524). Also work on fixing up the [pdf task class](https://lab.civicrm.org/dev/core/-/issues/2790) supporting[add participant tokens](https://lab.civicrm.org/dev/core/-/issues/780) (once we’ve finished [the standardisation of those](https://github.com/civicrm/civicrm-core/pull/21587))
| Email tasks | Migrated to token processor. Added tokens for other entities (participant, membership https://lab.civicrm.org/dev/core/-/issues/1396) [also see](https://lab.civicrm.org/dev/core/-/issues/2862)
| Export tasks (when merging contacts in export) | Migrated to token processor
| Profile link rendering | Migrated to token processor
| Storing contact greetings (eg. email_greeting_display) | In progress. Currently resolving inconsistent token syntax and load issues as this needs to be able to use partial pre-loads
Use random ad hoc code | Event badges | [migrated](https://github.com/civicrm/civicrm-core/pull/21587) - this is the only place outside of scheduled reminders where event or participant tokens were used in core
| Send SMS task (BAO_Activity::sendSMS) | migrated
| Labels task CRM_Contact_Form_Task_Label | argh
| CRM_Event_Form_SelfSvcTransfer | Still pretty argh - but this is a workflow message template so the fix is a bit different
| Transition participants | Also a workflow - possibly redundant as seems to be mostly about contact tokens which are resolved in the send function anyway
| Pledge acknowledgements | Also appear to be redundant
| CiviMail with flexmailer not used (many functions & classes) | Push the switch to flexmailer.
| Various unsubscribe / resubscribe type actions | Probably out of scope for this roundhttps://lab.civicrm.org/dev/core/-/issues/2863Agree / document how tokens should be rendered from outside core2023-09-24T22:52:19ZeileenAgree / document how tokens should be rendered from outside coreIdeally we would have one recommended api way to do this. This would be a way that is usable via api explorer and all the ways we use the api and core code would be converted to do things using that same api method
There is [a documenta...Ideally we would have one recommended api way to do this. This would be a way that is usable via api explorer and all the ways we use the api and core code would be converted to do things using that same api method
There is [a documentation pr here](https://lab.civicrm.org/documentation/docs/dev/-/merge_requests/962) - at the moment I don't think it meets this need.
**Permissions & non-workflow rendering**
There is a question as to whether the api would support non-workflow messaging (in which case the api would likely be more like `Message::render()`. The argument against is that the permissions are more complex. However some notes on that
1) the most common use case is probably when checkPermissions = FALSE in php code.
2) there is an appropriate permission already in core
```
render templates' => [
$prefix . ts('render templates'),
ts('Render open-ended template content. (Additional constraints may apply to autoloaded records and specific notations.)'),
],
```
3) currently the v3 MessageTemplate.send api allows access to the core function - it required a messageTemplateID to be set - but this can probably be faked to allow 'any text'https://lab.civicrm.org/dev/core/-/issues/2848Activity tokens - case id - explain?2023-09-24T22:52:50ZeileenActivity tokens - case id - explain?@ayduns I recently fixed up some activity tokens that weren't working - but in the process @DaveD queried whether 'case_id' makes sense as a token on activity tokens since there could be more than one - just opening this put that to you....@ayduns I recently fixed up some activity tokens that weren't working - but in the process @DaveD queried whether 'case_id' makes sense as a token on activity tokens since there could be more than one - just opening this put that to you....
https://github.com/civicrm/civicrm-core/pull/21489#pullrequestreview-757039309https://lab.civicrm.org/dev/core/-/issues/2788Add tokenlist api2023-09-24T22:53:09ZeileenAdd tokenlist apiWe need an api to call via ajax to determine the available tokens for a given entity. An example is the Scheduled reminders UI which currently presents the tokens for all entities (available or not) but would ideally look up the tokens v...We need an api to call via ajax to determine the available tokens for a given entity. An example is the Scheduled reminders UI which currently presents the tokens for all entities (available or not) but would ideally look up the tokens via ajax once the entity is selected.
I think the hardest part of doing this is agreeing how it should look - eg. entity, action, parameters - eg
```
Civi\Api4\Tokens::list()
->setSchema(['contributionId', 'contactId')
->setWhere('contact_type', '=', 'Organization')
->execute();
```
Possible entity names
- Token
- Tokens
- TokenProcessor
- EntityTokens
Possible actions
-list
- getTokens
- listTokens
Schema - maybe this one is clear cut
And - how do we pass relatively free form tokens such as activity_type_id, contact_type or (possibly in the future) saved_search_id where search kit plays a rolehttps://lab.civicrm.org/dev/core/-/issues/2225Add a contact.checksum_raw token that does not include "cs="2023-09-24T22:53:45ZherbdoolAdd a contact.checksum_raw token that does not include "cs="Unlike all the other tokens which only include the actual data, such as `{contact.contact_id}`, the `{contact.checksum}` also includes the parameter name. There doesn't seem to be any good reason other than that is how it was always done...Unlike all the other tokens which only include the actual data, such as `{contact.contact_id}`, the `{contact.checksum}` also includes the parameter name. There doesn't seem to be any good reason other than that is how it was always done.
I suppose it's not possible to fix this token at this point since lots of existing links rely on it. But perhaps a new token? A bit messy but I need something like `{contact.checksum.raw}`