Development issueshttps://lab.civicrm.org/groups/dev/-/issues2021-12-22T21:39:08Zhttps://lab.civicrm.org/dev/backdrop/-/issues/4Class civicrm_plugin_argument_default_civicrm_id not loaded2021-12-22T21:39:08ZherbdoolClass civicrm_plugin_argument_default_civicrm_id not loadedNeed to put `civicrm_plugin_argument_default_civicrm_id` in `hook_autoload_info`.Need to put `civicrm_plugin_argument_default_civicrm_id` in `hook_autoload_info`.https://lab.civicrm.org/dev/drupal/-/issues/172Deprecated function drupal_get_installed_schema_version() in 9.3, but with a ...2022-01-02T15:47:07ZDaveDDeprecated function drupal_get_installed_schema_version() in 9.3, but with a twistdrupal_get_installed_schema_version() is deprecated in drupal:9.3.0 and is removed from drupal:10.0.0. Use \Drupal\Core\Update\UpdateHookRegistry::getInstalledVersion() or \Drupal\Core\Update\UpdateHookRegistry::getAllInstalledVersions()...drupal_get_installed_schema_version() is deprecated in drupal:9.3.0 and is removed from drupal:10.0.0. Use \Drupal\Core\Update\UpdateHookRegistry::getInstalledVersion() or \Drupal\Core\Update\UpdateHookRegistry::getAllInstalledVersions() instead. See https://www.drupal.org/node/2444417
This is in vendor\civicrm\civicrm-core\CRM/Utils/System/Drupal8.php:
```
public function getModules() {
$modules = [];
$module_data = \Drupal::service('extension.list.module')->reset()->getList();
foreach ($module_data as $module_name => $extension) {
if (!isset($extension->info['hidden']) && $extension->origin != 'core') {
$extension->schema_version = drupal_get_installed_schema_version($module_name);
$modules[] = new CRM_Core_Module('drupal.' . $module_name, ($extension->status == 1));
}
}
return $modules;
}
```
The reason I haven't just put up a simple replacement PR is because if you look at the above function you'll notice schema_version is never used. If you look at the docblock in Base.php it says "List modules installed in the CMS, _including enabled and disabled ones_." Looking at the drupal 7 version (in DrupalBase.php), it does this:
`'SELECT name, status FROM {system} WHERE type = \'module\' AND schema_version <> -1'`
which means only the modules that are installed (but possibly disabled - that's what status is). Now in drupal 8 there is no concept of disabled, it's either installed or uninstalled, but the drupal 8 code is including all of them. In drupal 8 $extension->status means installed or uninstalled.
So two options are:
1. Try to match the drupal 7 implementation/docblock, which means excluding it if $extension->status is 0, and always passing 1 as the second parameter to CRM_Core_Module(), because disabled doesn't mean anything in drupal 8.
2. Leave it the way it is and just remove the unused line about schema_version.
Trying to track down where this gets used, it seems it's mostly in ManagedEntities, which I usually stay away from, and I'm not even sure why ManagedEntities would be dealing with drupal modules other than civicrm itself.
So I'm tempted to stop thinking about it and do item 2.5.46.0https://lab.civicrm.org/dev/core/-/issues/3001Escape single quotes in token html output2022-03-17T23:12:32ZeileenEscape single quotes in token html outputWhen rendering message templates with tokens it is reasonable to do something like
```
{if '{contact.last_name}'}
Dear {contact.prefix_id:label} {contact.last_name}
{else}
Dear {contact.first_name}
{/if}
```
However, this breaks if...When rendering message templates with tokens it is reasonable to do something like
```
{if '{contact.last_name}'}
Dear {contact.prefix_id:label} {contact.last_name}
{else}
Dear {contact.first_name}
{/if}
```
However, this breaks if the name is "O'Reily" as the single quote breaks the string.
There are 2 aspects to this
1) when the token is being rendered in html the text is being parsed through [htmlentities](https://www.php.net/manual/en/function.htmlentities.php). We are doing this without specifying any flags - so we fall back to ENT_COMPAT - switching to ENT_QUOTES solves this in the context of html tokens and I think it's probably more correct and more secure. I'm going to put [up a patch for that](https://github.com/civicrm/civicrm-core/pull/22285).
![image](/uploads/eda8db04ea8db39b46f7f6894d50425d/image.png)
2) when the token is being rendered in text the raw result is returned - I'm not quite sure the best approach here. Our principle of using smarty-like escaping would suggest we should support something like
``{$articleTitle|escape:'quotes'}``https://lab.civicrm.org/dev/core/-/issues/3000Can't save a shared address twice when you have custom address fields2021-12-25T19:34:53ZJonGoldCan't save a shared address twice when you have custom address fieldsThis is a regression from https://github.com/civicrm/civicrm-core/pull/21313, which is in Civi 5.42+.
### Steps to replicate
* Create an address custom field (it may have to be a certain type; it happens with alphanumeric select-autocom...This is a regression from https://github.com/civicrm/civicrm-core/pull/21313, which is in Civi 5.42+.
### Steps to replicate
* Create an address custom field (it may have to be a certain type; it happens with alphanumeric select-autocomplete for sure).
* Create or re-save an address on a contact (to create its custom field record).
* On a second contact, share the address from the first contact and save.
* Edit the address on the second contact and save.
### Expected result
Saves successfully.
### Actual result
`"DB Error: already exists"`
### Comments
The `entity_id` on a custom value field must be unique, but the PR mentioned above forces an `INSERT` when copying the custom fields of the original address.5.45.0https://lab.civicrm.org/dev/core/-/issues/2999Get API Error: "invalid string" if param value contains `select` string in it2023-11-02T11:36:40ZjitendraGet API Error: "invalid string" if param value contains `select` string in itTo replicate execute the following apis.
```
civicrm_api3('Contact', 'get', ['display_name' => 'selecton person name']);
```
or
```
civicrm_api3('Contribution', 'get', [
'sequential' => 1,
'source' => "xxxxselect xxxx",
]);
```
...To replicate execute the following apis.
```
civicrm_api3('Contact', 'get', ['display_name' => 'selecton person name']);
```
or
```
civicrm_api3('Contribution', 'get', [
'sequential' => 1,
'source' => "xxxxselect xxxx",
]);
```
or any other entity with `select` string in the param value.
The problematic part is https://github.com/civicrm/civicrm-core/blob/master/api/v3/utils.php#L884-L886, which results into an error if param value contains `select` string in it.
Seems to be present in core from a long time. Why is input params considered as an invalid string for SELECT? Is it to avoid any SQL queries in the params? If yes, probably we can replace it with a more valid check? eg an existence of select, from, etc?https://lab.civicrm.org/dev/core/-/issues/2997Search Builder (not Search Kit): groups not searched correctly2023-11-01T05:03:24Zaydunsaidan.saunders@squiffle.ukSearch Builder (not Search Kit): groups not searched correctlyOverview
----------------------------------------
In Search Builder, searching for both 'in group' and 'not in group' produces incorrect results.
As [reported in SE](https://civicrm.stackexchange.com/questions/40893/search-builder-fails...Overview
----------------------------------------
In Search Builder, searching for both 'in group' and 'not in group' produces incorrect results.
As [reported in SE](https://civicrm.stackexchange.com/questions/40893/search-builder-fails-in-group-and-not-in-group-search).
![Screenshot_from_2021-12-17_11-18-41](/uploads/10a879d4a29aa0ec727f2ff47c1527e2/Screenshot_from_2021-12-17_11-18-41.png)
NB: this is handled correctly in Search Kit and I doubt anyone will want to put effort into fixing this in Search Builder.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __CiviCRM:__ _Master (5.46.alpha1)_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->https://lab.civicrm.org/dev/core/-/issues/2996Increment recommended php version2021-12-20T20:30:34ZeileenIncrement recommended php versionPHP has just EOLed php 7.3 https://www.php.net/eol.php
We are just about to release the 5.45 ESR and we could take the opportunity to drop support for older php & mysql ie drop support for php 7.2 & mysql 5.6
The gut check in informal ...PHP has just EOLed php 7.3 https://www.php.net/eol.php
We are just about to release the 5.45 ESR and we could take the opportunity to drop support for older php & mysql ie drop support for php 7.2 & mysql 5.6
The gut check in informal discussion was to leave that for the next ESR and instead just increase our recommended versions.
While we support php 8.0 if has pretty low usage at the moment - so 7.4 seemed like the right pick
https://github.com/civicrm/civicrm-core/pull/222655.46.0https://lab.civicrm.org/dev/core/-/issues/2995From Email Address Options Bug2023-11-27T05:03:22ZLKuttnerFrom Email Address Options BugWhen sending some emails, such as using CiviRules and the MailAPI extension, the display name of the specified from email address option is being read from the non-ui editable Name column, while the email address is read from the Label c...When sending some emails, such as using CiviRules and the MailAPI extension, the display name of the specified from email address option is being read from the non-ui editable Name column, while the email address is read from the Label column. This results email being sent with the display name of FIXME when using the from email address that was created during the initial CiviCRM set-up. The Name of the first created email address is "FIXME" <info@example.com"> and is not editable via the user interface. This record can be updated by editing option_group_id 31 value 1 in the database.https://lab.civicrm.org/dev/core/-/issues/2993Add option to delete old log files during rotation2023-11-02T05:03:25ZJoeMurrayAdd option to delete old log files during rotationOverview
----------------------------------------
_When creating a new log file, optionally remove old ones like logrotate allows (https://linux.die.net/man/8/logrotate)._
Example use-case
----------------------------------------
CiviCR...Overview
----------------------------------------
_When creating a new log file, optionally remove old ones like logrotate allows (https://linux.die.net/man/8/logrotate)._
Example use-case
----------------------------------------
CiviCRM's simplistic log creation does not actually rotate, it just makes more files for the logs and never deletes any (https://github.com/civicrm/civicrm-core/blob/5433c81f5648bf484ef16debeca3c7e6e98d1a11/CRM/Core/Error.php#L684). This can be dangerous for systems where there is little to no active monitoring of logs, eg small orgs without a provider, or on a shoestring budget. It is also dangerous in cases where a change starts to generate high volumes of error messages, eg a client recently misconfigured a civirule and GBs of log were produced every hour. Running out of disk space causes hard crashes of sites.
It is standard practice to have a process in place to ensure that logs do not end up taking too much disk space. We propose allowing a setting to be added to civicrm.settings.php (eg NUM_LOG_FILES_TO_RETAIN) that would allow the number of logs to be retained to be specified. The default setting would be 0, meaning an infinite number, which would retain current behaviour. We would also be happy to make it another number such as 6, which would be 6 months or more than 1.5GB.
My understanding is that settings that can be added to civicrm.settings.php should be included as comments with explanation that can be uncommented, so we will do this.
Current behaviour
----------------------------------------
_CiviCRM generates log files with random hash names, and creates new ones every month or when the file exceeds 256MB. Log file space grows continuously unless log files are manually deleted._
Proposed behaviour
----------------------------------------
_When a new log file is created, if a maximum number of log files has been specified, then delete those over that number, starting with oldest first_
Comments
----------------------------------------
_To reduce the complexity of the settings pages, we propose that this be implemented as a setting that could be optionally specified in civicrm.settings.php._Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/2992cancelling preApproval payment and continue with credit card does not work.2023-11-21T05:03:16Zsunilcancelling preApproval payment and continue with credit card does not work.Overview
----------------------------------------
This issue related to preApproval payment. its present on Contribution and Event registartion form.
E.g Paypal Express.
Reproduction steps
----------------------------------------
1. Se...Overview
----------------------------------------
This issue related to preApproval payment. its present on Contribution and Event registartion form.
E.g Paypal Express.
Reproduction steps
----------------------------------------
1. Set up Paypal Pro account (live and test mode).
1. The configure Processor on Contribution page.
1. Visit online page (live or test mode).
1. Select amount and click on Paypal Button
1. It redirct you to login page, there is link to cancel the process,link look like this
`http://drupal7.test/civicrm/contribute/transact?_qf_Main_display=1&qfKey=CRMContributeControllerContribution67xqxb55jcow0k0gcs8sc8c4cs0c4sc00s4gcwg0skg84ws840_7945&cancel=1&token=EC-1V540554M6477413R` . Click on it. It redirect you to main page.
1. Now this time do the transaction using credit card.
1. Once you reach to CiviCRM confirm page and click to pay amount. You will get the error like this
`Payment Processor Error message :Express Checkout PayerID is missing.`
In Case of event registration, we were not passing qfkye to cancel url. when we cancel the payment on paypal express login page.. we are getting `Could not find valid value for id` Error.
After correcting the cancel url we need to apply same changes to reset `preApproval` data to continue payment with other method without resetting the page.https://lab.civicrm.org/dev/drupal/-/issues/171Drupal 10 requires Guzzle 72022-07-10T15:27:07ZDaveDDrupal 10 requires Guzzle 7It doesn't seem like there is any major change but I'm not super-familiar with everywhere civi uses guzzle: https://github.com/guzzle/guzzle/blob/master/UPGRADING.md#other-backwards-compatibility-breaking-changes
The main thing at the m...It doesn't seem like there is any major change but I'm not super-familiar with everywhere civi uses guzzle: https://github.com/guzzle/guzzle/blob/master/UPGRADING.md#other-backwards-compatibility-breaking-changes
The main thing at the moment is you need to do something like `composer require guzzlehttp/guzzle:"6.3.0 as 7.4.0"` just to get the civi files downloaded, but that's obviously not the right thing to do.5.52.0https://lab.civicrm.org/dev/core/-/issues/2990CiviCampaign - Move data into a single table2024-03-11T20:47:07ZcolemanwCiviCampaign - Move data into a single tableBackground
------------
CiviCampaign is an optional component (disabled by default on new installs). It allows contributions, events, etc. to be associated with a campaign.
Campaigns are basically like tags. The campaign itself contain...Background
------------
CiviCampaign is an optional component (disabled by default on new installs). It allows contributions, events, etc. to be associated with a campaign.
Campaigns are basically like tags. The campaign itself contains a bit more data (type, start & end date, description, goal) than a Tag, but the mechanism for linking an entity with a campaign is a very simple foreign key.
How it works now
-------------
"Tagging" an entity with a campaign works via a column on that entity's table. E.g. `civicrm_contribution_page.campaign_id`. There are currently 10 entities with such a column, allowing them to be "tagged" with a campaign_id.
The problem
-----------
This design involves tight coupling between CiviCampaign and other components, as it involves adding a column to their tables. It also limits the possibilities for which entities can have a campaign_id.
The solution
----------
There is another common pattern in CiviCRM, which is to add a small "bridge" table to join two entities, which is a good alternative to adding a column. `civicrm_entity_tag` is one example. It includes `tag_id`, `entity_id` and `entity_table` columns, and an OptionGroup `tag_used_for` which lists all the possible values for `entity_table`. Importantly, it's easily added-on by extensions; if an extension provides a new entity type which should be taggable, is just adds it to the option list.
The migration
------------
If CiviCampaign were a greenfield project designed today, we wouldn't think twice about structuring the data with a bridge table instead of littering our database with `campaign_id` columns. As a brownfield problem, fixing the structure may be more trouble than it's worth, but I thought I'd at least articulate how it might be possible:
- APIv4 has a new concept of "Extra" calculated fields, which could provide a faux `campaign_id` column for backward compatibility.
- CiviCampaign could implement a post-hook to save campaign_id if it's passed into "create" params. This would keep create and update working as if that column still exists.
- APIv3 would require some hacking to make a pseudo-field to fill in for a missing `campaign_id`.
Random musings
-----------
While researching this, I stumbled across a table called `civicrm_campaign_group`. I have no idea what it does but it looks very similar to how I imagined the new bridge table would be. It includes a `campaign_id`, `entity_id` and `entity_table` column. Why does this table exist??https://lab.civicrm.org/dev/core/-/issues/2989Import of contribution fails when invalid campaign id is provided2022-02-01T23:27:10ZKurund JalmiImport of contribution fails when invalid campaign id is providedCurrently, we do not validate campaign id hence contribution import silently fails to import.Currently, we do not validate campaign id hence contribution import silently fails to import.5.47.0https://lab.civicrm.org/dev/core/-/issues/2988Civi Scss compliler is autoloaded, and its (old) verion conflict with more re...2023-10-30T05:03:24ZjbonlineaCivi Scss compliler is autoloaded, and its (old) verion conflict with more recent ones causing fatail errorsHi there,
It seems there is a issue / conflict between CiviCRM Scss compiler and my wordpress theme (gantry 5) Scss compiler.
We've discussed it [here](https://chat.civicrm.org/civicrm/pl/mfsmpmhewjyd7p7srbe1h9cyfa) where I've linked w...Hi there,
It seems there is a issue / conflict between CiviCRM Scss compiler and my wordpress theme (gantry 5) Scss compiler.
We've discussed it [here](https://chat.civicrm.org/civicrm/pl/mfsmpmhewjyd7p7srbe1h9cyfa) where I've linked what put me on track to think is was due to Civi Scss compiler.
A workaround is to rename the folder `civicrm/civicrm/vendor/scssphp`
Let me know if you want more detail
Cheers
PHP 7.4
WP 5.8.2
Civi 5.40.2
Gantry 5.5.6 (theme I use that also bundle an scss compiler, but there are many others)https://lab.civicrm.org/dev/wordpress/-/issues/116Issue related to Civi and WP Scss compiler causing fatal error2021-12-09T15:17:29ZjbonlineaIssue related to Civi and WP Scss compiler causing fatal errorHi there,
It seems there is a issue / conflict between CiviCRM Scss compiler and my wordpress theme (gantry 5) Scss compiler.
We've discussed it [here](https://chat.civicrm.org/civicrm/pl/mfsmpmhewjyd7p7srbe1h9cyfa) where I've linked w...Hi there,
It seems there is a issue / conflict between CiviCRM Scss compiler and my wordpress theme (gantry 5) Scss compiler.
We've discussed it [here](https://chat.civicrm.org/civicrm/pl/mfsmpmhewjyd7p7srbe1h9cyfa) where I've linked what put me on track to think is was due to Civi Scss compiler.
A workaround is to rename the folder `civicrm/civicrm/vendor/scssphp`
Let me know if you want more detail
Cheers
PHP 7.4
WP 5.8.2
Civi 5.40.2
Gantry 5.5.6 (theme I use that also bundle an scss compiler, but there are many others)https://lab.civicrm.org/dev/core/-/issues/2987API call Contribution.repeattransaction fails with recurring contributions th...2023-03-20T01:51:15ZandrewcormickdockeryAPI call Contribution.repeattransaction fails with recurring contributions that have a one-to-one custom group record attachedOverview
----------------------------------------
Re: https://chat.civicrm.org/civicrm/pl/i8fht46isjn5uj4dbdosrqpqmr
The API call Contribution.repeattransaction appears to write a custom group record twice when completing a transaction....Overview
----------------------------------------
Re: https://chat.civicrm.org/civicrm/pl/i8fht46isjn5uj4dbdosrqpqmr
The API call Contribution.repeattransaction appears to write a custom group record twice when completing a transaction. On the second attempt, a database error caused by the clashing unique key is generated. The transaction appears to end up being recorded correctly, however the fatal error means that processes which call this function repeatedly end up not completing. Our use case involves finding all Eway transactions whose next scheduled contribution date is today, and then calling Contribution.repeattransaction for each one.
Reproduction steps
----------------------------------------
1. Ensure a one-to-one custom group exists against contributions.
1. Ensure a recurring contribution exists with a record in that custom group against the transaction.
1. Run `drush cvapi Contribution.repeattransaction contribution_status_id=Completed total_amount=<some value> contribution_recur_id=<contribution_recur_id in previous step> trxn_id=<random unique number>`
Current behaviour
----------------------------------------
Failure message appears: `DB Error: already exists`; process terminates. Record appears to be correctly produced in CiviCRM.
Log details:
```
Dec 07 12:40:11 [error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => -5
[message] => DB Error: already exists
[mode] => 16
[debug_info] => INSERT INTO civicrm_value_contribution_custom_group_1 ( `custom_field_1`,`custom_field_2`,`custom_field_3`,`custom_field_4`,`entity_id` ) VALUES ( 1,'Some Text','','22943426',123456 ) [nativecode=1062 ** Duplicate entry '123456' for key 'unique_entity_id']
[type] => DB_Error
[user_info] => INSERT INTO civicrm_value_contribution_custom_group_1 ( `custom_field_1`,`custom_field_2`,`custom_field_3`,`custom_field_4`,`entity_id` ) VALUES ( 1,'Some Text','','22943426',123456 ) [nativecode=1062 ** Duplicate entry '123456' for key 'unique_entity_id']
[to_string] => [db_error: message="DB Error: already exists" code=-5 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="INSERT INTO civicrm_value_contribution_custom_group_1 ( `custom_field_1`,`custom_field_2`,`custom_field_3`,`custom_field_4`,`entity_id` ) VALUES ( 1,'Some Text','','22943426',123456 ) [nativecode=1062 ** Duplicate entry '123456' for key 'unique_entity_id']"]
)
Dec 07 12:40:11 [debug] $backTrace = #0 /path/to/civi/root/civicrm/CRM/Core/Error.php(942): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /path/to/civi/root/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(922): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#2 /path/to/civi/root/civicrm/vendor/pear/db/DB.php(997): PEAR_Error->__construct("DB Error: already exists", -5, 16, (Array:2), "INSERT INTO civicrm_value_contribution_custom_group_1 ( `hide_from_slider_182`,`custom_...")
#3 /path/to/civi/root/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-5, 16, (Array:2), "INSERT INTO civicrm_value_contribution_custom_group_1 ( `custom_field_1`,`custom_...")
#4 /path/to/civi/root/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(223): PEAR->_raiseError(Object(DB_mysqli), NULL, -5, 16, (Array:2), "INSERT INTO civicrm_value_contribution_custom_group_1 ( `custom_field_1`,`custom_...", "DB_Error", TRUE)
#5 /path/to/civi/root/civicrm/vendor/pear/db/DB/common.php(1928): PEAR->__call("raiseError", (Array:7))
#6 /path/to/civi/root/civicrm/vendor/pear/db/DB/mysqli.php(936): DB_common->raiseError(-5, NULL, NULL, "INSERT INTO civicrm_value_contribution_custom_group_1 ( `custom_field_1`,`custom_...", "1062 ** Duplicate entry '123456' for key 'unique_entity_id'")
#7 /path/to/civi/root/civicrm/vendor/pear/db/DB/mysqli.php(406): DB_mysqli->mysqliRaiseError()
#8 /path/to/civi/root/civicrm/vendor/pear/db/DB/common.php(1234): DB_mysqli->simpleQuery("INSERT INTO civicrm_value_contribution_custom_group_1 ( `custom_field_1`,`custom_...")
#9 /path/to/civi/root/civicrm/packages/DB/DataObject.php(2696): DB_common->query("INSERT INTO civicrm_value_contribution_custom_group_1 ( `custom_field_1`,`custom_...")
#10 /path/to/civi/root/civicrm/packages/DB/DataObject.php(1829): DB_DataObject->_query("INSERT INTO civicrm_value_contribution_custom_group_1 ( `custom_field_1`,`custom_...")
#11 /path/to/civi/root/civicrm/CRM/Core/DAO.php(468): DB_DataObject->query("INSERT INTO civicrm_value_contribution_custom_group_1 ( `custom_field_1`,`custom_...")
#12 /path/to/civi/root/civicrm/CRM/Core/DAO.php(1621): CRM_Core_DAO->query("INSERT INTO civicrm_value_contribution_custom_group_1 ( `custom_field_1`,`custom_...", TRUE)
#13 /path/to/civi/root/civicrm/CRM/Core/BAO/CustomValueTable.php(271): CRM_Core_DAO::executeQuery("INSERT INTO civicrm_value_contribution_custom_group_1 ( `custom_field_1`,`custom_...", (Array:5))
#14 /path/to/civi/root/civicrm/CRM/Core/BAO/CustomValueTable.php(391): CRM_Core_BAO_CustomValueTable::create((Array:2), "create")
#15 /path/to/civi/root/civicrm/CRM/Core/BAO/CustomValueTable.php(411): CRM_Core_BAO_CustomValueTable::store((Array:5), "civicrm_contribution", 123456, "create")
#16 /path/to/civi/root/civicrm/CRM/Core/DAO.php(2022): CRM_Core_BAO_CustomValueTable::postProcess((Array:5), "civicrm_contribution", 123456, "Contribution", "create")
#17 /path/to/civi/root/civicrm/CRM/Contribute/BAO/Contribution.php(2394): CRM_Core_DAO->copyCustomFields(123455, 123456)
#18 /path/to/civi/root/civicrm/CRM/Contribute/BAO/Contribution.php(4000): CRM_Contribute_BAO_Contribution::repeatTransaction((Array:10), (Array:18))
#19 /path/to/civi/root/civicrm/api/v3/Contribution.php(687): CRM_Contribute_BAO_Contribution::completeOrder((Array:10), "2269", NULL, NULL)
#20 /path/to/civi/root/civicrm/api/v3/Contribution.php(635): _ipn_process_transaction((Array:7), Object(CRM_Contribute_BAO_Contribution), (Array:10), (Array:10))
#21 /path/to/civi/root/civicrm/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_contribution_repeattransaction((Array:7))
#22 /path/to/civi/root/civicrm/Civi/API/Kernel.php(149): Civi\API\Provider\MagicFunctionProvider->invoke((Array:8))
#23 /path/to/civi/root/civicrm/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest((Array:8))
#24 /path/to/civi/root/civicrm/api/api.php(132): Civi\API\Kernel->runSafe("contribution", "repeattransaction", (Array:5))
#25 /path/to/civi/root/civicrm/drupal/drush/civicrm.drush.inc(1581): civicrm_api3("Contribution", "repeattransaction", Array:5))
#26 /usr/local/src/drush/includes/command.inc(422): drush_civicrm_api("Contribution.repeattransaction", "contribution_status_id=Completed", "total_amount=11.00", "contribution_recur_id=22663", "trxn_id=aa11bb22cc33dd47")
#27 /usr/local/src/drush/includes/command.inc(231): _drush_invoke_hooks((Array:38), (Array:5))
#28 /usr/local/src/drush/includes/command.inc(199): drush_command("Contribution.repeattransaction", "contribution_status_id=Completed", "total_amount=11.00", "contribution_recur_id=22663", "trxn_id=aa11bb22cc33dd47")
#29 /usr/local/src/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch((Array:38))
#30 /usr/local/src/drush/includes/preflight.inc(67): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#31 /usr/local/src/drush/drush.php(12): drush_main()
#32 {main}
```
Expected behaviour
----------------------------------------
Fatal error not raised; no attempt to write the exact same record twice.
I have mitigated this behaviour with the following patch, but this is clearly a temporary solution and the real root cause needs to be found:
```
diff --git a/CRM/Core/BAO/CustomValueTable.php b/CRM/Core/BAO/CustomValueTable.php
index 8556c4ec21..6773b994c4 100644
--- a/CRM/Core/BAO/CustomValueTable.php
+++ b/CRM/Core/BAO/CustomValueTable.php
@@ -55,7 +55,7 @@ class CRM_Core_BAO_CustomValueTable {
$hookOP = 'edit';
}
else {
- $sqlOP = "INSERT INTO $tableName ";
+ $sqlOP = "INSERT IGNORE INTO $tableName ";
$where = NULL;
$hookOP = 'create';
}
```
Environment information
----------------------------------------
* __Browser:__ _Firefox 94.0.2_
* __CiviCRM:__ _5.43.2_
* __PHP:__ _7.3_
* __CMS:__ _Drupal 7.82_
* __Database:__ _MariaDB 10.4.21_
* __Web Server:__ _Nginx 1.10.3_https://lab.civicrm.org/dev/core/-/issues/2986PCP: Account creation profile does not support contact image2023-10-28T05:03:27ZKurund JalmiPCP: Account creation profile does not support contact image## Steps to replicate
* Create a profile with contact image field (Image URL)
* Include this profile as a part of PCP account creation process
* Contact image is never uploaded.## Steps to replicate
* Create a profile with contact image field (Image URL)
* Include this profile as a part of PCP account creation process
* Contact image is never uploaded.https://lab.civicrm.org/dev/core/-/issues/2985Original value is displayed after setting custom event field blank2023-01-21T04:07:10ZBobSOriginal value is displayed after setting custom event field blankOverview
----------------------------------------
Attempting to change the value of a custom event field from non-blank to blank results in the original value being populated in the form after the form is saved. If the form is subsequent...Overview
----------------------------------------
Attempting to change the value of a custom event field from non-blank to blank results in the original value being populated in the form after the form is saved. If the form is subsequently saved again, then the original non-blank value is written to the DB.
Reproduction steps
----------------------------------------
1. Create a custom event fieldset.
1. Add a custom field of type Alphanumeric, Single line input field. Accept all default settings.
1. Edit an event.
1. Set the new custom field to a non-blank value and save the event.
1. Set the new custom field to a blank value and save the event.
Current behaviour
----------------------------------------
The custom field displays the non-blank value. If the form is saved, the blank value currently in the DB is overwritten with the non-blank value.
Expected behaviour
----------------------------------------
The custom field should display the last saved value: blank.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__ Chrome Version 96.0
* __CiviCRM:__ _5.45.alpha1_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.4_
* __CMS:__ _Drupal 7.82_
* __Database:__ _MariaDB 10.4_
* __Web Server:__ _Apache 2.4_
Comments
----------------------------------------
Confirmed on dmaster.demo.civicrm.org5.59.0https://lab.civicrm.org/dev/core/-/issues/2984APIv4: Confusing error when calling CaseType API2021-12-09T21:08:05ZtottenAPIv4: Confusing error when calling CaseType APIOverview
----------------------------------------
`CaseType.get` API has a confusing disposition.
Reproduction steps
----------------------------------------
1. Disable CiviCase
1. Call `cv api4 CaseType.get`
Current behavior
--------...Overview
----------------------------------------
`CaseType.get` API has a confusing disposition.
Reproduction steps
----------------------------------------
1. Disable CiviCase
1. Call `cv api4 CaseType.get`
Current behavior
----------------------------------------
The call to `CaseType.get` begins executing - but it fails in the middle of query-building.
```
cv api4 CaseType.get -v
Entity: CaseType
Action: get
Params: {
"version": 4,
"checkPermissions": false
}
[Symfony\Component\Debug\Exception\FatalThrowableError]
Type error: array_merge(): Argument #1 must be of type array, null given
Exception trace:
() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Query/Api4SelectQuery.php:223
array_merge() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Query/Api4SelectQuery.php:223
Civi\Api4\Query\Api4SelectQuery->buildSelectClause() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Query/Api4SelectQuery.php:149
Civi\Api4\Query\Api4SelectQuery->getSql() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Query/Api4SelectQuery.php:165
Civi\Api4\Query\Api4SelectQuery->run() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Generic/DAOGetAction.php:111
Civi\Api4\Generic\DAOGetAction->getObjects() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Generic/DAOGetAction.php:99
Civi\Api4\Generic\DAOGetAction->_run() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Provider/ActionObjectProvider.php:68
Civi\Api4\Provider\ActionObjectProvider->invoke() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/API/Kernel.php:149
Civi\API\Kernel->runRequest() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/Civi/Api4/Generic/AbstractAction.php:234
Civi\Api4\Generic\AbstractAction->execute() at /home/m/bknix/build/tmp/web/sites/all/modules/civicrm/api/api.php:85
civicrm_api4() at phar:///home/m/bknix/bin/cv/src/Command/Api4Command.php:145
Civi\Cv\Command\Api4Command->execute() at phar:///home/m/bknix/bin/cv/vendor/symfony/console/Command/Command.php:257
Symfony\Component\Console\Command\Command->run() at phar:///home/m/bknix/bin/cv/vendor/symfony/console/Application.php:850
Symfony\Component\Console\Application->doRunCommand() at phar:///home/m/bknix/bin/cv/vendor/symfony/console/Application.php:193
Symfony\Component\Console\Application->doRun() at phar:///home/m/bknix/bin/cv/src/Application.php:46
Civi\Cv\Application->doRun() at phar:///home/m/bknix/bin/cv/vendor/symfony/console/Application.php:124
Symfony\Component\Console\Application->run() at phar:///home/m/bknix/bin/cv/src/Application.php:15
Civi\Cv\Application::main() at phar:///home/m/bknix/bin/cv/bin/cv:27
require() at /home/m/bknix/bin/cv:14
```
Expected behavior
----------------------------------------
Either:
* Allow `CaseType` API calls to work. Return the list of case types.
* OR... Disallow `CaseType` API calls. Give a clear error; eg
* `CaseType.get API is unavailable.`
* `Cannot process request. CiviCase is disabled.`https://lab.civicrm.org/dev/core/-/issues/2983On "My Contact Dashboard", what is the Manage Case link in the relationships ...2024-02-26T05:03:22ZDaveDOn "My Contact Dashboard", what is the Manage Case link in the relationships section supposed to do?At civicrm/user, in the relationships section, if you have a relationship to a case there's a link under More at the right that says Manage Case. But clicking it does nothing. Also there's an error on the page because it's trying to crea...At civicrm/user, in the relationships section, if you have a relationship to a case there's a link under More at the right that says Manage Case. But clicking it does nothing. Also there's an error on the page because it's trying to create the link as CRM_Core_Action::NONE but there is no offset 0 in the $links array, but I'm not sure if that's the full reason it fails.
It looks like it's supposed to do a popup-y version of manage case? Except it looks like the link if it were working would be e.g. civicrm/case/ajax/details?caseId=1&cid=3&snippet=4, which just gives a little table.
I'm just wondering if it's worth trying to fix or to just remove it. I have no idea when it broke - never even knew it existed.