CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-01-27T16:03:23Zhttps://lab.civicrm.org/dev/core/-/issues/4933Standalone: Cannot update default organisation to update it after Standalone ...2024-01-27T16:03:23ZAndy ClarkStandalone: Cannot update default organisation to update it after Standalone installAfter Standalone installation, it's require to update the default organisation to give it a name etc. However this crashes with the attached error. This is using the released 5.69.2 version of Standalone![screenshot_20240124_170636](/u...After Standalone installation, it's require to update the default organisation to give it a name etc. However this crashes with the attached error. This is using the released 5.69.2 version of Standalone![screenshot_20240124_170636](/uploads/c59bc5d9505b56cdb8764ffb36f0ad53/screenshot_20240124_170636.png)https://lab.civicrm.org/dev/core/-/issues/4932Outbound SMS and Send Email action missing when viewing contact summary2024-01-24T16:39:34ZDaveDOutbound SMS and Send Email action missing when viewing contact summaryI think it's from https://github.com/civicrm/civicrm-core/pull/27973/files. Note how it used to check for special types [BEFORE](https://github.com/civicrm/civicrm-core/pull/27973/files#diff-dfbc52a8403be6cfef3ecfd332d7b7fcc2e3ca579b325d...I think it's from https://github.com/civicrm/civicrm-core/pull/27973/files. Note how it used to check for special types [BEFORE](https://github.com/civicrm/civicrm-core/pull/27973/files#diff-dfbc52a8403be6cfef3ecfd332d7b7fcc2e3ca579b325d4a419c39a3226fdbd7L90) checking filter=1. But now it includes the filter [up front](https://github.com/civicrm/civicrm-core/pull/27973/files#diff-6edb9e1abb30f7ec07c2ea0cecde36eefe0bebf9535022ecd8e8625f02517192R85) so it doesn't get a chance to check for SMS.5.70.0https://lab.civicrm.org/dev/core/-/issues/4931Auto-renew checkbox hidden by default2024-01-29T03:48:57ZpatricklamAuto-renew checkbox hidden by defaultOverview
----------------------------------------
When signing up for a membership, where the membership type has auto-renew being available as an option, the auto-renew checkbox is initially hidden and only shows up after clicking on th...Overview
----------------------------------------
When signing up for a membership, where the membership type has auto-renew being available as an option, the auto-renew checkbox is initially hidden and only shows up after clicking on the membership type.
Reproduction steps
----------------------------------------
1. Create a membership type with auto-renew optional.
2. Create a contribution page with auto-renew optional.
3. Visit the contribution page. Membership amount shown, but not the "Please renew my membership automatically" checkbox.
4. Clicking on the membership amount causes the autorenew checkbox to appear.
Current behaviour
----------------------------------------
Autorenew checkbox is initially invisible and only appears after clicking on the membership amount.
Expected behaviour
----------------------------------------
Autorenew checkbox should appear on page load.
Environment information
----------------------------------------
Can reproduce on the demo sandbox with Firefox and Chrome.
Comments
----------------------------------------
Patch available: https://github.com/civicrm/civicrm-core/pull/290235.70.0https://lab.civicrm.org/dev/core/-/issues/4930Activity count is incorrect if contact is source and target2024-01-28T20:05:48ZbgmActivity count is incorrect if contact is source and targetRegression on 5.70/RC:
- Disable the AdminUI extension
- Go to a contact record
- New activity / Meeting
- Enter the same contact in the fields "with contact" and "assigned to contact"
- Save
The activity count displayed on the tab wil...Regression on 5.70/RC:
- Disable the AdminUI extension
- Go to a contact record
- New activity / Meeting
- Enter the same contact in the fields "with contact" and "assigned to contact"
- Save
The activity count displayed on the tab will count will be 3 instead of 1:
![image](/uploads/f4feac6831c8b35d58e88547129de366/image.png)
The AdminUI core-ext mitigates this problem by re-calculating, but we still see the incorrect count for a few seconds.5.70.0https://lab.civicrm.org/dev/core/-/issues/4929SK based on DB Entity includes contacts from the trash even when not specifie...2024-02-23T15:31:51ZlottieSK based on DB Entity includes contacts from the trash even when not specified as criteria## Overview
_When DB Entity is used as the 'search for' entity, it includes contacts from the trash even if not specified in the criteria of the original SK where the DB Entity display was constructed._
_This is the original post in _[...## Overview
_When DB Entity is used as the 'search for' entity, it includes contacts from the trash even if not specified in the criteria of the original SK where the DB Entity display was constructed._
_This is the original post in _[_Mattermost_](https://chat.civicrm.org/civicrm/pl/nji7p7prsid7dkf6p7ha3qksha)_._
## Reproduction steps
1. To test this you **_need to have some deleted contacts in your trash_**.
2. **Add a new** **SK** and do not change anything in the compose window (entity Contacts, everything default).
3. **Add a DB Entity display** to the SK you created in step 1 and preview it
4. **Save the SK** and **clear the cache** (I'm finding a have to clear the cache a 2-3 times)
5. **Add a new SK**
6. As the first **search for** entity, **_choose the DB Entity_** you created in step 2 and view the results
## Current behaviour
_The results returned for the child SK based on the DB Entity are higher than the results returned for the parent (first) SK. And the table created for the SK DB Entity the same number as shown in child SK. Note the result count in each of the following images. I have two contacts in the trash._
The SK created in step 1 (the parent for the DB Entity display - _Basic Contact Search_) has 201 results.
![sk-basic-contact-search_1.png](/uploads/c39cf6e5f33df445605656635569d70c/sk-basic-contact-search_1.png)
The SK where the DB Entity (_Basic Contact Search Child)_ created in step 1 is used as the **Search for** entity has 203 results.
![sk-basic-contact-search-child-based-on-db-entity_2.png](/uploads/7b7b5f3cc961fd0d3338fd06ea7726fa/sk-basic-contact-search-child-based-on-db-entity_2.png)
If I add the following where clause to the parent SK (_Basic Contact Search)_:
``WHERE (`a`.`is_deleted` = "0")``
![sk-basic-contact-search-addwhere-trash.png](/uploads/2a894589478f15154cebea240eaccbad/sk-basic-contact-search-addwhere-trash.png){width=491 height=178}
I get the correct result in my SK (_Basic Contact Search Child_) that is based on the DB Entity. The 201 results matches the original SK (_Basic Contact Search_).
![sk-basic-contact-search-child-updated.png](/uploads/ea5ebf91d8dc36c941cfa90a6409c411/sk-basic-contact-search-child-updated.png){width=525 height=272}
## Expected behaviour
_One should not be required to add the where clause to exclude the contacts in the trash. It seems as though that should be the default behaviour._
## Environment information
* **Browser:** _Firefox 59.0.1/Chrome 78.0.3904/Safari 13_
* **CiviCRM:** _5.69.2_
* **PHP:** _8.0_
* **CMS:** _Drupal 7.99_
* **Database:** _MariaDB 10.6_
* **Web Server:** _Apache 2.4_colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/4928Event registration crashes under Windows - is this a Smarty3 issue?2024-01-31T17:12:28ZspalmstromEvent registration crashes under Windows - is this a Smarty3 issue?## Overview
I raised this in Stackexchange and have had some feedback ([Is this the end of the road for CiviCRM under Windows?](https://civicrm.stackexchange.com/questions/46268/is-it-the-end-of-the-road-for-civicrm-under-windows?noredi...## Overview
I raised this in Stackexchange and have had some feedback ([Is this the end of the road for CiviCRM under Windows?](https://civicrm.stackexchange.com/questions/46268/is-it-the-end-of-the-road-for-civicrm-under-windows?noredirect=1#comment55813_46268))
## Reproduction steps
1. Create an event.
2. Fill in details for two people and click Review.
3. Click Register.
4. Got a cannot write file error:
```plaintext
SmartyException: "unable to write file <Drupal root>\web\sites\default\files\civicrm\templates_c\en_GB\c3\0d\eb\c30deb6712dca60a591491c1b9b34a88872d619f_0.string.{eval var=$smartySingleUseString|smarty:nodefaults}.php"
```
5. After replacing string: with eval: in line 1040 of \`\`\`\\vendor\\civicrm\\civicrm-core\\CRM\\Utils\\String.php\`\` got
```plaintext
Civi\Crypto\Exception\CryptoException: Failed to find key by ID or tag (z6BNl0_wDYQft0x4mbQidOEKlHk) in <Drupal root>\vendor\civicrm\civicrm-core\Civi\Crypto\CryptoToken.php on line 143
```
## Current behaviour
See above. The file write error is because Windows doesn't support colons and other unusual characters in file names.
## Expected behaviour
Registration should be successful.
## Environment information
* **Browser:** _IIS_ but probably not relevant.
* **CiviCRM:** _5.71.Alpha1 but also seen in 5.69.2_ The issue in the latter is stopping us updating our live environment.
* **PHP:** \_8.3.1_\_
* **CMS:** _Drupal 10.2.2_
* **Database:** _MySQL 8.0_
* **Web Server:** _IIS 10_
## Comments
Smarty is clearly intended to support Windows as there are references to it in the code. It looks as though the syntax for smartySingleUseString requires file names that are incompatible with running under Windows, or maybe I have misunderstood something. My knowledge of the mail system doesn't readily lend itself to discovering where the encryption keys or tags should be found, but maybe somebody reading this has a better knowledge than I.
I have not cluttered the issue with the long stack traces.5.71.0https://lab.civicrm.org/dev/core/-/issues/4927unrelease regression (master) Event with no participant yet is still full2024-01-28T19:35:40Zspalmstromunrelease regression (master) Event with no participant yet is still fullOverview
----------------------------------------
If you create an event on the Demo site and attempt to register, you are told it is full, though the event is new.
Reproduction steps
----------------------------------------
1. Create a...Overview
----------------------------------------
If you create an event on the Demo site and attempt to register, you are told it is full, though the event is new.
Reproduction steps
----------------------------------------
1. Create a new event with Online Registration.
1. Attempt to register.
1. You are told the event is full.
2.
Current behaviour
----------------------------------------
You are told the event is full.
```
Expected behaviour
----------------------------------------
You should be able to register for the event.
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:__ _Edge_. but probably irrelevant.
* __CiviCRM:__ _5.1.Alpha1_ The demo system.
* __PHP:__ _8.1__
* __CMS:__ _Whatever Demo is running on._
* __Database:__ _Whatever Demo uses_
* __Web Server:__ _Whatever Demo uses_
Comments
----------------------------------------
I saw this problem on the Demo system. I'm unable to investigate on my local system due to another issue that I shall be raising.5.71.0https://lab.civicrm.org/dev/core/-/issues/4926Drupal 10: `cv` fails on CiviCRM 5.69.22024-01-19T19:41:46ZpcurrierDrupal 10: `cv` fails on CiviCRM 5.69.2Overview
----------------------------------------
This is essentially a dupe of https://lab.civicrm.org/dev/core/-/issues/3438 -- Civi tries to call the drupal logger before it has been bootstrapped.
Reproduction steps
-----------------...Overview
----------------------------------------
This is essentially a dupe of https://lab.civicrm.org/dev/core/-/issues/3438 -- Civi tries to call the drupal logger before it has been bootstrapped.
Reproduction steps
----------------------------------------
1. Run a cv command, like "cv api system.check"
2. Get the error below if anything is logged before Drupal is up
Current behaviour
----------------------------------------
Here is the error from "cv -vvv":
```
In Drupal.php line 169:
[Drupal\Core\DependencyInjection\ContainerNotInitializedException]
\Drupal::$container is not initialized yet. \Drupal::setContainer() must be called with a real container.
Exception trace:
at /var/www/d8/web/core/lib/Drupal.php:169
Drupal::getContainer() at /var/www/d8/web/core/lib/Drupal.php:673
Drupal::logger() at /var/www/d8/vendor/civicrm/civicrm-core/CRM/Utils/System/Drupal8.php:301
CRM_Utils_System_Drupal8->url() at /var/www/d8/vendor/civicrm/civicrm-core/CRM/Utils/System.php:282
CRM_Utils_System::url() at /var/www/d8/vendor/civicrm/civicrm-core/tools/extensions/formprotection/settings/formprotection.setting.php:180
include() at /var/www/d8/vendor/civicrm/civicrm-core/Civi/Core/SettingsMetadata.php:109
Civi\Core\SettingsMetadata::loadSettingsMetadata() at /var/www/d8/vendor/civicrm/civicrm-core/Civi/Core/SettingsMetadata.php:92
Civi\Core\SettingsMetadata::loadSettingsMetaDataFolders() at /var/www/d8/vendor/civicrm/civicrm-core/Civi/Core/SettingsMetadata.php:66
Civi\Core\SettingsMetadata::getMetadata() at /var/www/d8/vendor/civicrm/civicrm-core/Civi/Core/SettingsManager.php:220
Civi\Core\SettingsManager->getDefaults() at /var/www/d8/vendor/civicrm/civicrm-core/Civi/Core/SettingsManager.php:102
Civi\Core\SettingsManager->useDefaults() at /var/www/d8/vendor/civicrm/civicrm-core/CRM/Core/Config.php:103
CRM_Core_Config::singleton() at phar:///usr/sbin/cv/src/Bootstrap.php:241
Civi\Cv\Bootstrap->boot() at phar:///usr/sbin/cv/src/Util/BootTrait.php:101
Civi\Cv\Command\ApiCommand->_boot_full() at n/a:n/a
call_user_func() at phar:///usr/sbin/cv/src/Util/BootTrait.php:45
Civi\Cv\Command\ApiCommand->boot() at phar:///usr/sbin/cv/src/Command/ApiCommand.php:59
Civi\Cv\Command\ApiCommand->execute() at phar:///usr/sbin/cv/vendor/symfony/console/Command/Command.php:255
Symfony\Component\Console\Command\Command->run() at phar:///usr/sbin/cv/vendor/symfony/console/Application.php:1009
Symfony\Component\Console\Application->doRunCommand() at phar:///usr/sbin/cv/vendor/symfony/console/Application.php:273
Symfony\Component\Console\Application->doRun() at phar:///usr/sbin/cv/src/Application.php:82
Civi\Cv\Application->doRun() at phar:///usr/sbin/cv/vendor/symfony/console/Application.php:149
Symfony\Component\Console\Application->run() at phar:///usr/sbin/cv/src/Application.php:49
Civi\Cv\Application::main() at phar:///usr/sbin/cv/bin/cv:27
require() at /usr/sbin/cv:14
```
Expected behaviour
----------------------------------------
cv should not throw this error.
Environment information
----------------------------------------
* CiviCRM: 5.69.2
* PHP: 8.1.14
* CMS: Drupal 10.2
Comments
----------------------------------------
I tried bgm's fix from issue https://lab.civicrm.org/dev/core/-/issues/3438 (basically having CRM_Utils_System_Drupal8->url() return null before calling logger() if Drupal is not bootstrapped yet) and the error disappeared.https://lab.civicrm.org/dev/core/-/issues/4925Using crm_optgroup for headers in select lists causes the first option to be ...2024-01-27T23:04:48ZJamesStephensUsing crm_optgroup for headers in select lists causes the first option to be selected by default when the list is single selectOverview
----------------------------------------
I noticed this issue yesterday and tested it on https://demo.circle-interactive.co.uk/ to make sure it wasn't just my installation. If I use crm_optgroup to define headers in a select lis...Overview
----------------------------------------
I noticed this issue yesterday and tested it on https://demo.circle-interactive.co.uk/ to make sure it wasn't just my installation. If I use crm_optgroup to define headers in a select list of options in a custom field and that list is single select it doesn't work as expected. Rather than showing the "- Select [field label] -" it defaults to the first item under the crm_optgroup. This results in users accidentally submitting that if they are entering data in other fields.
Reproduction steps
----------------------------------------
1. Create a custom select field that will be single select
2. Add a crm_optgroup to the select options with some options below the optgroup
Current behaviour
----------------------------------------
The first option in the topmost crm_optgroup is selected as the default
Expected behaviour
----------------------------------------
It should show "- select [field label] -" instead in the field so that users can leave it blank when needed.
Environment information
----------------------------------------
Tested this in a couple of CiviCRM environments. Specific versions tested were 5.66.2 and 5.69.2
Tested in Firefox and Safari
Comments
----------------------------------------
Removing the optgroups (or making the list multiselect) corrects the problem.https://lab.civicrm.org/dev/core/-/issues/4924CiviReport: Contribution Detail Report Joining Incorrectly on civicrm_note2024-03-01T20:08:18Zcrawford.morganCiviReport: Contribution Detail Report Joining Incorrectly on civicrm_noteOverview
----------------------------------------
When 'Contribution Note' is selected as a column in a Contribution Detail report, the join is treated as required and all contributions in the results without notes are filtered out.
Thi...Overview
----------------------------------------
When 'Contribution Note' is selected as a column in a Contribution Detail report, the join is treated as required and all contributions in the results without notes are filtered out.
This issue occurs when using the 'Contribution Detail' report, 'Extended Report - Contributions' report, and 'Extended Report - Bookkeeping with extra fields' report.
Thankfully, reports created in SearchKit function properly (all contributions are returned in the results) and contribution search exports are also functioning properly (including 'Contribution Note' in the exported fields does not affect the records exported).
Reproduction steps
----------------------------------------
1. example.com/civicrm/report/contribute/detail?reset=1
2. View results with Columns > Contribution Note toggled off
3. Toggle Contribution Note on, run report again, note that fewer records are returned
Environment information
----------------------------------------
* CiviCRM: 5.69.2
* PHP:8.1.27
* Drupal: 7.99
* MySQL: 8.0.33
Comments
----------------------------------------
This only recently became an issue after making a minor upgrade to 5.69.2https://lab.civicrm.org/dev/core/-/issues/4923Possible performance improvement: When a custom field is disabled, automatica...2024-02-08T14:11:58ZDaveDPossible performance improvement: When a custom field is disabled, automatically uncheck the searchable box and remove the db indexSuppose you have about 20 fields in the custom group and they were almost all searchable (had the searchable box checked). Over time let's say half get disabled. The indexes are still in the db, and the searchable checkbox is meaningless...Suppose you have about 20 fields in the custom group and they were almost all searchable (had the searchable box checked). Over time let's say half get disabled. The indexes are still in the db, and the searchable checkbox is meaningless because they don't appear anywhere anyway.
If the table is large, those indexes potentially cause trouble with no benefit.
If you go to re-enable, it's true it won't automatically re-check the searchable box and recreate the index, but there's no real harm, you just go back in and check the box.
An alternative to automatically doing this would be a status check: "The following fields are disabled but marked searchable. Consider making them unsearchable to improve performance on large databases."https://lab.civicrm.org/dev/core/-/issues/4922Best way to go from an Excel list of Contact IDs to a Civi group2024-01-18T17:34:49ZAndrew WestBest way to go from an Excel list of Contact IDs to a Civi groupI get regular requests to turn an external list of contact IDs into a Civi group. I don't have a nice way of doing this atm.
**Search Builder**
The best approach I have so far is with Search Builder, of all things. I have a little bit ...I get regular requests to turn an external list of contact IDs into a Civi group. I don't have a nice way of doing this atm.
**Search Builder**
The best approach I have so far is with Search Builder, of all things. I have a little bit of javascript that adds an input and then turns that into a search builder search. This sends the data via POST to the usual search results screen, where you can save it to a group in the normal way. You can do this with tens of thousands of IDs.
![image](/uploads/e617cbf436d0ee9c5efa26efdf89bd03/image.png)
But Search Builder is going away, and it'd be nice to do it in a nice Form Builder screen that doesn't need refreshing.
**Search Kit / Form Builder**
Search Kit can't _quite_ do it. You can't paste in a comma-separated list of IDs:
![image](/uploads/1024c4cf753f0477352d067d983a7d4f/image.png)
(you _can_ paste in comma-separated lists for other fields, just not when it's not a lookup field like Contact ID)
I thought about making a custom quickform that links to a Search with the values in the URL - but this hits limits of the max length of URLs. And we regularly have tens of thousands of people.
Any other ideas? Is there any way to send data to Search Kit in the POST?https://lab.civicrm.org/dev/core/-/issues/4921Add Soft Credit Recipient's and Contributor's Postal Address fields to includ...2024-01-29T10:13:28ZyashodhaAdd Soft Credit Recipient's and Contributor's Postal Address fields to include in the Soft Credit Report.Add Soft Credit Recipient's and Contributor's Postal Address fields to include in the Soft Credit Report. We already have phone/email having address would be helpful.Add Soft Credit Recipient's and Contributor's Postal Address fields to include in the Soft Credit Report. We already have phone/email having address would be helpful.https://lab.civicrm.org/dev/core/-/issues/4920Support the import of all API4 entities2024-02-20T09:29:00ZMichael McAndrewSupport the import of all API4 entitiesIt would be good to support importing of all APIv4 entities in core.
I found four extensions with a reasonable number of downloads that implement improvements to importing:
* https://civicrm.org/extensions/api-csv-import-gui by @eileen...It would be good to support importing of all APIv4 entities in core.
I found four extensions with a reasonable number of downloads that implement improvements to importing:
* https://civicrm.org/extensions/api-csv-import-gui by @eileen
* https://civicrm.org/node/5879 (csv import helper) by @artfulrobot
* https://civicrm.org/extensions/advanced-import by @bgm
* https://civicrm.org/extensions/option-value-importer by@sluc23
But most (if not all?) of these extensions are built on API3.
It would be great to have something built with API4 since this would allow import of any new 'API4 first' entities that are created in core and in extensions (including new entities that have been created with ECK @jensschuppe).
So I am wondering if there are any other initiatives to improve import in the works? And if anyone has the appetite for creating an import core extension that is powered by APIv4 with the long term aim of replacing and enhancing the core import functionality? Perhaps starting with one of the existing ones as a base.https://lab.civicrm.org/dev/core/-/issues/4919Update CiviCRM on Drupal 10: Deprecation Notices regarding TOGoS2024-01-25T14:10:46ZDetlev SieberUpdate CiviCRM on Drupal 10: Deprecation Notices regarding TOGoS## Overview
During the updating process of CiviCRM with Drupal 10.2.2, Composer shows several Deprecation Notices regarding the package "TOGoS"
## Reproduction steps
1. Update CiviCRM on Drupal 10.2.2 using Composer
2. Console output ...## Overview
During the updating process of CiviCRM with Drupal 10.2.2, Composer shows several Deprecation Notices regarding the package "TOGoS"
## Reproduction steps
1. Update CiviCRM on Drupal 10.2.2 using Composer
2. Console output includes numerous Depreation Notices regarding TOGos
## Current behaviour
See:
`Deprecation Notice: Creation of dynamic property TOGoS_GitIgnore_FileFinder::$ruleset is deprecated in /usr/www/users/crmeay6f/crm.adb.de/vendor/togos/gitignore/src/main/php/TOGoS/GitIgnore/FileFinder.php:7`
... and another \~ 100 lines like this one
## Expected behaviour
There should be no deprecation notices displayed
## Environment information
* **CiviCRM:** update to 5.69.2
* **PHP:** _8.2.14_
* **CMS:** _Drupal 10.2.2_
##https://lab.civicrm.org/dev/core/-/issues/4918All my events say "currently full"2024-01-29T14:17:43ZDaveDAll my events say "currently full"If you don't put in any value for the max number of participants, then on the event info page it will always say the event is full.
Probably from https://github.com/civicrm/civicrm-core/pull/28984?If you don't put in any value for the max number of participants, then on the event info page it will always say the event is full.
Probably from https://github.com/civicrm/civicrm-core/pull/28984?5.71.0https://lab.civicrm.org/dev/core/-/issues/4917Contribution Radio Buttons Incorrectly add other Amount2024-01-28T22:13:07ZtreseroContribution Radio Buttons Incorrectly add other Amount## Overview
With the focus fix for Contribution (Main.tpl), there is still an issue with the Other Amount being added to the original, default amount.
The Other Amount should not be adding to the original, unchecked amount.
## Reprodu...## Overview
With the focus fix for Contribution (Main.tpl), there is still an issue with the Other Amount being added to the original, default amount.
The Other Amount should not be adding to the original, unchecked amount.
## Reproduction steps
1. Click on your public facing Contribute page, civicrm/contribute/transact/?reset=1&id=1
2. Clicked in Other Amount text box and added $20
3. This added $20 to the default amount resulting in $70 for the amount, instead of $20
## Current behaviour
## Expected behaviour
This should clear the initial amount and only show the Other Amount, and move focus to the Other Amount button.
## Environment information
* **CiviCRM:** _5.69.2_
* **PHP:** _8.1_
* **CMS:** _Wordpress_
## Comments
![Screenshot 2024-01-16 161324.png](/uploads/68f7a46cac54e4256937d6d472a868c2/Screenshot_2024-01-16_161324.png)5.70.0https://lab.civicrm.org/dev/core/-/issues/4916Invisible notes2024-02-23T15:31:02ZBohdanDmytryshynInvisible notesOverview
----------------------------------------
On install or update CiviCRM, null-valued notes creating.
After researching, I can assume that the problem is a misassignment of keys.
![image](/uploads/9f4fb6a13d4cf2460a5a5c87d238b3d6/...Overview
----------------------------------------
On install or update CiviCRM, null-valued notes creating.
After researching, I can assume that the problem is a misassignment of keys.
![image](/uploads/9f4fb6a13d4cf2460a5a5c87d238b3d6/image.png)
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.67.1_
* __PHP:__ _/7.1/8.1_
* __CMS:__ Joomla 4.4.2/WordPress 6.4.2/..._https://lab.civicrm.org/dev/core/-/issues/4915Sending an invoice per email goes to primary address, not to billing2024-02-09T23:08:39ZMariaVSending an invoice per email goes to primary address, not to billingI have found this post on StackExchange:
https://civicrm.stackexchange.com/questions/9094/sending-an-invoice-per-email-goes-to-primary-address-not-to-billing
I tested on CiviCRM 5.68.1 and it seems that CiviCRM still only sends the invo...I have found this post on StackExchange:
https://civicrm.stackexchange.com/questions/9094/sending-an-invoice-per-email-goes-to-primary-address-not-to-billing
I tested on CiviCRM 5.68.1 and it seems that CiviCRM still only sends the invoice to the primary address.
What do you think about a setting 'send invoice email to Billing if it exists, otherwise send it to Primary'?
The setting could be optional so that nothing changes for users who want to keep it as it is.
Or is there any knowing extension already that I could not find?
Thanks in advance!https://lab.civicrm.org/dev/core/-/issues/4914Duplicate declaration of static variable $fields MailingEventForward.php2024-01-16T20:00:27ZspeleoDuplicate declaration of static variable $fields MailingEventForward.phpOverview
----------------------------------------
PHP Fatal error: Duplicate declaration of static variable $fields in ..../CRM/Mailing/Event/BAO/MailingEventForward.php on line 236
Reproduction steps
----------------------------------...Overview
----------------------------------------
PHP Fatal error: Duplicate declaration of static variable $fields in ..../CRM/Mailing/Event/BAO/MailingEventForward.php on line 236
Reproduction steps
----------------------------------------
1. Change site to php 8.3
1. Login to site
1. Got an error "PHP Fatal error: Duplicate declaration of static variable $fields in .../wp-content/plugins/civicrm/civicrm/CRM/Mailing/Event/BAO/MailingEventForward.php on line 236".
Current behaviour
----------------------------------------
```PHP Fatal error: Duplicate declaration of static variable $fields in .../wp-content/plugins/civicrm/civicrm/CRM/Mailing/Event/BAO/MailingEventForward.php on line 236
```
Expected behaviour
----------------------------------------
no error :)
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 Version 120.0.6099.217 (Official Build) (64-bit)
* __CiviCRM:__ CiviCRM 5.69.1 and latest on git
* __PHP:__ 8.3
* __CMS:__ WordPress 6.4.2
* __Database:__ mysql
* __Web Server:__ _Apache
Comments
----------------------------------------
Commented out line 236 to fix.