CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-01-15T23:27:12Zhttps://lab.civicrm.org/dev/core/-/issues/4069Broken event confirmation emails with multiple participants and external paym...2023-01-15T23:27:12ZJKingsnorthBroken event confirmation emails with multiple participants and external payment gateways (contribution.sendconfirmation)Raised on StackExchange here: https://civicrm.stackexchange.com/questions/34004/event-email-receipt-doesnt-have-the-profile-information
We have also hit this issue.
This is an old regression from late 2019 by the looks of it.
When boo...Raised on StackExchange here: https://civicrm.stackexchange.com/questions/34004/event-email-receipt-doesnt-have-the-profile-information
We have also hit this issue.
This is an old regression from late 2019 by the looks of it.
When booking on to an event with multiple participants (ie lead booker and a guest), and using an external payment gateway using IPN, the confirmation email is missing the total amount, and all of the participant information.
Actual: [image](/uploads/b55b515da0be99cc4806c4f0cc3a3b96/image.png)
Expected: [image](/uploads/60ff3fdfc56fc6dc7765210628870ae4/image.png)
Another way to recreate this issue is to call the contribution.sendconfirmation API on any contribution record linked to a lead booker that has additional participants.
IPN-based payment gateways call completetransaction API, which in turn calls the sendconfirmation API, which explains.
---
Tracking through the code, it looks like the sendconfirmation API call only has the participant information for the 'last' participant ID associated with the booking?
It looks like @eileen you've been doing some refactoring in this area (rightly so - it looks like a bit of a swamp!).
I'm struggling to track down exactly where the issue is coming from.https://lab.civicrm.org/dev/core/-/issues/4063Pagination and counts for soft credits on contact contribution tab are broken2023-01-31T04:22:10ZlarsssandergreenPagination and counts for soft credits on contact contribution tab are broken![image](/uploads/bb821970b38d324542ed222f854986c7/image.png)
![image](/uploads/6f7546327ec73b18a8811048bcf59d92/image.png)
If the total number of soft credits on a contact's contribution tab exceeds the number set in Show N entries, th...![image](/uploads/bb821970b38d324542ed222f854986c7/image.png)
![image](/uploads/6f7546327ec73b18a8811048bcf59d92/image.png)
If the total number of soft credits on a contact's contribution tab exceeds the number set in Show N entries, then the count is broken as above and the Next and Last links are disabled. You can use the page numbers to get to other pages, but it will always show five pages no matter how many actual soft credits are found.
Is this something that's worth digging into or is it anticipated that this will be replaced with SearchKit relatively soon?
To reproduce, add soft credit for 11 contributions to one contact, then go to that contact's contributions tab and select Show 10 entries.https://lab.civicrm.org/dev/core/-/issues/4049Tag tree broken for nested tags when the tags weren't created in the same ord...2023-01-03T21:07:11ZgellweilerTag tree broken for nested tags when the tags weren't created in the same order as they are nestedOverview
----------------------------------------
Commit https://lab.civicrm.org/dev/core/-/commit/a902f9f9268899c31ca21296d19d8c247a370a43 brakes the tag tree (in the add tag to contact dialog) for nested tags when the tags weren't crea...Overview
----------------------------------------
Commit https://lab.civicrm.org/dev/core/-/commit/a902f9f9268899c31ca21296d19d8c247a370a43 brakes the tag tree (in the add tag to contact dialog) for nested tags when the tags weren't created in the same order as they are nested.
This happens when a child tag that has itself children is moved under a newer parent tag.
Reproduction steps
----------------------------------------
1. Go to civicrm/tag
2. Add a new tag called "Isaac" to the tag tree
3. Add a new tag called "Abraham" to the tag tree
4. Add a new tag called "Jacob" to the tag tree
5. Move the tag "Jacob" below "Isaac"
6. Move the tag "Isaac" below "Abraham"
7. Try to add the Tag Jacob to a contact (it will not show up).
The order of tag creation is important.
![order_of_creation_and_tag_hierarchy](/uploads/f6d9e14d41fe988231fcea735ae73ebd/order_of_creation_and_tag_hierarchy.png)
Current behaviour
----------------------------------------
The tag Jacob is not shown when trying to add it to a contact.
![jacob_missing](/uploads/2f968f85eca49eb574d724df63300536/jacob_missing.png)
Expected behaviour
----------------------------------------
_What should happen._
This is how it used to be and how it is after applying the fix:
![expected_behavior](/uploads/1477bb98b6fee39836d81b152669e5d3/expected_behavior.png)
Fix and cause of issue
----------------------------------------
If you uncomment `$thisref['children'] = [];` in line 92 in file `CRM/Core/BAO/Tag.php` everything works again as expected.
This error was introduced by commit https://lab.civicrm.org/dev/core/-/commit/a902f9f9268899c31ca21296d19d8c247a370a43.https://lab.civicrm.org/dev/core/-/issues/4043translation of extension strings fails after upgrade from 5.52.2 to 5.562023-02-08T15:12:50Zjamietranslation of extension strings fails after upgrade from 5.52.2 to 5.56Overview
----------------------------------------
After upgrading from 5.52.2 to 5.56.0, translations in a message template that is sent by email using a custom invocation of the token code fail to translate.
Other UI translations are p...Overview
----------------------------------------
After upgrading from 5.52.2 to 5.56.0, translations in a message template that is sent by email using a custom invocation of the token code fail to translate.
Other UI translations are properly displayed (e.g. in the angular app).
Example use-case
----------------------------------------
1. We have defined custom message templates in `templates/MessageTemplates/Folder/html.tpl` (see for example: https://code.mayfirst.org/mfmt/outreach/-/blob/master/web/sites/all/extensions/mayfirst/templates/MessageTemplate/MayfirstDuesReminderGrace/html.tpl).
2. We have defined that path in our `*.mgd.php` file (see https://code.mayfirst.org/mfmt/outreach/-/blob/master/web/sites/all/extensions/mayfirst/mayfirst.mgd.php).
3. We send the email via custom code. Here's a sample:
```
$p = new \Civi\Token\TokenProcessor(\Civi::dispatcher(), array(
'controller' => __CLASS__,
// We need smarty for translation.
'smarty' => TRUE,
'schema' => [ 'contactId', 'membershipId' ],
));
// Fill the processor with a batch of data.
$p->addMessage('body_html', $html, 'text/html');
$p->addMessage('subject', $subject, 'text/plain');
// Now we have to create content for each of the contactIds that we
// need to send to. Each message might be different (different first name
// and also it might be in english or spanish).
foreach($recipients as $recipientContactId => $recipient) {
$p->addRow()
->context('contactId', $recipientContactId)
->context('membershipId', $this->membershipId)
->context('contributionId', $this->contributionId)
->context('locale', $recipient['locale']);
}
$p->evaluate();
```
Full code available here: https://code.mayfirst.org/mfmt/outreach/-/blob/master/web/sites/all/extensions/mayfirst/Civi/Mayfirst/Email.php#L450
4. When we send to a contact with locale set to `es_MX` using the UI, it sends the english content.
5. Interestingly, in our unit test, it translates the strings present in CiviCRM core's translation file, but not the extension's translation file.
Current behaviour
----------------------------------------
The email is not properly translated.
Proposed behaviour
----------------------------------------
The email should be translated.
Comments
----------------------------------------
I traced the change to this [commit](https://github.com/civicrm/civicrm-core/commit/1190626dc6669a5a9242ab788a64d058e42dd9cb). Specifically, when I changed these lines, it started working in the UI (but not in the unit tests):
```
diff --git a/web/sites/all/modules/civicrm/CRM/Core/I18n.php b/web/sites/all/modules/civicrm/CRM/Core/I18n.php
index b1aa48974..4e690fc64 100644
--- a/web/sites/all/modules/civicrm/CRM/Core/I18n.php
+++ b/web/sites/all/modules/civicrm/CRM/Core/I18n.php
@@ -672,18 +672,18 @@ class CRM_Core_I18n {
}
// Change the language of the CMS as well, for URLs.
- CRM_Utils_System::setUFLocale($civicrmLocale->uf);
+ CRM_Utils_System::setUFLocale($locale);
// For sql queries, if running in DB multi-lingual mode.
global $dbLocale;
if ($dbLocale) {
- $dbLocale = '_' . $civicrmLocale->db;
+ $dbLocale = '_' . $locale;
}
// For self::getLocale()
global $tsLocale;
- $tsLocale = $civicrmLocale->ts;
+ $tsLocale = $locale;
CRM_Core_I18n::singleton()->reactivate();
}
```
The weird part is that `$locale` seems to be the same as `$civicrmLocale->ts`, `$civicrmLocale->db`, and `$civicrmLocale->uf`. It's merely accessing the {ts,db,uf} properties of `$civicrmLocale` that causes the problem. In other words, if I simply log `$civicrmLocale->ts` it fails to translate.
@totten - since the commit is yours I was hoping you might have some insight? I'm available to try things out if you have any suggestions.https://lab.civicrm.org/dev/core/-/issues/4039Invoices have started miscalculating on save in version 5.56.0, rounding down...2022-12-23T16:33:29ZphilmckInvoices have started miscalculating on save in version 5.56.0, rounding down quantitiesOverview
----------------------------------------
_Please describe your problem or bug in detail._
Since version 5.56.0 (or possibly a slightly earlier version) my generated invoices have started to calculate incorrectly. The item quanti...Overview
----------------------------------------
_Please describe your problem or bug in detail._
Since version 5.56.0 (or possibly a slightly earlier version) my generated invoices have started to calculate incorrectly. The item quantities are rounded down to integers. Fractional quantities can still be entered and the Total Value looks correct until the Save button is pressed, at which point the total value of the invoice becomes incorrect (lower than expected). It appears that all item quantities are now being rounded down to integers.
_If you have already posted on https://civicrm.stackexchange.com or https://chat.civicrm.org, please include the link to that conversation._
Reproduction steps
----------------------------------------
1. In **CiviContribute Component Settings** check **Enable Tax and Invoicing**. Create a price set in **CiviContribute > Manage Price Sets** and add a price field of type **Text / Numeric Quantity**. Give it a value.
2. Go to the **Contributions** tab for any individual and click **Record Contribution**. Select the price set and field created in the previous step, and add a non-integer value (e.g. 1.5). Press TAB. Observe that the Total Amount is calculated correctly.
3. Click the **Save** button. Observe that the total amount is now incorrect. Click the **View** link and observe that the item quantity has been rounded down to an integer.
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._
Item quantities in invoices are rounded down to integers when the "Save" button for a new contribution is pressed (but are allowed and calculated correctly up to that point).
```
TIP: The best way to convey an error message is to copy it in here and use
three backtick ` symbols. You may edit the message to remove private
information (like passwords). The backticks will help to preserve any
special characters or spaces.
```
Expected behaviour
----------------------------------------
_What should happen._
Fractional item quantities allowed, as they were in previous versions. If they have been deliberately removed (why?), the restriction should be flagged earlier, rather than quietly recalculating after the invoice disappears from the screen.
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:__ _Chrome 108.0.5359.125_
* __CiviCRM:__ _5.56.0_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _8.0__
* __CMS:__ _WordPress 6.1.1_
* __Database:__ _MariaDB version 10.4.27_
* __Web Server:__ _Apache version 2.4.54_
Comments
----------------------------------------
_Anything else you would like the reviewer to note._5.57.0https://lab.civicrm.org/dev/core/-/issues/4036"New Batch" page no longer loads2022-12-17T19:15:25ZJonGold"New Batch" page no longer loadsOverview
----------------------------------------
"New Batch" no longer loads. When you try, you get an error.
Reproduction steps
----------------------------------------
1. Go to http://yoursite/civicrm/batch/add?reset=1&action=add
C...Overview
----------------------------------------
"New Batch" no longer loads. When you try, you get an error.
Reproduction steps
----------------------------------------
1. Go to http://yoursite/civicrm/batch/add?reset=1&action=add
Current behaviour
----------------------------------------
![image001](/uploads/2a7a6b049f0917e4c112cb72616659ba/image001.png)
Expected behaviour
----------------------------------------
No error.
Comments
----------------------------------------
This is a regression in https://github.com/civicrm/civicrm-core/pull/24770. I did some checking to see what other classes might be affected (using `ag -l 'extends CRM_Admin_Form' | xargs ag -L DefaultEntity` as a base) but couldn't find any others.5.56.1JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4035Cannot run scheduled jobs - cli.php errors out with uninformative "Error"2023-01-11T13:57:48Zthoni56Cannot run scheduled jobs - cli.php errors out with uninformative "Error"Overview
----------------------------------------
Our scheduled jobs stopped working, possibly after upgrading to 5.56. Investigating this further revealed that the crontab command failed.
Reproduction steps
----------------------------...Overview
----------------------------------------
Our scheduled jobs stopped working, possibly after upgrading to 5.56. Investigating this further revealed that the crontab command failed.
Reproduction steps
----------------------------------------
1. Execute `cd $CIVI_ROOT; $PHP bin/cli.php -j -s $CIVISITE -u $CIVIUSER -p $CIVIPASS -e Job -a execute`
Current behaviour
----------------------------------------
The command exits without triggering the scheduled jobs, displaying the text "Error".
Expected behaviour
----------------------------------------
That the scheduled CiviCRM jobs are triggered.
Environment information
----------------------------------------
* __CiviCRM:__ _5.56.0_
* __PHP:__ _7.4__
* __CMS:__ _Joomla 3.10.11_
* __Web Server:__ _Apache 2.4_
Comments
----------------------------------------
Is there a way to debug/trace the execution of the `bin/cli.php`?5.57.1https://lab.civicrm.org/dev/core/-/issues/4029Around 5.49 pan_truncation and card_type_id (containing card type VISA/MC and...2023-05-05T13:23:07ZStoobAround 5.49 pan_truncation and card_type_id (containing card type VISA/MC and last 4 digits last four digits stopped getting recordedDoes anyone know the reasoning behind this and if it's deliberate or a bug? We used Authorize.net consistently. No change that I'm aware of the the config other than upgrade to 5.49, since then these 2 fields haven't been getting filled...Does anyone know the reasoning behind this and if it's deliberate or a bug? We used Authorize.net consistently. No change that I'm aware of the the config other than upgrade to 5.49, since then these 2 fields haven't been getting filled in with any online translations.
I checked these tables in the schema and confirmed it's not a display issue - _the data doesn't exist_ in table: `civicrm_financial_trxn` columns: `pan_truncation` and `card_type_id`
Example of what it looks like in the UI prior to 5.49
![yes](/uploads/3efbb6e78e2526d9525ec28d6cfa060c/yes.png)
And now after 5.49
![nope](/uploads/24429e375e0c3f708d10a38059d70eff/nope.png)5.60.0https://lab.civicrm.org/dev/core/-/issues/4013Regression: Error when editing search preferences2023-01-05T01:40:51ZJonGoldRegression: Error when editing search preferencesTo replicate:
* Go to **Administer » Customize Data and Screens » Search Preferences**.
* Change the default pager limit to anything and save.
* Visit the **Search Preferences** page again.
Expected Result:
No errors.
Actual Result:
``...To replicate:
* Go to **Administer » Customize Data and Screens » Search Preferences**.
* Change the default pager limit to anything and save.
* Visit the **Search Preferences** page again.
Expected Result:
No errors.
Actual Result:
```
Warning: array_flip() expects parameter 1 to be array, string given in CRM_Admin_Form_Setting::reorderSortableOptions() (line 380 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Admin/Form/SettingTrait.php).
Warning: array_merge(): Expected parameter 1 to be an array, null given in CRM_Admin_Form_Setting::reorderSortableOptions() (line 380 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Admin/Form/SettingTrait.php).
Warning: array_flip() expects parameter 1 to be array, null given in CRM_Admin_Form_Setting->addFieldsDefinedInSettingsMetadata() (line 224 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Admin/Form/SettingTrait.php).
Warning: Invalid argument supplied for foreach() in CRM_Core_Form->addCheckBox() (line 1418 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Form.php).
```
Note that this is on dmaster.demo.c.o, running PHP 7.4. PHP 8+ will throw a fatal error here.
I don't have time to work on this today but if no one else has a minute, I can devote some of Brienne's time Thursday/Friday.5.57.0https://lab.civicrm.org/dev/core/-/issues/4008Regression - lotsa noise on Searchkit screen if Form code editor enabled2022-12-08T02:47:10ZeileenRegression - lotsa noise on Searchkit screen if Form code editor enabledOn upgrading a dev site with Form Code Editor enabled from 5.54 to 5.56 the search kit screen went 'haywire'. Doing the same on dmaster gave a more modest error display (but the difference is the other site has some aggressive xdebug err...On upgrading a dev site with Form Code Editor enabled from 5.54 to 5.56 the search kit screen went 'haywire'. Doing the same on dmaster gave a more modest error display (but the difference is the other site has some aggressive xdebug error display stuff going on)
![image](/uploads/6a20d0e4ecde37ff138a54381401feb7/image.png)
![image](/uploads/f1d0812dc9daf2ca176e2389c0487432/image.png)
@totten @colemanw unless we are actively deprecating that extension we need to fix (I can disable on the site in question)5.56.0https://lab.civicrm.org/dev/core/-/issues/4000only update `contributionRecur` when `templateContribution` is updated IF it ...2023-03-16T21:47:09Zeileenonly update `contributionRecur` when `templateContribution` is updated IF it is actively marked as suchIn https://github.com/civicrm/civicrm-core/pull/21473 code was added to update the Currency and Amount of the template contribution is updated. However, the code appears to me to be too aggressive and updating the amount or currency of A...In https://github.com/civicrm/civicrm-core/pull/21473 code was added to update the Currency and Amount of the template contribution is updated. However, the code appears to me to be too aggressive and updating the amount or currency of ANY contribution in the series causes it to update. There are good reasons to update individual contributions without any implicit template update.5.61.0https://lab.civicrm.org/dev/core/-/issues/3999Unable to delete Price field2022-11-21T20:52:46ZMonish DebUnable to delete Price fieldSteps to replicate:
2. Create a any kind of price-field (In this example I have created a checkbox field)
1. Created a price set used for any one of the civi component
3. Then delete the price-field
Error:
> Unable to delete the '...Steps to replicate:
2. Create a any kind of price-field (In this example I have created a checkbox field)
1. Created a price set used for any one of the civi component
3. Then delete the price-field
Error:
> Unable to delete the '' Price Field - it is currently in use by one or more active events or contribution pages or contributions or event templates.
Expected: The price set is not used in any donation or event page, then one should be allowed to delete the price-field
Demo:
![after1](/uploads/321c38eaa3707cbb9ac7a6bb020f484f/after1.gif)5.56.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3997FormBuilder filter fails on some fields2022-11-28T09:20:40Zaydunsaidan.saunders@squiffle.ukFormBuilder filter fails on some fieldsOverview
----------------------------------------
On some fields, a FormBuilder filter works when a value is entered but deleting the filter value does not show the full listing.
Reproduction steps
--------------------------------------...Overview
----------------------------------------
On some fields, a FormBuilder filter works when a value is entered but deleting the filter value does not show the full listing.
Reproduction steps
----------------------------------------
1. In SearchKit, create a search of CaseTypes
2. Display the ID & Title
3. Create a table display - default settings
4. Create a FormBuilder form
5. Add Case Type Title as a filter
6. Add route, name, save.
7. View page
8. Should see listing of case types
9. In filter box, type 'sup' - should filter correctly to show Housing Support
10. then delete 'sup' from the filter
Current behaviour
----------------------------------------
Does not show all results. Angular error in browser 'val is undefined'
Expected behaviour
----------------------------------------
It should go back to showing all results
Environment information
----------------------------------------
* __CiviCRM:__ _Master_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
Comments
----------------------------------------
Verified on dmaster.
This is only on some fields. Eg doing the same for Case instead of Case Type works as expected.colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3979civi/core/Locale->uf doesn't get set usually2022-11-23T18:18:41ZDaveDcivi/core/Locale->uf doesn't get set usuallyThis started as what I thought was a simple php 8.1 warning: `CRM_Core_I18n::singleton()->setLocale('en_US')` gives one of those "don't pass null as a string parameter" warnings. But then I looked into a bit.
1. Unit tests don't catch t...This started as what I thought was a simple php 8.1 warning: `CRM_Core_I18n::singleton()->setLocale('en_US')` gives one of those "don't pass null as a string parameter" warnings. But then I looked into a bit.
1. Unit tests don't catch this because the error is happening when [setting the UF locale](https://github.com/civicrm/civicrm-core/blob/98b99133c1b5b8f7c093c8426f26316444420695/CRM/Utils/System/DrupalBase.php#L453), and in the unit test UF it [doesn't do anything](https://github.com/civicrm/civicrm-core/blob/98b99133c1b5b8f7c093c8426f26316444420695/CRM/Utils/System/Base.php#L519).
2. The only way the parameter is not null is if the `uf` member of \Civi\Core\Locale gets set. But that only happens when code is doing things in a way that nobody (currently) does things. It doesn't happen by calling `CRM_Core_I18n::singleton()->setLocale()`.
3. In drupal 7 in a stock install, these get swallowed and don't even appear on screen. You can see them if you comment out [this line](https://git.drupalcode.org/project/drupal/-/blob/9f59535277d2bcaf7ad4555b12e62ddc4fac372f/includes/bootstrap.inc#L2692), and then do e.g. `cv ev "CRM_Core_I18n::singleton()->setLocale('en_US');"`.
4. Looks like it's from https://github.com/civicrm/civicrm-core/commit/1190626dc6669a5a9242ab788a64d058e42dd9cb.
5. I'm a little scared to touch setLocale().5.56.0tottentottenhttps://lab.civicrm.org/dev/core/-/issues/3978Sample data price sets not showing correctly2022-11-17T22:54:04ZeileenSample data price sets not showing correctlyPer https://lab.civicrm.org/dev/core/-/issues/3685#note_83376
Note the issue is the FinancialType ACls require a financial type ID - it should be there BUT the financial type ID code should not require itPer https://lab.civicrm.org/dev/core/-/issues/3685#note_83376
Note the issue is the FinancialType ACls require a financial type ID - it should be there BUT the financial type ID code should not require it5.55.2https://lab.civicrm.org/dev/core/-/issues/3968unsupported operand types in BAO/Navigation.php, orderByWeight2022-11-07T10:27:07Zsebalisunsupported operand types in BAO/Navigation.php, orderByWeightHi,
when trying out if a Wordpress+Civi test instance would survive a PHP upgrade to 8.0, I found that the CiviCRM menu had gone missing. It turned out that a fatal PHP error occured in the AJAX call that retrieves the menu structure. I...Hi,
when trying out if a Wordpress+Civi test instance would survive a PHP upgrade to 8.0, I found that the CiviCRM menu had gone missing. It turned out that a fatal PHP error occured in the AJAX call that retrieves the menu structure. It originated in line 323 of CRM/Core/BAO/Navigation.php, which is in the orderByWeight function:
`return $a['attributes']['weight'] - $b['attributes']['weight'];`
Perhaps PHP 8 is treating such issues more seriously than 7 – sorry but I simply don’t know. In any case, I was able to overcome this by adding explicit type casts:
`return (int) $a['attributes']['weight'] - (int) $b['attributes']['weight'];`
This was complete guesswork and maybe I should have cast to float instead – again, I don’t know. But I thought this might be worth reporting so you can decide how to best safeguard that line. For now I am happy to have my menu back with this temporary and local patch.
By the way, this was observed in version 5.54.1 but I notice that the line is unchanged in the master, 5.55 and 5.56 branches.5.56.0https://lab.civicrm.org/dev/core/-/issues/3960Assigning to accounting batch and closing batch fails with javascript error2022-11-07T23:48:10Zaydunsaidan.saunders@squiffle.ukAssigning to accounting batch and closing batch fails with javascript errorOverview
----------------------------------------
Attempting to assign a contribution to an accounting batch using the 'assign' link fails with
```
Uncaught TypeError: text is undefined
alert https://dmaster.demo.civicrm.org/sites/...Overview
----------------------------------------
Attempting to assign a contribution to an accounting batch using the 'assign' link fails with
```
Uncaught TypeError: text is undefined
alert https://dmaster.demo.civicrm.org/sites/all/modules/civicrm/js/Common.js?rkod02:1339
saveRecord https://dmaster.demo.civicrm.org/civicrm/batchtransaction?reset=1&bid=1:2123
jQuery 7
saveRecord https://dmaster.demo.civicrm.org/civicrm/batchtransaction?reset=1&bid=1:2110
assignRemove https://dmaster.demo.civicrm.org/civicrm/batchtransaction?reset=1&bid=1:2078
onclick https://dmaster.demo.civicrm.org/civicrm/batchtransaction?reset=1&bid=1:1
Common.js:1339:9
```
Similarly attempting to close a batch using the 'Close Batch' button produces the same javascript error. The 'Close and Export Batch' button does work.
Reproduction steps
----------------------------------------
1. Create a new batch using **Contributions -> Accounting Batches > New Batch**.
1. On the list of contributions, use the 'Assign' menu option at the right of a contribution
1. Enjoy the spinning wheel of doom.
Next:
1. Reload the page
2. Check the tickbox next to a contribution and use the 'Assign to Batch' action from the drop-down menu to add a contribution to the batch.
3. Attempt to close the batch using the 'Close Batch' button.
4. After the confirmation popup, nothing happens except for the javascript error in the browser console.
Current behaviour
----------------------------------------
Javascript Error as above
Also, in the browser's dev tools network tab note the response to the REST call:
```
{
"error_message": "FATAL: Invalid credential",
"is_error": 1
}
```
Expected behaviour
----------------------------------------
No error
Environment information
----------------------------------------
* __CiviCRM:__ _Master_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
This happens on the current version of master (confirmed on dmaster.demo.civicrm.org) but was also present in at least 5.53.0 and 5.54.15.56.0https://lab.civicrm.org/dev/core/-/issues/3952Event badges, json may be broken (was CiviEvent - Date tokens may be misforma...2023-11-14T01:27:44ZtottenEvent badges, json may be broken (was CiviEvent - Date tokens may be misformatted)(*This is an offshoot from #3829. PR [24695](https://github.com/civicrm/civicrm-core/pull/24695) bundled in a partial fix for this date-token issue, but it looks to me like this is distinct from the barcode problem - and this still has s...(*This is an offshoot from #3829. PR [24695](https://github.com/civicrm/civicrm-core/pull/24695) bundled in a partial fix for this date-token issue, but it looks to me like this is distinct from the barcode problem - and this still has some TODOs.*)
v5.43 included an update for certain tokens. It recommended adding an explicit date filter:
* `{event.start_date}` => `{event.start_date|crmDate:"%B %E%f}`
* `{event.end_date}` => `{event.end_date|crmDate:"%B %E%f}`
Notably, the default content in `civicrm_print_label`.`data` has references to these tokens. It was updated by way of [873bfeb503caa413f17460](https://github.com/civicrm/civicrm-core/commit/873bfeb503caa413f17460dbe450b74fac3d6dbf#diff-b604dfcba0703a9cd5e9f1431451f657c2a580b1dfd8eb56e2c4e4a960c4b43c) (see `FiveFortyThree.php` and `civicrm_navigation.tpl`). However, the `data` field have special encoding requirements (JSON?), so it's not a simple string-substitution.
With [24695](https://github.com/civicrm/civicrm-core/pull/24695), it sounds like the escaping is fixed for new installs (5.54.1+). However, we probably need a cleanup/upgrade step for sites which either (a) installed 5.43-5.54 or (b) installed <5.43 and ran the upgrade.5.69.0https://lab.civicrm.org/dev/core/-/issues/3939Import contributions: Contact matching by email no longer available2022-11-02T21:02:44ZDetlev SieberImport contributions: Contact matching by email no longer availableOverview
----------------------------------------
When importing contributions, step 2 of 3 defines matching fields.
Hereby, we also have to define how to match the contact, for which the contributions should be attached.
Matching of c...Overview
----------------------------------------
When importing contributions, step 2 of 3 defines matching fields.
Hereby, we also have to define how to match the contact, for which the contributions should be attached.
Matching of contacts is possible by contact ID, external identifier or by email.
However, starting with CiviCRM 5.54.0, email is no longer available for contact matching!
Also, if we select email and check "update this field mapping", the field "email" won't be saved anymore.
Reproduction steps
----------------------------------------
1. Click on **Contributions -> Import contributions**.
1. Select a file with emails and the other mandatory fields for contribution import
1. Within "Match Fields (step 2 of 3)": select email as contact match ```-> error "Missing required contact matching fields. email(weight 10) (Sum of all weights should be greater than or equal to threshold: 10)"```.
Current behaviour
----------------------------------------
Importing contributions seems to be based on the unsupervised de-dupe rule.
However, matching on email is not accepted anymore.
This issue started with 5.54.0. The previous version, 5.53.0 was still working as expected.
Expected behaviour
----------------------------------------
As in previous versions, it should be possible to identify contacts by using the email as contact matcher
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 105.0.3
* __CiviCRM:__ _5.54.0 (was working well with 5.52.x)
* __PHP:__ _7.4
* __CMS:__ _Drupal 7.52
* __Database:__ _MariaDB 10.5.15_
Comments
----------------------------------------
There is a workaround to import contributions using email as contact identifier:
* Add an empty column to the csv file, that shall be imported
* Use "External Identifier (match to contact)" as field match for that column
* Select email as field match
* make sure to have a unsupervised de-dupe rule that only uses email
-> this will import contributions based on the mail.
However, this workaround doesn't solve that part of the issue, that email is not saved in the field mapping.5.55.0https://lab.civicrm.org/dev/core/-/issues/3932Event participant import fails, Cannot call constructor2022-10-24T23:56:29ZguitarmanEvent participant import fails, Cannot call constructorOverview
----------------------------------------
The import of event participants fails on Joomla with the following error: 0 Cannot call constructor
Reproduction steps
----------------------------------------
1. Click on Events / impo...Overview
----------------------------------------
The import of event participants fails on Joomla with the following error: 0 Cannot call constructor
Reproduction steps
----------------------------------------
1. Click on Events / import participants
2. Choose .csv-file and click on "submit" to import the file.
3. The error shows up immediately, CiviCRM is unable to import the file.
Current behaviour
----------------------------------------
The import of the file fails with error: 0 Cannot call constructor.
Joomla Call Stack (Debug)
| # | Function | Location |
|----|--------------------------------------------------------------|-----------------------------------------------------------------------------------------------|
| 1 | () | JROOT/administrator/components/com_civicrm/civicrm/CRM/Event/Import/Parser/Participant.php:68 |
| 2 | CRM_Event_Import_Parser_Participant->__construct() | JROOT/administrator/components/com_civicrm/civicrm/CRM/Import/DataSource.php:558 |
| 3 | CRM_Import_DataSource->getParser() | JROOT/administrator/components/com_civicrm/civicrm/CRM/Import/DataSource.php:535 |
| 4 | CRM_Import_DataSource->getAdditionalTrackingFields() | JROOT/administrator/components/com_civicrm/civicrm/CRM/Import/DataSource.php:518 |
| 5 | CRM_Import_DataSource->addTrackingFieldsToTable() | JROOT/administrator/components/com_civicrm/civicrm/CRM/Import/DataSource/CSV.php:82 |
| 6 | CRM_Import_DataSource_CSV->initialize() | JROOT/administrator/components/com_civicrm/civicrm/CRM/Import/Form/DataSource.php:199 |
| 7 | CRM_Import_Form_DataSource->instantiateDataSource() | JROOT/administrator/components/com_civicrm/civicrm/CRM/Import/Form/DataSource.php:187 |
| 8 | CRM_Import_Form_DataSource->processDatasource() | JROOT/administrator/components/com_civicrm/civicrm/CRM/Import/Form/DataSource.php:159 |
| 9 | CRM_Import_Form_DataSource->postProcess() | JROOT/administrator/components/com_civicrm/civicrm/CRM/Core/Form.php:573 |
| 10 | CRM_Core_Form->mainProcess() | JROOT/administrator/components/com_civicrm/civicrm/CRM/Core/QuickForm/Action/Upload.php:152 |
| 11 | CRM_Core_QuickForm_Action_Upload->realPerform() | JROOT/administrator/components/com_civicrm/civicrm/CRM/Core/QuickForm/Action/Upload.php:119 |
| 12 | CRM_Core_QuickForm_Action_Upload->perform() | JROOT/administrator/components/com_civicrm/civicrm/packages/HTML/QuickForm/Controller.php:203 |
| 13 | HTML_QuickForm_Controller->handle() | JROOT/administrator/components/com_civicrm/civicrm/packages/HTML/QuickForm/Page.php:103 |
| 14 | HTML_QuickForm_Page->handle() | JROOT/administrator/components/com_civicrm/civicrm/CRM/Core/Controller.php:355 |
| 15 | CRM_Core_Controller->run() | JROOT/administrator/components/com_civicrm/civicrm/CRM/Core/Invoke.php:319 |
| 16 | CRM_Core_Invoke::runItem() | JROOT/administrator/components/com_civicrm/civicrm/CRM/Core/Invoke.php:69 |
| 17 | CRM_Core_Invoke::_invoke() | JROOT/administrator/components/com_civicrm/civicrm/CRM/Core/Invoke.php:36 |
| 18 | CRM_Core_Invoke::invoke() | JROOT/administrator/components/com_civicrm/civicrm.php:121 |
| 19 | civicrm_invoke() | JROOT/administrator/components/com_civicrm/civicrm.php:40 |
| 20 | require_once() | JROOT/libraries/src/Component/ComponentHelper.php:402 |
| 21 | Joomla\CMS\Component\ComponentHelper::executeComponent() | JROOT/libraries/src/Component/ComponentHelper.php:377 |
| 22 | Joomla\CMS\Component\ComponentHelper::renderComponent() | JROOT/libraries/src/Application/AdministratorApplication.php:101 |
| 23 | Joomla\CMS\Application\AdministratorApplication->dispatch() | JROOT/libraries/src/Application/AdministratorApplication.php:159 |
| 24 | Joomla\CMS\Application\AdministratorApplication->doExecute() | JROOT/libraries/src/Application/CMSApplication.php:225 |
| 25 | Joomla\CMS\Application\CMSApplication->execute() | JROOT/administrator/index.php:51 | |
Expected behaviour
----------------------------------------
Civi should import the file and advance to step 2 / field mapping.
Environment information
----------------------------------------
* __CiviCRM:__ 5.54.0
* __PHP:__ 7.4
* __CMS:__ _Joomla 3.10.11_
* __Database:__ _MySQLi 5.5.5-10.3.35-MariaDB_
* __Web Server:__ _Apache_5.54.1