CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2020-01-10T13:06:15Zhttps://lab.civicrm.org/dev/core/-/issues/1510"_[custom field id number]" suffix is causing issues2020-01-10T13:06:15Zndavis"_[custom field id number]" suffix is causing issuesThis custom field id number changes between environments requiring a lookup algorithm to get the correct field name when writing code.
Why add this ID at all? Developers should be entrusted to name their custom fields the way they see f...This custom field id number changes between environments requiring a lookup algorithm to get the correct field name when writing code.
Why add this ID at all? Developers should be entrusted to name their custom fields the way they see fit. If this causes a name collision that's on the developer. It's not the project's responsibility to manage custom field names.
At the most you should force a "custom_" prefix or something similar. Forcing an _[custom field id number] suffix causes more problems than it solves, at least for those of us that don't develop on our production server since these ids change from one environment to the next, depending on what order features get implemented by the organizational development team. _PLEASE_ fix this. It makes custom fields nearly unusable for some organizations.https://lab.civicrm.org/dev/core/-/issues/1539"Cannot add field", row size "is greater than maximum allowed size (8126) for...2023-02-01T05:03:52ZDmitry Smirnov"Cannot add field", row size "is greater than maximum allowed size (8126) for a record on index leaf page"CiviCRM 5.21.1; Spotted the following in MariaDB logs:
```
[Warning] InnoDB: Cannot add field `postal_greeting_display` in table `wordpress-civicrm`.`civicrm_contact` because after adding it, the row size is 8486 which is greater than m...CiviCRM 5.21.1; Spotted the following in MariaDB logs:
```
[Warning] InnoDB: Cannot add field `postal_greeting_display` in table `wordpress-civicrm`.`civicrm_contact` because after adding it, the row size is 8486 which is greater than maximum allowed size (8126) for a record on index leaf page.
[Warning] InnoDB: Cannot add field `confirm_text` in table `wordpress-civicrm`.`civicrm_event` because after adding it, the row size is 8275 which is greater than maximum allowed size (8126) for a record on index leaf page.
```
No idea how serious this is...
Any ideas how to address the issue? Thanks.https://lab.civicrm.org/dev/core/-/issues/2429"Class not found" error on `\Civi\*` because hook_civicrm_config runs after h...2021-03-08T16:34:44ZJonGold"Class not found" error on `\Civi\*` because hook_civicrm_config runs after hook_civicrm_container`hook_civicrm_config` is responsible for telling the autoloader which classes exist in extensions, so must run before any other hooks.
However:
* `hook_civicrm_fieldOptions` is called before `hook_civicrm_config`; this is issue #1132, a...`hook_civicrm_config` is responsible for telling the autoloader which classes exist in extensions, so must run before any other hooks.
However:
* `hook_civicrm_fieldOptions` is called before `hook_civicrm_config`; this is issue #1132, and there's a [PR](https://github.com/civicrm/civicrm-core/pull/19580).
* `hook_civicrm_container` runs before `hook_civicrm_config`; this ticket discusses that.
Here are some examples (with backtraces):
* Issue #2334 appears to be this issue.
There's also the backtrace below, which happens when my Drupal cron runs.
This only happens on classes in the `\Civi` namespace, which isn't as common in extensions, which is why this isn't more widespread.
I don't know enough about `hook_civicrm_config` and `hook_civicrm_container`, but it seems we should guarantee that `hook_civicrm_config` always runs first.
```
Mar 02 15:54:01 [debug] $pdfapi-backtrace = #0 /var/www/mysite.org/web/sites/all/civicrm-custom/extensions/org.civicoop.pdfapi/pdfapi.php(14): CRM_Core_Error::backtrace("pdfapi-backtrace", TRUE)
#1 /var/www/mysite.org/web/sites/all/modules/civicrm/CRM/Utils/Hook.php(271): pdfapi_civicrm_container(Object(Symfony\Component\DependencyInjection\ContainerBuilder))
#2 /var/www/mysite.org/web/sites/all/modules/civicrm/CRM/Utils/Hook/DrupalBase.php(73): CRM_Utils_Hook->runHooks((Array:99), "civicrm_container", 1, Object(Symfony\Component\DependencyInjection\ContainerBuilder), NULL, NULL, NULL, NULL, NULL)
#3 /var/www/mysite.org/web/sites/all/modules/civicrm/Civi/Core/CiviEventDispatcher.php(168): CRM_Utils_Hook_DrupalBase->invokeViaUF(1, Object(Symfony\Component\DependencyInjection\ContainerBuilder), NULL, NULL, NULL, NULL, NULL, "civicrm_container")
#4 /var/www/mysite.org/web/sites/all/modules/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php(214): Civi\Core\CiviEventDispatcher::delegateToUF(Object(Civi\Core\Event\GenericHookEvent), "hook_civicrm_container", Object(Civi\Core\CiviEventDispatcher))
#5 /var/www/mysite.org/web/sites/all/modules/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php(44): Symfony\Component\EventDispatcher\EventDispatcher->doDispatch((Array:1), "hook_civicrm_container", Object(Civi\Core\Event\GenericHookEvent))
#6 /var/www/mysite.org/web/sites/all/modules/civicrm/Civi/Core/CiviEventDispatcher.php(129): Symfony\Component\EventDispatcher\EventDispatcher->dispatch("hook_civicrm_container", Object(Civi\Core\Event\GenericHookEvent))
#7 /var/www/mysite.org/web/sites/all/modules/civicrm/CRM/Utils/Hook.php(167): Civi\Core\CiviEventDispatcher->dispatch("hook_civicrm_container", Object(Civi\Core\Event\GenericHookEvent))
#8 /var/www/mysite.org/web/sites/all/modules/civicrm/CRM/Utils/Hook.php(2523): CRM_Utils_Hook->invoke((Array:1), Object(Symfony\Component\DependencyInjection\ContainerBuilder), NULL, NULL, NULL, NULL, NULL, "civicrm_container")
#9 /var/www/mysite.org/web/sites/all/modules/civicrm/Civi/Core/Container.php(334): CRM_Utils_Hook::container(Object(Symfony\Component\DependencyInjection\ContainerBuilder))
#10 /var/www/mysite.org/web/sites/all/modules/civicrm/Civi/Core/Container.php(69): Civi\Core\Container->createContainer()
#11 /var/www/mysite.org/web/sites/all/modules/civicrm/Civi/Core/Container.php(564): Civi\Core\Container->loadContainer()
#12 /var/www/mysite.org/web/sites/all/modules/civicrm/CRM/Core/Config.php(93): Civi\Core\Container::boot(TRUE)
#13 /var/www/mysite.org/web/sites/all/modules/civicrm/drupal/civicrm.module(227): CRM_Core_Config::singleton()
#14 /var/www/mysite.org/web/sites/all/modules/civicrm/drupal/modules/civicrmtheme/civicrmtheme.module(98): civicrm_initialize()
#15 /var/www/mysite.org/web/includes/module.inc(965): civicrmtheme_custom_theme()
#16 /var/www/mysite.org/web/includes/menu.inc(1760): module_invoke_all("custom_theme")
#17 /var/www/mysite.org/web/includes/menu.inc(1782): menu_get_custom_theme(TRUE)
#18 /var/www/mysite.org/web/includes/common.inc(5376): menu_set_custom_theme()
#19 /var/www/mysite.org/web/includes/bootstrap.inc(2552): _drupal_bootstrap_full()
#20 /usr/local/src/drush7/lib/Drush/Boot/DrupalBoot7.php(74): drupal_bootstrap(7)
#21 /usr/local/src/drush7/includes/bootstrap.inc(313): Drush\Boot\DrupalBoot7->bootstrap_drupal_full()
#22 /usr/local/src/drush7/includes/bootstrap.inc(429): drush_bootstrap(5, 6)
#23 /usr/local/src/drush7/lib/Drush/Boot/BaseBoot.php(56): drush_bootstrap_to_phase(6)
#24 /usr/local/src/drush7/drush.php(70): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#25 /usr/local/src/drush7/drush.php(11): drush_main()
#26 {main}
```https://lab.civicrm.org/dev/core/-/issues/1387"config_backend" should be thoroughly removed2023-02-05T05:03:36Ztotten"config_backend" should be thoroughly removedOverview
----------------------------------------
In CiviCRM 4.7.0, the column `civicrm_domain.config_backend` was migrated to the `civicrm_setting` table. However, the migration was incomplete.
Reproduction steps
----------------------...Overview
----------------------------------------
In CiviCRM 4.7.0, the column `civicrm_domain.config_backend` was migrated to the `civicrm_setting` table. However, the migration was incomplete.
Reproduction steps
----------------------------------------
1. Create a new site (e.g. `civibuild create dmaster`)
2. Run `DESC civicrm_domain`
3. Observe that column `config_backend` exists
Current behaviour
----------------------------------------
* If a site upgrades from `$ver <= 4.6`, then the column `civicrm_domain.config_backend` does NOT exist.
* If a new site is created in `4.7 <= $ver <= 5.21`, then the column `civicrm_domain.config_backend` DOES exist.
Expected behaviour
----------------------------------------
The column should not exist in v5.21 (or whatever gets the fix). It should not matter if the site originated on v4.5, v4.7, or v5.20.
Comments
----------------------------------------
Historically, this field is related to `CRM_Core_BAO_ConfigSetting`. One should grep on both `config_backend` and `ConfigSetting` to track down code-paths that may be referencing it.
It is still desirable to retain upgrade/transitional logic (eg `CRM_Upgrade_Incremental_php_FourSeven`, `Civi\Core\SettingsBag`); but otherwise these should be removed, and any dependent code-paths should be re-tested.https://lab.civicrm.org/dev/core/-/issues/3061"Country" multiselect custom field won't support more than 50-or-so countries2023-11-25T05:03:16ZAllenShaw"Country" multiselect custom field won't support more than 50-or-so countriesOn dmaster.demo.civicrm.org ("Powered by CiviCRM 5.48.alpha1."):
- Create a custom field of type Country, set to multi-select, in any custom group
- Edit an entity using this custom field, and try to add more than 50-or-so countries to ...On dmaster.demo.civicrm.org ("Powered by CiviCRM 5.48.alpha1."):
- Create a custom field of type Country, set to multi-select, in any custom group
- Edit an entity using this custom field, and try to add more than 50-or-so countries to it.
- Trying to save this entity will generate fatal error: "DB Error: unknown error" (on our site running CiviCRM 5.35.2, the entity will save without error, but only the first 50-or-so options are saved in the field; additional options are truncated out; this difference may be due to mysql configuration rather than civicrm version.)
This appears to be due to the `varchar(255)` column specification for the custom field storage.
On our own site, we resolved this by altering the column to `varchar(2550)`; that's probably much larger than is needed, but by doing this we can now select all options in this field and save the entity without error, retaining all selected options.
E.g.
```
ALTER TABLE `civicrm_value_additional_contact_info_2` CHANGE `locations_43` `locations_43` varchar(2550);
```https://lab.civicrm.org/dev/core/-/issues/2964"DB Error: no such field" in civicrm-core/Civi/ActionSchedule/RecipientBuilde...2023-10-26T05:03:27Zmagnolia61"DB Error: no such field" in civicrm-core/Civi/ActionSchedule/RecipientBuilder.phpI my log files i notice an error when running the scheduled reminder cron for activities.
```
[db_error: message="DB Error: no such field" code=-19 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="INSERT INTO civi...I my log files i notice an error when running the scheduled reminder cron for activities.
```
[db_error: message="DB Error: no such field" code=-19 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="INSERT INTO civicrm_action_log (contact_id, entity_id, entity_table, action_schedule_id)
SELECT r.contact_id as contact_id, e.id as entity_id, "civicrm_activity" as entity_table, 131 as action_schedule_id
FROM civicrm_activity e
INNER JOIN civicrm_contact c ON c.id = r.contact_id AND c.is_deleted = 0 AND c.is_deceased = 0
LEFT JOIN civicrm_action_log reminder ON reminder.contact_id = r.contact_id AND
reminder.entity_id = e.id AND
reminder.entity_table = 'civicrm_activity' AND
reminder.action_schedule_id = 131
WHERE (e.activity_type_id IN (119)) AND (e.status_id IN (4)) AND (e.is_current_revision = 1 AND e.is_deleted = 0) AND (reminder.id IS NULL) AND ('20211121085238' >= DATE_SUB(e.activity_date_time, INTERVAL 16 day)) AND (DATE_SUB(20211121085238, INTERVAL 1 DAY ) <= DATE_SUB(e.activity_date_time, INTERVAL 16 day)) AND ('2020-12-31 23:00:00' <= DATE_SUB(e.activity_date_time, INTERVAL 16 day)) AND ('2022-12-30 23:00:00' > DATE_SUB(e.activity_date_time, INTERVAL 16 day))
[nativecode=1054 ** Unknown column 'r.contact_id' in 'field list']"]
```
I tried to debug a little and think I found that in civicrm-core/CRM/Activity/ActionMapping.php
casContactIdField is defined as r.contact_id
`$query['casContactIdField'] = 'r.contact_id';`
But in the above other query r.contact_id fails because civicrm_action_log has the alias of reminder and not 'r'
Not sure what this breaks but it seems something that needs to be fixedhttps://lab.civicrm.org/dev/core/-/issues/3079"Manage Extensions" - Allow deleting unused extensions2023-11-27T05:03:22Ztotten"Manage Extensions" - Allow deleting unused extensionsOverview
----------------------------------------
The "Manage Extensions" UI allows you to download extensions. It does not allow you delete extensions... ever.
Example use-case
----------------------------------------
The web-user go...Overview
----------------------------------------
The "Manage Extensions" UI allows you to download extensions. It does not allow you delete extensions... ever.
Example use-case
----------------------------------------
The web-user goes through this process...
1. Download and enable the "Ice Cream" extension
2. Download and enable the "Cherry Pie" extension
3. Download and enable the "Gulab Jamun" extension
4. Disable and uninstall the "Ice Cream" extension
5. Disable and uninstall the "Cherry Pie" extension
6. Disable and uninstall the "Gulab Jamun" extension
Current behaviour
----------------------------------------
The inactive extensions add noise to the "Manage Extensions" UI.
The web user is stuck with inactive extensions "Ice Cream", "Cherry Pie", and "Gulab Jamun".
Proposed behaviour
----------------------------------------
Add a "Delete" button. "Delete" is only supported if these conditions are met:
* Ext status is "Uninstalled" (no db content)
* Ext lives in the "default container" (`[civicrm.files]/ext`)
* Ext is writable by current POSIX user
* Ext does not have any other ext's underneath it
* Web-user has permission to manage exts
* (*Undecided: If there are multiple copies of an ext, do we still allow deleting the copy in `[civicrm.files]/ext`? I think probably so...*)
Comments
----------------------------------------
The pre-conditions above should ensure that we don't (eg) delete extensions that live in `vendor/` or `civicrm/ext/`. Those extensions usually aren't managed via web UI (eg they're managed by `composer install` or `tar xvzf civicrm-XYZ.tar.gz`), and they may be shared in multitenant deployments.
The "Delete" button is not necessarily something to take too lightly. Perhaps it goes in expanded/drill-down section? Maybe next to the "Local Path"?
If a user gets into a situation where they want to delete an extension but cannot, then (1) there should be an indication of why "Delete" is unsupported, and (2) we may want to suggest manual/CLI-based deletion as an alternative.https://lab.civicrm.org/dev/core/-/issues/3626"New Mailing" prematurely schedules blasts and old mailings can be resent2022-06-11T14:57:24Ztotten"New Mailing" prematurely schedules blasts and old mailings can be resent## Steps to reproduce
* Open a MySQL console where you can monitor the content of `civicrm_mailing_job`.
* Make a `Mailing => New Mailing`
* Fill in name/subject/recipients/body on the first page.
* Go to the second page
* __Observe__:...## Steps to reproduce
* Open a MySQL console where you can monitor the content of `civicrm_mailing_job`.
* Make a `Mailing => New Mailing`
* Fill in name/subject/recipients/body on the first page.
* Go to the second page
* __Observe__: In the MySQL console, observe that there are no jobs scheduled for this mailing.
* Set a delivery time. *But don't hit `Submit`*. (You're just thinking about delivery... but not actually sending yet.)
* Open an HTML or plain-text preview.
* __Observe__: In the MySQL console, observe that there is now a scheduled job for this mailing.
To resend an old mailing:
* Any mailing will be queued for redelivery if a user with permission to use CiviMail visits URL `civicrm/a/#/mailing/<MAILING_ID>` (we've seen several users end up on this URL, apparently via browser history)
## Mitigating factors
The only way I've found to trigger the premature mailing (so far) has been to explicitly set the delivery date. It's quite bad to be sending prematurely, but I think it's taken a while to recognize because the delivery date is *the last thing* in the entire process -- *most of the time*, one doesn't set the delivery date until everything else has been settled. This probably means the real-world impact hasn't been as bad one might fear.
## Context
This appears to be a regression in 4.7.31. Related PRs:
* https://issues.civicrm.org/jira/browse/CRM-21260
* https://issues.civicrm.org/jira/browse/CRM-21316
* https://issues.civicrm.org/jira/browse/CRM-21749
* https://github.com/civicrm/civicrm-core/pull/11142/
* https://github.com/civicrm/civicrm-core/pull/11653/
## Solution
* Because the fix is in javascript, resolving this bug requires flushing CiviCRM caches (`cv flush` command) after upgrading to CiviCRM 5.0.05.0.0https://lab.civicrm.org/dev/core/-/issues/2203"Resource URL" help text incorrect2020-12-06T22:04:52Zdarren.woods"Resource URL" help text incorrectThe help text for "Resource URL" still says the absolute URL should be used, which then leads to errors.
> Resource URL
> Absolute URL of the location where the civicrm module or component has been installed.
> Example
> If your site's ...The help text for "Resource URL" still says the absolute URL should be used, which then leads to errors.
> Resource URL
> Absolute URL of the location where the civicrm module or component has been installed.
> Example
> If your site's home url is http://www.example.com/ ... then your CiviCRM Resource URL would be:
> http://www.example.com/
Suggest the shortcodes are added to this guidance, i.e. "[civicrm.root]/" to prevent new users getting mislead.5.33.0https://lab.civicrm.org/dev/core/-/issues/2813"Soft Credit Only" Contribution export screen and exported data don't match2023-09-22T05:03:27Zalicefrumin"Soft Credit Only" Contribution export screen and exported data don't matchOverview
----------------------------------------
When Exporting Contributions from a search with the "Soft Credits Only" filter, the export screen shows the contributor information but the exported file shows the soft credited contact.
...Overview
----------------------------------------
When Exporting Contributions from a search with the "Soft Credits Only" filter, the export screen shows the contributor information but the exported file shows the soft credited contact.
Reproduction steps
----------------------------------------
1. Go to the "Find Contributions" search form (CiviCRM Admin menu -> Search -> Find Contributions)
2. For the "Contributions OR Soft Credits?" field select "Soft Credits Only"
3. Click Search
4. Select All records
5. Select the Action "export contributions"
6. pick the "Select fields for Export" option and click "Continue"
7. Add a "First Name" Field
8. Click "Download File"
Current behaviour
----------------------------------------
The export screen shows the first name of the Contributor
The export file shows the first name of the person who is soft credited
Expected behaviour
----------------------------------------
The export screen and exported file should display the same information. Because the filter is for "Soft Credit Only" I would expect they would both show the soft credit contact.
Environment information
----------------------------------------
I was able to recreate this on https://dmaster.demo.civicrm.org/
* __CiviCRM: 5.43.alpha1
* __CMS:drupalhttps://lab.civicrm.org/dev/core/-/issues/3620"View in Browser" does not feed mailing statistics2024-02-19T05:03:28Ztotten"View in Browser" does not feed mailing statisticsI just want to log the existence of the issue generally... suppose you send a newsletter and it has a "View in Browser" link.
Suppose the recipient uses that link. The view the mailing and then drill-down, clicking through some more lin...I just want to log the existence of the issue generally... suppose you send a newsletter and it has a "View in Browser" link.
Suppose the recipient uses that link. The view the mailing and then drill-down, clicking through some more links.
What happens to the stats?
* The web-based view does not count as an "Open". The MUA may or may not report back the "Open" on the original message.
* You will not have any "Click Through" events logged.
This is because the "View in browser" variant of the newsletter is not instrumented with tracking codes (while the MUA variant of the newsletter does have tracking codes).https://lab.civicrm.org/dev/core/-/issues/2482$civicrm_root with relative paths causes core extensions to fail to be found2023-07-14T05:03:22Zanemirovsky$civicrm_root with relative paths causes core extensions to fail to be foundOverview
----------------------------------------
For some instances of CiviCRM, like with Drupal 8, CiviCRM is outside the web root. In that case, depending on how the $civicrm_root is generated/set, it can be set to something like "/va...Overview
----------------------------------------
For some instances of CiviCRM, like with Drupal 8, CiviCRM is outside the web root. In that case, depending on how the $civicrm_root is generated/set, it can be set to something like "/var/www/sitename.org/web/../vendor/civicrm/civicrm-core". After a change made in https://github.com/civicrm/civicrm-core/commit/ba89bdbde1aa7f21badab003b89b2cb0052fd175, paths like this cause CiviCRM to fail to locate core extensions which causes a fatal error.
Reproduction steps
----------------------------------------
1. Change the $civicrm_root to a path that contains a '..'.
1. Attempt to load CiviCRM.
1. Get an error "CRM_Extension_Exception_MissingException: Unknown extension: org.civicrm.shoreditch in CRM_Extension_Container_Collection->getContainer() (line 150 of /var/www/sitename.org/vendor/civicrm/civicrm-core/CRM/Extension/Container/Collection.php).".
Expected behaviour
----------------------------------------
CiviCRM should either handle paths with '..' gracefully or add validation/documentation that prevents $civicrm_root from being set to a path with invalid parts. For now, we're wrapping our $civicrm_root in realpath() to resolve the reference to '..'.https://lab.civicrm.org/dev/core/-/issues/1939$crazy_null assignment in DB_DataObject has a typo that makes it crazier2020-08-10T13:39:22ZDaveD$crazy_null assignment in DB_DataObject has a typo that makes it crazierhttps://github.com/civicrm/civicrm-packages/blob/02e7eaa0a2aa072a032afff8179f6c26c1ad87b3/DB/DataObject.php#L4936
`strtolower($options['disable_null_strings'] === 'full')`
It should be
`strtolower($options['disable_null_strings']) ===...https://github.com/civicrm/civicrm-packages/blob/02e7eaa0a2aa072a032afff8179f6c26c1ad87b3/DB/DataObject.php#L4936
`strtolower($options['disable_null_strings'] === 'full')`
It should be
`strtolower($options['disable_null_strings']) === 'full'`
Is DB_DataObject still being updated upstream? I can't find a recent repo. Although I don't think this bug ever comes up in practice how it's used in civi.https://lab.civicrm.org/dev/core/-/issues/945$this can not be used in static methods2019-07-31T20:49:25Zherbdool$this can not be used in static methodsMy IDE tells me that "$this can not be used in static methods". This is for in `public static function getIncompleteImportTables()` in `CRM/Contact/Import/ImportJob.php`. I don't know the best way to fix it, but here's a helpful link htt...My IDE tells me that "$this can not be used in static methods". This is for in `public static function getIncompleteImportTables()` in `CRM/Contact/Import/ImportJob.php`. I don't know the best way to fix it, but here's a helpful link https://stackoverflow.com/questions/2286696/using-this-inside-a-static-function-fails.5.16.0https://lab.civicrm.org/dev/core/-/issues/1474(On Hold) text missing from email column when custom search profile is used i...2020-01-20T06:23:45Zjitendra(On Hold) text missing from email column when custom search profile is used in Advanced SearchTo replicate
- Create a search profile with an email field.
- Use this profile to view Advanced Search results.
Email is (on hold) on the contact -
![image](/uploads/34f289e6c6916c08733d5d4bddd4e488/image.png)
- `jitendra@fuzion.co....To replicate
- Create a search profile with an email field.
- Use this profile to view Advanced Search results.
Email is (on hold) on the contact -
![image](/uploads/34f289e6c6916c08733d5d4bddd4e488/image.png)
- `jitendra@fuzion.co.nz` is on hold, but is not specified in Advanced Search results -
![image](/uploads/359fc3143ae04b4e42628a3f276451aa/image.png)jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/3065(Regression) Strict typing on CRM_Contact_BAO_Contact::getDuplicateContacts()...2023-11-23T05:03:25ZJonGold(Regression) Strict typing on CRM_Contact_BAO_Contact::getDuplicateContacts() causes fatal error[PR 22394](https://github.com/civicrm/civicrm-core/pull/22394) adds strict type checking, which causes a fatal error with inputs that were previously acceptable.
### Steps to replicate
Run `cv api Contact.duplicatecheck` with no argume...[PR 22394](https://github.com/civicrm/civicrm-core/pull/22394) adds strict type checking, which causes a fatal error with inputs that were previously acceptable.
### Steps to replicate
Run `cv api Contact.duplicatecheck` with no arguments.
### Result in 5.45
```
{
"is_error": 0,
"version": 3,
"count": 0,
"values": []
}
```
### Result in 5.46
```
[Symfony\Component\Debug\Exception\FatalThrowableError]
Type error: Argument 1 passed to CRM_Contact_BAO_Contact::getDuplicateContacts() must be of the type array, null given, called in /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/api/v3/Contact.php on line 1611
```
Now, passing no arguments should arguably not be supported, but a typical usage is to leave the rule type undefined, which defaults to `Unsupervised`. Now, leaving it undefined gives an error of "Argument 3 must be a string, null given".
Since this is a bug that will bite a lot of folks, I'm going to do a quick PR to allow these arguments to be nullable - but I imagine in the long term we want to modify the calling functions to pass valid values. Though I think that argument 3 (`$rule`) should always be nullable.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4624(unreleased regression) Can't use QuickSearch for address anymore2023-11-10T13:54:49ZJonGold(unreleased regression) Can't use QuickSearch for address anymoreAfter https://github.com/civicrm/civicrm-core/pull/26676 is applied, quick searching by address returns all contacts.After https://github.com/civicrm/civicrm-core/pull/26676 is applied, quick searching by address returns all contacts.5.67.1https://lab.civicrm.org/dev/core/-/issues/974.ics files should be whitelisted as file types for upload2019-08-15T14:00:20ZStoob.ics files should be whitelisted as file types for uploadCurrently an uploaded .ics file to Civi has the 'unknown' suffix appended. To offer some background, .ics file is a common format used by Google, Outlook and many other calendar software https://en.wikipedia.org/wiki/ICalendar. Indeed ...Currently an uploaded .ics file to Civi has the 'unknown' suffix appended. To offer some background, .ics file is a common format used by Google, Outlook and many other calendar software https://en.wikipedia.org/wiki/ICalendar. Indeed you will see this filetype attached to many email invitations you get for meetings.
I suggest that this filetype should be whitelisted by CiviCRM and uploaded without modification, for use in all places where attachments are allowed: CiviMail, custom data fields, etc. Since the filetype contains only data (similar to JSON or XML) there are no security issues I'm aware of, but I will rely on security experts to judge ultimately be the judge. Here's an example of part of the problem CiviCRM's appended suffix causes. The ".unknown" file cannot be recognized nor easily opened. @eileen @seamuslee
![ics](/uploads/f3f6c8c202dba00da35eda94eecdd974/ics.png)
![ics2](/uploads/3823eebea44838c339af41bb241e3d07/ics2.png)5.14.0seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/15055.20.3: TRUNCATE civicrm_menu [nativecode=1118 ** Row size too large (> 8126)2023-01-31T05:03:26ZDmitry Smirnov5.20.3: TRUNCATE civicrm_menu [nativecode=1118 ** Row size too large (> 8126)After upgrade 5.18.2 --> 5.20.3 the following error is thrown:
~~~~
Jan 02 12:04:20 [error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[co...After upgrade 5.18.2 --> 5.20.3 the following error is thrown:
~~~~
Jan 02 12:04:20 [error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[code] => -1
[message] => DB Error: unknown error
[mode] => 16
[debug_info] => TRUNCATE civicrm_menu [nativecode=1118 ** Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.]
[type] => DB_Error
[user_info] => TRUNCATE civicrm_menu [nativecode=1118 ** Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.]
[to_string] => [db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::handle prefix="" info="TRUNCATE civicrm_menu [nativecode=1118 ** Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.]"]
)
Jan 02 12:04:20 [debug] $backTrace = #0 /usr/share/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(208): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /usr/share/php/PEAR.php(922): CRM_Core_Error::handle(Object(DB_Error))
#2 /usr/share/civicrm/packages/DB.php(986): PEAR_Error->__construct("DB Error: unknown error", -1, 16, (Array:2), "TRUNCATE civicrm_menu [nativecode=1118 ** Row size too large (> 8126). Changi...")
#3 /usr/share/php/PEAR.php(575): DB_Error->__construct(-1, 16, (Array:2), "TRUNCATE civicrm_menu [nativecode=1118 ** Row size too large (> 8126). Changi...")
#4 /usr/share/php/PEAR.php(223): PEAR->_raiseError(Object(DB_mysqli), NULL, -1, 16, (Array:2), "TRUNCATE civicrm_menu [nativecode=1118 ** Row size too large (> 8126). Changi...", "DB_Error", TRUE)
#5 /usr/share/civicrm/packages/DB/common.php(1920): PEAR->__call("raiseError", (Array:7))
#6 /usr/share/civicrm/packages/DB/mysqli.php(933): DB_common->raiseError(-1, NULL, NULL, "TRUNCATE civicrm_menu [nativecode=1118 ** Row size too large (> 8126). Changi...", "1118 ** Row size too large (> 8126). Changing some columns to TEXT or BLOB or...")
#7 /usr/share/civicrm/packages/DB/mysqli.php(403): DB_mysqli->mysqliRaiseError()
#8 /usr/share/civicrm/packages/DB/common.php(1229): DB_mysqli->simpleQuery("TRUNCATE civicrm_menu")
#9 /usr/share/civicrm/packages/DB/DataObject.php(2416): DB_common->query("TRUNCATE civicrm_menu")
#10 /usr/share/civicrm/packages/DB/DataObject.php(1607): DB_DataObject->_query("TRUNCATE civicrm_menu")
#11 /usr/share/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php(435): DB_DataObject->query("TRUNCATE civicrm_menu")
#12 /usr/share/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php(1428): CRM_Core_DAO->query("TRUNCATE civicrm_menu", TRUE)
#13 /usr/share/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/Menu.php(304): CRM_Core_DAO::executeQuery("TRUNCATE civicrm_menu")
#14 /usr/share/civicrm/CRM/Upgrade/Page/Upgrade.php(105): CRM_Core_Menu::store()
#15 /usr/share/civicrm/CRM/Upgrade/Page/Upgrade.php(73): CRM_Upgrade_Page_Upgrade->runIntro()
#16 /usr/share/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(284): CRM_Upgrade_Page_Upgrade->run((Array:2), NULL)
#17 /usr/share/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:13))
#18 /usr/share/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:2))
#19 /usr/share/wordpress/wp-content/plugins/civicrm/civicrm.php(1466): CRM_Core_Invoke::invoke((Array:2))
#20 /usr/share/wordpress/wp-includes/class-wp-hook.php(286): CiviCRM_For_WordPress->invoke("")
#21 /usr/share/wordpress/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters("", (Array:1))
#22 /usr/share/wordpress/wp-includes/plugin.php(453): WP_Hook->do_action((Array:1))
#23 /usr/share/wordpress/wp-admin/admin.php(224): do_action("toplevel_page_CiviCRM")
#24 {main}
~~~~
Because of this problem I could not run DB schema upgrade as the web page show `DB Error: unknown error` (Catch-22?).
The following StackExchange questions might be relevant:
* https://civicrm.stackexchange.com/questions/33220
* https://civicrm.stackexchange.com/questions/31632
What is the recommended remedy, if that's a known problem? Thanks.https://lab.civicrm.org/dev/core/-/issues/23245.33.2: jquery.validate.js is vulnerable to CVE-2021-212522021-02-03T23:15:41ZDmitry Smirnov5.33.2: jquery.validate.js is vulnerable to CVE-2021-21252As reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980892 , `jquery.validate.js`1.19.1 (in `bower_components/jquery-validation/dist`) is vulnerable to
[CVE-2021-21252](https://security-tracker.debian.org/tracker/CVE-2021-2...As reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980892 , `jquery.validate.js`1.19.1 (in `bower_components/jquery-validation/dist`) is vulnerable to
[CVE-2021-21252](https://security-tracker.debian.org/tracker/CVE-2021-21252) (has been fixed in version 1.19.3).5.34.0