Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-12-07T00:42:41Zhttps://lab.civicrm.org/dev/core/-/issues/3133Extend Authx functionality to support validation of externally generated JWTs2023-12-07T00:42:41ZJohn TwymanExtend Authx functionality to support validation of externally generated JWTsOverview
----------------------------------------
We would like to extend AuthX's functionality so that it can validate JWTs generated/signed by third party systems. The motivation for this is that we use auth0 for authZ/authN with CiviC...Overview
----------------------------------------
We would like to extend AuthX's functionality so that it can validate JWTs generated/signed by third party systems. The motivation for this is that we use auth0 for authZ/authN with CiviCRM. We're building new applications that need to query Civi via its API _as the user rather than as the client apps themselves_.
Creating API keys for every user is not feasible. Accessing the AuthX-supported API endpoint and supplying a valid JWT for the user is what we're keen to implement.
Current behaviour
----------------------------------------
AuthX can validate JWTs that have been generated by the same CiviCRM installation.
Proposed behaviour
----------------------------------------
Implement code that dispatches a new Symfony event which would allow an extension to override how the scope and sub claims are validated by the AuthX framework (for example currently, if it doesn't start with `cid` no claim can be validated).
This would make it possible to validate externally generated/signed JWTs.
Comments
----------------------------------------
Tim and I had a chat about this [a while ago](https://chat.civicrm.org/civicrm/pl/acbnapozsbgimrsmh4bqdrtbwh). That conversation proved the basis for writing up an implementation for this improvement. We'd love to see it reviewed, merged, etc. We'll raise a Pull Request accordingly and I'll update this Issue here with the link.
We've also written [a CiviCRM extension that leverages this new functionality](https://github.com/australiangreens/civiauth0jwt), to make it possible for people using auth0 as their IdP to use CiviCRM's API with user permissions.https://lab.civicrm.org/dev/core/-/issues/3132CRM_Core_BAO_Address::addGeocoderData mishandling NULL geocodes2022-03-24T04:03:56ZJohn TwymanCRM_Core_BAO_Address::addGeocoderData mishandling NULL geocodesOverview
----------------------------------------
NULL lat/lng return values from the Nominatim/OSM geocoding service - through either the de.systopia.osm or org.wikimedia.geocoder extensions - are being saved as 0,0. [Discussion on Matt...Overview
----------------------------------------
NULL lat/lng return values from the Nominatim/OSM geocoding service - through either the de.systopia.osm or org.wikimedia.geocoder extensions - are being saved as 0,0. [Discussion on Mattermost points to a bug](https://chat.civicrm.org/civicrm/pl/esa4sr15opfdjps6c64faecuqc) in the `CRM_Core_BAO_Address:addGeocoderData` function.
Reproduction steps
----------------------------------------
1. Install, enable and configure either the [de.systopia.osm](https://github.com/systopia/de.systopia.osm) or [org.wikimedia.geocoder](https://github.com/eileenmcnaughton/org.wikimedia.geocoder) extensions.
2. Load any Contact record
3. Add/edit an address; make sure it's one that won't geocode (eg. "123 Alphabet St, Pretendsville")
4. You should receive an alert indicating a failure to geocode the address
5. Edit the address and inspect the lat/lng fields. They will contain zeroes.
Current behaviour
----------------------------------------
The latitude and longitude fields (`geo_code_1`, `geo_code_2` in `civicrm_address`) are saving `0` as their values when OSM/Nominatim returns an empty array (ie. no geocode results).
Expected behaviour
----------------------------------------
The latitude and longitude fields should store `NULL`.
Environment information
----------------------------------------
* __CiviCRM:__ _5.49alpha1/5.46.3_
* __PHP:__ _7.3__
* __CMS:__ _/Drupal 7.88_
* __Database:__ _MariaDB 10.4.21_
Comments
----------------------------------------
@seamuslee has highlighted [this line in CRM_Core_BAO_Address::addGeocoderData](https://github.com/civicrm/civicrm-core/blob/a5755b2f3add870c1e8e5b9b4539aff43e39795f/CRM/Core/BAO/Address.php#L1315) as the most likely cause of the problem.5.49.0https://lab.civicrm.org/dev/core/-/issues/3131Enable selective visibility of contacts in search using a profile2023-12-07T05:03:22ZspalmstromEnable selective visibility of contacts in search using a profileOverview
----------------------------------------
In some environments it may be desirable to limit what most users can see when searching for contacts using a profile, for example restricting visibility to first name and city unless th...Overview
----------------------------------------
In some environments it may be desirable to limit what most users can see when searching for contacts using a profile, for example restricting visibility to first name and city unless the user has the right to view the contact. Currently, whilst you can restrict what the user sees using the profile, mapping for example, reveals the address and clicking on the icon on the map reveals the contact details. An improvement would be to disable mapping and the ability to view contact details unless the user has the rights to view the contact in question.
Example use-case
----------------------------------------
1. Create a suitable profile.
1. Enter a search term that will return contacts to which the user has view rights and some to which they have not.
Current behaviour
----------------------------------------
![image](/uploads/ddd0f64ae64632f662e430d2453002a7/image.png)
Proposed behaviour
----------------------------------------
![image](/uploads/c1fdaeafe57911839966ff83a460ee78/image.png)
Note that the user has view rights on 851 but not on 853. Notice that the first and last name is blanked out. If they had no view rights on any contact, the _Map these contacts_ would not appear. The little person icon does not appear if the user cannot view all contacts (as clicking on it doesn't do much). If the user has no rights to view any of the contacts, the _Last and First Name_ column does not appear either.
![image](/uploads/82d2fd5cfdad41d8f55eabd49885431c/image.png)https://lab.civicrm.org/dev/backdrop/-/issues/6Clean up autoloader and views plugins2022-10-11T19:36:35ZlarynClean up autoloader and views pluginsI was seeing this while trying to edit an unrelated view (the exposed filter modal wouldn't open and this error was in the log):
> Warning: require_once(/app/modules/civicrm/backdrop/modules/views/civicrm/civicrm_plugin_argument_default...I was seeing this while trying to edit an unrelated view (the exposed filter modal wouldn't open and this error was in the log):
> Warning: require_once(/app/modules/civicrm/backdrop/modules/views/civicrm/civicrm_plugin_argument_default_civicrm_id.inc): failed to open stream: No such file or directory in require_once() (line 4054 of /app/core/includes/bootstrap.inc).
I looked in `backdrop/modules/views/civicrm` and it seems that perhaps one of the files is mis-named. I renamed `civicrm_plugin_argument_default.inc` to be `civicrm_plugin_argument_default_civicrm_id.inc` and then the exposed filter modal opened for me again. I haven't tested further beyond that, though.https://lab.civicrm.org/dev/core/-/issues/3129The way the Most Recent Activity column on Find Cases is calculated makes no ...2023-12-04T05:03:27ZDaveDThe way the Most Recent Activity column on Find Cases is calculated makes no senseIt shares code with the Case Dashboard, where the Most Recent Activity column only appears in a section for cases that have _recent_ activity. But on Find Cases depending on your search criteria it will of course include cases that do no...It shares code with the Case Dashboard, where the Most Recent Activity column only appears in a section for cases that have _recent_ activity. But on Find Cases depending on your search criteria it will of course include cases that do not have recent activity. For those cases, the column displays blank, when it really should simply display the most recent activity, whenever it was.
To reproduce, create a case and complete an activity. Wait 2 weeks. Then do a find cases and look at the Most Recent Activity column for that case.
Does Find Cases even need this column?https://lab.civicrm.org/dev/core/-/issues/3127Print/Merge document filename does not include .pdf when using wkhtmltopdf2022-03-28T23:45:18Zchris_bluejacPrint/Merge document filename does not include .pdf when using wkhtmltopdfOverview
----------------------------------------
Using wkhtmltopd for pdf generation
Print/Merge Document for selected contact
The downloaded pdf file has no extension (i.e. its just CiviLetter not CiviLetter.pdf)
Reproduction steps
-...Overview
----------------------------------------
Using wkhtmltopd for pdf generation
Print/Merge Document for selected contact
The downloaded pdf file has no extension (i.e. its just CiviLetter not CiviLetter.pdf)
Reproduction steps
----------------------------------------
1. Click on Contact -> Print/Merge Document
2. Select Document Typ: Portable Document Format (.pdf)
3. Select Download Document
Document downloaded is a valid pdf, but the file has no extension
Current behaviour
----------------------------------------
As above.
Expected behaviour
----------------------------------------
Filename includes ".pdf"
Receipts, Mailing labels etc do not have the same issue.
Environment information
----------------------------------------
* __CiviCRM: 5.46.2
* __wkhtmltox: 0.12.6-1.buster amd64
Comments
----------------------------------------
Likely problem and fix
CRM_Contact_Form_Task PDFTrait.php calls
https://lab.civicrm.org/dev/core/-/blob/5.48/CRM/Contact/Form/Task/PDFTrait.php#L266
```php
if ($type === 'pdf') {
CRM_Utils_PDF_Utils::html2pdf($html, $fileName, FALSE, $formValues);
}
```
At this point $fileName does not have .pdf file type
The extension is stripped in CRM_Utils_PDF_Utils _html2pdf_dompdf
```php
// CRM-19183 remove .pdf extension from filename
$fileName = basename($fileName, ".pdf");
```
So a fix in PDFTrait.pdf, without impacting dompdf operation:
https://lab.civicrm.org/dev/core/-/blob/5.48/CRM/Contact/Form/Task/PDFTrait.php#L266
```php
if ($type === 'pdf') {
CRM_Utils_PDF_Utils::html2pdf($html, $fileName . '.' . $type, FALSE, $formValues);
}
```
The above has been tested with dompdf and wkhtmltopdf5.49.0https://lab.civicrm.org/dev/financial/-/issues/192CiviCRM crashes when I select ZMK as default currency2022-09-09T13:10:06ZmitoworksCiviCRM crashes when I select ZMK as default currencyA clean install of CiviCRM on Wordpress crashes whenever I select ZMK as default currency. My installation details are:
> WordPress version 5.9.2
> Current theme: Twenty Twenty-Two (version 1.1)
> Current plugin: CiviCRM (version 5.4...A clean install of CiviCRM on Wordpress crashes whenever I select ZMK as default currency. My installation details are:
> WordPress version 5.9.2
> Current theme: Twenty Twenty-Two (version 1.1)
> Current plugin: CiviCRM (version 5.47.2)
> PHP version 8.0.16
```
Error Details
=============
An error of type E_ERROR was caused in line 19 of the file /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/vendor/brick/money/src/Exception/UnknownCurrencyException.php. Error message: Uncaught Brick\Money\Exception\UnknownCurrencyException: Unknown currency code: ZMK in /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/vendor/brick/money/src/Exception/UnknownCurrencyException.php:19
Stack trace:
#0 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/vendor/brick/money/src/ISOCurrencyProvider.php(120): Brick\Money\Exception\UnknownCurrencyException::unknownCurrency()
#1 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/vendor/brick/money/src/Currency.php(91): Brick\Money\ISOCurrencyProvider->getCurrency()
#2 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/vendor/brick/money/src/Money.php(189): Brick\Money\Currency::of()
#3 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/CRM/Utils/Money.php(209): Brick\Money\Money::of()
#4 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/CRM/Utils/Money.php(88): CRM_Utils_Money::formatUSLocaleNumericRounded()
#5 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/CRM/Core/Resources/Common.php(219): CRM_Utils_Money::format()
#6 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/CRM/Core/Resources/Common.php(128): CRM_Core_Resources_Common::coreResourceList()
#7 /home/monkey/public_html/civic/wp-content/uploads/civicrm/templates_c/CachedCiviContainer.a02b080bd0d8fdf7053d123f1aecc5d2.php(807): CRM_Core_Resources_Common::createFullBundle()
#8 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/vendor/symfony/dependency-injection/Container.php(306): CachedCiviContainer->getBundle_CoreResourcesService()
#9 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/Civi.php(174): Symfony\Component\DependencyInjection\Container->get()
#10 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/CRM/Core/Resources.php(214): Civi::service()
#11 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm/CRM/Core/Resources.php(382): CRM_Core_Resources->addBundle()
#12 /home/monkey/public_html/civic/wp-content/plugins/civicrm/civicrm.php(1087): CRM_Core_Resources->addCoreResources()
#13 /home/monkey/public_html/civic/wp-content/plugins/civicrm/includes/civicrm.admin.php(761): CiviCRM_For_WordPress->add_core_resources()
#14 /home/monkey/public_html/civic/wp-includes/class-wp-hook.php(307): CiviCRM_For_WordPress_Admin->admin_page_load()
#15 /home/monkey/public_html/civic/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters()
#16 /home/monkey/public_html/civic/wp-includes/plugin.php(474): WP_Hook->do_action()
#17 /home/monkey/public_html/civic/wp-admin/admin.php(237): do_action()
#18 {main}
thrown
```
After this, I can't do anything else under the CiviCRM menu
It looks like a change in currency to ZMW in 2013 is causing the issue.5.54.0https://lab.civicrm.org/dev/core/-/issues/3126CiviReport - Title and Statistics appearing at top and bottom of reports (fix...2022-03-19T15:08:54Zchris_bluejacCiviReport - Title and Statistics appearing at top and bottom of reports (fix identified)Overview
----------------------------------------
Reports (e.g. Contribution, membership reports etc) present with Title, query details at top; and Title, query details and Statistics, at bottom of the report.
This appears to be inadver...Overview
----------------------------------------
Reports (e.g. Contribution, membership reports etc) present with Title, query details at top; and Title, query details and Statistics, at bottom of the report.
This appears to be inadvertent - caused by an error in tpl script. See screenshot
![Screenshot_2022-03-18_205435](/uploads/98963f5b3b28dce7f9da68b3fd7593a4/Screenshot_2022-03-18_205435.png)
Reproduction steps
----------------------------------------
1. Run a report - print or save to pdf
Current behaviour
----------------------------------------
See outline above.
Expected behaviour
----------------------------------------
Title and Query at top of report only.
Statistics at bottom of report.
Environment information
----------------------------------------
* __CiviCRM: 5.46.2
Solution
----------------------------------------
The error in the tpl is here -->
https://lab.civicrm.org/dev/core/-/blob/master/templates/CRM/Report/Form.tpl#L47
Replace:
`{include file="CRM/Report/Form/Statistics.tpl" top="false" bottom=true}`
With:
`{include file="CRM/Report/Form/Statistics.tpl" top=false bottom=true}`
I'm not sure how to do a pull request/merge request.5.47.3https://lab.civicrm.org/dev/core/-/issues/3125Release 5.46.3 includes jquery-ui 1.13.0 rather than 1.13.12023-12-05T05:03:20ZkenRelease 5.46.3 includes jquery-ui 1.13.0 rather than 1.13.1Overview
----------------------------------------
Release 5.46.3 includes jquery-ui 1.13.0 rather than 1.13.1
Reproduction steps
----------------------------------------
1. View bower_components/jquery-ui/bower.json
1. Version is 1.13.0Overview
----------------------------------------
Release 5.46.3 includes jquery-ui 1.13.0 rather than 1.13.1
Reproduction steps
----------------------------------------
1. View bower_components/jquery-ui/bower.json
1. Version is 1.13.0https://lab.civicrm.org/dev/core/-/issues/3124SearchKit - Add fields for core icons (contact type / activity type)2022-04-06T00:43:28ZsamuelsovSearchKit - Add fields for core icons (contact type / activity type)In the idea that we want to make searches a bit more compact and easy for the eyes, it would be good to add support for new fields to display :
- contact type and sub type icons
- activity font-awesome icons
![ksnip_20220316-170327](/up...In the idea that we want to make searches a bit more compact and easy for the eyes, it would be good to add support for new fields to display :
- contact type and sub type icons
- activity font-awesome icons
![ksnip_20220316-170327](/uploads/89c180dacb96a941197ea418e54bce4a/ksnip_20220316-170327.png)colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3123Blog.tpl has text-wrap css for "#civicrm-news-feed .collapsed .crm-accordion...2023-12-02T05:03:29ZTrixorBlog.tpl has text-wrap css for "#civicrm-news-feed .collapsed .crm-accordion-header"I spent some time finding more info about the text-wrap CSS option, but I can't find a browser that supports it. Within CiviCRM there is a reference within the monaco-editor (bower_components) for CSS white-space (cssMode.js & cssWorker....I spent some time finding more info about the text-wrap CSS option, but I can't find a browser that supports it. Within CiviCRM there is a reference within the monaco-editor (bower_components) for CSS white-space (cssMode.js & cssWorker.js). So far I can tell it is only in the Blog.tpl. Not a big deal, but maybe remove or replace it.https://lab.civicrm.org/dev/core/-/issues/3122Form Builder: Deleting a form with a corresponding dashboard breaks the dashb...2022-03-22T17:07:09ZJonGoldForm Builder: Deleting a form with a corresponding dashboard breaks the dashboardOverview
----------------------------------------
Deleting a Form Builder form that has a corresponding `civicrm_dashboard` entry doesn't delete the `civicrm_dashboard` entry, resulting in a broken dashboard.
Reproduction steps
--------...Overview
----------------------------------------
Deleting a Form Builder form that has a corresponding `civicrm_dashboard` entry doesn't delete the `civicrm_dashboard` entry, resulting in a broken dashboard.
Reproduction steps
----------------------------------------
1. Create a search in Search Kit.
1. Create a corresponding Search Form.
1. Delete the search. Get the message `Form "%1" will also be deleted because it contains an embedded display from this search.`
1. Visit your dashboard.
Current behaviour
----------------------------------------
Drupal WSOD in one instance (D9), dashboard is completely missing in another (D7).
Expected behaviour
----------------------------------------
Deleting the Form should delete the dashboard entry just as deleting the search deletes the form.colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3120FormBuilder - Saving container as block is uneditable2022-03-19T21:47:08ZandyburnsFormBuilder - Saving container as block is uneditableIn my test if I save a container as a block in formbuilder, I cannot edit it when clicking here
![image](/uploads/f98ac1fa1b4a6895fa80b34cdff8db85/image.png)
Console errors attached.[console-export-formbuilder-edit.txt](/uploads/ec8f7c6...In my test if I save a container as a block in formbuilder, I cannot edit it when clicking here
![image](/uploads/f98ac1fa1b4a6895fa80b34cdff8db85/image.png)
Console errors attached.[console-export-formbuilder-edit.txt](/uploads/ec8f7c6757f587e24189a7128b3ae6d0/console-export-formbuilder-edit.txt)
Deactivated all WP plugins except for CiviCRM and switched to WP 2021 Theme.
Console errors then: [console-export-formbuilder-plugins-deactivate-step.txt](/uploads/4cdfd6ea5a4bb5ff4aabac678c5720de/console-export-formbuilder-plugins-deactivate-step.txt)
Civi 5.46.2 on WP 5.8.3 multisite.colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3119Post-upgrade messages no longer being displayed2022-03-22T13:16:42ZDaveDPost-upgrade messages no longer being displayedIn 5.44 for example, the post-upgrade message looks like this:
```
Congratulations! Your upgrade was successful!
A token has been updated in the invoice template. Check the system checks page to see if any action is required.
```
Note...In 5.44 for example, the post-upgrade message looks like this:
```
Congratulations! Your upgrade was successful!
A token has been updated in the invoice template. Check the system checks page to see if any action is required.
```
Note that there is always at least the `Congratulations! Your upgrade was successful!` that comes from https://github.com/civicrm/civicrm-core/blob/2eab44850a420083bafef133278b34f43d28cc70/CRM/Upgrade/Page/Upgrade.php#L139
In 5.47 for example you get nothing. This line is no longer TRUE: https://github.com/civicrm/civicrm-core/blob/2eab44850a420083bafef133278b34f43d28cc70/CRM/Upgrade/Page/Upgrade.php#L172
Doesn't affect `cv` just the UI.5.47.3https://lab.civicrm.org/dev/core/-/issues/3118CiviGrant - Can't edit existing grants following move to Core Extension2022-03-16T12:49:25ZMatt TrimCiviGrant - Can't edit existing grants following move to Core ExtensionOverview
----------------------------------------
When trying to edit an existing grant in CiviCRM of Civi versions 5.47.0 onwards, I am greeted with an error message.
Reproduction steps
----------------------------------------
Editin...Overview
----------------------------------------
When trying to edit an existing grant in CiviCRM of Civi versions 5.47.0 onwards, I am greeted with an error message.
Reproduction steps
----------------------------------------
Editing a Grant from a Contact Record:
1. Find any existing contact record that has an existing Grant, and navigate to the Contact Record -> Grants tab.
1. Press the "Edit" button.
1. Receive "Network Error Unable to reach the server. Please refresh this page in your browser and try again." status bounce message
1. Look at Watchdog / Error logs:
```
TypeError: Argument 2 passed to CRM_Grant_BAO_Grant::retrieve() must be of the type array, null given, called in /buildkit/build/user-prompts/vendor/civicrm/civicrm-core/ext/civigrant/CRM/Grant/Form/Grant.php on line 106 in CRM_Grant_BAO_Grant::retrieve() (line 75 of /buildkit/build/test/vendor/civicrm/civicrm-core/ext/civigrant/CRM/Grant/BAO/Grant.php)
```
Editing a Grant from the "Find Grants" screen:
1. Navigate to the "Find Grants" screen
1. Press "Search"
1. Press "Edit" on any of the displayed Grants
1. Note the same behaviour presents as above.
Current behaviour
----------------------------------------
```
TypeError: Argument 2 passed to CRM_Grant_BAO_Grant::retrieve() must be of the type array, null given, called in /buildkit/build/user-prompts/vendor/civicrm/civicrm-core/ext/civigrant/CRM/Grant/Form/Grant.php on line 106 in CRM_Grant_BAO_Grant::retrieve() (line 75 of /buildkit/build/test/vendor/civicrm/civicrm-core/ext/civigrant/CRM/Grant/BAO/Grant.php)
```
Expected behaviour
----------------------------------------
I should be able to edit a grant.
Comments
----------------------------------------
Pradeep has raised a Pull Request that addresses this: https://github.com/civicrm/civicrm-core/pull/22947
OR
https://github.com/civicrm/civicrm-core/pull/22948https://lab.civicrm.org/dev/core/-/issues/3117FormBuilder - support relationships between contacts2022-05-09T20:31:53ZsamuelsovFormBuilder - support relationships between contactsAdd the possibility to add/edit multiple contacts specifying the relationship between them in FormBuilder.
Example of use case that we want to be able to do on one form :
- create/edit an organization with a primary contact and a list o...Add the possibility to add/edit multiple contacts specifying the relationship between them in FormBuilder.
Example of use case that we want to be able to do on one form :
- create/edit an organization with a primary contact and a list of employees
- create/edit a household contact with parents and children contacts
Example of custom form that we currently use that we would like to replace with FormBuilder :
![screenshot](/uploads/61d27d13f044748b7d273f513628829d/screenshot.png)colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3116Event API is not available after upgrading to 5.472022-03-17T18:12:40ZedvanleeuwenEvent API is not available after upgrading to 5.47After upgrading from 5.46.0 to 5.47.1, I get the following error:
`API Exception: Event API is not available because CiviEvent component is disabled while checking events for timezones.`
Is this a regression fault or should I change so...After upgrading from 5.46.0 to 5.47.1, I get the following error:
`API Exception: Event API is not available because CiviEvent component is disabled while checking events for timezones.`
Is this a regression fault or should I change some configuration setting?5.47.2https://lab.civicrm.org/dev/core/-/issues/3115Error retrieving false settings via ajax/REST (API v3)2023-12-08T05:03:27ZAndrew WestError retrieving false settings via ajax/REST (API v3)Overview
----------------------------------------
If a setting is false in the settings table (encoded as "b:0;"), the JS V3 settings API doesn't return it via getvalue. You get 'Unknown error.' instead.
I think it's because of [this li...Overview
----------------------------------------
If a setting is false in the settings table (encoded as "b:0;"), the JS V3 settings API doesn't return it via getvalue. You get 'Unknown error.' instead.
I think it's because of [this line](https://github.com/civicrm/civicrm-core/blob/1754e1752eb8e516ec846a438005f6fcb55be247/CRM/Utils/REST.php#L303) in CRM_Utils_REST, where any FALSE results are interpreted as an error.
I assume this doesn't happen much via JS, as it would have come up. But I just hit it in a mailing, which [tries to retrieve](https://github.com/civicrm/civicrm-core/blob/1754e1752eb8e516ec846a438005f6fcb55be247/ang/crmMailing/EditRecipCtrl.js#L76) the auto_recipient_rebuild setting. It fails, so CiviMail doesn't respect this setting as a result.
The settings I have set as b:0 are:
- activity_assignee_notification
- profile_double_optin
- profile_add_to_group_double_optin
- civimail_workflow
- civimail_server_wide_lock
- activity_assignee_notification_ics
- civimail_multiple_bulk_emails
- hash_mailing_url
- auto_recipient_rebuild
- preserve_activity_tab_filter
I don't know if any of the others are ever actually retrieved by JS. Entirely possible they aren't!
Doesn't happen in API4. It might be easier to update the request in CiviMail, but this seemed weird enough to be worth flagging.
Reproduction steps
----------------------------------------
1. Go to the [API explorer](https://wpmaster.demo.civicrm.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fapi3#explorer)
2. Set the Entity to Setting, and the Action to getvalue
3. Set the parameter 'name' to 'auto_recipient_rebuild'
4. Execute the query. You'll get a "result" of true
5. Go to the [CiviMail settings](https://wpmaster.demo.civicrm.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fadmin%2Fsetting%2Fpreferences%2Fmailing&reset=1) and disable "Enable automatic CiviMail recipient count display"
6. Run the query again and you'll get an error
Environment information
----------------------------------------
Tested on latest wpmasterhttps://lab.civicrm.org/dev/core/-/issues/3114CiviMail - Error on sending/viewing mail via Mosaico following core update2023-09-05T09:58:20ZsbyrneCiviMail - Error on sending/viewing mail via Mosaico following core updateWe're seeing the error: "DB Error: no such field" when trying to send email from Mosaico. This happens regardless of whether the email is a test, or going out to the intended recipients. The error appears immediately upon submitting the ...We're seeing the error: "DB Error: no such field" when trying to send email from Mosaico. This happens regardless of whether the email is a test, or going out to the intended recipients. The error appears immediately upon submitting the mailing.
We're also unable to view old mailings submitted via Mosico, with the same error appearing but as a webpage rather than a pop-up.
This started happening after we upgraded CiviCRM from 5.39.0 to 5.46.0.
"Traditional" mails are working fine (sending and viewing)
I've done a few basic things to fix the problem with no success:
- Cleaned all caches
- Tricked Civi into thinking it was running an older version of the database and upgraded again to rule out problems with the DB update
- Upgraded Civi to 5.47.0
- Updated Mosaico to 2.9, while also installing Form Core and Seatch kit. Completed additional database updates required by this.
The error that appears while sending the mailing doesn't leave anything in the error log. I do get the following when viewing old mailings though:
```
Mar 11 16:35:20 [error]
$Fatal Error Details = array:3 [
"message" => "DB Error: no such field"
"code" => null
"exception" => CiviCRM_API3_Exception {#3486
-extraParams: array:4 [
"error_code" => "no such field"
"tip" => "add debug=1 to your API call to have more info about the error"
"is_error" => 1
"error_message" => "DB Error: no such field"
]
#message: "DB Error: no such field"
#code: 0
#file: ".../sites/all/modules/civicrm/api/api.php"
#line: 134
trace: {
/.../sites/all/modules/civicrm/api/api.php:134 {
› if (is_array($result) && !empty($result['is_error'])) {
› throw new CiviCRM_API3_Exception($result['error_message'], CRM_Utils_Array::value('error_code', $result, 'undefined'), $result);
› }
}
/.../sites/all/modules/civicrm/CRM/Mailing/Page/View.php:148 { …}
/.../sites/all/modules/civicrm/CRM/Core/Invoke.php:319 { …}
/.../sites/all/modules/civicrm/CRM/Core/Invoke.php:69 { …}
/.../sites/all/modules/civicrm/CRM/Core/Invoke.php:36 { …}
/.../sites/all/modules/civicrm/drupal/civicrm.module:471 { …}
/.../domains/secure/htdocs/includes/menu.inc:527 { …}
/.../domains/secure/htdocs/index.php:21 { …}
}
}
]
Mar 11 16:35:20 [debug] $backTrace = #0 /.../domains/secure/htdocs/sites/all/modules/civicrm/CRM/Core/Error.php(433): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /.../domains/secure/htdocs/sites/all/modules/civicrm/CRM/Core/Invoke.php(39): CRM_Core_Error::handleUnhandledException(Object(CiviCRM_API3_Exception))
#2 /.../domains/secure/htdocs/sites/all/modules/civicrm/drupal/civicrm.module(471): CRM_Core_Invoke::invoke((Array:3))
#3 /.../domains/secure/htdocs/includes/menu.inc(527): civicrm_invoke("mailing", "view")
#4 /.../domains/secure/htdocs/index.php(21): menu_execute_active_handler()
#5 {main}
```
Environment:
- Debian 10 (64 bit)
- MariaDB 10.3
- PHP 7.3
- Drupal 7.88
- CiviCRM 5.47.0
- Mosaico 2.9https://lab.civicrm.org/dev/core/-/issues/3113Export Contacts from Search Builder with contribute Note get DB Error2023-12-02T05:03:30ZsunilExport Contacts from Search Builder with contribute Note get DB ErrorOverview
----------------------------------------
Export Contacts from Search Builder with contribute Note get DB Error
Reproduction steps
----------------------------------------
1. Create contribution record with contribution note
1. ...Overview
----------------------------------------
Export Contacts from Search Builder with contribute Note get DB Error
Reproduction steps
----------------------------------------
1. Create contribution record with contribution note
1. go to search builder,
`Contribution Status = Completed` and `Contribution Note IS NOT EMPTY`
1. Search Contact, you get exepected result.
1. Select contact and choose action `Export Contact`
1. Got an error "**Fatal error: DB error**".
[nativecode=1054 ** Unknown column 'civicrm_note.note' in 'where clause']"]
Somewhere `civicrm_note` table from join disaapear in export operation.
Tested on 5.27 to 5.45 and latest dmaster site.