Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-04-24T23:29:16Zhttps://lab.civicrm.org/dev/core/-/issues/4218Submitting CiviMailings is flaky2023-04-24T23:29:16ZJonGoldSubmitting CiviMailings is flakyI've noticed several times that when you press "Submit Mailing" you get an error that says that submission was unsuccessful. I thought it was just me but now I'm getting user reports about it. Do others see this? I realize this isn't ...I've noticed several times that when you press "Submit Mailing" you get an error that says that submission was unsuccessful. I thought it was just me but now I'm getting user reports about it. Do others see this? I realize this isn't a proper bug report but I'm guessing this is common enough that folks can share their experiences and we can move toward a proper report.https://lab.civicrm.org/dev/core/-/issues/4216Primary email adress gets overwritten by profile submissions2023-04-12T13:09:09ZTobias Voigttobias.voigt@civiservice.dePrimary email adress gets overwritten by profile submissionsBehaviour:
When a profile (e.g. for a newsletter subscription) is submitted, the system searches through possible duplicates by checking, if an email address (a@a.com) already exists. If it finds an existing secondary email adress (and ...Behaviour:
When a profile (e.g. for a newsletter subscription) is submitted, the system searches through possible duplicates by checking, if an email address (a@a.com) already exists. If it finds an existing secondary email adress (and the profile is configured to retrieve the primary email adress, which makes sense for a newsletter subscription form) it overwrites the primary email (b@b.com)of the corresponding contact with the (secondary) address it found (a@a.com). The result is a contact that has two entries for email adresses (primary and secondary) that are the same (a@a.com). The former primary email (b@b.com) gets lost.
Expected behaviour:
When the system finds an existing secondary email address, it should set the marker for "Bulk Mailings" for that address. The primary email address should remain untouched.https://lab.civicrm.org/dev/core/-/issues/4215CiviCRM geographical data is never accurate2023-06-17T22:10:12ZJonGoldCiviCRM geographical data is never accurateOverview
----------------------------------------
We are constantly finding problems with our lists of country names, state/province names, and state/province abbreviations. We're missing some, others are incorrect. Some folks [have th...Overview
----------------------------------------
We are constantly finding problems with our lists of country names, state/province names, and state/province abbreviations. We're missing some, others are incorrect. Some folks [have thought](https://forum.civicrm.org/index.php%3Ftopic=32877.0.html) it'd be nice to automate it.
Unfortunately, this isn't very straightforward. The ISO source we claim to follow isn't publicly available. Even at the country level - many official names differ from what we use (e.g. "United Kingdom" vs. "United Kingdom of Great Britain and Northern Ireland"). And even "official names" differ depending on whether we reference Wikipedia, the CIA, etc.
So some of our data is wrong by everyone's standard - but is it worth fixing state/provinces if we don't fix countries?
The code
----------------------------------------
For giggles, I wrote a dirty script to identify discrepancies between Civi data and published data called [civiregioncheck](https://github.com/MegaphoneJon/civiregioncheck). It's not complete because given the volume of necessary changes, I don't want to sink effort into finishing it if we can't take action on it.
Attached is a partial list of discrepancies:
* Country names that don't match ISO-3166-1.
* State/provinces that have a matching ISO-3166-1 country and ISO-3166-2 name, but the abbreviation is incorrect.
Ideally we also find state/provinces that are missing (or dissolved), and state/provinces with a matching abbreviation but incorrect name.
What next?
----------------------------------------
Are we really changing the UK (above) or "United States" to "United States of America"? And if not, where do we draw the line? ISO-3166-1 current specifies the official country name of Taiwan as "Taiwan, Province of China". And we include Kosovo despite it not having an official ISO 3166-1 code.
If this is too thorny to hash out, we'll go back to our patchwork process - but our data has hundreds of discrepancies.
[civi_geographic_discrepancies.csv](/uploads/b6a99ec66ef4f1affadab53b61027b1d/civi_geographic_discrepancies.csv)JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4214Too many CiviCRM custom fields breaks logging resulting in mysterious errors2023-04-05T14:36:26Zluke.stewartToo many CiviCRM custom fields breaks logging resulting in mysterious errorsOverview
----------------------------------------
If for some strange reason you decide to create **_a lot_** of custom fields - and use detailed logging you can break stuff rather badly without getting a nice warning.
Reproduction ...Overview
----------------------------------------
If for some strange reason you decide to create **_a lot_** of custom fields - and use detailed logging you can break stuff rather badly without getting a nice warning.
Reproduction steps
----------------------------------------
1. Turn on detailed logging
1. Create yourself a custom field group - or use one you've prepared earlier.
1. Add a lot of text fields with max length. This probably depends on database settings - for mariadb what your database innodb_page_size variable is set to.
1. At some point you will be able to add new fields to the custom group - but the row size will be exceeded when these fields are added to the log_custom_group_value_thing_table.
1. From this point on any operation attempting to write data into that table will result in errors when Detail logging is turned on. However due to the joys of detailed logging it will say something like field X doesn't exist - however it does - but field Y will exist on that table but not on the log_table.
1. You will possibly notice a small error message showing when turning detailed logging on.
Current behaviour
----------------------------------------
You get errors like this when turning
```
[nativecode=1118 ** Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs]
```
Expected behaviour
----------------------------------------
You should probably not be able to create custom fields after a certain point. however perhaps more to the point - if there is an error turning detailed logging on and it relates to a schema mismatch then perhaps it would be better to - turn the detailed logging back off - return a Computer says no message - along with a list of log tables that don't match what they should.https://lab.civicrm.org/dev/core/-/issues/4213Make frontend_title consistently required and use it in all front end present...2023-04-04T08:46:17ZeileenMake frontend_title consistently required and use it in all front end presentationsWhen we added frontend_title it was an optional override for title, which would fall back to title but this has been confusing to manage and means things like the token `{group.frontend_title}` token don't work and usage is inconsistent....When we added frontend_title it was an optional override for title, which would fall back to title but this has been confusing to manage and means things like the token `{group.frontend_title}` token don't work and usage is inconsistent.
The affected entities are
- Contribution Page
- Group
- Profile (UFGroup)
- PaymentProcessor - but this already follows the schema in this proposal
We need to get to a more consistent space. Front end title is currently effectively required (as it falls back to title) & holds the contents of title, or frontend title so the scope of this change is to make that the case at the DB / form level and then fix front end usages to display the front end title (only).
This addresses the inconsistencies and means that by requiring people to enter front end title they will be prompted to think about what the public see when creating the title.
There are some requests to permit title to be blank - the difficulties around handling this are what has caused us not to embark on addressing the consistencies to date. However, part of that request is better addressed through Wordpress - ie https://lab.civicrm.org/dev/core/-/issues/4212 and the other articulated reason is to ensure people are not accidentally exposing inappropriate names (which making it required will do).
There might be other reasons that an 'allow blank' feature might make sense - but I think we need to separate that feature request from our need to get to a sane place with frontend titles - so the plan is for 5.61 we will
1) make all frontend title fields required at the DB level & form level
2) do a db upgrade to populate these fields with the values in title
3) ensure that front end references always just display frontend_title.https://lab.civicrm.org/dev/core/-/issues/4212Wordpress - allow suppressing CiviCRM title in profiles / contribution pages?...2023-04-04T08:45:49ZeileenWordpress - allow suppressing CiviCRM title in profiles / contribution pages? when displaying via short codeThere is a problem @justinfreeman has been reporting whereby you wind up with double-titles because the title is not optional on the CiviCRM or the Wordpress level.
I think the right fix for this is to handle in within the short code co...There is a problem @justinfreeman has been reporting whereby you wind up with double-titles because the title is not optional on the CiviCRM or the Wordpress level.
I think the right fix for this is to handle in within the short code configuration - do you have any thoughts on how to do that @kcristiano @haystack ?
![image](/uploads/e40555c9a25d0948ca0dc5f8d60daa1f/image.png)
![image](/uploads/0a1231cdc2be7d04feeb0801163b0d38/image.png)https://lab.civicrm.org/dev/core/-/issues/4210Only possible to add A-B relationships types or B-A relationship types (not b...2023-04-04T08:45:11ZScottMasonOnly possible to add A-B relationships types or B-A relationship types (not both) to new contact using Form BuilderWhen using Form Builder to create a new contact and then add relationships to that contact using a single form it appears that it is only possible to select to add A-B relationship or B-A relationships but not both. For example, if creat...When using Form Builder to create a new contact and then add relationships to that contact using a single form it appears that it is only possible to select to add A-B relationship or B-A relationships but not both. For example, if creating a new Individual the form can be configured to allow users to add 'Child of' relationships or 'Parent of' relationships but not both.
1. Create a new contact form using form builder
2. Add a relationship fieldset
3. Set as a default value either Contact A or Contact B as 'Organisation1' (i.e. the new contact being created) - see image below.
![image](/uploads/49caec4139d87f8e17878e4785fabec3/image.png)
4. Quite understandably if Organisation1 is set as 'Contact A' only A-B relationship types can be selected in the form and if Organisation1 is set to 'Contact B' only B-A relationship types can be selected. For example, in our case if adding a new company it is possible to add 'Parent of' relationships to the new company but not 'Subsidiary of' relationships.
![image](/uploads/bf24ad54c5fff2ff4c3011d7c8900ca4/image.png)
This is logical given the way the form has been configured, so I am not sure if this is necessarily a 'bug' but I wondered if there was a way of configuring the form so that I user can select both A-B and B-A relationship types when adding relationships using form builder?
Thanks
Scotthttps://lab.civicrm.org/dev/core/-/issues/4209Form builder does not load activity 'details' in pop-up edit mode2023-04-04T08:44:40ZScottMasonForm builder does not load activity 'details' in pop-up edit mode1. Create a form builder for an activity including the 'details' field
2. Add an activity using the form
3. Create a SK display for activities with a menu item 'edit' configured to load the form in popup mode
4. Select edit from the SK d...1. Create a form builder for an activity including the 'details' field
2. Add an activity using the form
3. Create a SK display for activities with a menu item 'edit' configured to load the form in popup mode
4. Select edit from the SK display - the form is loaded with all data except for the details field which is blank.
Strangely when tested on dmaster demo the popup appears to load the details data on the first load but not any subsquent attempts.
![image](/uploads/9149c476f4563d457425512dd024398a/image.png)https://lab.civicrm.org/dev/core/-/issues/4208Generating invoices generates an error with version >= 0.12.6 of wkhtmltopdf.2023-04-04T08:44:14ZeileenGenerating invoices generates an error with version >= 0.12.6 of wkhtmltopdf.Full detail in https://github.com/civicrm/civicrm-core/pull/23055 - am creating this to track that issue as the patch is not mergeable as isFull detail in https://github.com/civicrm/civicrm-core/pull/23055 - am creating this to track that issue as the patch is not mergeable as ishttps://lab.civicrm.org/dev/core/-/issues/4203add end date to petition2023-03-27T06:52:21Zjamieadd end date to petitionOverview
----------------------------------------
This proposed feature would add a new field to petitions called: End date. If someone tries to sign a petition that has an end date in the past, they would get a friendly error warning t...Overview
----------------------------------------
This proposed feature would add a new field to petitions called: End date. If someone tries to sign a petition that has an end date in the past, they would get a friendly error warning them that the petition is no longer active.
Current behaviour
----------------------------------------
Now, we can create petitions and manually disable them. However there are two problems:
1. If you disable a petition it no longer shows up in advanced search so you can no longer find signatories.
2. It's easy to forget to disable a petition. That means these potentially spam-collecting forms can live on for too long
3.
Proposed behaviour
----------------------------------------
By adding an end date when you create the petition, you can set it up and forget about it.
Comments
----------------------------------------
I'm open to taking a crack at implementing, but wanted to first get feedback to see if this is the best way to go about it or if there are any potential pitfalls.https://lab.civicrm.org/dev/core/-/issues/4199SearchKit: DB Error: no such field a.total_amount when adding Tax Exclusive A...2023-03-24T03:46:42ZherbdoolSearchKit: DB Error: no such field a.total_amount when adding Tax Exclusive Amount and Balance (starting with Line Items : Contributions)Overview
----------------------------------------
There's an "Unknown column `a.total_amount` when trying to add these fields onto a SearchKit search that starts with `Line Items` and with `Contributions`:
Line Item Contribution: Tax Ex...Overview
----------------------------------------
There's an "Unknown column `a.total_amount` when trying to add these fields onto a SearchKit search that starts with `Line Items` and with `Contributions`:
Line Item Contribution: Tax Exclusive Amount
Line Item Contribution: Balance
**Note this only happens when starting with Line Items and *not* when starting with Contributions (and optionally adding Line Items).**
It's adding a field like this:
```
COALESCE(a.total_amount, 0) - COALESCE(a.tax_amount, 0) AS `LineItem_Contribution_contribution_id_01.tax_exclusive_amount`
```
and like this:
```
a.total_amount - COALESCE((SELECT SUM(ft.total_amount) FROM civicrm_financial_trxn ft
INNER JOIN civicrm_entity_financial_trxn eft ON (eft.financial_trxn_id = ft.id AND eft.entity_table = 'civicrm_contribution')
WHERE eft.entity_id = a.id AND ft.is_payment = 1 AND ft.status_id IN (1,7)), 0) AS `LineItem_Contribution_contribution_id_01.balance_amount`
```
where `a` is `civicrm_line_item`. It's assuming, I think, that the first table is `civicrm_contributions`.
Current behaviour
----------------------------------------
_What happens currently. Please provide error messages, screenshots or gifs ([LICEcap](http://www.cockos.com/licecap/), [SilentCast](https://github.com/colinkeenan/silentcast)) where appropriate._
Environment information
----------------------------------------
* __CiviCRM:__ 5.58.1 (but I looked through the release notes and I don't think it was fixed in 5.59.x)https://lab.civicrm.org/dev/core/-/issues/4198Access to undeclared variable in merge code2023-03-23T14:06:20ZRichAccess to undeclared variable in merge codeAt:
https://lab.civicrm.org/dev/core/-/blob/96d550c70dd1f406851895ddfe236fbfd718ab77/CRM/Dedupe/Merger.php#L1376
we reference `$migrationData` which is not declared. I have a hunch it should be `$migrationInfo`?
Ping @eileenAt:
https://lab.civicrm.org/dev/core/-/blob/96d550c70dd1f406851895ddfe236fbfd718ab77/CRM/Dedupe/Merger.php#L1376
we reference `$migrationData` which is not declared. I have a hunch it should be `$migrationInfo`?
Ping @eileenhttps://lab.civicrm.org/dev/core/-/issues/4196hook_civicrm_links - are the docs wrong or the code?2023-03-23T20:11:09ZJonGoldhook_civicrm_links - are the docs wrong or the code?The docs for `hook_civicrm_links` provides this signature:
```php
hook_civicrm_links(string $op, string $objectName, int $objectID, array &$links, int &$mask, array &$values)
```
However, the type hinting isn't always correct. I've fo...The docs for `hook_civicrm_links` provides this signature:
```php
hook_civicrm_links(string $op, string $objectName, int $objectID, array &$links, int &$mask, array &$values)
```
However, the type hinting isn't always correct. I've found:
* PCP pages pass `NULL` for `$mask`.
* The extensions page passes a string for `$objectID`.
Should we change the docs or the code?https://lab.civicrm.org/dev/core/-/issues/4195Cannot reach custom fields on Contributions from SearchKit2023-03-23T14:29:20ZRichCannot reach custom fields on Contributions from SearchKitNot sure if this is a bug or a feature request. Is it a bug if SK can't do what advanced search can?
Custom fields (1-1) on Contributions can be used in Api4, but are not reachable in SK; the fields are not listed in the "With/on" field...Not sure if this is a bug or a feature request. Is it a bug if SK can't do what advanced search can?
Custom fields (1-1) on Contributions can be used in Api4, but are not reachable in SK; the fields are not listed in the "With/on" fieldsets, and I couldn't find a CustomValues or such entity to add as a second "With".https://lab.civicrm.org/dev/core/-/issues/4194Proposal - remove some fields from dedupe field options2023-03-27T02:42:05ZeileenProposal - remove some fields from dedupe field optionsWhen creating dedupe rules there are some fields in the drop down that don't make sense to me
![image](/uploads/87e8fe511a5e795ce362dd7027705505/image.png)
Specifically
**Irrational (technical term)**
(if these are present the dedupe...When creating dedupe rules there are some fields in the drop down that don't make sense to me
![image](/uploads/87e8fe511a5e795ce362dd7027705505/image.png)
Specifically
**Irrational (technical term)**
(if these are present the dedupe rule functionality won't apply)
- 'id' => 'Contact ID',
- 'external_identifier' => 'External Identifier',
**Dumb (technical term)**
- Contact.is_deceased
- 'addressee_id' => 'Addressee',
- 'addressee_custom' => 'Addressee Custom',
- 'do_not_email' => 'Do Not Email',
- 'do_not_mail' => 'Do Not Mail',
- 'do_not_phone' => 'Do Not Phone',
- 'do_not_sms' => 'Do Not Sms',
- 'do_not_trade' => 'Do Not Trade',
- 'email_greeting_id' => 'Email Greeting',
- 'email_greeting_custom' => 'Email Greeting Custom',
- 'external_identifier' => 'External Identifier',
- 'image_URL' => 'Image Url',
- 'is_opt_out' => 'No Bulk Emails (User Opt Out)',
- 'postal_greeting_id' => 'Postal Greeting',
- 'postal_greeting_custom' => 'Postal Greeting Custom',
- 'preferred_communication_method' => 'Preferred Communication Method',
- 'communication_style_id' => 'Communication Style',
- 'signature_html' => 'Signature Html',
- 'signature_text' => 'Signature Text',
**Marginal (laymans' term) **
- 'geo_code_1' => 'Latitude',
- 'geo_code_2' => 'Longitude',
- 'master_id' => 'Master Address ID',
<details>
<summary>Full list - excluding custom fields</summary>
```
/**
* Get the list of supportedFields to test against.
*
* This is a statically maintained (in this test list).
*
*/
public function getSupportedFields() {
return [
'civicrm_address' =>
[
'name' => 'Address Name',
'city' => 'City',
'country_id' => 'Country',
'county_id' => 'County',
'geo_code_1' => 'Latitude',
'geo_code_2' => 'Longitude',
'master_id' => 'Master Address ID',
'postal_code' => 'Postal Code',
'postal_code_suffix' => 'Postal Code Suffix',
'state_province_id' => 'State',
'street_address' => 'Street Address',
'supplemental_address_1' => 'Supplemental Address 1',
'supplemental_address_2' => 'Supplemental Address 2',
'supplemental_address_3' => 'Supplemental Address 3',
],
'civicrm_contact' =>
[
'addressee_id' => 'Addressee',
'addressee_custom' => 'Addressee Custom',
'id' => 'Contact ID',
'source' => 'Contact Source',
'contact_sub_type' => 'Contact Subtype',
'do_not_email' => 'Do Not Email',
'do_not_mail' => 'Do Not Mail',
'do_not_phone' => 'Do Not Phone',
'do_not_sms' => 'Do Not Sms',
'do_not_trade' => 'Do Not Trade',
'email_greeting_id' => 'Email Greeting',
'email_greeting_custom' => 'Email Greeting Custom',
'external_identifier' => 'External Identifier',
'image_URL' => 'Image Url',
'legal_identifier' => 'Legal Identifier',
'legal_name' => 'Legal Name',
'nick_name' => 'Nickname',
'is_opt_out' => 'No Bulk Emails (User Opt Out)',
'organization_name' => 'Organization Name',
'postal_greeting_id' => 'Postal Greeting',
'postal_greeting_custom' => 'Postal Greeting Custom',
'preferred_communication_method' => 'Preferred Communication Method',
'preferred_language' => 'Preferred Language',
'sic_code' => 'Sic Code',
'user_unique_id' => 'Unique ID (OpenID)',
'sort_name' => 'Sort Name',
'communication_style_id' => 'Communication Style',
],
'civicrm_email' =>
[
'email' => 'Email',
'signature_html' => 'Signature Html',
'signature_text' => 'Signature Text',
],
'civicrm_im' =>
[
'name' => 'IM Screen Name',
],
'civicrm_note' =>
[
'note' => 'Note',
],
'civicrm_openid' =>
[
'openid' => 'OpenID',
],
'civicrm_phone' =>
[
'phone_numeric' => 'Phone',
'phone_ext' => 'Phone Extension',
],
'civicrm_website' =>
[
'url' => 'Website',
],
];
}
```
</details>
'sic_code' => 'Sic Code',
'user_unique_id' => 'Unique ID (OpenID)',https://lab.civicrm.org/dev/core/-/issues/4193Possible issue with recursive locks2023-03-24T09:24:48ZeileenPossible issue with recursive locksI've brought this over from [pr 22013](https://github.com/civicrm/civicrm-core/pull/22013) because it needs to be discussed in gitlab before it can be reviewed as a PR & hence doesn't belong in the PR queue at this stage.
Note that par...I've brought this over from [pr 22013](https://github.com/civicrm/civicrm-core/pull/22013) because it needs to be discussed in gitlab before it can be reviewed as a PR & hence doesn't belong in the PR queue at this stage.
Note that part of the confusion is the recursion is within a process / connection from my understanding - which is where php statics would be used. Mysql locks are our protection against other processes.
On a version of Maria DB > 10.0.2 I can reserve a lock in one process (recursively if I want)
![image](/uploads/1e3a1f2b6bd34391fcff9225cc15ca44/image.png)
But cannot get it in the other process unless it times out
![image](/uploads/9f45a6eba869d2fda0c748365940aedc/image.png)
What moved the other along was an explanation as to how a problem could arise (e.g like https://lab.civicrm.org/dev/core/-/issues/3988#note_87911 ).
----------------FROM gitlab
From MariaDB 10.0.2 it is possible to recursively set the same lock. This completely breaks the locking mechanism in CRM_Core_Lock because it assumes that GET_LOCK can only be called once for a named lock.
See: https://mariadb.com/kb/en/get_lock/ "From MariaDB 10.0.2, it is also possible to recursively set the same lock".
This is certainly the case on MariaDB 10.3. But I ran some tests on 10.5 and it doesn't seem to allow you to recursively set the same lock anymore. So I think this goes a long way to explaining why locking doesn't seem to be working properly on some sites.
Before
CiviCRM locking mechanism doesn't work on versions of MariaDB (between 10.0.2-10.4.x?) as multiple locks of the same name can be acquired.
After
CiviCRM locking mechanism works on mariaDB to limit each lock to a single named lock.
Technical Details
Described above.https://lab.civicrm.org/dev/core/-/issues/4192Improvement: Required? when creating Custom Field2023-03-23T08:14:19ZStoobImprovement: Required? when creating Custom FieldAfter many years in my position working with clients, and even explicit training on this issue, clients continue to flummox themselves by not reading the 'help text' and clicking **Required? [ ]** in a Custom Data field ... when that in ...After many years in my position working with clients, and even explicit training on this issue, clients continue to flummox themselves by not reading the 'help text' and clicking **Required? [ ]** in a Custom Data field ... when that in fact isn't their intent.
Proposal Pt 1: Expanding the caution to the label itself like so: **[ ] Always require a value?**
Proposal Pt 2: Clarifying the help text like so. **This forces a value in this field to create or edit this type of record. To make a field required on a specific form, use a Profile.**
In a comparison other software:
Salesforce:
`[ ] Always require a value in this field in order to save a record`
Network for Good:
`[ ] Required?` same as Civi but I like their help text a bit better than Civi's `If "Yes" this custom field will be required when manually adding/editing contacts.`https://lab.civicrm.org/dev/core/-/issues/4185Single quote in contribution amount label breaks text receipt emails2023-11-23T07:47:01Zchrisgaraffachris@aghstrategies.comSingle quote in contribution amount label breaks text receipt emailsSteps to reproduce:
- Configure a confirmation page to use contribution amounts without a price set.
- Have a single quote in a Contribution Label. Example: "Provides a family with a month's worth of groceries"
- Make a contribution sele...Steps to reproduce:
- Configure a confirmation page to use contribution amounts without a price set.
- Have a single quote in a Contribution Label. Example: "Provides a family with a month's worth of groceries"
- Make a contribution selecting that contribution option
Expected result:
- Contribution receipt email is sent
Actual result:
- PHP error: `"Message was not parsed due to invalid smarty syntax : Smarty error: [in evaluated template line 55]: syntax error: (secure mode) 's' not allowed in if statement (Smarty_Compiler.class.php, line 1398)"`
Can also be triggered by finding the contribution and sending a receipt email.
Full PHP error details from ConfigAndLog: https://lab.civicrm.org/-/snippets/86
Observations:
- This line in the default Contributions - Receipt (on-line) text template seems to be the issue: `{ts}Amount{/ts}: {contribution.total_amount} {if '{contribution.amount_level}'} - {contribution.amount_level}{/if}`
- Adding `{assign var="contributionAmountLevel" value="{contribution.amount_level}"}` and then changing that line to `{ts}Amount{/ts}: {contribution.total_amount} {if $contributionAmountLevel} - {contribution.amount_level}{/if}` is a workaround
- Doesn't seem to be an issue if a Price Set is used where the label has the same character.
- I was able to reproduce on 5.59.2, 5.58.1, 5.56.2, 5.49.5https://lab.civicrm.org/dev/core/-/issues/4182Create a generic copy or clone api2023-03-17T07:50:37ZeileenCreate a generic copy or clone apiThis is a spin off of https://lab.civicrm.org/dev/core/-/issues/4130
I was looking at supporting import job templates & thought a clone or copy api makes sense.
I'm no longer prioritising this part & I think putting the code in the fo...This is a spin off of https://lab.civicrm.org/dev/core/-/issues/4130
I was looking at supporting import job templates & thought a clone or copy api makes sense.
I'm no longer prioritising this part & I think putting the code in the form layer or BAO layer for the specific entity is enouugh for now.
In order to clone the job the code looks something like
```
$userJob = UserJob::get()->addWhere('id', '=', $templateID)->execute()->first();
unset($userJob['metadata']['DataSource']['table_name'], $userJob['metadata']['submitted_values']['uploadFile'], $userJob['id'], $userJob['created_id'], $userJob['created_date'], $userJob['expires_date']);
$userJobID = UserJob::create(FALSE)->setValues($userJob)->execute()->first()['id'];
```
I feel like there is a case for a generic `Copy` api - in the `DAO` we have [a function with a signature that I think is probably 'a bit much'](https://github.com/civicrm/civicrm-core/blob/8bf6c5853cf76da43765cd8ef79d4323a442f350/CRM/Core/DAO.php#L1845-L1868) - so it might make sense to migrate to a new function... & create a generic API
I checked what Entities implement `Copy` and found a handful -the non static ones are not in the BAO - so we just have one non-std signature which is unused https://github.com/civicrm/civicrm-core/pull/25594
![image](/uploads/c4e1bbdf63fb79efaa06b03bca44fde4/image.png)
One option would be to add a parameter to the schema eg.
'is_not_clonable'
And then we could add that to fields like `created_id` and they would not need to be in the params. We already have the title of the entity so can assume that should be prefixed with `Copy Of`. The `UserJob` would have to override to set some of the deeper valueshttps://lab.civicrm.org/dev/core/-/issues/4181Custom fields on multiple entities2023-10-13T15:42:00Zaydunsaidan.saunders@squiffle.ukCustom fields on multiple entitiesOverview
----------------------------------------
Currently Custom Fields 'extend' one type of entity, possibly limited to one or more subtypes(*) of that entity.
Sometimes it would be useful to allow a set of Custom Fields to be linked...Overview
----------------------------------------
Currently Custom Fields 'extend' one type of entity, possibly limited to one or more subtypes(*) of that entity.
Sometimes it would be useful to allow a set of Custom Fields to be linked to multiple entities.
[(*) - "subtypes" in a broad sense. In the case of Contacts, the fields can be linked to sub-types. For entities like Activities, fields can be linked to say Phone Calls and Meetings which are not strictly subtypes]
Example use-case
----------------------------------------
1) Suppose we want to create custom fields for 'service providers'. Some 'service providers' are Organizations (subtype SP-O), some are Individuals (subtype SP-I).
Current options are:
- link the fields to Contacts - but the fields are only relevant to small proportion of Contacts.
- duplicate the custom fields for each subtype - need to search multiple similar fields that logically should be one.
2) Suppose we want to create a field common to multiple entities (eg 'is_validated' on Memberships, Contributions & Participants). This would require separate field sets per entity.
Current behaviour
----------------------------------------
The current model comes from a single inheritance background: this set of fields 'extends' a particular entity.
Proposed behaviour
----------------------------------------
A more flexible model is to think of a set of fields 'attached' to a selection of entities.
(Vaguely like PHP traits vs class inheritance.)
Comments
----------------------------------------
Looking for feedback on this in two main areas:
1) Is this desirable?
2) How practical is it? Custom fields are used very widely so figuring out a transition plan is key. If APIv4 can bridge the gap between the current situation and a new world then it becomes feasible. @colemanw - I know you've already done a load of work with APIv4 and Custom Fields and probably best placed to answer this bit.