Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-02-07T10:27:26Zhttps://lab.civicrm.org/dev/core/-/issues/4964Attaching multiple contacts to an activity in afform dies if one in the middl...2024-02-07T10:27:26ZufundoAttaching multiple contacts to an activity in afform dies if one in the middle is missingHit an issue today with trying to assign multiple contacts to an activity with an afform.
Example afform:
````
<af-form ctrl="afform">
<af-entity data="{source_contact_id: 'user_contact_id', activity_type_id: '1', **target_contact_id...Hit an issue today with trying to assign multiple contacts to an activity with an afform.
Example afform:
````
<af-form ctrl="afform">
<af-entity data="{source_contact_id: 'user_contact_id', activity_type_id: '1', **target_contact_id: ['Individual1', 'Individual2', 'Organization1']**}" type="Activity" name="Activity1" label="Activity 1" actions="{create: true, update: true}" security="RBAC" />
<af-entity data="{contact_type: 'Individual', source: 'Meeting Log'}" type="Contact" name="Individual1" label="Chair" actions="{create: true, update: true}" security="RBAC" />
<af-entity data="{contact_type: 'Individual', source: 'Meeting Log'}" type="Contact" name="Individual2" label="Minute Taker" actions="{create: true, update: true}" security="RBAC" />
<af-entity data="{contact_type: 'Organization', source: 'Meeting Log'}" type="Contact" name="Organization1" label="Host Organisation" actions="{create: true, update: true}" security="RBAC" />
<button class="af-button btn btn-primary" crm-icon="fa-check" ng-click="afform.submit()" ng-if="afform.showSubmitButton">Submit</button>
<fieldset af-fieldset="Activity1" class="af-container" af-title="Meeting">
<af-field name="subject" />
</fieldset>
<fieldset af-fieldset="Individual1" class="af-container" af-title="Chair">
<div class="af-container">
<div class="af-container af-layout-inline">
<af-field name="first_name" />
<af-field name="last_name" />
</div>
</div>
</fieldset>
<fieldset af-fieldset="Individual2" class="af-container" af-title="Minute Taker">
<div class="af-container">
<div class="af-container af-layout-inline">
<af-field name="first_name" />
<af-field name="last_name" />
</div>
</div>
</fieldset>
<fieldset af-fieldset="Organization1" class="af-container" af-title="Host Organisation">
<af-field name="organization_name" />
</fieldset>
</af-form>
```
Fill in all the contacts and you get an activity with 3 contacts.
If you skip Individual2 (Minute Taker), however... what happens? The Activity, Individual1 and the Organisation are created, but only Individual1 is linked to the Activity...
Think the issue is with the splicing here https://github.com/civicrm/civicrm-core/blob/1880f9bdfe20be6e1d0a47a74c2b480b6f27e055/ext/afform/core/Civi/Api4/Action/Afform/AbstractProcessor.php#L355 - patch incoming :slight_smile:https://lab.civicrm.org/dev/core/-/issues/49565.69.1 critical error: Undefined array key "crmSearchTasks" in "ext/search_ki...2024-02-07T10:25:28ZDmitry Smirnov5.69.1 critical error: Undefined array key "crmSearchTasks" in "ext/search_kit/search_kit.php" on line 61```
PHP Warning: Undefined array key "crmSearchTasks" in ext/search_kit/search_kit.php on line 61
PHP Warning: Trying to access array offset on value of type null in ext/search_kit/search_kit.php on line 61
PHP Fatal error: Uncaught T...```
PHP Warning: Undefined array key "crmSearchTasks" in ext/search_kit/search_kit.php on line 61
PHP Warning: Trying to access array offset on value of type null in ext/search_kit/search_kit.php on line 61
PHP Fatal error: Uncaught TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in ext/search_kit/search_kit.php:61
```https://lab.civicrm.org/dev/core/-/issues/4955Upgrade to Smarty52024-02-01T10:45:19ZeileenUpgrade to Smarty5Now that we have upgraded many sites to Smarty3 Smarty5 is on the cusp of being release....
See related issue https://lab.civicrm.org/dev/core/-/issues/4954 on getting to Smarty4
The upgrade from Smarty 3 or 4 to Smarty 5 has some mino...Now that we have upgraded many sites to Smarty3 Smarty5 is on the cusp of being release....
See related issue https://lab.civicrm.org/dev/core/-/issues/4954 on getting to Smarty4
The upgrade from Smarty 3 or 4 to Smarty 5 has some minor challenges.
https://smarty-php.github.io/smarty/5.x/upgrading/
1) assign_by_ref needs to be replaced with assign wherever it appears (yay I've been wanting to get rid of those)
2) some php-language modifiers will stop working without intervention (not sure how affected we are but if some are common it is easy to 'make them work')
3) before we can see / address the above there is a problem with our Smarty compatibility class. Our Smarty class has functions like `getTemplateVars()` to allow sites still on Smarty2 to call the v3 functions. That particular function has a different signature in Smarty5 so overriding it causes fatals
Proposal
1) Check Smarty5 into packages like Smarty4 - see https://github.com/civicrm/civicrm-packages/pull/380
2) the path fix in Smarty4 will allow easy switch to Smarty5 for developers
3) Move `getTemplateVars()` & any other functions in the same boat from being on our Smarty compatibility class to being 'hacked onto' the Smarty 2 code in our packages folder.
4) replace assign-by-ref with assign
- That should be enough to get us to the point where we can get dev sites to load and from there we can figure out if we have to scale a mountain or a molehill to move to Smarty5 instead of 3 or 4 when we do our force changehttps://lab.civicrm.org/dev/core/-/issues/4952PHP 8.3 Support2024-01-31T22:32:21ZJoeMurrayPHP 8.3 SupportThis is an epic for PHP 8.3 support.
PHP 8.3 was released 2023-11, has active support till 2024-12-8, and security support till 2025-12-08.
Some extra motivation to support 8.3 sooner rather that later is the significant performance im...This is an epic for PHP 8.3 support.
PHP 8.3 was released 2023-11, has active support till 2024-12-8, and security support till 2025-12-08.
Some extra motivation to support 8.3 sooner rather that later is the significant performance improvements it has, up to 55% for D10 over 8.1: https://kinsta.com/blog/php-benchmarks/
Reference: [https://www.php.net/manual/en/migration83.incompatible.php](https://www.php.net/manual/en/migration83.incompatible.php)
See also [thttps://php.watch/versions/8.3](https://php.watch/versions/8.3) and [https://www.php.net/releases/8.3/en.php](https://www.php.net/releases/8.3/en.php).
Here are the breaking changes listed here for reference. Almost all seem like they would be difficult to search for and identify in the codebase. Whack-a-mole from running on edge test servers might be a helpful approach.
- [ ] Uses of traits with static properties: Uses of traits with static properties will now redeclare static properties inherited from the parent class. This will create a separate static property storage for the current class. This is analogous to adding the static property to the class directly without traits.
- [ ] Assigning a negative index to an empty array: Assigning a negative index $n to an empty array will now make sure that the next index is $n+1 instead of 0.
- [ ] Class constant visibility variance check: Class constant visibility variance is now correctly checked when inherited from interfaces.
- [ ] WeakMap entries whose key maps to itself: WeakMap entries whose key maps to itself (possibly transitively) may now be removed during cycle collection if the key is not reachable except by iterating over the WeakMap (reachability via iteration is considered weak). Previously, such entries would never be automatically removed.
- [ ] Date: The DateTime extension has introduced Date extension specific exceptions and errors under the DateError and DateException hierarchies, instead of warnings and generic exceptions. This improves error handling, at the expense of having to check for errors and exceptions.
- [ ] DOM: Calling DOMChildNode::after(), DOMChildNode::before(), DOMChildNode::replaceWith() on a node that has no parent is now a no-op instead of a hierarchy exception, which is the behaviour demanded by the DOM specification.
Using the DOMParentNode and DOMChildNode methods without a document now works instead of throwing a DOM_HIERARCHY_REQUEST_ERR DOMException. This is in line with the behaviour demanded by the DOM specification.
Calling DOMDocument::createAttributeNS() without specifying a prefix would incorrectly create a default namespace, placing the element inside the namespace instead of the attribute. This bug is now fixed.
DOMDocument::createAttributeNS() would previously incorrectly throw a DOM_NAMESPACE_ERRNAMESPACE_ERR DOMException when the prefix was already used for a different URI. It now correctly chooses a different prefix when there's a prefix name conflict.
New methods and properties were added to some DOM classes. If a userland class inherits from these classes and declare a method or property with the same name, the declarations must be compatible. Otherwise, a typical compile error about incompatible declarations will be thrown. See the list of new features and new functions for a list of the newly implemented methods and properties.
- [x] FFI: C functions that have a return type of void now return null instead of returning the following object object(FFI\CData:void) { }
- [ ] Opcache: The opcache.consistency_checks INI directive was removed. This feature was broken with the tracing JIT, as well as with inheritance cache, and has been disabled without a way to enable it since PHP 8.1.18 and PHP 8.2.5. Both the tracing JIT and inheritance cache may modify shm after the script has been persisted by invalidating its checksum. The attempted fix skipped over the modifiable pointers but was rejected due to complexity. For this reason, it was decided to remove the feature instead.
- [ ] Phar: The type of Phar class constants are now declared.
- [ ] Standard: The range() function has had various changes:
A TypeError is now thrown when passing objects, resources, or arrays as the boundary inputs.
A more descriptive ValueError is thrown when passing 0 for $step.
A ValueError is now thrown when using a negative $step for increasing ranges.
If $step is a float that can be interpreted as an int, it is now done so.
A ValueError is now thrown if any argument is infinity or NAN.
An E_WARNING is now emitted if $start or $end is the empty string. The value continues to be cast to the value 0.
An E_WARNING is now emitted if $start or $end has more than one byte, only if it is a non-numeric string.
An E_WARNING is now emitted if $start or $end is cast to an integer because the other boundary input is a number. (e.g. range(5, 'z');).
An E_WARNING is now emitted if $step is a float when trying to generate a range of characters, except if both boundary inputs are numeric strings (e.g. range('5', '9', 0.5); does not produce a warning).
range() now produce a list of characters if one of the boundary inputs is a string digit instead of casting the other input to int (e.g. range('9', 'A');).
```
<?php
range('9', 'A'); // ["9", ":", ";", "<", "=", ">", "?", "@", "A"], as of PHP 8.3.0
range('9', 'A'); // [9, 8, 7, 6, 5, 4, 3, 2, 1, 0], prior to PHP 8.3.0
?>
```
The file() flags error check now catches all invalid flags. Notably FILE_APPEND was previously silently accepted.
- [ ] SNMP: The type of SNMP class constants are now declared.https://lab.civicrm.org/dev/core/-/issues/4950Acivity tab timing out after 5.70 upgrade on large DB2024-02-08T19:14:09ZElliott EgglestonAcivity tab timing out after 5.70 upgrade on large DBThe admin_ui version of the activity tab is generating queries for some CIDs that don't return in a reasonable amount of time. EXPLAIN shows that filesort is being used for the first subquery.
One example query, generated for a contact ...The admin_ui version of the activity tab is generating queries for some CIDs that don't return in a reasonable amount of time. EXPLAIN shows that filesort is being used for the first subquery.
One example query, generated for a contact with only 18 activities: https://phabricator.wikimedia.org/P55961
Wikimedia's tracking task, with the SQL query explain: https://phabricator.wikimedia.org/T356269
Oddly, I WAS able to load the activities tab for my own user which has 700+ activities, so it's not just related to the number of activities on a contact.
If I just roll back 04078d359e298a5a02ea274404dcdb8af83225dd it restores the previous activity tab and I can load the CID's activity tab fine with no runaway query generated.5.70.0colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/4947Proposal: Store Contribution Page ID in the `civicrm_contribution_recur` table2024-02-01T10:23:33ZjaapjansmaProposal: Store Contribution Page ID in the `civicrm_contribution_recur` tableOverview
----------------------------------------
When a recurring contribution is created with a contribution page. Also store the contribution page ID in the `civicrm_contribution_recur` table.
This works already for 'normal' contrib...Overview
----------------------------------------
When a recurring contribution is created with a contribution page. Also store the contribution page ID in the `civicrm_contribution_recur` table.
This works already for 'normal' contribution.
Example use-case
----------------------------------------
1. CiviRules can be used when a new Contribution Recur is added and a condition can then be used which Contribution Page this came from.
Current behaviour
----------------------------------------
Currently for the 'normal' contributions the contribution page ID is stored in the `civicrm_contribution` table.
Proposed behaviour
----------------------------------------
1. Add a column to the `civicrm_contribution_recur` table called `contribution_page_id`
2. When a contribution recur is added through a Contribution Page then store the contribution page id into this column
3. Optional we can show the data from this field in the user interface when a user views a contribution recur
Workaround
----------------------------------------
There is a workaround with an extension: https://lab.civicrm.org/extensions/storecontributionpageidoncontribrecurjaapjansmajaapjansmahttps://lab.civicrm.org/dev/core/-/issues/4946DB error on gender searches2024-02-01T16:06:14ZyashodhaDB error on gender searchesWe should NOT allow non numeric values for gender option values.
gender_id in the database expects numeric values instead, we should form rule for such entities.We should NOT allow non numeric values for gender option values.
gender_id in the database expects numeric values instead, we should form rule for such entities.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4944Mass SMS continue button creates a new mass SMS2024-02-02T13:10:39ZDaveDMass SMS continue button creates a new mass SMSCame up during PR review.
The screens appear as though it's editing the existing one but there's a warning about missing ssid, so I assume it's not getting passed on so it then creates a new one.
1. Mailings - New SMS.
1. Fill out the ...Came up during PR review.
The screens appear as though it's editing the existing one but there's a warning about missing ssid, so I assume it's not getting passed on so it then creates a new one.
1. Mailings - New SMS.
1. Fill out the fields. Click Next.
1. Click Continue Later.
1. This takes you to the Find Mass SMS screen and you'll see your draft.
1. Click the Continue link at the far right.
1. It looks as though you're editing the draft, but click Next and then Next again, and then click the Continue Later button.
1. Note in the Find Mass SMS screen there's now two draft mailings.https://lab.civicrm.org/dev/core/-/issues/4940Proposal to Change the Invoice date in the default Invoice message template t...2024-02-08T10:45:03ZeileenProposal to Change the Invoice date in the default Invoice message template to contribution.receive_dateThis spins off one discussion topic from https://lab.civicrm.org/dev/core/-/issues/1403 -
As part of our general effort to make the WorkflowMessage templates operate independently of the quickform layer (ie be available as actions from ...This spins off one discussion topic from https://lab.civicrm.org/dev/core/-/issues/1403 -
As part of our general effort to make the WorkflowMessage templates operate independently of the quickform layer (ie be available as actions from SearchKit etc) we should clarify which value is used for the invoice_date in the default message template that we ship from \`{$invoice_date}\`
```html
{domain.now|crmDate:"Full"}
or
{contribution.receive_date|crmDate:"Full"}
```
If we change the default it will affect new installs and un-customised templates. I'm not proposing any push upgrade on the customised templates at this stage so for most invoice-using sites this will be no change at this point. However, I am going to try to 'complete' the variable to token changes in this template so that anyone who is updating their customised template or installing a new site is using the tokens (& hence will be able to benefit from message previewability via MessageAdmin now & sending & rendering from outside QF if they install a relevant extension /when we add to core).
Potentially if we want to make it clear to people that they can change it we can use one of
```html
{domain.now|crmDate:"Full"}{* Code comment: - You can replace the domain.now token with this to show the contribution date instead {contribution.receive_date|crmDate:"Full"} *}
OR
{contribution.receive_date|crmDate:"Full"}{* Code comment: - You can replace the domain.now token with this to show the current date instead with {domain.now|crmDate:"Full"} *}
```
Note that the assumption in this gitlab is that any change would be opt in for existing sites (since basically everyone who uses invoices puts a logo in there). There is a proposal at https://github.com/civicrm/civicrm-core/pull/28630 that would force a change on everyone. I'm not convinced we should do a force update because it is pretty clear from the code & code history that the use of now was a deliberate attempt to meet a use case. However I have added an option to the emjoi poll below to allow people to vote for a forced update - basically a string_replace on upgrade.
EMOJI POLL Options
1) :boom: Change to {domain.now|crmDate:"Full"}
2) :man_dancing_tone2: Change to {contribution.receive_date|crmDate:"Full"}
3) :avocado: Change to 1 with additional in-code comments per above
4) :bellhop: Change to 2 with additional in code comments per above
5) :pick: Do 2 with a forced upgrade to replace {$invoice_date} with the above with {contribution.receive_date|crmDate:"Full"}https://lab.civicrm.org/dev/core/-/issues/4934Standalone: messages from Civi don't appear as expected2024-03-11T18:54:28ZAndy ClarkStandalone: messages from Civi don't appear as expectedMessages from Civi don't appear as expected e.g. when testing outbound email, check the mail() button and click 'Send and Save email' and no message will appear. This is 100% reproducible. Sometimes messages will appear a couple of scre...Messages from Civi don't appear as expected e.g. when testing outbound email, check the mail() button and click 'Send and Save email' and no message will appear. This is 100% reproducible. Sometimes messages will appear a couple of screens after they have been created, but not always. Using the 5.69.2 version of Standalone.RichRichhttps://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/coworker/-/issues/13Logging inadequate2024-01-25T14:19:24ZeileenLogging inadequateOur syslog is full of
Jan 23 22:03:34 coworker[1015]: #033[31m[2024-01-23T22:03:34.987520+00:00] CiviQueueWatcher.ERROR: Failed to read queues!#033[0m
The actual logged exception includes the exception but because this does not reach s...Our syslog is full of
Jan 23 22:03:34 coworker[1015]: #033[31m[2024-01-23T22:03:34.987520+00:00] CiviQueueWatcher.ERROR: Failed to read queues!#033[0m
The actual logged exception includes the exception but because this does not reach syslog because without logging to a file it winds up adding the ColorFormatter with no context or extra
https://lab.civicrm.org/dev/coworker/-/blob/master/src/Command/ConfigurationTrait.php#L168
The easiest fix would be to just add to the format line - eg
`$consoleFormatter = new ColoredLineFormatter(NULL, '[%datetime%] %channel%.%level_name%: %message%');`
`$consoleFormatter = new ColoredLineFormatter(NULL, '[%datetime%] %channel%.%level_name%: %message% %context% %extra%');`
or bring it into line with the LineFormatter used in file mode - ie pass in NULL & we get
` public const SIMPLE_FORMAT = "[%datetime%] %channel%.%level_name%: %message% %context% %extra%\n";`
There are various ways we can make this configurable but I lean towards passing in NULL for the format & using the defaults. As we don't have obvious other users it seems hard to make a case for a lot of work on configurability & when there is an obvious advantage of just using the package default over the existing default that feels like the easy / sane fix.
Related: - we have a lot of noise in our syslog from these two
Jan 23 12:45:17 coworker[1448965]: #033[31m[2024-01-23T12:45:17.882285+00:00] Pipe[ctl#1].ERROR: Received unexpected response line: "{"jsonrpc":"2.0","result":[],"id":667944}"#033[0m
Jan 23 12:45:19 coworker[1448965]: #033[31m[2024-01-23T12:45:19.882223+00:00] Pipe[ctl#1].ERROR: Received unexpected response line: "civicrm.wmf.INFO: Early return as queue is backed up. 529 contributions in the last 5 minutes is greater than the threshold of 500"#033[0m
In the former case I think the issue is that it should be a notice not an error - this seems to be what happens when coworker respawns as part of it's normal operation
In the latter case the issue is not that it gets logged - but that it gets logged every second. We might be able to figure out how to do something to pause the queue in this case but it would also be every second when the queue processing is in maintenance mode I think. Perhaps that is fine since that is a more unusual eventhttps://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/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/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/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.0