Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-25T18:55:32Zhttps://lab.civicrm.org/dev/translation/-/issues/85Some strings in core afforms do not translate2024-03-25T18:55:32ZbgmSome strings in core afforms do not translateFor example:
- Enable CiviCampaign
- Go to the CiviCampaign dashboard
![image](/uploads/49a1d30b027b36f57971cbc4fb9d48ff/image.png)
For the tabs, the strings are correctly wrapped with `ts`, and I double-checked that the strings are t...For example:
- Enable CiviCampaign
- Go to the CiviCampaign dashboard
![image](/uploads/49a1d30b027b36f57971cbc4fb9d48ff/image.png)
For the tabs, the strings are correctly wrapped with `ts`, and I double-checked that the strings are translated in my translation file.
For the placeholders on the filter fields, the strings are not correctly wrapped in `ts`, but even if I do wrap them, and I make sure to add the strings to my translation files, they do not translate.
cc @colemanwhttps://lab.civicrm.org/dev/core/-/issues/539Create a hook for custom relative date filters (CRM-16195)2024-03-25T15:18:49ZJonGoldCreate a hook for custom relative date filters (CRM-16195)To summarize: From the time relative date filters debuted in 4.2(?) until 4.7, each release added a number of relative date filters that one person needed and the rest of the world didn't. To prevent this happening forever, we moved rel...To summarize: From the time relative date filters debuted in 4.2(?) until 4.7, each release added a number of relative date filters that one person needed and the rest of the world didn't. To prevent this happening forever, we moved relative dates into an OptionGroup, and intended to give the ability to create new ones.
I worked on this last year but some cleanup PRs got stalled. They're all merged now so I'm submitting this.
While @eileen did work recently to support relative dates like "32 months in the past", it's still not possible to do relative dates like, "from 6 months ago to the end of this year", or "from Thanksgiving to Christmas". A former client of mine had reports that went from October to September, but this was NOT their fiscal year.
A simple hook facilitates the creation of custom relative date filters. I'll submit tests, but you can see an extension that uses it here: https://github.com/MegaphoneJon/com.megaphonetech.relativedatetest5.9JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/5110afform: Display option "Remember Filters" not keeping value2024-03-25T15:01:10Zjensschuppeafform: Display option "Remember Filters" not keeping value## Overview
The display option "Remember Filters" in search displays does not retain its value when the configuration form is being reloaded.
## Reproduction steps
1. Create a _SearchKit_ search with a search form
2. Add a form displa...## Overview
The display option "Remember Filters" in search displays does not retain its value when the configuration form is being reloaded.
## Reproduction steps
1. Create a _SearchKit_ search with a search form
2. Add a form display (e.g. _Table_)
3. add some exposed filters
4. Check _Remember Filters_
5. Reload the configuration form for that form display
## Current behaviour
The option seems to be stored and filter values are being stored per user. The option field (checkbox) however is not set when reloading the config form of the form display. Saving the config form without changing that option still seems to retain its value (still storing filter values). So the config form does not reflect the actual option value.
## Expected behaviour
The option should be set when re-visiting the form display config form. Saving the form should respect the value (unchecked: unset the option).
## Environment information
* **Browser:** _Chromium 123.0.6312.58_
* **CiviCRM:** _5.71.0_https://lab.civicrm.org/dev/core/-/issues/3681Double down or remove use of empoweredBy in invoice template2024-03-25T05:03:20ZeileenDouble down or remove use of empoweredBy in invoice templateThe invoice template but exactly ZERO of the other templates adds the `empoweredBy` CiviCRM logo to the header.
As part of trying to consolidate template handling code I want to EITHER
- switch to using a token for the empoweredBy imag...The invoice template but exactly ZERO of the other templates adds the `empoweredBy` CiviCRM logo to the header.
As part of trying to consolidate template handling code I want to EITHER
- switch to using a token for the empoweredBy image OR
- remove it from the invoice template (on new installs- but in the long-term it might break on existing ones if I do that)
I feel an emoji poll coming on - go on - be Caesar - thumbs up it lives - thumbs down it dies (although death would be slow & gradual in this case)
Tangential issues
- invoice also uses an image-based horizonal line - I'm leaning towards making that a token `{formatting.line}` but that is for a separate issue
- this brings up a bunch of feature requests around what WOULD be useful in place of the empoweredBy. I did chat with Tim on that & will try to put it in another issuehttps://lab.civicrm.org/dev/core/-/issues/2975Drupal8/composer: upgrading do not move vendor files to the library folder2024-03-25T05:03:19ZcalbasiDrupal8/composer: upgrading do not move vendor files to the library folderOverview
----------------------------------------
I've upgraded from civicrm 5.36 to 5.43 using composer. I have no composer nor database errors but website menu, panels, etc. are not shown.
It seems some library files are missing on l...Overview
----------------------------------------
I've upgraded from civicrm 5.36 to 5.43 using composer. I have no composer nor database errors but website menu, panels, etc. are not shown.
It seems some library files are missing on libraries folder (but not at vendor folder). Copying some of them from vendor to library folder solves inspector errors...
Reproduction steps
----------------------------------------
1. Upgrade the code:
- composer update civicrm/civicrm-{core,packages,drupal-8} --with-dependencies
- update database
Current behaviour
----------------------------------------
Website don't load menu, panels, floating panels. Just the most basic info (html).
The inspector show errors (a couple of library files are missing)
```
The resource from “https://my_domain/libraries/civicrm/core/ang/resetLocationProviderHashPrefix.js?r=ZdPSJ” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).
The resource from “https://my_domain/libraries/civicrm/core/js/crm-angularjs-loader.js?r=ZdPSJ” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).
The resource from “https://my_domain/libraries/civicrm/core/ang/resetLocationProviderHashPrefix.js?r=ZdPSJ” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).
Loading failed for the <script> with source “https://my_domain/libraries/civicrm/core/ang/resetLocationProviderHashPrefix.js?r=ZdPSJ”.
The resource from “https://my_domain/libraries/civicrm/core/js/crm-angularjs-loader.js?r=ZdPSJ” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).
```
After copy the missing errors:
```
cp js/crm-angularjs-loader.js /var/www/my_website/web/web/libraries/civicrm/core/js/
cp resetLocationProviderHashPrefix.js /var/www/my_website/web/web/libraries/civicrm/core/ang/
```
I think the composer info is OK:
```
"extra": {
"installer-paths": {
"web/core": ["type:drupal-core"],
"web/libraries/{$name}": ["type:drupal-library"],
```
In fact, vendor/civicrm/civicrm-core has updated files, but not /libraries/civicrm/core
Environment information
----------------------------------------
* __CiviCRM:__ _5.43.2_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __OS:__ _Debian 10__
* __PHP:__ _7.3__
* __CMS:__ _Drupal 8 (updated version)..._
* __Database:__ _MariaDB_
* __Web Server:__ _Apache 2_https://lab.civicrm.org/dev/core/-/issues/2239Make submitting of A/B mailing atomic2024-03-24T05:03:29ZromainMake submitting of A/B mailing atomicThe [API function that submits A/B mailings](https://github.com/civicrm/civicrm-core/blob/master/api/v3/MailingAB.php#L100) performs the following actions:
1. submits mailing A (= set scheduled date to now)
2. submits mailing B
3. di...The [API function that submits A/B mailings](https://github.com/civicrm/civicrm-core/blob/master/api/v3/MailingAB.php#L100) performs the following actions:
1. submits mailing A (= set scheduled date to now)
2. submits mailing B
3. distribute recipients between A and B
4. set status of the A/B mailing from Draft to Testing, regardless of what happened in previous steps
I can see 3 problems in this code:
- Recipients distribution happens after submitting mailing. So if we are unlucky (i.e. if a mailing job picks up the mailings right at that moment) the mailing sender can start sending the mailings before the distribution has happened
- None of the steps checks whether the earlier steps reported any error
- The change is not atomic: if an error happens, there is no attempt to undo the earlier steps
These problems can have various consequences, from my experience:
- The submitting works but setting the status fails: the A/B mailing is being sent but this has status Draft. Opening it will display a report but it will not be possible to pick the Final
- The submitting fails but setting the status works: the A/B mailing is not sent but has status Testing. Opening it will display the composer but it will not be possible to submit the mailing.
- In any of the previous cases, if the distribution worked fine any attempt to send again the mailing without precaution will cause the distribution to happen again, which means that recipients of mailing A will be reset to whole target group and mailing B and C will receive due percentage of that group, **without removing the recipients they already got in previous submit**, hence duplicate sendings. That one can be even worse when the error is a deadlock, and the query is retried.
I *think* that making all 4 steps happen in a single DB transaction would solve all the problems I mention here.
Would that be a good approach? If so, does it make sense to put the whole function in a transaction regardless of the target status, or shall the function be re-organised a bit to have the status setting done in the case statement and make only the `Testing` use case atomic?
With those answers, I'm happy to work on a PR.https://lab.civicrm.org/dev/core/-/issues/3775Disable Deadlock retries for Mailing Jobs2024-03-24T05:03:28ZseamusleeDisable Deadlock retries for Mailing JobsSo CiviCRM added a feature which re-tries the same query x number of times by default that is 3 when either a deadlock or a lock wait timeout is hit which is useful, but in the concept of mailing job processing it is not so useful becaus...So CiviCRM added a feature which re-tries the same query x number of times by default that is 3 when either a deadlock or a lock wait timeout is hit which is useful, but in the concept of mailing job processing it is not so useful because it means it can get tied up on get_lock queries re-trying them a silly number of times when it should be moving onto the next thingseamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/5108Inconsistent handling of tag name and tag label2024-03-23T14:15:54ZDetlev SieberInconsistent handling of tag name and tag label## Overview
When you change a tag in the tag tree, only the label is changed, the name remains the old entry. So after changing and reloading, in the tag tree the old entry is still shown - despite the previous change.
In the contact s...## Overview
When you change a tag in the tag tree, only the label is changed, the name remains the old entry. So after changing and reloading, in the tag tree the old entry is still shown - despite the previous change.
In the contact summary, the change is not reflected: Because there, the tag name is used, not the tag label. Which also seems, hmm..., interesting...
## Reproduction steps
1. Tag a contact with a specific tag from the tag tree
2. Click on **Contacts -\> Manage Tags**
3. Rename the previously selected tag
4. Reload the tag list -\> again, the old label/name is shown
5. Reload the contact from step 1.: -\> again, the old label/name is shown
## Current behaviour
Renaming the tag in the tag tree only changes the field civicrm_tag.label, not the field civicrm\_tag.name.
This "might" be what we want - however, on several occasions, the tag name is used instead of the tag name.
## Expected behaviour
I would recommend, that both name and label should be changed.
## Environment information
* **CiviCRM:** 5.69.5https://lab.civicrm.org/dev/core/-/issues/3787Issue with SQL import with > and < in the SQL query2024-03-23T05:03:32ZseamusleeIssue with SQL import with > and < in the SQL queryOverview
----------------------------------------
When using the SQL import datasource there is an issue in recent versions of CiviCRM due to the user job entity.
Reproduction steps
----------------------------------------
1. Create tab...Overview
----------------------------------------
When using the SQL import datasource there is an issue in recent versions of CiviCRM due to the user job entity.
Reproduction steps
----------------------------------------
1. Create table in database that contains at least a field called id and insert some rows, less than 15 would be enough
1. Ensure that your role has permission to use the SQL datasource
1. Click on **Contacts -> Import Contacts**.
1. Select SQL mode and enter an SQL like `SELECT * FROM <table name> WHERE id > 5 AND id <= 12`.
1. Got an error "**Fatal error: DB syntax error**".
Expected behaviour
----------------------------------------
Should be able to move onto the Field mapping stepps
Environment information
----------------------------------------
* __CiviCRM:__ _5.49.5_
Comments
----------------------------------------
It seems to be because we are getting the sqlQuery from the userJob entity as per https://github.com/civicrm/civicrm-core/blob/master/CRM/Import/DataSource/SQL.php#L85 and https://github.com/civicrm/civicrm-core/blob/master/CRM/Import/DataSource.php#L225 and that seems to have an html encoded value for < and > so the query includes > etc rather than > in it
ping @eileenhttps://lab.civicrm.org/dev/core/-/issues/3785participant field group sort order does not reflect configured order2024-03-23T05:03:29Zmagnolia61participant field group sort order does not reflect configured orderOverview
----------------------------------------
We have several custom field groups for participants.
Some for a specific event type, some others for specific participant roles
Current behaviour
---------------------------------------...Overview
----------------------------------------
We have several custom field groups for participants.
Some for a specific event type, some others for specific participant roles
Current behaviour
----------------------------------------
Currently the order in which the custom field groups are displayed while editing of viewing does not reflect the sort order that we selected in the custom field group settings. There is even a difference between viewing and editing a participant the one is ascending, the other descending.
Proposed behaviour
----------------------------------------
The sort order of the custom field groups for participants follows the selected order of the custom field groups. They are not groupes by selector (event type, role, etc), but follow the order that is configured.
Comments
----------------------------------------
I have no clue where to find this, and I'm not really a coder. Probably this is a very small change if you know where to look for.https://lab.civicrm.org/dev/core/-/issues/5057Make descriptions visible in drop down2024-03-22T18:22:38ZyashodhaMake descriptions visible in drop downAll the select2 drop-down are mostly option values which do have a description field in the database.
It will be useful to use this for display in select2 drop-downs.
We already show description for entities like events. It will be help...All the select2 drop-down are mostly option values which do have a description field in the database.
It will be useful to use this for display in select2 drop-downs.
We already show description for entities like events. It will be helpful to choose options for the user(if options do indeed explanation and are configured as such)https://lab.civicrm.org/dev/core/-/issues/5109Smarty 3 causes crash if exception thrown, e.g. by crmAPI2024-03-22T15:10:45ZRichSmarty 3 causes crash if exception thrown, e.g. by crmAPIOverview
----------------------------------------
I think this is a general problem that could occur if a smarty function throws an exception. The page crashes with:
> undefined extension class 'Smarty_Internal_Method_Trigger_Error'
[...Overview
----------------------------------------
I think this is a general problem that could occur if a smarty function throws an exception. The page crashes with:
> undefined extension class 'Smarty_Internal_Method_Trigger_Error'
[chat mention](https://chat.civicrm.org/civicrm/pl/gnqn1rihnprc7er1fcssqd1j6r)
Reproduction steps
----------------------------------------
I edited EventInfo.tpl to put this in:
```
{crmAPI var='local_date_time' entity='Event' action='getvalue' return="custom_115" id=$event.id}
```
Note that I had a custom_115 field defined for all events, but this event did not have a value for that field.
Visit the page that uses that template.
Crash.
Environment information
----------------------------------------
* __CiviCRM:__ 5.70 - 5.71.1
* __PHP:__ 8.1
* __CMS:__ D7
Comments
----------------------------------------
I'm not sure, but from memory api3 getvalue has changed; it now gives an *error* saying:
> "error_message": "field custom_115 unset or not existing"
I'm sure before it just used to return nothing.
Or it could be that before Smarty 3, it was happy to treat nothing as '' and now it's more picky.
I think the main problem seems to be that the exception/error handling is broken in Smarty3. Obviously if there's a bug in the template, it's going not to work, but it oughtn't crash the whole page.
The code that throws the error that causes the crash is CRM/Core/Smarty/plugins/function.crmAPI.php L35:
$smarty->trigger_error('{crmAPI} ' . $e->getMessage());https://lab.civicrm.org/dev/core/-/issues/5107Premiums configuration gives a 500 error2024-03-22T15:02:16ZJonGoldPremiums configuration gives a 500 errorOverview
----------------------------------------
In "Manage Contribution Pages", clicking on the "Premiums" page gives a 500 error. This happens in 5.71 and master, not in 5.70.
Reproduction steps
-------------------------------------...Overview
----------------------------------------
In "Manage Contribution Pages", clicking on the "Premiums" page gives a 500 error. This happens in 5.71 and master, not in 5.70.
Reproduction steps
----------------------------------------
See above.
Comments
----------------------------------------
This seems Smarty-related. I tried a `git bisect` but there's a different issue that breaks this page that makes that difficult. However, below is the error and backtrace I get when I set XDebug to pause on error:
```
"Type of SmartyCompilerException:: must be int (as in class Exception)"
include (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smartycompilerexception.php:8)
Composer\Autoload\{closure:/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/composer/ClassLoader.php:575-577} (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/composer/ClassLoader.php:576)
Composer\Autoload\ClassLoader->loadClass (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/composer/ClassLoader.php:427)
Smarty_Internal_TemplateCompilerBase->trigger_template_error (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatecompilerbase.php:1153)
Smarty_Internal_CompileBase->closeTag (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_compilebase.php:196)
Smarty_Internal_Compile_Private_Block_Plugin->compile (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_compile_private_block_plugin.php:77)
Smarty_Internal_TemplateCompilerBase->callTagCompiler (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatecompilerbase.php:768)
Smarty_Internal_TemplateCompilerBase->compileTag2 (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatecompilerbase.php:1722)
Smarty_Internal_TemplateCompilerBase->compileTag (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatecompilerbase.php:565)
Smarty_Internal_Templateparser->yy_r45 (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templateparser.php:2559)
Smarty_Internal_Templateparser->yy_reduce (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templateparser.php:3481)
Smarty_Internal_Templateparser->doParse (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templateparser.php:3573)
Smarty_Internal_SmartyTemplateCompiler->doCompile (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_smartytemplatecompiler.php:128)
Smarty_Internal_TemplateCompilerBase->compileTemplateSource (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatecompilerbase.php:481)
Smarty_Internal_TemplateCompilerBase->compileTemplate (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatecompilerbase.php:402)
Smarty_Template_Compiled->compileTemplateSource (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php:184)
Smarty_Template_Compiled->process (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php:141)
Smarty_Template_Compiled->render (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php:105)
Smarty_Internal_Template->render (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php:216)
Smarty_Internal_Template->_subTemplateRender (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php:385)
content_65fa056d841377_41904664 (/home/jon/local/civicrm-buildkit/app/private/dmaster/default/civicrm/templates_c/en_US/3f/b3/c1/3fb3c10824e8bcce0275790f5b54d852eeb8a4d7_0.file.default.tpl.php:53)
Smarty_Template_Resource_Base->getRenderedTemplateCode (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php:123)
Smarty_Template_Compiled->render (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php:114)
Smarty_Internal_Template->render (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php:216)
Smarty_Internal_Template->_subTemplateRender (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php:385)
content_65fc658f02ae61_03133634 (/home/jon/local/civicrm-buildkit/app/private/dmaster/default/civicrm/templates_c/en_US/7e/52/3d/7e523d898add0d1ddbfb9d731ea772b38ca3b855_0.file.snippet.tpl.php:73)
Smarty_Template_Resource_Base->getRenderedTemplateCode (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php:123)
Smarty_Template_Compiled->render (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php:114)
Smarty_Internal_Template->render (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php:216)
Smarty_Internal_TemplateBase->_execute (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php:232)
Smarty_Internal_TemplateBase->fetch (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php:116)
CRM_Core_QuickForm_Action_Display->renderForm (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Display.php:117)
CRM_Core_QuickForm_Action_Display->perform (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Display.php:83)
HTML_QuickForm_Controller->handle (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php:203)
HTML_QuickForm_Page->handle (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php:103)
CRM_Core_Controller->run (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Controller.php:355)
CRM_Utils_Wrapper->run (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Utils/Wrapper.php:98)
CRM_Core_Invoke::runItem (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Invoke.php:298)
CRM_Core_Invoke::_invoke (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Invoke.php:69)
CRM_Core_Invoke::invoke (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Invoke.php:36)
civicrm_invoke (/home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/drupal/civicrm.module:471)
menu_execute_active_handler (/home/jon/local/civicrm-buildkit/build/dmaster/web/includes/menu.inc:527)
{main} (/home/jon/local/civicrm-buildkit/build/dmaster/web/index.php:21)https://lab.civicrm.org/dev/core/-/issues/5100Payment appears as 123 units of $1 rather than one unit of $123 if using othe...2024-03-22T14:38:36ZwmortadaPayment appears as 123 units of $1 rather than one unit of $123 if using other amount fieldOverview
----------------------------------------
This appears to be a regression in CiviCRM 5.69 upwards. If you create a contribution pages that allows other amounts the amount in that field is recorded in the quantity field of the li...Overview
----------------------------------------
This appears to be a regression in CiviCRM 5.69 upwards. If you create a contribution pages that allows other amounts the amount in that field is recorded in the quantity field of the line item rather than the unit price.
It looks like the quantity and the unit price have been swapped.
Reproduction steps
----------------------------------------
1. Create a contribution page with the other amounts section enabled
2. Visit the contribution page and type an amount in 'Other amount' field
3. View the contact record - note that the quantity is the amount and the unit price is 1.00
![image](/uploads/c16ed4be20e97bb2f86d63d5842d481e/image.png)
![image](/uploads/2e27e1f53dfca423a63ef4d98a5f0042/image.png)
![image](/uploads/85840162f1fc088ddcd6de5c7565ea5d/image.png)
Current behaviour
----------------------------------------
The amount is recorded in the quantity field. The unit price is $1.00.
Expected behaviour
----------------------------------------
The quantity is 1. The amount is recorded in the unit price field.
Environment information
----------------------------------------
Tested in CiviCRM 5.69, 5.70 and 5.73alpha1 (current dmaster). It is an issue in all three versions.
I'm not sure when this stopped working, but think it is quite recent.5.71.2https://lab.civicrm.org/dev/core/-/issues/3833PHP 8.2 Dynamic Properties are deprecated2024-03-22T12:22:59ZBradley TaylorPHP 8.2 Dynamic Properties are deprecatedSee https://wiki.php.net/rfc/deprecate_dynamic_properties.
I see this as a big one, which could require a significant number of fixes for CiviCRM. The RFC has a good example showing what has changed:
```
class User {
public $name;
...See https://wiki.php.net/rfc/deprecate_dynamic_properties.
I see this as a big one, which could require a significant number of fixes for CiviCRM. The RFC has a good example showing what has changed:
```
class User {
public $name;
}
$user = new User;
// Assigns declared property User::$name.
$user->name = "foo";
// Oops, a typo:
$user->nane = "foo";
// PHP <= 8.1: Silently creates dynamic $user->nane property.
// PHP 8.2: Raises deprecation warning, still creates dynamic property.
// PHP 9.0: Throws Error exception.
```
There are many uses of dynamic properties in CiviCRM core which fall into multiple categories:
1. Known undeclared properties. For example `CRM_Activity_Form_Task_Batch` repeatedly references `$_fields` which should just be defined.
2. Dynamic properties. The main example of this is `CRM_Core_DAO`. PHP allows for this use-case by either extending `stdClass` or using the new ` #[AllowDynamicProperties]` attribute. Where possible we should prefer extending `stdClass` which is likely to have better long-term support (i.e. into the PHP 9.x series)
3. Typo's etc. Cases where the property is defined, but later referenced with a different name. These are easy; we just fix the typo (whilst ensuring we don't break any backwards compatiability for plugins using the wrong spelling)
I suggest CiviCRM developers should start to be made aware of this now, to avoid making the problem worse. Incrementally starting to fix the issue, a class or two at a time, seems like a good idea.
In many cases it's not clear why dynamic properties (or declared properties for that matter) are being used instead of a standard variable. This might be a good chance to start annotating properties as either:
- `@api`; designed to be used within hooks, on singletons etc by CiviCRM extensions
- `@internal`; not designed to be used by extensions, and liable to be removed without deprecation.https://lab.civicrm.org/dev/core/-/issues/1968Can't display System Status page - Guzzle error2024-03-22T05:03:28Zaydunsaidan.saunders@squiffle.ukCan't display System Status page - Guzzle errorOverview
----------------------------------------
Accessing the System Status page produces the boilerplate but no content.
Reproduction steps
----------------------------------------
1. Go to **Administer > Administration Console > Sy...Overview
----------------------------------------
Accessing the System Status page produces the boilerplate but no content.
Reproduction steps
----------------------------------------
1. Go to **Administer > Administration Console > System Status**
Current behaviour
----------------------------------------
The Drupal log shows:
```
| Location | https://example.org/civicrm/ajax/rest |
| Referrer | https://example.org/civicrm/a/ |
| Message | Error: Call to undefined function GuzzleHttp\Psr7\get_message_body_summary() in GuzzleHttp\Exception\RequestException::getResponseBodySummary() (line 127 of /var/www/sites/all/modules/civicrm/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php). |
```
This is a failure in handling an exception, so unless there is some other failure this function is not called.
It looks to be an internal error in the Guzzle. A quick search, shows reports of the problem in other software using this Guzzle.
- https://github.com/nextcloud/twofactor_gateway/issues/312
- https://wordpress.org/support/topic/internal-server-error-620/
- https://stackoverflow.com/questions/61363997/guzzlehttp-gives-call-to-undefined-function-guzzlehttp-psr7-get-message-body-su
This is only happening on one server. Others are functioning normally.
Commenting out the referenced line lets the status be produced.
Dumping the `$response` object shows a status of 403, but does not contain the URL.
Environment information
----------------------------------------
* __CiviCRM:__ _5.28.2_
* __PHP:__ _7.3_
* __CMS:__ _Drupal 7.30_
* __Web Server:__ _Apache 2.4_https://lab.civicrm.org/dev/core/-/issues/3768Improvement to Case Detail report2024-03-22T05:03:27ZyashodhaImprovement to Case Detail reportExpose some of the useful columns and filters :
- expose city in case detail report
- add filter for 'Activity type of the last activity'Expose some of the useful columns and filters :
- expose city in case detail report
- add filter for 'Activity type of the last activity'yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/5103Saving checkbox custom fields via APIv4 fails for custom/dynamic entities2024-03-22T03:13:00ZjensschuppeSaving checkbox custom fields via APIv4 fails for custom/dynamic entities## Steps to reproduce
* For a custom/dynamic entity type (e.g. using the [_Entity Construction Kit_](https://github.com/systopia/de.systopia.eck)), add a custom field with HTML type `CheckBox`
* Try to create/save an entity with that fi...## Steps to reproduce
* For a custom/dynamic entity type (e.g. using the [_Entity Construction Kit_](https://github.com/systopia/de.systopia.eck)), add a custom field with HTML type `CheckBox`
* Try to create/save an entity with that field with APIv4, e.g. using the _ECK_ Afform forms (whether the field has a value is irrelevant)
## Expected behavior
Entity saved, field has selected (or no) value
## Actual behavior
Entity not saving, error is `Error: Class name must be a valid object or a string in civicrm_api3_generic_getoptions() (line 442 of /path/to/civicrm/civicrm-core/api/v3/Generic.php).`
## Technical details
* `DAOActionTrait` calls the global (APIv3) function `formatCheckBoxField()` for fields with an HTML type of `CheckBox` [here](https://github.com/civicrm/civicrm-core/blob/018741e09162a29f34a01d04141e3f96ddcade19/Civi/Api4/Generic/Traits/DAOActionTrait.php#L260-L263)
* That function calls APIv3 `getoptions` with the given entity (`Eck_*`)
* APIv3 "normalizes" entity names, stripping the `_` which results in the APIv3 entity being `Eck*`
* Resolving the entity to a DAO class fails at the latest in `_civicrm_api3_get_DAO()` due to the "normalized" entity name
* Finally, when calling `$dao::buildOptions()` on `null`, the error occurs
## Proposed solution
As commented in `DAOActionTrait` for the call of `formatCheckBoxField()`: `this function should be part of a class` - and re-implemented using APIv4 `getFields` with `loadOptions=TRUE` for the given `custom_field_id`.https://lab.civicrm.org/dev/core/-/issues/2994Support oEmbed for external facing pages2024-03-21T18:50:44ZJoeMurraySupport oEmbed for external facing pagesAn important evolution of CiviCRM is to better support remote sites exposing CiviCRM forms and content.
Many platforms including WordPress and Drupal core since 8.6 support oEmbed, which allows a site to pull in content from a different...An important evolution of CiviCRM is to better support remote sites exposing CiviCRM forms and content.
Many platforms including WordPress and Drupal core since 8.6 support oEmbed, which allows a site to pull in content from a different site that exposes its content as oEmbed.
There is a good list of oEmbed providers, and CiviCRM should aspire to join it: https://oembed.com/providers.json
We should expose the following 'pages' as oEmbed content, using appropriate standard markup for use in WordPress and Drupal 8.6+ sites, and support the workflow for confirmation, thank you, and search results as appropriate:
1. Phase 1
1. Contribution page
2. Event info page
3. Event registration page
2. Phase 2
1. Something like a profile create/edit page that does not involve a payment but allows submission of a form to create a contact and activity and perhaps more (eg parent-child relationship)
2. Search Kit page
3. Petition page
3. Phase 3
1. Personal Campaign Page
2. Pages from extensions, eg Grant Application Page
3. CiviSurvey pages
Note: I haven't done the research to understand the details of oEmbed and potential challenges. I think this could be done through extension(s).
I'm posting this in order to generate discussion for a possible Roadmap item.https://lab.civicrm.org/dev/core/-/issues/3449Afform: checkboxes should have default false value2024-03-21T05:03:28ZRichAfform: checkboxes should have default false valueOverview
----------------------------------------
If you have a checkbox used, for example, for "is_test" on a contribution search table but without explictly configuring a default value, the UI shows an un-checked checkbox, which *shou...Overview
----------------------------------------
If you have a checkbox used, for example, for "is_test" on a contribution search table but without explictly configuring a default value, the UI shows an un-checked checkbox, which *should* be the visual representation of "is_test = 0" but is actually representing *no filter on is_test*.
After operating the checkbox the UI and the meaning are in-sync.
While this can be solved by the form builder designer setting an explicit default value, there is no logical sense to *not* having a default value when the form element is binary.
Current behaviour
----------------------------------------
If person who built the form forgets / does not know to include a default value on a checkbox, the UI is initially broken, results are misleading.
Proposed behaviour
----------------------------------------
A checkbox should insist on a default value, defaulting to false, so that the UI and the meaning of the filter are always in sync.
Comments
----------------------------------------
https://chat.civicrm.org/civicrm/pl/9613mtpi6j8ypxf879p7eyyz5a