Development issueshttps://lab.civicrm.org/groups/dev/-/issues2020-09-17T09:48:45Zhttps://lab.civicrm.org/dev/core/-/issues/1072Combine the CiviMail Settings and the CiviMail Components Settings which are ...2020-09-17T09:48:45Zjustinfreeman (Agileware)Combine the CiviMail Settings and the CiviMail Components Settings which are currently on two different pages to be on the same pageCombine the CiviMail Settings and the CiviMail Components Settings which are currently on two different pages to be on the same page.
The reasoning is that these settings are all related to CiviMail and should be shown on the same page....Combine the CiviMail Settings and the CiviMail Components Settings which are currently on two different pages to be on the same page.
The reasoning is that these settings are all related to CiviMail and should be shown on the same page.
Particularly confusing when the VERP configuration is on BOTH pages.
**Settings - CiviMail**
* Enable Custom Reply-To
* VERP Separator
**CiviMail Component Settings**
* Track replies using VERP in Reply-To header
![Settings_-_CiviMail](/uploads/735ca3a60a22986c58a2f9bfe1a21946/Settings_-_CiviMail.png)
![CiviMail_Component_Settings](/uploads/a6ef9a8e20d71b46744d511d97d85590/CiviMail_Component_Settings.png)
Agileware Ref: CIVICRM-1255https://lab.civicrm.org/dev/core/-/issues/1045Repeat Activities broken from 5.13+2019-06-20T10:57:54ZSteveEllisRepeat Activities broken from 5.13+In 5.14.0, Repeat Activities is broken. It doesn't matter how many repeats or whether you state the number of repeats or set an end date - in all cases you get a brief preview of the activities you expect to be created and a 'saved' mess...In 5.14.0, Repeat Activities is broken. It doesn't matter how many repeats or whether you state the number of repeats or set an end date - in all cases you get a brief preview of the activities you expect to be created and a 'saved' message but it fails silently. There are no new records in the activity table.
Tested it on 3 Civis with 5.14 and also tried it on Circle Interactive's demo site (running 5.13.4) and it occurs on this too.5.14.1https://lab.civicrm.org/dev/core/-/issues/1043Pricing showing as 9 decimals places for all prices in Core2022-06-08T13:50:22ZSohalKhatwaniPricing showing as 9 decimals places for all prices in CoreWe are using Windows and the one of the latest version of CiviCRM 5.13.5. The pricing always shows 9 decimal places. E.g. if you create an event ticket it shows 20.000000000. Read in a few places that this was fixed but does not seem to ...We are using Windows and the one of the latest version of CiviCRM 5.13.5. The pricing always shows 9 decimal places. E.g. if you create an event ticket it shows 20.000000000. Read in a few places that this was fixed but does not seem to be the case.https://lab.civicrm.org/dev/core/-/issues/1041Refactor CiviCRM status checks so that checks are only performed when request...2020-09-17T09:42:52Zjustinfreeman (Agileware)Refactor CiviCRM status checks so that checks are only performed when requested and status alerts are only accessible to users with appropriate permissionsRefactor CiviCRM status checks so that:
1. checks are only performed when requested (and not on every CiviCRM page load)
2. where status alert information is available or shown
3. status alerts are only accessible to users with appropria...Refactor CiviCRM status checks so that:
1. checks are only performed when requested (and not on every CiviCRM page load)
2. where status alert information is available or shown
3. status alerts are only accessible to users with appropriate permissions
4. status check information is accessible via API supporting remote monitoring and alerts
Related PR for the new status check permission, https://github.com/civicrm/civicrm-core/pull/14521
On CiviCRM performance (1): if you run something in CiviCRM's menu it then invokes runItem to process and start the relevant functions to call the status check.
*List of status checks and suggested frequency*
TBCjustinfreeman (Agileware)justinfreeman (Agileware)https://lab.civicrm.org/dev/core/-/issues/1040Inconsistent validation of price field and option visibility combinations2022-11-12T05:03:50ZAndie HuntInconsistent validation of price field and option visibility combinationsSee https://github.com/civicrm/civicrm-core/pull/13966 for early discussion. Basically, CiviCRM occasionally attempts to prevent you from creating a price field with Admin visibility that only has options with Public visibility or vice-...See https://github.com/civicrm/civicrm-core/pull/13966 for early discussion. Basically, CiviCRM occasionally attempts to prevent you from creating a price field with Admin visibility that only has options with Public visibility or vice-versa. It is by no means consistent or effective in stopping this, however.
Some people [hold the opinion](https://github.com/civicrm/civicrm-core/pull/13966#issuecomment-480379731) that there should be no validation on this. At the very least, the validation should allow you to fix situations where there is no price option with visibility that matches its field's visibility (the situation that PR 13966 fixes).https://lab.civicrm.org/dev/core/-/issues/1035Incorrect Resource URLs message when they are correctly set2020-08-16T21:26:20ZJGauntIncorrect Resource URLs message when they are correctly setWe have recently upgraded to CiviCRM 5.13.4 on Drupal 7 and quite a lot of sites have the issue where the 'Incorrect Resource URL' message is showing despite them being set correctly.
Most of the sites are just the default paths so I fi...We have recently upgraded to CiviCRM 5.13.4 on Drupal 7 and quite a lot of sites have the issue where the 'Incorrect Resource URL' message is showing despite them being set correctly.
Most of the sites are just the default paths so I find it hard to believe that there is problems on all of them.
Pre-upgrade, the websites were not showing the message.
This doesn't seem to be an isolated incident as another member of the community has also said that he had the same issue.5.15.0https://lab.civicrm.org/dev/core/-/issues/1028civicrm custom data multiple choice values can be too long for varchar type2023-04-17T05:03:19ZMichael McAndrewcivicrm custom data multiple choice values can be too long for varchar type**Steps to reproduce:**
Create a checkbox field with multiple choice options. Assign long values to the options so that the sum of the length of the values is greater than 255, e.g. 10 options of 30 characters each.
Try and save the fi...**Steps to reproduce:**
Create a checkbox field with multiple choice options. Assign long values to the options so that the sum of the length of the values is greater than 255, e.g. 10 options of 30 characters each.
Try and save the field with all options selected.
You will get an error along the lines of
```
[db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::handle prefix="" info="INSERT INTO civicrm_value_...[nativecode=1406 ** Data too long for column '...
```
**Proposed fix:**
Add a validation that the sum of the length of the values for multiple choice radio / multiselect groups is less than some number less than 255 (since we also need to take account of all the null seperator characters that CiviCRM adds).
Perform this validation at the API and form layer.https://lab.civicrm.org/dev/core/-/issues/1021“Address History” link for contacts disappeared?2019-06-11T09:04:34Ztapash“Address History” link for contacts disappeared?I used to have an "Address History" link that appeared when an address was updated in CiviCRM 5.10 probably (can't remember the exact version). I have logging turned on in settings.
But since I have updated to the latest 5.13.5 that "Ad...I used to have an "Address History" link that appeared when an address was updated in CiviCRM 5.10 probably (can't remember the exact version). I have logging turned on in settings.
But since I have updated to the latest 5.13.5 that "Address History" link has disappeared. I have checked on https://dmaster.demo.civicrm.org and it does not appear there too. Is it a bug or intentional removal? Any suggestion on how can I get back this please, because it used to be a great feature I think. Thankshttps://lab.civicrm.org/dev/financial/-/issues/62PayPal Pro IPN doesn't record failed recurring payments2020-01-18T22:29:49ZJonGoldPayPal Pro IPN doesn't record failed recurring paymentsOnce upon a time, some payment processors recorded failed recurring payments, others didn't, based on the preference of the author.
These days, we've settled on "failed recurring payments should create a failed contribution entry" acros...Once upon a time, some payment processors recorded failed recurring payments, others didn't, based on the preference of the author.
These days, we've settled on "failed recurring payments should create a failed contribution entry" across the board, except PayPal Pro, which has the note "[// Also consider accepting 'Failed' like other processors.](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment/PayPalProIPN.php#L248)".
I wrote a patch for this years ago, but at the time it wasn't settled that this was correct behavior. I recently had another client request this functionality, so I'm going to modernize the patch, put it in production, and submit it upstream if it looks good.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/997Autorenewal memberships should support differing frequencies in a single pric...2020-09-17T22:58:28ZFrancis (Agileware)Autorenewal memberships should support differing frequencies in a single price setOverview
========
Currently if you set up auto-renewing memberships with a price set, contribution pages using that price set will always use the duration unit and interval of the first membership listed as the recurring frequency.
Ver...Overview
========
Currently if you set up auto-renewing memberships with a price set, contribution pages using that price set will always use the duration unit and interval of the first membership listed as the recurring frequency.
Verified on dmaster 28/May/2019.
Steps to Reproduce
==================
1. Create two membership types, "Monthly" and "Annual", with respective durations and auto-renewal enabled
2. Create a price set and field with three membership options:
1. Monthly (1 term)
2. Annual (1 term)
3. Monthly (12 terms)
3. Create a contribution page that uses this price set
4. Submit the contribution page once for each option.
Expected results
----------------
Three Membership & Recurring Contribution pairs with the respective intervals.
Actual results
--------------
Three Memberships, all with the correct intervals, however all are linked to recurring contributions with a frequency of 1 month.
Comments
========
I'm fairly certain the problem occurs because of a call from `CRM_Contribute_Form_Contribution::setRecurringMembershipParams()` to `CRM_Price_BAO_PriceSet::getRecurDetails($priceSetId)` (https://github.com/civicrm/civicrm-core/blob/9f26604/CRM/Contribute/Form/ContributionBase.php#L1381) which will only return the details for the first membership related PriceFieldValue in the referenced price set, **in the order the MySQL retrieves it**.
Agileware Ref: CIVICRM-1202https://lab.civicrm.org/dev/core/-/issues/996Ensure that the oldest creation date is preserved when deduping2023-02-11T05:03:23ZseamusleeEnsure that the oldest creation date is preserved when dedupingNormally when you go to merge 2 contacts CiviCRM will by default suggest to merging a higher cid into a lower cid which will mean that the create date on the merged records will be correct. However if you flip it so your merging a lower ...Normally when you go to merge 2 contacts CiviCRM will by default suggest to merging a higher cid into a lower cid which will mean that the create date on the merged records will be correct. However if you flip it so your merging a lower cid into a higher cid for whatever reason, it is likely you may find that the create date is now wrong because there may have been activites or other items created on the lower cid before the higher cid came around.
thoughts @eileenhttps://lab.civicrm.org/dev/core/-/issues/995CiviCRM social media integration in 20192022-11-12T05:03:58ZJamie Novick - CompucoCiviCRM social media integration in 2019Just doing a little bit of poking around and was wondering what the current state of CivICRM’s social media integration is.
I know there was the following extension a while back - https://civicrm.org/extensions/attentively-integration b...Just doing a little bit of poking around and was wondering what the current state of CivICRM’s social media integration is.
I know there was the following extension a while back - https://civicrm.org/extensions/attentively-integration but I see that they’ve since been bought by Blackbaud so thats probably dead in the water.
What are others doing about social media when it comes up with clients?https://lab.civicrm.org/dev/core/-/issues/992Campaign dashboard isn't sorting clicking in the header2019-11-14T16:59:19ZCésarCampaign dashboard isn't sorting clicking in the headerHello,
The campaign dashboard isn't sorting clicking in the header from a specific columns: type, status, created_by and external_id.
Observed in 5.12.0Hello,
The campaign dashboard isn't sorting clicking in the header from a specific columns: type, status, created_by and external_id.
Observed in 5.12.0https://lab.civicrm.org/dev/core/-/issues/982Cleanup & api-ise the dedupe code2022-11-07T05:03:57ZeileenCleanup & api-ise the dedupe codeI've been looking at the dedupe code a lot. The problem is it was written to support a particular form & there is no layering. I think the right steps to clean it up involve adding some apis. I have been experimenting with a new angular ...I've been looking at the dedupe code a lot. The problem is it was written to support a particular form & there is no layering. I think the right steps to clean it up involve adding some apis. I have been experimenting with a new angular interface but we need to expose the logic via the api for it to be usable. Currently I'm looking at adding find apis - looking at creating a new api entity 'Dedupe' (I could use 'Rule' and add actions - on the fence there)
& looking at an action Dedupe.getmatcheshttps://lab.civicrm.org/dev/core/-/issues/978CiviCRM 5.13.4 - Specified key was too long; max key length is 767 bytes2019-06-17T04:54:35Zjustinfreeman (Agileware)CiviCRM 5.13.4 - Specified key was too long; max key length is 767 bytesSince CiviCRM 5.13.4 the following error is being reported on standard CPanel, Plesk and CentOS 6, CentOS 7 hosts using MariaDB 10.1.
May 20 10:26:22 [info] $Fatal Error Details = Array
(
[callback] => Array
(
[...Since CiviCRM 5.13.4 the following error is being reported on standard CPanel, Plesk and CentOS 6, CentOS 7 hosts using MariaDB 10.1.
May 20 10:26:22 [info] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => -1
[message] => DB Error: unknown error
[mode] => 16
[debug_info] => CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(255))) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC ENGINE=INNODB [nativecode=1071 ** Specified key was too long; max key length is 767 bytes]
[type] => DB_Error
[user_info] => CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(255))) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC ENGINE=INNODB [nativecode=1071 ** Specified key was too long; max key length is 767 bytes]
[to_string] => [db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(255))) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC ENGINE=INNODB [nativecode=1071 ** Specified key was too long; max key length is 767 bytes]"]
)
May 20 10:26:22 [info] $backTrace = #0 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/CRM/Core/Error.php(952): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(922): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#2 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/packages/DB.php(985): PEAR_Error->__construct("DB Error: unknown error", -1, 16, (Array:2), "CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(...")
#3 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-1, 16, (Array:2), "CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(...")
#4 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(223): PEAR->_raiseError(Object(DB_mysqli), NULL, -1, 16, (Array:2), "CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(...", "DB_Error", TRUE)
#5 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/packages/DB/common.php(1907): PEAR->__call("raiseError", (Array:7))
#6 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/packages/DB/mysqli.php(933): DB_common->raiseError(-1, NULL, NULL, "CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(...", "1071 ** Specified key was too long; max key length is 767 bytes")
#7 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/packages/DB/mysqli.php(403): DB_mysqli->mysqliRaiseError()
#8 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/packages/DB/common.php(1216): DB_mysqli->simpleQuery("CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(...")
#9 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/packages/DB/DataObject.php(2415): DB_common->query("CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(...")
#10 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/packages/DB/DataObject.php(1607): DB_DataObject->_query("CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(...")
#11 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/CRM/Core/DAO.php(439): DB_DataObject->query("CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(...")
#12 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/CRM/Core/DAO.php(1414): CRM_Core_DAO->query("CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(...", TRUE)
#13 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/CRM/Utils/Check/Component/Env.php(914): CRM_Core_DAO::executeQuery("CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(...")
#14 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/CRM/Utils/Check/Component.php(55): CRM_Utils_Check_Component_Env->checkMysqlUtf8mb4()
#15 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/CRM/Utils/Check.php(209): CRM_Utils_Check_Component->checkAll()
#16 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/api/v3/System.php(153): CRM_Utils_Check::checkAll()
#17 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/Civi/API/Provider/MagicFunctionProvider.php(101): civicrm_api3_system_check((Array:3))
#18 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/Civi/API/Kernel.php(168): Civi\API\Provider\MagicFunctionProvider->invoke((Array:9))
#19 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/Civi/API/Kernel.php(99): Civi\API\Kernel->runRequest((Array:9))
#20 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/api/api.php(23): Civi\API\Kernel->runSafe("System", "check", (Array:3), NULL)
#21 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/CRM/Utils/REST.php(316): civicrm_api("System", "check", (Array:3))
#22 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/CRM/Utils/REST.php(566): CRM_Utils_REST::process((Array:3), (Array:3))
#23 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/CRM/Core/Invoke.php(277): CRM_Utils_REST::ajax()
#24 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/CRM/Core/Invoke.php(85): CRM_Core_Invoke::runItem((Array:12))
#25 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:3))
#26 /var/www/vhosts/websiteorgau.org.au/httpdocs/sites/all/modules/civicrm/drupal/civicrm.module(444): CRM_Core_Invoke::invoke((Array:3))
#27 /var/www/vhosts/websiteorgau.org.au/httpdocs/includes/menu.inc(527): civicrm_invoke("ajax", "rest")
#28 /var/www/vhosts/websiteorgau.org.au/httpdocs/index.php(21): menu_execute_active_handler()
#29 {main}
And another example.
May 21 11:40:13 [info] $backTrace = #0 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/CRM/Core/Error.php(952): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(922): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#2 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/packages/DB.php(985): PEAR_Error->__construct("DB Error: unknown error", -1, 16, (Array:2), "CREATE TEMPORARY TABLE civicrm_utf8mb4
_test (id VARCHAR(255), PRIMARY KEY(id(...")
#3 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-1, 16, (Array:2), "CREATE TEMPORARY TABLE civicrm_utf8mb4_t
est (id VARCHAR(255), PRIMARY KEY(id(...")
#4 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(223): PEAR->_raiseError(Object(DB_mysqli), NULL, -1, 16, (Array:2), "CREATE TEMPORARY TA
BLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(...", "DB_Error", TRUE)
#5 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/packages/DB/common.php(1907): PEAR->__call("raiseError", (Array:7))
#6 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/packages/DB/mysqli.php(933): DB_common->raiseError(-1, NULL, NULL, "CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), P
RIMARY KEY(id(...", "1071 ** Specified key was too long; max key length is 767 bytes")
#7 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/packages/DB/mysqli.php(403): DB_mysqli->mysqliRaiseError()
#8 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/packages/DB/common.php(1216): DB_mysqli->simpleQuery("CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(
...")
#9 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/packages/DB/DataObject.php(2415): DB_common->query("CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(..
.")
#10 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/packages/DB/DataObject.php(1607): DB_DataObject->_query("CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY
(id(...")
#11 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/CRM/Core/DAO.php(439): DB_DataObject->query("CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(...")
#12 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/CRM/Core/DAO.php(1414): CRM_Core_DAO->query("CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255), PRIMARY KEY(id(...", TR
UE)
#13 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/CRM/Utils/Check/Component/Env.php(914): CRM_Core_DAO::executeQuery("CREATE TEMPORARY TABLE civicrm_utf8mb4_test (id VARCHAR(255),
PRIMARY KEY(id(...")
#14 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/CRM/Utils/Check/Component.php(55): CRM_Utils_Check_Component_Env->checkMysqlUtf8mb4()
#15 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/CRM/Utils/Check.php(209): CRM_Utils_Check_Component->checkAll()
#16 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/CRM/Utils/Check.php(93): CRM_Utils_Check::checkAll()
#17 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/CRM/Core/Page.php(218): CRM_Utils_Check->showPeriodicAlerts()
#18 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/CRM/Contact/Page/DashBoard.php(69): CRM_Core_Page->run()
#19 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/CRM/Core/Invoke.php(311): CRM_Contact_Page_DashBoard->run((Array:1), NULL)
#20 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/CRM/Core/Invoke.php(85): CRM_Core_Invoke::runItem((Array:13))
#21 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:1))
#22 /var/www/vhosts/websiteorgau/httpdocs/sites/all/modules/civicrm/drupal/civicrm.module(444): CRM_Core_Invoke::invoke((Array:1))
#23 /var/www/vhosts/websiteorgau/httpdocs/includes/menu.inc(527): civicrm_invoke()
#24 /var/www/vhosts/websiteorgau/httpdocs/index.php(21): menu_execute_active_handler()
#25 {main}
Agileware Ref: CIVICRM-1213https://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/972Participant change selection tax issue2023-04-21T05:03:28Zvakeesan26Participant change selection tax issueWhen we do the participant change selection, Tax is not being calculated properly [ for html type Text ]
![image](/uploads/573cde653f6bcd6da6463aec74466e9e/image.png)
![image](/uploads/1723321e6c87cc4cf4bca50ad2c34e41/image.png)
Also...When we do the participant change selection, Tax is not being calculated properly [ for html type Text ]
![image](/uploads/573cde653f6bcd6da6463aec74466e9e/image.png)
![image](/uploads/1723321e6c87cc4cf4bca50ad2c34e41/image.png)
Also when we do the edit & save with out making any change, screen hanging up
![image](/uploads/f7cded92261386a7626e6b876a38597e/image.png)
In the CiviCRM error log we are getting following error message
$Fatal Error Details = array(3) {
["message"]=>
string(61) "Mandatory key(s) missing from params array: financial_trxn_id"
["code"]=>
NULL
["exception"]=>https://lab.civicrm.org/dev/core/-/issues/970Customised greetings not handled during merge2022-11-02T05:03:41ZJKingsnorthCustomised greetings not handled during mergeIt is possible to set customised email or postal 'greetings' in the system. However, when you choose to take across a customised greeting during a merge - the greeting itself is not migrated.
Steps to recreate:
- Create a contact record...It is possible to set customised email or postal 'greetings' in the system. However, when you choose to take across a customised greeting during a merge - the greeting itself is not migrated.
Steps to recreate:
- Create a contact record A, email address 'dupe@example.com'
- Edit record A, change the 'email greeting' to 'Customised' and the text to 'Why hi A!'
- Create a contact record B, email address 'dupe@example.com'
- Find duplicates on email address
- Go to merge the contacts, ensure that 'Email greeting ID 4' is being taken across:
![image](/uploads/6931d4c2c29057b95eb4490dea1a968a/image.png)
(note this is easier with patch https://github.com/civicrm/civicrm-core/pull/14260 applied!)
- Merge and view result
- Notice that the fact it is 'customised' has been retained, but the actual value has been lost:
![image](/uploads/be3c91513060ade5df0597c9342016a0/image.png)
This needs to be fixed for: email greeting, postal greeting and addressee fields. + tests written!
The fix would be:
- Ensure that the customised values are also displayed on the merge form
- Ensure that the 'customisations' are taken across when selected during a merge
- Ensure that customisations are removed appropriately if they are not longer customised as the result of a merge
- Handle cases where both contacts have different customised greetings
Thoughts:
The display could be like:
`Greeting ID: Customised: Hello A --[]--> Customised: Hello hello A!`
rather than having the customisation displayed in a separate row on the merge screenhttps://lab.civicrm.org/dev/core/-/issues/905Better support in core for token payment processing2023-02-16T05:03:39ZeileenBetter support in core for token payment processingOver time token payments have become the preferred way of handling recurring payments. A while back we added the payment_token table for storage but we still have a situation where various processor extensions are solving the same proble...Over time token payments have become the preferred way of handling recurring payments. A while back we added the payment_token table for storage but we still have a situation where various processor extensions are solving the same problems separately (with varying degrees of maintainability). If we can converge on some improvements in core to better support this we can add tests in core & make the whole thing more reliable. Use of new methods would be recommended rather than required.
The focus here is on the regular scheduled job that finds recurring contributions that need to be charged, charges them and updates them in CiviCRM. I'm imagining we would add additional functions to the CRM_Core_Payment class that can be used and overridden by the various processors. We might visually separate them into a trait but I think it would be 'used' by CRM_Core_Payment.
The basic flow is
- getDuePayments
- preProcessDuePayments
- submitDuePaymentsToGateway
- updateSuccessfulPayments OR updateFailedPayments
Potentially status reporting - e.g emailing an administrator or logging to system log fits in at the end - I'm gonna leave that out of scope for now.
**Get Due Payments**
There are 2 types of payments here - those that are naturally due and those that are due to be retried due to previous failure. I think we should have 2 methods
- getDueScheduledPayments &
- getDueFailureRetryPayments
**Preprocess due payments**
Generally we create a pending contribution here (repeattransaction, status-pending)
We also attempt to 'lock' the recurring contribution so that it won't be retried the same day if the script fails or if there is a concurrent process. I'm imagining the functions to be
- createPendingTokenPayment
- lockRecurringContribution (more on this down below)
** Submit payments to gateway***
This generally uses 'doPayment'
** Update Successful Payments Update Failed Payment**
We call completetransaction for success & unlock the recurring contribution. Fails is the area we are trying to converge on
**Locking recurrings**
The main ways currently in use for 'locking recurrings' are to
- change the status on the recurring contribution
- add a pending contribution (& use the presence of that in a pending state as a blocker to further processing)
- push out the next_sched_contribution_date and failure_retry_date before starting so it won't be retried again before the schedule is due
After some thought I think we should do more with the status on the recurring contribution. My main reservation at the moment is that processors that use that method are overloading the 'Pending' status which actually means 'no payment yet received' - but I think that stems back to another design decision that I think was a mistake. Originally contribution, contribution_recur, pledge & pledge status were set up to share an option group. This causes a bunch of issues & hacky handling & as of now only contribution & contribution recur share statuses. I think we should separate them out into 2 option groups & then have some extra statuses that reflect the lock situation e.g
- 'Processing' - this would be our 'locked' status & nothing more would happen until that is resolved
- 'Failing' - this would mean one or more fails have happened but we haven't given up yet
This would mean that to be processed the next_sched_contribution_date needs to be now AND the status needs to not be 'Processing' OR the status needs to be 'Failing' and the failure_retry_date needs to be now.
Note that separating out the option group also addresses some other issues so I will likely do it in a 'numbers are all still the same' way sooner rather than later and we will be in a better position later.
**Unlocking recurring**
Success is easy - we just complete the transaction & push next_sched_contribution_date & null our failure_count & failure_retry_date
Failure is hard. The fails could be
- script does not complete. In this case the contribution is left in the 'Processing' status - in some cases people will manually intervene here and in some cases audit information from the processor will update the recurring. However, if, after a month it is still in Processing then it should be tried again. This feels like the case for pushing out next_sched_contribution_date BEFORE attempting payment
- payment fails with a temporary error related to the server (server says come back later)
- payment fails with a temporary error related to the user (card is overdrawn)
- payment fails with a permanent error (card is cancelled, stolen)
- payment fails with a permanent user error because they have cancelled the token at the gateway
Generally in a temporary error we will try again (using the failure_retry_date) and in a permanent error we will cancel the recurring contribution, in the case of the user-cancel it might make more sense for some sites to set it to completed....
**Next steps**
Overall I think if we start to get to some agreed additional functionality to support in core / add to the interface & keep tested that is a good thing. I feel like I need to ponder it for a bit & this will be an ongoing thing. But there are 2 things I think are worth doing now
1) add 4 new exception classes to core (all extending PaymentProcessorException)
- PermanentTokenPaymentException
- TemporaryServerTokenPaymentException
- TemporaryUserTokenPaymentException
- TokenCancelledByUserException
2) create a new contribution_recur_status_id option group - ensure the values exactly match the contribution option group & chip away at updating the various code places to use it (they should still work if using the old one as the numbers will be the same - this is how we managed it on pledges)
Initial discussion at https://github.com/iATSPayments/com.iatspayments.civicrm/pull/273
"Related" issues:
* https://lab.civicrm.org/dev/financial/issues/57
* https://lab.civicrm.org/dev/financial/issues/53
EDIT NOTE - 'Being processed' has been updated in this test to 'Processing' - since that was what was agreed. Comments below may be confusing without realising the text used to refer to Being Processedhttps://lab.civicrm.org/dev/core/-/issues/899PCP is still active after contribution page is disabled.2023-11-15T05:03:17ZjitendraPCP is still active after contribution page is disabled.To replicate -
- Create a contribution page and enable PCP.
- User makes a donation from the live page and creates a PCP of his own.
- When an admin approves the PCP, a notification email is sent to the creator.
- Disable the Contributi...To replicate -
- Create a contribution page and enable PCP.
- User makes a donation from the live page and creates a PCP of his own.
- When an admin approves the PCP, a notification email is sent to the creator.
- Disable the Contribution page.
- PCP is kept as it is.
- When the live page is visited by the promoter or the user from the PCP link, a yellow message is displayed on the page
![image](/uploads/0b1710ed1f37bcce8b9b4d9c1779ee85/image.png)
Real problem seems to be - you have someone who has made a P2P contribution page who might have no clue the page has been disabled by a site admin and is out promoting the page!
Thoughts on expected behavior? @eileen @KarinG...
- Disable PCP when CP is disabled.
- Keep PCP as it is and change the error message on PCP load.
- Disable the PCP and send an email notification to the creator.
- The current error is perhaps the correct and enough response to be shown to the user :shrug:jitendrajitendra