Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-09-18T12:24:16Zhttps://lab.civicrm.org/dev/core/-/issues/4572Proposal: Retrieval of Defaults w/ Form Builder and Form Processor2023-09-18T12:24:16ZMariaVProposal: Retrieval of Defaults w/ Form Builder and Form ProcessorOverview
----------------------------------------
At the CiviSprint in Germany we found out that Submission forms (Form Builder) currently do not support use cases such as self-service forms that allow users to check and change their exi...Overview
----------------------------------------
At the CiviSprint in Germany we found out that Submission forms (Form Builder) currently do not support use cases such as self-service forms that allow users to check and change their existing contact data.
A lot of Wordpress projects use CalderaForms together with Form Processor to transfer the data to CiviCRM. In CalderaForms there is an option to activate Retrieval of Defaults:
![grafik](/uploads/912921154b32fbf34052c77dcf79b597/grafik.png)
As well as in Form Processor:
![grafik](/uploads/8802a13e8aa75798be4a25bfa9126fcf/grafik.png)
Caldera Forms allows passing URL parameters to the form processor – e.g. a contact CiviCRM ID along with a checksum to prove that the user is allowed to see and edit data for this particular contact, as a way of authentication without requiring a login. These URLs look as follows:
_https//link.org/example-page/cid={contact.contact_id}&{contact.checksum}_
With this information the form processor can retrieve data from within CiviCRM when the form is loaded and prefill fields in the form.
What works in the Form Builder already?
----------------------------------------
- Adding Form Processor as an entity
- Using Form Processor fields for a form
- Submitting/Creating data entered in submission form
- Using the entity id as an URL parameter (requires login)
What is missing?
----------------------------------------
- Option to enable retrieval of defaults (like in CalderaForms) to fill forms with existing data.
- Forms that work for anonymous users, using a checksum for authentication
Comments
----------------------------------------
If you need any further information, please let me know.
I could assist in setting up an example in a test environment since I am not able to implement this function myself.https://lab.civicrm.org/dev/core/-/issues/4221SearchKit: calculating average of money value does not result in money2023-09-18T12:49:57ZjmargrafSearchKit: calculating average of money value does not result in moneyOverview
----------------------------------------
We use SearchKit to calculate the average membership contribution.
The input values are in €. In Version 5.50.4 the result was presented as money [in €].
But with an update to Version 5.5...Overview
----------------------------------------
We use SearchKit to calculate the average membership contribution.
The input values are in €. In Version 5.50.4 the result was presented as money [in €].
But with an update to Version 5.58.1 the result is presented as a number instead of as money [in €].
The represenation of the mean value should als be as money [in €].
presentation in 5.50.4:
![mean-value-old](/uploads/9e17c1c2f8ea52b8aad08960fd9faeab/mean-value-old.png)
presentation in 5.58.1:
![mean-value-new](/uploads/22f212e498fe82dd0dac0b6291fc97f2/mean-value-new.png)
Reproduction steps
----------------------------------------
The following SearchKit configuration is used:
![searchkit](/uploads/f6f8ec275d84c34fff59e5edb341f5a0/searchkit.png)
Current behaviour
----------------------------------------
mean value is represented as a value
Expected behaviour
----------------------------------------
mean value should be represented as money [in €]
Environment information
----------------------------------------
* __CiviCRM:__ 5.58.1
* __CMS:__ Drupal 9.4.8https://lab.civicrm.org/dev/core/-/issues/4504Create new campaign "on the fly" when entering new contribution: custom field...2023-09-18T15:18:01ZDetlev SieberCreate new campaign "on the fly" when entering new contribution: custom fields are not supported## Overview
When I enter a new contribution as a CiviCRM Admin user, I can select a campaign - and, when the campaign is not found, I can add a new campaign.
However, the pop up screen for entering the new campaign does not include cam...## Overview
When I enter a new contribution as a CiviCRM Admin user, I can select a campaign - and, when the campaign is not found, I can add a new campaign.
However, the pop up screen for entering the new campaign does not include campaign custom fields - what makes this feature in certain use cases dysfunctional.
## Current behaviour
1. Create a custom field for a campaign.
2. Click on Campaigns -\> New Campaign: As you see on the screenshot, you can enter something in that custom field
![grafik.png](/uploads/82dd2d0b7dcf927ddef04e6cc6a60564/grafik.png)
3. Now, click on **Contributions -\> New Contributions**
4. Click on Campaigns and (1) enter some non-existent value. Now, you can click on "+" to enter a new campaign (2)
![grafik.png](/uploads/8aaf3446170f02b6fe7a0d9af8177431/grafik.png)
5. After Click on **New Campaign** a pop up opens where you can enter a new campaign - but here, the campaign's custom field is missing:
![grafik.png](/uploads/44069feb22709c809764a1db80d5d919/grafik.png)
## Proposed behaviour
It should be possible to access the custom fields in the same way as with **Campaign -\> New Campaign**
_What should happen? How is this better? If appropriate/available, include any wireframes or mockups._
##https://lab.civicrm.org/dev/core/-/issues/4579Importing contribution with same transaction id as an existing contribution h...2023-09-18T21:27:34ZDaveDImporting contribution with same transaction id as an existing contribution hijacks the initial contribution1. Create a contribution.
2. Give it a trxn id, or note the trxn id if it was automatic.
3. Do a contribution import, choosing to insert new records, where you make the trxn id in the file the same as the one just created, and with some ...1. Create a contribution.
2. Give it a trxn id, or note the trxn id if it was automatic.
3. Do a contribution import, choosing to insert new records, where you make the trxn id in the file the same as the one just created, and with some different particulars.
4. Notice that the contribution with that transaction id has now moved to whatever contact was in your import file, and the details updated.
What I would expect is that it says it's a duplicate and doesn't import it.
----
Edited since originally it came up with a recurring contribution but it applies to all.https://lab.civicrm.org/dev/core/-/issues/4581Define re-usable idiom for deferrable upgrade steps2023-09-19T13:05:13ZtottenDefine re-usable idiom for deferrable upgrade stepsOverview
----------------------------------------
In managing upgrade-steps, there is some tension between:
* Making the upgrades automatic for typical sysadmins
* Allowing very large deployments to schedule/manage expensive upgrade-st...Overview
----------------------------------------
In managing upgrade-steps, there is some tension between:
* Making the upgrades automatic for typical sysadmins
* Allowing very large deployments to schedule/manage expensive upgrade-steps
This proposes to balance those expectations by defining a _deferrable upgrade task_. Sysadmins can choose to approach them a few ways:
* "Just run the task like every other upgrade step" (*e.g. default; for average and small systems*)
* "Let me decide when to run it... but please don't make me figure out obscure incantations" (*for larger systems*)
* "Let me find a highly-optimized/bespoke way to accomplish the change" (*for extra-large systems with a team of admins*)
Example use-case
----------------------------------------
1. Take a table (like `civicrm_contact`, `civicrm_activity`, `civicrm_mailing_event_queue`) which can be very large on some deployments.
1. Define a schema change (e.g. add a column and an index)
1. Executing this change be quite slow.
1. In the long-term, all systems need the schema-change. If people skip it, then it will lead to problems/confusion/bug-reports/etc.
1. In the near-future, the schema change is not quite mandatory. (The new column isn't actively used; or its usages are limited+guarded.)
A sketch
----------------------------------------
* Designate a place to store a list of deferred upgrade steps (e.g. `civicrm_deferred_upgrade` or `civicrm_queue_item`)
* In the `CRM/Upgrade/` system, add some helpers to conditionally execute or defer a step. Ex:
```php
$this->addDeferrableTask(ts('Update CiviMail tracking'), 'doCiviMailQueueConversion');
```
```php
function addDeferrableTask($title, $funcName, $args) {
if (deferred upgrades enabled) {
// Add $title, $action, $args to a persistent TODO list
}
else {
$this->addTask($title, $funcName, $args);
}
}
```
* Add a system-status-check and post-upgrade message to warn if there are any of these things that need to run
* Add an API/job/command/UI to list/execute/skip/delete deferred stepshttps://lab.civicrm.org/dev/core/-/issues/4490Feature request - Queue api should respect maintenance mode2023-09-20T02:39:21ZeileenFeature request - Queue api should respect maintenance modeProposal to add a maintenance mode setting that is respected by the Queue api such that it would not permit `claimItems` while this setting is enabled - except for possibly upgrade tasks?
Note that when coworker respects this it should ...Proposal to add a maintenance mode setting that is respected by the Queue api such that it would not permit `claimItems` while this setting is enabled - except for possibly upgrade tasks?
Note that when coworker respects this it should log a message with a priority of `warning` so that a sysadmin can see that although the process is running no tasks are.
Chat discussion to date https://chat.civicrm.org/civicrm/pl/9h93yabz33g17qa3apcet8irdy
The summary of the chat is that `claimItem` api should be the place where maintenance mode is checked & heeded. This would be for 'persistent queues' - ie `CRM_Queue_Queue_Memory` would not check it.
- [ ] The claim item/s functions should call a symfony listener - returning false in this piece of code if an external listener (threshold check) sets the status to false
- [ ] we should add a setting for Maintenance mode (keep it simple) - call it `queue_maintenance_mode`? ClaimItem should return FALSE if this is TRUE
**Notes**
1) the following query will determine whether all queues have finished once maintenance mode is enabled:
`SELECT * FROM civicrm_queue_item where release_time > NOW()`
If future scheduling is in use (civi-rules?) then this might not suffice and if that ever arises as a feature someone wants to work on they could add a suitable field to the `civicrm_queue_item` table (`is_future_scheduled` ?)
2) I can't recall what we decided re should claimItems support an override - ie if you took everything else down in order to keep one queue running & want that queue to still claim items.... perhaps I'll find ithttps://lab.civicrm.org/dev/user-interface/-/issues/46Modernise ship-with-civi theme2023-09-20T15:55:57ZeileenModernise ship-with-civi themeI've opened this issue to see if we can agree on a way to improve the theme that ships with core (or to ship an additional theme with core) without the discussion spinning out into the technical sprawl that always seems to paralyse us on...I've opened this issue to see if we can agree on a way to improve the theme that ships with core (or to ship an additional theme with core) without the discussion spinning out into the technical sprawl that always seems to paralyse us on this issue...
**Problem statement**
CiviCRM ships with a theme looks dated and is off-putting to new adopters- some specific criticisms
- Colours are …. Beige. Current fashion would seem to be more white space (also drab in bootstrap)
- Button styling seems dated
- Some people seem to prefer side tabs - not sure if this is consensus
Goal of issue/discussion
- Find some achievable improvements
- Don’t get bogged down on solving everything
Potential solutions
- Improve the Greenwich theme - possibly as a paralell theme - addressing the most egregious issues (e.g just swapping colours / using more white makes it look more modern)
- Add an existing theme to core (Shoreditch, Aah, Finsbury park, Christian’s theme). Note that if we do this
1) it will mean that the theme becomes part of core codebase & would be maintained as such, with a priority place on maintainability and ensuring not too much css is downloaded (which might not always be in line with the designer’s vision).
2) bringing an existing theme into core would require the mainintainer agreeing to their theme being forked into a core extension & the core extension being maintained according to core maintenance priorities & principles. This may not be something current theme maintainers want as some design elements are likely to be sacrificed in the pursuit of maintainability / compatibility.
2) Anything that ships in core must work on all CMS and have acceptable page load speed for anonymouse users.
- Build up a minimal theme - ie what is the min theming we need to do to make it ‘load’ & move the rest of the css to greenwich (this is assuming a minimal theme would be better….)
Note that this ticket https://lab.civicrm.org/dev/user-interface/-/issues/33 covers previously discussion. Those discussions focussed on making it easier for themers to theme CiviCRM whereas the focus on this is what can we do to make the CiviCRM that ships with core look better.https://lab.civicrm.org/dev/core/-/issues/3869Cannot update contacts via profile from Search Kit results2023-09-22T02:06:27ZlarsssandergreenCannot update contacts via profile from Search Kit resultsIf you select contacts from Search Kit results and then select Profile Update from the Action menu, you are able to select a profile in the dialog box, but after clicking Continue, the dialog simply closes.
Tested on dmaster (5.55.alpha...If you select contacts from Search Kit results and then select Profile Update from the Action menu, you are able to select a profile in the dialog box, but after clicking Continue, the dialog simply closes.
Tested on dmaster (5.55.alpha1) and 5.49.5.https://lab.civicrm.org/dev/core/-/issues/4270CiviCRM Log File: Dates and Security2023-09-22T18:28:09ZAlanDixonCiviCRM Log File: Dates and SecurityOverview
----------------------------------------
The (text) log file generated by CiviCRM has three issues:
1. The risk of XSS (as described here: https://github.com/adixon/ca.civicrm.logviewer/issues/11)
2. The formatting of date/times...Overview
----------------------------------------
The (text) log file generated by CiviCRM has three issues:
1. The risk of XSS (as described here: https://github.com/adixon/ca.civicrm.logviewer/issues/11)
2. The formatting of date/times that are dependent on locale (as noted here: https://github.com/adixon/ca.civicrm.logviewer/pull/10)
3. The timezone of the date/time which is dependent on the source of the error but not specified in the output (i.e. the date time is of unknown and indeterminate timzeone).
Expected behaviour
----------------------------------------
1. I would expect the date/time of the error to be consistent and machine parseable and the timezone explicit.
2. I would expect the urls in the file to be XSS safe.
Comments
----------------------------------------
As per @bgm the log file date/times may be coming from a PEAR package.https://lab.civicrm.org/dev/core/-/issues/4607AdminUI: Scheduled Jobs Log: missing name of job and Execute Now button when ...2023-09-23T05:00:19ZcomposerjkAdminUI: Scheduled Jobs Log: missing name of job and Execute Now button when viewing a single scheduled job logOverview
----------------------------------------
In the newer AdminUI Scheduled Jobs single job log view, the following are missing:
- Name of the job log being viewed.
- `Execute Now` button to run the scheduled job.
Related to issue ...Overview
----------------------------------------
In the newer AdminUI Scheduled Jobs single job log view, the following are missing:
- Name of the job log being viewed.
- `Execute Now` button to run the scheduled job.
Related to issue #3912 and [PR 26060](https://github.com/civicrm/civicrm-core/pull/26060) by @ayduns.
Reproduction steps
----------------------------------------
1. Enable `AdminUI` extension.
1. Go to _CiviCRM > Administer > System Settings > Scheduled Jobs_
1. Select _View joblog_ for a single job.
1. Notice the job name missing and lack of the `Execute Now` button.
Current behaviour
----------------------------------------
AdminUI SearchKit replacement of Scheduled Jobs single job log view **without the job name nor the Execute Now button:**
![AdminUI SearchKit replacement of Scheduled Jobs single job log view](/uploads/f2fae4452c29db11bdfe0d6a19548342/image.png)
Expected behaviour
----------------------------------------
Should include the job name and the `Execute Now` button, assuming the goal is to recreate the existing Scheduled Jobs experience.
Original Scheduled Jobs view of single job log **with job name and Execute Now button:**
![Original Scheduled Jobs view of single job log with Execute Now button](/uploads/65b32b2690569d84eb6bfb646381522d/image.png)
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__ _Firefox 59.0.1/Chrome 78.0.3904/Safari 13_
* __CiviCRM:__ 5.65.1
* __PHP:__ 8.0.30
* __CMS:__ WordPress 6.2.2
* __Database:__ MariaDB 10.6.3https://lab.civicrm.org/dev/core/-/issues/4536Report improvements2023-09-23T05:02:21ZyashodhaReport improvements_Primary Membership_ filter option in _Membership Details_ report has options that don't make sense.
![dddsdsd](/uploads/0e74060c879cbaf416c85e8eb1067134/dddsdsd.png)
Remove options that don't make sense and add option to choose _All_..._Primary Membership_ filter option in _Membership Details_ report has options that don't make sense.
![dddsdsd](/uploads/0e74060c879cbaf416c85e8eb1067134/dddsdsd.png)
Remove options that don't make sense and add option to choose _All_ as well.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4520Simplify and improve offline event receipt template contribution section details2023-09-23T22:55:28ZlarsssandergreenSimplify and improve offline event receipt template contribution section detailsAn offline event receipt includes the following (in this case, for a pending (pay later) registration):
![image](/uploads/67eefa5dc465c6ee31b71d7523f2c20c/image.png)
Here's a non-pending one:
![image](/uploads/954f9780ed01de7e46519f6b...An offline event receipt includes the following (in this case, for a pending (pay later) registration):
![image](/uploads/67eefa5dc465c6ee31b71d7523f2c20c/image.png)
Here's a non-pending one:
![image](/uploads/954f9780ed01de7e46519f6b36f2dc2b/image.png)
1. I don't think we need to include Registration Date. I don't know when this would be useful information for the recipient. It is almost always going to be the date of the email and even if it isn't (which I think is only possible if you manually change the date while inputting the registration), what purpose does it serve for the recipient? Note that we have Transaction Date just below this and they are going to be the same almost all the time. If it is important to someone that we include both we could do so if they are different, but I don't really see why we need to include Registration Date in an email receipt.
1. Paid By: This should not be included if no payment was recorded, as it is misleading in that case.
1. Total Amount: This should be included and we should show a balance if no payment has been made and the status is pending (pay later) - but not if the status is otherwise, because then we can assume that we aren't charging the person. In this case, we shouldn't include a total at all.
1. Pay later text. This should be included if we register the person as pending (pay later) and this text exists. It looks like there is some attempt to include this in the template, but it doesn't seem to work - I think is_pay_later may not be set for offline registrations.
2. Financial Type: Do we need to include this? In general, I think it doesn't add anything, but I suppose it could be useful to differentiate donations from non-donations. Seems like that could also be misleading though, as only part of the contribution may be tax deductible. I'd lean on the side of removing this.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/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/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}`https://lab.civicrm.org/dev/core/-/issues/1516Discussion ticket for handling multivalued tokens in pdfs/emails2023-09-25T14:58:11ZDaveDDiscussion ticket for handling multivalued tokens in pdfs/emailsIn particular related to:
* https://github.com/civicrm/civicrm-core/pull/12012
* and its rebased version https://github.com/civicrm/civicrm-core/pull/16200
* https://github.com/civicrm/civicrm-core/pull/16208
There are a number of way...In particular related to:
* https://github.com/civicrm/civicrm-core/pull/12012
* and its rebased version https://github.com/civicrm/civicrm-core/pull/16200
* https://github.com/civicrm/civicrm-core/pull/16208
There are a number of ways to deal with multivalued fields when you need to produce scalar output based on the field.
For example:
* Take the "first" one.
* This has the disadvantage that "first" doesn't really mean anything, especially if the order is not guaranteed to be the same each time.
* Take the "last" one.
* Ditto.
* Combine them separated by commas.
* This has the disadvantage that it may not make any sense or might look silly. Consider something like the "With Contact" on an activity. Suppose there are 3. Suppose you want to include the primary phone of the contact. Your pdf might look like this. It's not terrible, but now think about adding in address too.
* With Contact: John Smith, Mary Brown, Indiana Jones
* Phone: 555-123-2222, , 555-383-8383
* And it's not clear to me that it can guarantee that the phone values are in the same order as the names when the tokens are separate.
* Do as in https://github.com/civicrm/civicrm-core/pull/12012, where you give the template designer the option to specify a numeric suffix on the token, e.g. {activity.target_2_display_name}. The way it's implemented there has some limitations:
* The order is still arbitrary - what does "2" actually mean?
* The template designer doesn't know max(N), so they can't easily do something like concatenate all of them if they want to.
* Provide some shorthand tokens for some common uses, e.g.
* {activity.target_1_phone} means arbitrarily take the first one.
* {activity.target_COMBINE_phone} means combine all with commas.
* {activity.target_ALL_phone} means give an array and I'll do some smarty-based looping in my template to get what I want.
Further, there are some situations where you might not want some recipients to see some of the other values. An example might be activity.case_id as in [16208](https://github.com/civicrm/civicrm-core/pull/16208). There maybe it makes sense to have a token that means "concatenate all the cases where the recipient has a role, and leave out the others". A similar one might apply for activity.target_display_name, where it might mean "concatenate all the with contact display names for activities where the recipient is one of the activity_contacts.
A related note that's just food for thought: In my other life, I always try to set up 2 fields when somebody asks for something multivalued. For example "services performed". Somebody might come to you asking for a couple of the different types of service you offer. You can designate one as the primary service, which is a single-valued field, which then makes reporting work because you don't run into double-counting, and then have a secondary services field that is multi-valued, which you don't use for reporting, and in emails/pdfs you can concatenate it without it being arbitrary because you would also output the primary which is single-valued. That may not be useful right now, but this is a discussion ticket.https://lab.civicrm.org/dev/core/-/issues/3682Feature request - `{domain.logo}`2023-09-25T19:36:31ZeileenFeature request - `{domain.logo}`Tim & I discussed the other day adding the `{domain.logo}` token. As always when this comes up we started with 'it would be very easy to do this minimal version' and by the end of the discussion the scope was un-manageable as unsponsored...Tim & I discussed the other day adding the `{domain.logo}` token. As always when this comes up we started with 'it would be very easy to do this minimal version' and by the end of the discussion the scope was un-manageable as unsponsored work.
However, I think the thing we CAN do is document it....
**The easy way**
`{domain.logo}`
refers to the image (if any) in the image_url field for the domain contact. That's it.
Probably we would need a version with `<img>` tags & one without.
**But then ... sizing & ^^ is too basic/ limited**
So next most complex is to use a setting. Once we start down this path we wind up having to develop a UI, handling sizing and it seems we might as well skip to....
**Mailing Component tokens**
In this version we would add a new component type to `civicrm_mailing_component` and rows of this type would be available as tokens using `{domain.{civicrm_mailing_component.name}}`. Placeholders ones for '{domain.logo}' and '{domain.header}' would be added. The existing UI could be used.
**And still spiralling**
- from there we got into trying to make it possible to nest the above, to use regions, to do the sort of thing the `entity_messages` token attempted to whereby we could store entity-related snippets (the idea was both to be able to insert a contribution specific block and to store entity-specific text to re-use - e.g to re-send an invoice with the original form-base message text)