Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-12-08T02:47:10Zhttps://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.1https://lab.civicrm.org/dev/core/-/issues/3927Import failure when related contact is a different contact type2022-10-24T21:47:07ZJonGoldImport failure when related contact is a different contact typeIn some import mappings, you can't import an Organization as a related contact to an Individual.
### Steps to Replicate
* Create a CSV with columns "First Name", "Last Name", and "Employer", with a corresponding row of data.
* On import...In some import mappings, you can't import an Organization as a related contact to an Individual.
### Steps to Replicate
* Create a CSV with columns "First Name", "Last Name", and "Employer", with a corresponding row of data.
* On import, map to First Name, Last Name, and "Employee of: Organization Name".
* Import.
### Expected Result
2 contacts created.
### Actual Result
Import fails, error shows "Mismatched contact type."
This is happening because `CRM_Contact_Import_Parser_Contact::lookupContactID()` calls `$this->getPossibleContactMatch` and passes the dedupe rule ID selected in the import UI. However, that rule is an Individual dedupe rule, and the related contact is an organization.
Brienne is working on a fix, we'll shout if we run into trouble.5.54.1JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3918Contribution in Australia returns yellow error banner with "setBillingCountry...2022-11-22T22:57:09ZjhungerfordContribution in Australia returns yellow error banner with "setBillingCountry expects ISO 3166-1 alpha-2 country code"Overview
----------------------------------------
After upgrading to CiviCRM 5.54.0, test donations result in a yellow error banner with the message ```setBillingCountry expects ISO 3166-1 alpha-2 country code```. I haven't tried a real ...Overview
----------------------------------------
After upgrading to CiviCRM 5.54.0, test donations result in a yellow error banner with the message ```setBillingCountry expects ISO 3166-1 alpha-2 country code```. I haven't tried a real donation. We are located in Australia, and we use Stripe as the payment processor.
I asked a question about this issue here: https://chat.civicrm.org/civicrm/pl/atwjzr4ozf8fbdkokzegze9iiw
Reproduction steps
----------------------------------------
1. Upgrade a CiviCRM site to 5.54.0
2. Navigate to a Test-drive contribution page
3. Attempt to make a test contribution
Current behaviour
----------------------------------------
A yellow error banner appears with the message ```setBillingCountry expects ISO 3166-1 alpha-2 country code```.
Expected behaviour
----------------------------------------
The test contribution should be processed, and the donor should be redirected to the thank-you page.
Environment information
----------------------------------------
* __Browser:__ Chromium 105.0.5195.125 (Official Build) Arch Linux (64-bit)
* __CiviCRM:__ 5.54.0 (upgraded from 5.53.0)
* __PHP:__ 7.4.30
* __CMS:__ Drupal 7.92, also tested on Drupal 9.4.7
* __Database:__ 10.3.36-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
* __Web Server:__ Apache 2.4
* __civicrm-Stripe version:__ 6.7.11, also tested on 6.7.10
* __Payment Shared version:__ 1.2.9, also tested on 1.2.8
Comments
----------------------------------------
I'll post an example of a failing test contribution page in the chat linked above.
Reverting to CiviCRM 5.53.0 results in a working contribution page.5.55.1https://lab.civicrm.org/dev/core/-/issues/3879Including Soft Credits causes Contribution Import to fail2022-11-03T05:07:07ZphilmorbruIncluding Soft Credits causes Contribution Import to failOverview
----------------------------------------
When importing contributions, if Soft Credit fields are included, the import fails. No records are created. This is a regression.
Originally [described at SE](https://civicrm.stackexchan...Overview
----------------------------------------
When importing contributions, if Soft Credit fields are included, the import fails. No records are created. This is a regression.
Originally [described at SE](https://civicrm.stackexchange.com/questions/42470/contribution-import-fails-with-invalid-field-email-error). Note comment in that thread that points to soft credits as the culprit.
Reproduction steps
----------------------------------------
1. Prepare a csv file for Contribution Import and include a Soft Credit field
2. Begin a new Contribution Import and make sure the Soft Credit field is mapped correctly
3. Run the import
Current behaviour
----------------------------------------
The Queue Runner shows it is working. Then on the result screen...
```
Import has completed successfully. The information below summarizes the results.
CiviCRM has detected invalid data and/or formatting errors in 5 records. These records have not been imported.
You can Download Errors. You may then correct them, and import the new file with the corrected data.
```
In the Error_Report file, the Reason given for the failure on each record is "_Invalid field 'email'_."
Expected behaviour
----------------------------------------
Records should be imported and assigned a soft credit accordingly.
Environment information
----------------------------------------
* __Browser:__ _Chrome 105.0.5195.125_
* __CiviCRM:__ _5.53.0_
* __PHP:__ _7.4.29__
* __CMS:__ _Joomla 3.10.6_5.55.0https://lab.civicrm.org/dev/core/-/issues/3864Localisation lost when upgrading to 5.53.02022-10-10T13:38:35Zthoni56Localisation lost when upgrading to 5.53.0Overview
----------------------------------------
When upgrading to 5.53.0 from 5.50 (possibly) every menu, dialogue, screen and form has reverted back to English. Only custom texts remain in Swedish (obviously).
Reproduction steps
----...Overview
----------------------------------------
When upgrading to 5.53.0 from 5.50 (possibly) every menu, dialogue, screen and form has reverted back to English. Only custom texts remain in Swedish (obviously).
Reproduction steps
----------------------------------------
Unknown
Current behaviour
----------------------------------------
As above.
Expected behaviour
----------------------------------------
All texts that have been localized to Swedish should show up in Swedish.
Environment information
----------------------------------------
Joomla 3.10, Ubuntu 20.04, Apache 2.4.41, PHP 7.4.3
Comments
----------------------------------------
After upgrade "Default Language" had been reset to English, resetting it to Swedish did not help.
Everything in the backend is in English. I have tried "follow CMS", which is in Swedish, no change.
Having mixed languages makes our site look amateurish...
![image](/uploads/1d72f3d3306812c7dfe04b0ae2222ec3/image.png)
![image](/uploads/ed9ff4bfdc2e996451f91b502f2f3b4d/image.png)https://lab.civicrm.org/dev/core/-/issues/3863Default location type for email seems to have become Billing, even if Home is...2022-09-22T12:22:51ZDaveDDefault location type for email seems to have become Billing, even if Home is set as the default.1. Go to customize - dropdown options - location types and note that Home is the default.
1. Create a new individual.
1. Note the location type for email is Billing not Home.
Ok in 5.53, not ok in 5.54.1. Go to customize - dropdown options - location types and note that Home is the default.
1. Create a new individual.
1. Note the location type for email is Billing not Home.
Ok in 5.53, not ok in 5.54.5.54.0https://lab.civicrm.org/dev/core/-/issues/3862Error when creating a message template2022-09-26T19:48:49ZDaveDError when creating a message templateSteps to reproduce
----
1. Create a message template
Expected result
----
Not this
```
CRM_Core_Exception: One of parameters (value: null) is not of the type Integer in /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Cor...Steps to reproduce
----
1. Create a message template
Expected result
----
Not this
```
CRM_Core_Exception: One of parameters (value: null) is not of the type Integer in /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/DAO.php on line 1750
Exception trace
Function Location
0 CRM_Utils_Type::validate() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/DAO.php:1750
1 CRM_Core_DAO::composeQuery() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/DAO.php:1714
2 CRM_Core_DAO::singleValueQuery() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/BAO/RecurringEntity.php:506
3 CRM_Core_BAO_RecurringEntity::getParentFor() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/BAO/RecurringEntity.php:469
4 CRM_Core_BAO_RecurringEntity::getEntitiesFor() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/BAO/RecurringEntity.php:605
5 CRM_Core_BAO_RecurringEntity::triggerUpdate() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php:264
6 Symfony\Component\EventDispatcher\EventDispatcher->doDispatch() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php:239
7 Symfony\Component\EventDispatcher\EventDispatcher->callListeners() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php:73
8 Symfony\Component\EventDispatcher\EventDispatcher->dispatch() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/Civi/Core/CiviEventDispatcher.php:217
9 Civi\Core\CiviEventDispatcher->dispatch() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/DAO.php:660
10 CRM_Core_DAO->save() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/BAO/MessageTemplate.php:139
11 CRM_Core_BAO_MessageTemplate::add() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/Civi/Api4/Generic/Traits/DAOActionTrait.php:163
12 Civi\Api4\Generic\DAOSaveAction->write() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/Civi/Api4/Generic/Traits/DAOActionTrait.php:134
13 Civi\Api4\Generic\DAOSaveAction->writeObjects() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/Civi/Api4/Generic/DAOSaveAction.php:38
14 Civi\Api4\Generic\DAOSaveAction->_run() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/Civi/Api4/Provider/ActionObjectProvider.php:72
15 Civi\Api4\Provider\ActionObjectProvider->invoke() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php:149
16 Civi\API\Kernel->runRequest() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/Civi/Api4/Generic/AbstractAction.php:250
17 Civi\Api4\Generic\AbstractAction->execute() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Admin/Form/MessageTemplates.php:316
18 CRM_Admin_Form_MessageTemplates->postProcess() /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Form.php:573
```5.54.0https://lab.civicrm.org/dev/core/-/issues/3853Can no longer install civirules2022-09-18T14:05:21ZDaveDCan no longer install civirulesThis must be something merged yesterday, and in fact dmaster.demo and others failed to build today for the same reason.
Error is `Expected one OptionGroup but found 0 ... CRM/Civirules/Utils/OptionGroup.php(70)`This must be something merged yesterday, and in fact dmaster.demo and others failed to build today for the same reason.
Error is `Expected one OptionGroup but found 0 ... CRM/Civirules/Utils/OptionGroup.php(70)`5.55.0https://lab.civicrm.org/dev/core/-/issues/3852Bootstrap classloading list incomplete (or something) when classscanner runs ...2022-09-18T19:09:55ZDaveDBootstrap classloading list incomplete (or something) when classscanner runs during extension installSome preliminary notes since I don't have a full handle on what's happening, but after https://github.com/civicrm/civicrm-core/pull/24276, class scanning now runs more. This might be fine normally, but I think a test folder isn't getting...Some preliminary notes since I don't have a full handle on what's happening, but after https://github.com/civicrm/civicrm-core/pull/24276, class scanning now runs more. This might be fine normally, but I think a test folder isn't getting included somewhere in the classloader config.
I can reproduce it like so:
1. Create the following simple test file:
```php
<?php
class CRM_Foo_FooTest extends CiviUnitTestCase {
public function testFoo() {
$this->callAPISuccess('Extension', 'install', ['keys' => 'org.civicrm.search_kit']);
// yes the same thing again
$this->callAPISuccess('Extension', 'install', ['keys' => 'org.civicrm.search_kit']);
}
}
```
1. export CIVICRM_UF=UnitTests
1. phpunit tests\phpunit\CRM\Foo\FooTest.php
1. Failure in api call for Extension install: `Scanned file Civi/Search/AdminTest.php for class Civi\Search\AdminTest, but it was not found.`
1. It's happening on this line where baseDir is search_kit's folder https://github.com/civicrm/civicrm-core/blob/06d92d394b6c6f127c82d43fe25b18948fd29d80/mixin/scan-classes%401/mixin.php#L58
In a non-core environment, I can reproduce it in a drupal test, where searchkit gets installed during the civi module enable during initial install. But note it fails on the test folder scanning, whereas the line 55 that runs before it for non-test files runs fine. This is why I think it's test folder bootstrap related.
But also confusing (or maybe a clue) is that if you start from a fresh database (e.g. DROP then CREATE so it's completely empty), then the test only fails if you try to install searchkit twice. If it's not a fresh database then it can fail earlier.
FYI @totten @colemanw
Technically a regression so marking regression it's just not the usual kind.5.55.0https://lab.civicrm.org/dev/core/-/issues/3850Importing to checkbox field updates incorrectly2023-03-01T01:47:07ZandyburnsImporting to checkbox field updates incorrectlyReproduced this regression on https://wpmaster.demo.civicrm.org/ with 5.55.alpha1 also reported on 5.51.1, 5.53.0:
- Create checkbox custom field with option values of 1,2,3
- Import to this field
- Observe that values in db are now 0,1...Reproduced this regression on https://wpmaster.demo.civicrm.org/ with 5.55.alpha1 also reported on 5.51.1, 5.53.0:
- Create checkbox custom field with option values of 1,2,3
- Import to this field
- Observe that values in db are now 0,1,2
![image](/uploads/dc09ebbe334285c627c73f8194b4264f/image.png)
![image](/uploads/630dd2a9108ddf3e33d948bd2288cdbe/image.png)
![image](/uploads/800d0ec68a4f40cf17e86e026adb1582/image.png)
Pattern:
```
"1,2,3" becomes => "0,1,2"
"2,3,4" becomes => "1,2,3"
```
Same behavior exists using labels e.g. Red,Green,Blue.
Importing a singular option value e.g. "2" works as expected.
Ref: https://chat.civicrm.org/civicrm/pl/x1imgh3affbmfb4o9b6ei6fx4h5.55.0