Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-14T05:03:20Zhttps://lab.civicrm.org/dev/core/-/issues/2594Contribution Recur reference in membership not updated in merging2024-03-14T05:03:20ZseamusleeContribution Recur reference in membership not updated in mergingWhen 2 contacts are merged and memberships are merged together, if the duplicate membership has a recurring contribution linked to it but the original didn't or visa versa (say someone renewed and opted in for a recurring membership). Th...When 2 contacts are merged and memberships are merged together, if the duplicate membership has a recurring contribution linked to it but the original didn't or visa versa (say someone renewed and opted in for a recurring membership). There is at present no handling in https://github.com/civicrm/civicrm-core/blob/master/CRM/Member/BAO/Membership.php#L2599 or https://github.com/civicrm/civicrm-core/blob/master/CRM/Dedupe/Merger.php#L385 https://github.com/civicrm/civicrm-core/blob/master/CRM/Dedupe/Merger.php#L427 which would cause the contribution recur information to be migrated across to the kept membership
cc @JoeMurrayhttps://lab.civicrm.org/dev/core/-/issues/3988Cache race conditions2024-02-16T09:46:55ZJonGoldCache race conditionsA client was asking me to find out why a $2,500 donation failed. I found this error in the logs (full backtrace below):
```
Nov 10 10:58:40 [error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CR...A client was asking me to find out why a $2,500 donation failed. I found this error in the logs (full backtrace below):
```
Nov 10 10:58:40 [error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => -5
[message] => DB Error: already exists
[mode] => 16
[debug_info] => UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5OiJDb21wbGV0ZWQiO2k6MztzOjk6IkNhbmNlbGxlZCI7aTo0O3M6MTI6IkxlZnQgTWVzc2FnZSI7aTo1O3M6MTE6IlVucmVhY2hhYmxlIjtpOjY7czoxMjoiTm90IFJlcXVpcmVkIjtpOjc7czo5OiJBdmFpbGFibGUiO2k6ODtzOjc6Ik5vX3Nob3ciO2k6OTtzOjY6IlVucmVhZCI7aToxMDtzOjU6IkRyYWZ0Ijt9', created_date = FROM_UNIXTIME(1668095920), expired_date = FROM_UNIXTIME(1668117520) WHERE group_name = "metadata_5_54_1" AND path = "CRM_OG_activitystatus_883f1c0c1790789755f726d1e41232c2" [nativecode=1062 ** Duplicate entry 'metadata_5_54_1-CRM_OG_activitystatus_883f1c0c1790789755f726d...' for key 'UI_group_path_date']
[type] => DB_Error
[user_info] => UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5OiJDb21wbGV0ZWQiO2k6MztzOjk6IkNhbmNlbGxlZCI7aTo0O3M6MTI6IkxlZnQgTWVzc2FnZSI7aTo1O3M6MTE6IlVucmVhY2hhYmxlIjtpOjY7czoxMjoiTm90IFJlcXVpcmVkIjtpOjc7czo5OiJBdmFpbGFibGUiO2k6ODtzOjc6Ik5vX3Nob3ciO2k6OTtzOjY6IlVucmVhZCI7aToxMDtzOjU6IkRyYWZ0Ijt9', created_date = FROM_UNIXTIME(1668095920), expired_date = FROM_UNIXTIME(1668117520) WHERE group_name = "metadata_5_54_1" AND path = "CRM_OG_activitystatus_883f1c0c1790789755f726d1e41232c2" [nativecode=1062 ** Duplicate entry 'metadata_5_54_1-CRM_OG_activitystatus_883f1c0c1790789755f726d...' for key 'UI_group_path_date']
[to_string] => [db_error: message="DB Error: already exists" code=-5 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5OiJDb21wbGV0ZWQiO2k6MztzOjk6IkNhbmNlbGxlZCI7aTo0O3M6MTI6IkxlZnQgTWVzc2FnZSI7aTo1O3M6MTE6IlVucmVhY2hhYmxlIjtpOjY7czoxMjoiTm90IFJlcXVpcmVkIjtpOjc7czo5OiJBdmFpbGFibGUiO2k6ODtzOjc6Ik5vX3Nob3ciO2k6OTtzOjY6IlVucmVhZCI7aToxMDtzOjU6IkRyYWZ0Ijt9', created_date = FROM_UNIXTIME(1668095920), expired_date = FROM_UNIXTIME(1668117520) WHERE group_name = "metadata_5_54_1" AND path = "CRM_OG_activitystatus_883f1c0c1790789755f726d1e41232c2" [nativecode=1062 ** Duplicate entry 'metadata_5_54_1-CRM_OG_activitystatus_883f1c0c1790789755f726d...' for key 'UI_group_path_date']"]
)
```
In `CRM_Core_OptionGroup::values()`, we check for a cached result. If we don't find one, we run the query, then cache the result. However, between the `$cache->has()` and `$cache->set()`, this value was added to the cache.
### How to resolve?
It seems to me like there's no way to avoid a race condition without recovering gracefully from this error.
It seems like a failure to write to cache shouldn't be fatal - could we catch `CRM_Utils_Cache_CacheException` and continue execution?
Backtrace
```
Nov 10 10:58:40 [debug] $backTrace = #0 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Error.php(954): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /var/www/mysiten.org/vendor/pear/pear-core-minimal/src/PEAR.php(944): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#2 /var/www/mysiten.org/vendor/pear/db/DB.php(997): PEAR_Error->__construct("DB Error: already exists", -5, 16, (Array:2), "UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#3 /var/www/mysiten.org/vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-5, 16, (Array:2), "UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#4 /var/www/mysiten.org/vendor/pear/pear-core-minimal/src/PEAR.php(223): PEAR::_raiseError(Object(DB_mysqli), NULL, -5, 16, (Array:2), "UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...", "DB_Error", TRUE)
#5 /var/www/mysiten.org/vendor/pear/db/DB/common.php(1928): PEAR->__call("raiseError", (Array:7))
#6 /var/www/mysiten.org/vendor/pear/db/DB/mysqli.php(943): DB_common->raiseError(-5, NULL, NULL, "UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...", "1062 ** Duplicate entry 'metadata_5_54_1-CRM_OG_activitystatus_883f1c0c179078...")
#7 /var/www/mysiten.org/vendor/pear/db/DB/mysqli.php(413): DB_mysqli->mysqliRaiseError()
#8 /var/www/mysiten.org/vendor/pear/db/DB/common.php(1234): DB_mysqli->simpleQuery("UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#9 /var/www/mysiten.org/vendor/civicrm/civicrm-packages/DB/DataObject.php(2696): DB_common->query("UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#10 /var/www/mysiten.org/vendor/civicrm/civicrm-packages/DB/DataObject.php(1829): DB_DataObject->_query("UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#11 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/DAO.php(494): DB_DataObject->query("UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#12 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/DAO.php(1675): CRM_Core_DAO->query("UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...", FALSE)
#13 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Utils/Cache/SqlGroup.php(137): CRM_Core_DAO::executeQuery("UPDATE civicrm_cache SET data = %1, created_date = FROM_UNIXTIME(%2), expired...", (Array:3), TRUE, NULL, FALSE, FALSE)
#14 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/OptionGroup.php(173): CRM_Utils_Cache_SqlGroup->set("CRM_OG_activitystatus_883f1c0c1790789755f726d1e41232c2", (Array:10))
#15 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/PseudoConstant.php(262): CRM_Core_OptionGroup::values("activity_status", FALSE, FALSE, FALSE, NULL, "name", FALSE, FALSE, "value", "weight")
#16 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/DAO.php(2837): CRM_Core_PseudoConstant::get("CRM_Activity_BAO_Activity", "status_id", (Array:8), "validate")
#17 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Utils/FormattingUtil.php(264): CRM_Core_DAO::buildOptions("status_id", "validate", (Array:10))
#18 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Generic/AbstractAction.php(530): Civi\Api4\Utils\FormattingUtil::getPseudoconstantList((Array:30), "status_id:name", (Array:10), "create")
#19 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Generic/Traits/DAOActionTrait.php(178): Civi\Api4\Generic\AbstractAction->formatWriteValues((Array:10))
#20 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Generic/DAOSaveAction.php(30): Civi\Api4\Generic\DAOSaveAction->formatWriteValues((Array:10))
#21 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Provider/ActionObjectProvider.php(69): Civi\Api4\Generic\DAOSaveAction->_run(Object(Civi\Api4\Generic\Result))
#22 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(149): Civi\Api4\Provider\ActionObjectProvider->invoke(Object(Civi\Api4\Generic\DAOSaveAction))
#23 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Generic/AbstractAction.php(250): Civi\API\Kernel->runRequest(Object(Civi\Api4\Generic\DAOSaveAction))
#24 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/BAO/Contribution.php(552): Civi\Api4\Generic\AbstractAction->execute()
#25 /var/www/mysiten.org/vendor/civicrm/civicrm-core/api/v3/utils.php(1319): CRM_Contribute_BAO_Contribution::create((Array:23))
#26 /var/www/mysiten.org/vendor/civicrm/civicrm-core/api/v3/Contribution.php(87): _civicrm_api3_basic_create("CRM_Contribute_BAO_Contribution", (Array:23), "Contribution")
#27 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_contribution_create((Array:23))
#28 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(149): Civi\API\Provider\MagicFunctionProvider->invoke((Array:8))
#29 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest((Array:8))
#30 /var/www/mysiten.org/vendor/civicrm/civicrm-core/api/api.php(133): Civi\API\Kernel->runSafe("Contribution", "create", (Array:10))
#31 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/BAO/Contribution.php(3848): civicrm_api3("Contribution", "create", (Array:10))
#32 /var/www/mysiten.org/vendor/civicrm/civicrm-core/api/v3/Contribution.php(522): CRM_Contribute_BAO_Contribution::completeOrder((Array:5), NULL, 21523, NULL)
#33 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_contribution_completetransaction((Array:9))
#34 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(149): Civi\API\Provider\MagicFunctionProvider->invoke((Array:8))
#35 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest((Array:8))
#36 /var/www/mysiten.org/vendor/civicrm/civicrm-core/api/api.php(133): Civi\API\Kernel->runSafe("contribution", "completetransaction", (Array:9))
#37 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Confirm.php(2412): civicrm_api3("contribution", "completetransaction", (Array:9))
#38 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Confirm.php(861): CRM_Contribute_Form_Contribution_Confirm->processFormSubmission("100769")
#39 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Form.php(573): CRM_Contribute_Form_Contribution_Confirm->postProcess()
#40 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Main.php(1472): CRM_Core_Form->mainProcess()
#41 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Main.php(1220): CRM_Contribute_Form_Contribution_Main->skipToThankYouPage()
#42 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Form.php(573): CRM_Contribute_Form_Contribution_Main->postProcess()
#43 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Upload.php(152): CRM_Core_Form->mainProcess()
#44 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Upload.php(119): CRM_Core_QuickForm_Action_Upload->realPerform(Object(CRM_Contribute_Form_Contribution_Main), "upload")
#45 /var/www/mysiten.org/vendor/civicrm/civicrm-packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Upload->perform(Object(CRM_Contribute_Form_Contribution_Main), "upload")
#46 /var/www/mysiten.org/vendor/civicrm/civicrm-packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contribute_Form_Contribution_Main), "upload")
#47 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Controller.php(355): HTML_QuickForm_Page->handle("upload")
#48 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(319): CRM_Core_Controller->run((Array:3), NULL)
#49 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem((Array:18))
#50 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:3))
#51 /var/www/mysiten.org/web/modules/contrib/civicrm/src/Civicrm.php(88): CRM_Core_Invoke::invoke((Array:3))
#52 /var/www/mysiten.org/web/modules/contrib/civicrm/src/Controller/CivicrmController.php(80): Drupal\civicrm\Civicrm->invoke((Array:3))
#53 [internal function](): Drupal\civicrm\Controller\CivicrmController->main((Array:3), "")
#54 /var/www/mysiten.org/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array((Array:2), (Array:2))
#55 /var/www/mysiten.org/web/core/lib/Drupal/Core/Render/Renderer.php(564): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#56 /var/www/mysiten.org/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#57 /var/www/mysiten.org/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext((Array:2), (Array:2))
#58 /var/www/mysiten.org/vendor/symfony/http-kernel/HttpKernel.php(159): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#59 /var/www/mysiten.org/vendor/symfony/http-kernel/HttpKernel.php(81): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#60 /var/www/mysiten.org/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#61 /var/www/mysiten.org/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#62 /var/www/mysiten.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#63 /var/www/mysiten.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#64 /var/www/mysiten.org/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#65 /var/www/mysiten.org/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#66 /var/www/mysiten.org/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#67 /var/www/mysiten.org/web/core/lib/Drupal/Core/DrupalKernel.php(709): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#68 /var/www/mysiten.org/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#69 {main}
```5.61.0https://lab.civicrm.org/dev/core/-/issues/2629Participant Status: pending refund can have two conflicting meanings2024-01-17T05:03:29Zmagnolia61Participant Status: pending refund can have two conflicting meaningsOverview
----------------------------------------
With partial payments and partial refunds becoming mainstream in CiviCRM, I think it is time to reconsider the connection between contribution status and participant status. I think there...Overview
----------------------------------------
With partial payments and partial refunds becoming mainstream in CiviCRM, I think it is time to reconsider the connection between contribution status and participant status. I think there are more than one aspects of this, but I will focus on 'pending refund'
Example use-cases
----------------------------------------
1. change the payment or price-set to make a partial refund necessary
2. cancel the participant to make a (partial) refund necessary
Current behaviour
----------------------------------------
Currently a participant status: Pending Refund defaults as a positive count.
But there are two scenario's that can cause this participant status:
1. there is a contribution total that is higher than the total event fee amount
2. there has been a cancellation for the event and the fee is pending to be refunded
In scenario 1: The participant is still expected to attend the event
In scenario 2: The participant will not attend the event
Proposed behaviour
----------------------------------------
I think it is becoming troublesome to relate the contribution status with the event status.
The default is that 'Pending refund' counts positive towards attendance.
Two proposals could be
a) to remove participant statuses connected with the contribution
- may cause other difficulties, might me the best in the long end
b) to add a new status and to differentiate between two types of pending refund scenarios:
- Pending refund (cancelled)
- Pending refund (attending)
First one would have count status 0, second one count status 1
Comments
----------------------------------------
Any thoughts on this one? Can I find agreement on this proposal?https://lab.civicrm.org/dev/core/-/issues/3395Separate out Search participant register form from backoffice form2024-01-14T05:03:27ZeileenSeparate out Search participant register form from backoffice formThe form you reach when selecting 'Register participant' from contact search is the same as participant edit or create for a single participant. This creates a few problems
1) AdditionalPayment form is extending the Task class purely to...The form you reach when selecting 'Register participant' from contact search is the same as participant edit or create for a single participant. This creates a few problems
1) AdditionalPayment form is extending the Task class purely to support this form
2) This form is calling CRM_Contact_Form_Task::preProcessCommon($this); - which is one of 2 places the static-ness of that function is locked in. By using a static method the expectations around the forms become much harder to track
3) Lots of hard-to-read if-else
Part of the reason for how it is I think is the focus on 'preProcess' as the action. Since that is often blocked using a different action seems to make sense allowing us to switch to $form->preProcessTask as the preferred method & extract out parts of that function (knowing they are accessible since $form is potentially 'any' form & is not restricted to an interface ). We could go down the interface path but that requires us to understand all the classes & methods & properties involved so it feels like an end goal rather than a step - how we re-wind the wool once unknotted)
![Screen_Shot_2020-09-16_at_4.11.12_PM](/uploads/562ff062b7de80d83fc30ffa4ab0bb11/Screen_Shot_2020-09-16_at_4.11.12_PM.png)https://lab.civicrm.org/dev/core/-/issues/3355Error when using cart and Stipe payment processor2024-01-06T05:03:25Zjorich_2000Error when using cart and Stipe payment processorCompleting transaction from the cart with Stripe causes the following error:
Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details a...Completing transaction from the cart with Stripe causes the following error:
Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred.
Attemted to setCurrency with a value that was not an ISO 3166-1 alpha 3 currency code
Th payment has been processed by Stripe and a stripe receipt issued
The same event with the cart disabled and all the same personal details works okhttps://lab.civicrm.org/dev/core/-/issues/4833Authorize.net webhooks fail, because processor expects Integer for x_invoice_...2024-01-05T03:42:40ZAllenShawAuthorize.net webhooks fail, because processor expects Integer for x_invoice_num, while some have 20-character alphanumericI have a situation in which some Authorize.net ARB webhook notifications are not being processed successfully.
This appears to be because:
- CiviCRM expects an integer for the webhook value of x_invoice_num
- These webhooks have a 20-ch...I have a situation in which some Authorize.net ARB webhook notifications are not being processed successfully.
This appears to be because:
- CiviCRM expects an integer for the webhook value of x_invoice_num
- These webhooks have a 20-character alphanumeric string (e.g. "512def29489e1bcc8856") for this value.
More details:
- Affected recurring contributions were all created before Nov 2021
- This x_invoice_num string (e.g. "512def29489e1bcc8856") does appear in the database, only in these places:
- `civicrm_contribution` for the first contribution in the recurring series:
- civicrm_contribution.invoice_id contains a 32-character alphanumeric string, the first 20 characters of which are this x_invoice_num value
- civicrm_contribution.trxn_id contains two strings, joined by a comma; the first is this x_invoice_num value; the second is an integer which appears to be an FK to civicrm_financial_trxn.order_reference.
Technical assessment:
1. I'm guessing that older civicrm versions used to handle things this way (passing 20-character alphanumeric to Authorize.net, so that it gets returned in webhook's x_invoice_num value), and that way of things has changed at some point since Nov 2021.
I can work on a PR, but first I thought someone might know of a previous issue/commit that removed some code relevant to this process.
I'm at the sprint now and aim to work on a fix either way.
(Joinery reference: F#1270)5.70.0https://lab.civicrm.org/dev/core/-/issues/1402Inconsistent behaviour when paying/completing a pending contribution with lin...2023-12-30T05:03:27ZJamie Novick - CompucoInconsistent behaviour when paying/completing a pending contribution with linked membershipOverview
----------------------------------------
CiviCRM has inconsistent behaviour when completing a pending contribution with linked pending membership either by a) completing the contribution or b) recording a payment.
This applie...Overview
----------------------------------------
CiviCRM has inconsistent behaviour when completing a pending contribution with linked pending membership either by a) completing the contribution or b) recording a payment.
This applies to both a "new/pending" membership or when renewing an expired membership.
Reproduction steps
----------------------------------------
Scenario 1: New membership
----------------------------------------
Create a membership with start date 1/1/2019 and term 1 year.
Set the membership status to anything.
Set the contribution status to pending.
Save
Scenario 1.1: Record payment
If you completed the payment using “Record Payment” and no matter what you set the receive date to during completing the payment the end date and the start date will remain the same (start date = 1/1/2019 , end date = 31/12/2019).
Scenario 1.2: “Edit Contribution -> change status to completed"
While completing the payment using “Edit Contribution -> change status to completed” will result in changing the membership start date to equal the contribution receive date and the end date to be 1 term away from the receive date, so if you set the receive date for example to 1/3/2019 then the start date will become 1/3/2019 and the end date 29/2/2020
Scenario 2. Renew membership that has expired (end date in the past)
----------------------------------------
Create a membership with start date 1/1/2018 and term 1 year.
Set the membership status to anything. It will be created as an expired membership.
Set the contribution status to completed.
Save
Scenario 2.1: Record payment
If you complete the renewal pending payment using “Record Payment” option, then no matter what you set the payment receive date to, the start date will change to “today's date” and the end date will be one 1 term after the start date
Scenario 2.2: “Edit Contribution -> change status to completed"
If you complete the payment with “edit contribution -> change status to completed” then also here Civi ignores the the receive date and it will always set the start date to “today's date” and the end date to 1 term after the start date.
Expected behaviour
----------------------------------------
Well, they should at least be consistent... but perhaps this is our opportunity to make CiviCRM less opaque and give users control over how the system should work?
| Scenario no | Situation | Recording payment approach | Current behaviour | Suggested behaviour |
| ------ | ------ | ------ | ------ | ------ |
|1.1| New | Record payment | Start date will remain as before | Message 1 below
|1.2| New | Edit Contribution -> change status to completed | Changes the membership start date to equal the contribution receive date | Message 1 below
|2.1| Renew expired | Record payment | The start date will change to “today's date” and the end date will be one 1 term after the start date | Message 2 below
|2.2| Renew expired | Edit Contribution -> change status to completed | Set the start date to “today's date” and the end date to 1 term after the start date. |Message 2 below
Message 1:
Show a message / popup to tell ask the user "The membership payment has been made in full, but the membership's start date is different to the payment date. Would you like to set the membership start date to the payment date?
1. Option 1: Yes - Set Membership Start Date to the payment date (**Show the proposed start date if using the payment date**) This would be the date of the last payment if recording the payment OR the contribution received date if completing the contribution by changing the status.
1. Option 2: No - Do not change the membership start date (**Show the existing start date**)
Message 2:
Show a message / popup to tell ask the user "The membership payment has been made in full. Please select a start date:
1. Option 1: Set Membership Start Date to the previous membership term end date
1. Option 2: Set Membership Start Date to the payment date (**Show the proposed start date if using the payment date**) This would be the date of the last payment if recording the payment OR the contribution received date if completing the contribution by changing the status.
1. Option 3: Create a new membership line with Membership start date on the payment date (**Show the proposed start date if using the payment date**) This would be the date of the last payment if recording the payment OR the contribution received date if completing the contribution by changing the status.
In future we could allow admin to have a setting to set the defaults and hide the message to define the behaviour.
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.21 etc
Comments
----------------------------------------
This isn't the place for the long discussion about it but just to reiterate that I think the contribution "received" date field needs the label changed to be something more generic like "contribution date" as the field is used as the invoice date when generating an invoice (and cannot mean received date when the contribution is pending...). It also leads to inconsistencies with the above - the date of the last payment could be different from the contribution received date which is a meaningless statement. We should decouple "payment" from the order or invoice object (the contribution) and make the payments mean what they mean - when we got the payment - and the order/invoice mean what is means - when the contact entered into the obligation to pay from an accounting perspective.
Oh well seems I started a discussion on that here: https://lab.civicrm.org/dev/core/issues/1403#note_27422 and a decision on how the above should work should be done once the contribution date field usage is confirmed.https://lab.civicrm.org/dev/core/-/issues/3086Paypal declines recurring payments with wrong decimal delimiter2023-11-30T05:03:15ZMatthiasKPaypal declines recurring payments with wrong decimal delimiterOverview
----------------------------------------
Recurring paypal payments wont work if the "Decimal Delimiter" is not set to "." which is the usual the case in germany. This happend when using the payment processor "PayPal - Website Pa...Overview
----------------------------------------
Recurring paypal payments wont work if the "Decimal Delimiter" is not set to "." which is the usual the case in germany. This happend when using the payment processor "PayPal - Website Payments Standard".
Example use-case
----------------------------------------
1. Click on **Administer -> Localisation -> Languages, Currency, Locations **.
2. Set "Decimal Delimiter" to "," (common decimal delimiter in germany)
3. Configure Paypal as payment processor with payment processor type "PayPal - Website Payments Standard"
4. Configure an event that requires recurring payments and allow payments via paypal
Current behaviour
----------------------------------------
At the moment recurring payments are only possible if the "Decimal Delimiter" is set to ".". This results in problems and misunderstandings for accounting and when paying contributions.
Proposed behaviour
----------------------------------------
The paypal implementation is done in ** Core/Payment/PayPalImpl.php **. Maybe it could be checked if the "Decimal Delimiter" is set to "." before sending the request to paypal and change it if its not the case.https://lab.civicrm.org/dev/core/-/issues/4553PropertyBag.php propMap errors2023-09-12T13:20:44ZtreseroPropertyBag.php propMap errors## Overview
Using Stripe (not sure of other processors), email throws error in PropertyBag.php
## Reproduction steps
1. Create event and checkout
2. When using email (and I assume other fields that have similar many-many relations), i...## Overview
Using Stripe (not sure of other processors), email throws error in PropertyBag.php
## Reproduction steps
1. Create event and checkout
2. When using email (and I assume other fields that have similar many-many relations), it will error out on checkout.
3. The reason is that in \`\`\` protected static $propMap = \[ \`\`\` array is set to email.
4. It needs to be parsed different
## Expected behaviour
_It parses the email submitted and strips the -Primary etc._
Temp fix is note email-Primary pointing to email:
![image.png](/uploads/28d94490221f29292354d0d376c1a627/image.png)
## Comments
_This is a fatal error and will also be an issue for address etc._
I thought about doing a regex like preg_replace('/email.\*$/', 'email'... but that won't work with multiple keys. In my case that's not an issue, but may be for others.https://lab.civicrm.org/dev/core/-/issues/1459Note field in contribution profile exposes unrelated note to donor2023-08-25T05:03:34ZBobSNote field in contribution profile exposes unrelated note to donorOverview
----------------------------------------
If a donor makes a recurring contribution and the profile defined for the contribution page contains a note field, then the receipt for each subsequent payment sent to the donor may displ...Overview
----------------------------------------
If a donor makes a recurring contribution and the profile defined for the contribution page contains a note field, then the receipt for each subsequent payment sent to the donor may display a note from the donor's profile unrelated to any note recorded when the original contribution was made.
Similarly, if a donor makes a recurring contribution and specifies an honoree, and the honoree profile contains a note field, then the receipt for each subsequent payment sent to the donor may display a note from the honoree's profile unrelated to that contribution.
The same problem occurs on a non-recurring contribution, and on the original contribution of a recurring contribution, if either the main profile or the honoree profile contains a note field and that field is left blank. Even if the note field is not left blank, it is possible for the wrong note to be displayed as the displayed note is simply the last note returned from a query of notes associated with the contact, with no relevant sorting criteria.
The particular note displayed is thus indeterminate in all of these cases, but in my testing it has been the last note recorded for the contact (donor or honoree, respectively).
Reproduction steps
----------------------------------------
__Create the Contacts__
1. Create a contact who will be the donor. Add a note: "Existing donor note".
1. Create a contact who will be the honoree. Add a note: "Existing honoree note".
__Create the Contribution Page__
1. Create a contribution page, check the "Honoree Section Enabled" option.
1. Edit the Honoree Profile and add an Individual Note field.
1. On the Profiles tab, select a profile which contains a note field.
1. On the Receipts tab, check the "Enable Email Receipt to Contributor" option, and complete the required fields in that section.
1. Save the contribution form.
__Make the Contribution__
1. Go to the online contribution page (test mode).
1. Specify the above created donor as the donor.
1. Specifying the above created honoree as the honoree.
1. Leave blank the note fields in the main profile and the honoree profile.
Current behaviour
----------------------------------------
The email received by the donor indicates:<br>
"Note(s): Existing donor note" and <br>
"Note(s): Existing honoree note"
Expected behaviour
----------------------------------------
The email received by the donor should indicate:<br>
"Note(s):<br>
"Note(s):<br>
i.e. two blank note fields
Background Information
--------------------------------
This is similar to https://lab.civicrm.org/dev/event/issues/10 which affected the note displayed in events confirmation emails. The fix there was simple -- remove the note field from the email if the submitted note was blank. I suspect that solution, in the case of a non-blank note field submission, unfortunately relies on the same indeterminate query results which generally returns, but is not guaranteed to return, the most recent note for the contact..
In the case of contribution receipts, the problem is compounded by recurring contributions. In this case, even if the indeterminate query happens to return the most recent note, that is not necessarily the note related to the contribution which was made some time in the past.
The best solution, I believe, would involve adding a field to the notes table which ties each note to a particular contribution or event registration, or adding a table analogous to civicrm_uf_join to provide that kind of linkage.
A "poor man's" solution is to simply prevent notes fields from being displayed in contribution receipts. This could be done by adding `unset($fields['note']);` and `unset($profileFields['note']);`, respectively, prior to the calls to getValues in the two Relevant Code functions shown below.
Relevant Code
---------------------------
1. Values from the main profile are retrieved with a call to CRM_Core_BAO_UFGroup::getValues in
CRM/Contribute/BAO/ContributionPage.php::getProfileNameAndFields
1. Values from the honoree profile are retrieved with a call to CRM_Core_BAO_UFGroup::getValues in
CRM/Contribute/BAO/ContributionSoft.php::formatHonoreeProfileFields
Environment information
----------------------------------------
* __CiviCRM:__ _5.20.0_
* __PHP:__ _7.2.25_
* __CMS:__ _Drupal 7.30_
* __Database:__ _MariaDB 10.0_
* __Payment Processor:__ _Paypal Standard_https://lab.civicrm.org/dev/core/-/issues/2643Proposal - Require Civi\Payment\PropertyBag. Partial compatibility break.2023-08-20T05:03:21ZeileenProposal - Require Civi\Payment\PropertyBag. Partial compatibility break.This is a duplication of what I wrote in the dev-digest to explain the compatibility break decision that needs to be made with PropertyBag to the wider community.
As I mentioned in the digest I spend nearly 2 days doing documentation up...This is a duplication of what I wrote in the dev-digest to explain the compatibility break decision that needs to be made with PropertyBag to the wider community.
As I mentioned in the digest I spend nearly 2 days doing documentation updates & research to write this all up but that is the end of my involvement - I won't be reading / commenting on / making decisions on this.
===== FROM dev-digest=============
We have a proposal to change the contract that payment processors have with core and with other extensions. This change will hopefully not cause issues for many sites but if it does it’s likely to result in payment processing breaking.
## The history
It has traditionally been difficult for payment processors, and code calling payment processors, to know what parameters they can expect to receive from the form layer. In fact I think the documentation cleanup I did in preparation for this dev-digest is the first time they were documented. Some of those params have been standardised over the years but it’s still not uncommon to see code ‘testing’ multiple params - eg. authorize.net still checks ‘total_amount’ even though we standardised on ‘amount’ many years ago. The format for the billing fields is pretty funky (‘billing_street_address_5’ where 5 is the location type id for billing).
In late 2019 we looked at adding a bunch of getters to the CRM_Core_Payment class that the other processors inherit - eg. `getBillingStreetAddress()`. However, it turned out some of these might cause breakage (ie stripe had already implemented functions with the same names) and Rich Lott came up with the idea of the PropertyBag - an object that implemented array access that could be passed to doPayment as if it were an array and accessed as if it were an array - allowing us to pass through something more powerful without breaking the contract.
However, as we worked through it we found that we couldn’t just pass out the PropertyBag in place of the $params array and be confident that nothing would break. We can be confident that the vast majority of code will continue working but not 100% of code. Historically, this was mitigated by making the PropertyBag optional - each payment-processor could internally use the PropertyBag (or continue using the array).
## The change
Recently, Matt opened a PR which would pave the way to a full transition to the PropertyBag (https://github.com/civicrm/civicrm-core/pull/20408). The test suites have shown that Authorize.net integration would break if we switch to PropertyBag, so the PR specifically fixes Authorize.net. However, these unit tests are the “canary in the coal mine” - changing the processor to make them pass requires a decision to proceed with a compatibility break which we have avoided making up until now.
It turns out, this compatibility-break can be avoided by altering PropertyBag design (in ways that may or may not be acceptable), but a contract-change would bring other, unavoidable compatibility breakage so the decision must be made at some point.
The community / other mergers must decide if the benefit of the change outweighs the risk. I have detailed below information to assist with that.
## The contract
```php
function doPayment($params, $component);
function hook_alterPaymentProcessorParams($paymentObj, &$rawParams, &$cookedParams);
```
Currently, `doPayment($params)` and `alterPaymentProcessorParams(....$cookedParams)` are references to a PHP array.
The proposal changes `$params` and `$cookedParams` to `PropertyBag` references.
## What still works if we pass a PropertyBag in place of the array
```php
$paymentToken = $params['payment_token'] ?? NULL;
```
Any parameter that the processor is used to accessing as an array key is still available. In addition the newly defined ‘preferred variants’ work.
```php
$paymentToken = $params['paymentToken'] ?? NULL;
```
And the new property methods work ie
```php
$paymentToken = $params->has('paymentToken') && $params->getPaymentToken();
```
## What breaks
Type hinting - eg. in wmf code it turned out we passed $params to an function like
`function parseRecurFields(array $params)` which resulted in a fatal if $params was a PropertyBag
Array functions used on the params array eg. array_merge, array_diff_key etc. The only one of the php array functions that could still work (depending on which approach we use) is array_key_exists. This pattern was hit in Stripe (which I think Matt has now removed)
Iterating through $params. This is the pattern in Authorize.net that is the canary currently up for execution - so for example
```$isRecur = $params[‘is_recur’];```
Will be 1 if it is set but
```php
$myParams = [];
foreach($params as $key => $value) {
$myParams[$key] = $value;
}
```
Will leave `$myParams` as an empty array
What is affected
Matt has done an audit of published payment processors with recent-ish updates and concluded pattern 3 is not present in any of them. I think he would have spotted patterns 1 & 2 as well.
We really can’t do much to audit the prevalence of these patterns in unpublished code (I picked up the type hinting issue in Wikimedia code because I was able to throw the change at the internal CI process). This is an unknown unknown.
## Options
3 ways we can proceed with the property bag:
1. Shoot the canary - accept the 3 forms of breakage discussed. Change the code to not break rather than change property bag to not break the code.
2. Leave the canary alone - but agree to some breakage later - In the course of writing this up I tested whether we could avoid breakage type 3 and I found it was avoidable, at the cost of some strictness (as of writing tests are still running on my preferred variant) and this one has passed tests
3. Resolve to keep property bag as an optional helper class that payment processors can cast to if they want. The input array can be converted by calling
```php
$propertyBag = \Civi\Payment\PropertyBag::cast($params);
```
This means that the propertyBag will never ‘pass the doPayment veil’ but we can potentially use it on both sides of that line. (ie. never break contract)
## Strictness vs helpfulness
I think this is the fundamental tension of the `PropertyBag`. I think we went into it with 2 goals with eventually turned out to be in conflict
- Strictness - get rid of the ‘anything goes’, make it consistent and predictable, create a mechanism to push out deprecation notices to ‘improve coders behaviour’ and allow us to eventually remove weird stuff
- Helpfulness - make it easy for the dev because they ‘all work’. Make the code UI discoverable
Option 2 moves the needle from strictness to helpfulness considerably - since you can simply do
```php
$params = (array) $propertyBag;
```
And you basically have the original array, plus some extra params that are consistent and preferred (option 2 & 3 are not mutually exclusive so this could be the case with option 3 too.)
However, this approach kinda neuters efforts to be strict - ie you can pretty much avoid all the notices that the property bag tries to send you and you can ‘just use it like an array with reliable variables’.
The design for property bag already leans to the side of strictness over usability (e.g if you do `$propertyBag->getBillingSupplementalAddress2()` it will give an error if the value has not been set and there is no IDE-discoverable way to retrieve the submitted credit card expiry date or helpers libraries offer like getting the card expiry year padded to 4 digits). Depending on your point of view being able to circumvent the propertyBag design is an upside or downside of option 2. (Both these strictness over usability decisions were contentious so points of view on the benefits of making it easier to circumvent the property bad design are likely to differ)https://lab.civicrm.org/dev/core/-/issues/2589doPayment vs doDirectPayment and $0 payments - regression, bug or feature?2023-08-07T05:03:23ZAlanDixondoPayment vs doDirectPayment and $0 payments - regression, bug or feature?As per https://github.com/iATSPayments/com.iatspayments.civicrm/issues/362 it appears that the switch from doDirectPayment to doPayment can result in $0 transactions being sent to payment processors.
@mattwire has kindly provided some c...As per https://github.com/iATSPayments/com.iatspayments.civicrm/issues/362 it appears that the switch from doDirectPayment to doPayment can result in $0 transactions being sent to payment processors.
@mattwire has kindly provided some code to handle the issue in this extension, but I wonder if it was intentional, and if so why, and if it should be documented somewhere.
Or whether doPayment should be smarter?https://lab.civicrm.org/dev/core/-/issues/4435Undefined index: payment_type2023-07-24T02:33:18ZJoeMurrayUndefined index: payment_typeOn dmaster I changed default contribution page to purchase memberships so it allowed pay later, went to live page and did a pay later payment for a $100 membership and got (on https://dmaster.demo.civicrm.org/civicrm/contribute/transact?...On dmaster I changed default contribution page to purchase memberships so it allowed pay later, went to live page and did a pay later payment for a $100 membership and got (on https://dmaster.demo.civicrm.org/civicrm/contribute/transact?_qf_Confirm_display=true&qfKey=CRMContributeControllerContribution4dhfkffigym8c4c8k0kos0ko00440gkg8008wss00gowwc8ckw_9868):
Notice: Undefined index: payment_type in CRM_Core_Payment->validatePaymentInstrument() (line 511 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Payment.php).
Dummy Payment processor is only defined payment processor and it is enabled.
Changing Fall Fundraising default event to allow Pay Later, then using Live page to do so, also results in an error on the confirm but not Thank You page (https://dmaster.demo.civicrm.org/civicrm/event/register?_qf_Confirm_display=true&qfKey=CRMEventControllerRegistrationxabxsqxsysgg88scss808ksog0o4okko84cw4ok0s0ss8cgsk_1767):
Notice: Undefined index: payment_type in CRM_Core_Payment->validatePaymentInstrument() (line 511 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Payment.php).5.65.0https://lab.civicrm.org/dev/core/-/issues/2512Recording the payment is not working if we deleted the "New" Membership Status2023-07-22T05:03:29Zahed_compucorpRecording the payment is not working if we deleted the "New" Membership StatusOverview
----------------------------------------
Some Admins will delete the `New` membership status rule and that is possible because CiviCRM allow adding/editing/removing membership status rules.
Reproduction steps
------------------...Overview
----------------------------------------
Some Admins will delete the `New` membership status rule and that is possible because CiviCRM allow adding/editing/removing membership status rules.
Reproduction steps
----------------------------------------
![Peek_2021-04-01_21-46](/uploads/201ca4c8839b920a896b55ea1de026a0/Peek_2021-04-01_21-46.gif)
Current behaviour
----------------------------------------
Recording a payment for a pending membership will not work and CiviCRM will throw the following error.
```
'New' is not a valid option for field status_id
```
Expected behaviour
----------------------------------------
Recording a payment for a pending membership should work.
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.35.1/5.28.3_
PR: https://github.com/civicrm/civicrm-core/pull/19975https://lab.civicrm.org/dev/core/-/issues/2642In Accounting Batch it is not filtered by custom fields2023-07-21T17:11:50ZdmunioIn Accounting Batch it is not filtered by custom fieldsOverview
----------------------------------------
When filtering transactions to be included in a batch, custom field filters do not work.
Reproduction steps
----------------------------------------
1. Click on **Contributions -> Accoun...Overview
----------------------------------------
When filtering transactions to be included in a batch, custom field filters do not work.
Reproduction steps
----------------------------------------
1. Click on **Contributions -> Accounting Batches -> Open Batches**.
2. Click on **Transactions**.
3. Filter transactions by one or more contribution custom fields.5.41.0https://lab.civicrm.org/dev/core/-/issues/2496Api support for afform contribution pages2023-07-17T05:03:23ZeileenApi support for afform contribution pagesAfform what do we need to do to offer Contribution form
Contribution entity - but just basic fields
Payment block
To do the latter we need an api like
PaymentForm with the actions
```
->submit
->getfields
->validate
```
```payment_pro...Afform what do we need to do to offer Contribution form
Contribution entity - but just basic fields
Payment block
To do the latter we need an api like
PaymentForm with the actions
```
->submit
->getfields
->validate
```
```payment_processor_id ``` would be required for each of these (getfields would reply with metadata that would indicate what additional fields are required)
That should be the minimum for a totally basic processor (like paypal std, paypalpro, dummy, payment express, Mollie, Sagepay recurring in Omnipay, some IATS)
All the complexity comes in when we start adding in the js - e.g Stripe, Paypal checkout, some IATS. I think it makes much more sense to get the easy ones working first - but once they are then for phase 2 we will need at minimum
- An api function to get the JS to add with some details about it
- A js object on the pay to return the total_amount from the form - this is something Matt has been working on & would need to be thought through across forms - eg. CRM.PaymentForm.getAmount() should do the same on the angular form and on the core civicrm forms. We probably need to articulate what other functions it may or may not need
On submission we would do
```
Order.create (this can just be the same params as Contribution.create in the initial submit. At minimum it is basically contribution.create with a forced ‘Pending’ status
PaymentProcessor.pay
Payment.create
```
These exist in apiv3 & I think we would use them for nowhttps://lab.civicrm.org/dev/core/-/issues/2447Wrong event fee shown in CiviCRM2023-07-07T05:03:20ZjaapjansmaWrong event fee shown in CiviCRM**Steps to reproduce**
1. Set the localization settings to **decimal separator**: `,` and **thousand separator**: `.`
2. Create a price set with two quantity fields and a drop down.
3. Create an event with only registration and payments...**Steps to reproduce**
1. Set the localization settings to **decimal separator**: `,` and **thousand separator**: `.`
2. Create a price set with two quantity fields and a drop down.
3. Create an event with only registration and payments and select the created price set above
4. Do a registration and a payment. All amounts are correct on the registration screen
5. After you have done a registration check the participant list or the event tab on the contact card. And/or click on view participant. The total amount for the event fee is displayed wrong.
**Screenshot**
Below a screenshot which shows the wrong amount.
![Screenshot_20210309_114606](/uploads/c3150fda8f90aacccfc26b9c50584e92/Screenshot_20210309_114606.png)
**Remarks**
This also happens when you do an event registration from the contact record in CiviCRM.
**Environment**
Drupal 7
CiviCRM 5.37.aplha1 (dmaster)https://lab.civicrm.org/dev/core/-/issues/2433Changing participant to another event fee hangs2023-07-02T05:03:21ZjaapjansmaChanging participant to another event fee hangsChanging a selection on an event registration sometimes hangs.
After changing the selection a few times the wrong amount is displayed in the contact card Event tab and on in the screen on view participant.
**How to reproduce**
1. Creat...Changing a selection on an event registration sometimes hangs.
After changing the selection a few times the wrong amount is displayed in the contact card Event tab and on in the screen on view participant.
**How to reproduce**
1. Create an event with online registration and a fee of $ 12.90 (called Min), $ 200 (called Family) and $ 897,654,321.99 (called Max). Also add a dummy payment processor.
2. Register via online registration and select Max and pay with the dummy payment processor.
3. Now go to the contact card and click Event and click on Edit behind the registration.
4. In the next screen click on Change Selection and change Max to Family.
**Environment**
- _dmaster.demo.civicrm.org_
- Drupal 7
- CiviCRM: 5.36.aplha1https://lab.civicrm.org/dev/core/-/issues/2343“Cancel recurring payment” link missing from receipt when multiple payment pr...2023-06-20T05:03:20Ztapash“Cancel recurring payment” link missing from receipt when multiple payment processor enabledOverview
---------------------------------------
When I enable 1 payment processor like stripe the cancel recurring payment link appears in the receipt without any problem.
But as soon as I enable 2 payment processor the link disappe...Overview
---------------------------------------
When I enable 1 payment processor like stripe the cancel recurring payment link appears in the receipt without any problem.
But as soon as I enable 2 payment processor the link disappears and only shows “this is a recurring contribution “.
Reproduction steps
----------------------------------------
- Enable 2 different payment processor like stripe and Gocardless.
- Signup for a recurring payment with any of payment method.
- Link to cancel recurring is missing.
Expected behaviour
----------------------------------------
A link should appear in the receipt body to cancel the future payment.
Environment information
----------------------------------------
* CiviCRM: 5.33.2
* PHP:7.3
* CMS:Drupal 7.xx
Comments
----------------------------------------
Did not use multiple payment processor previously, so can’t be sure if it’s a regressions bug!https://lab.civicrm.org/dev/core/-/issues/2095Switch "Online Pay now" functionality to payment create API2023-05-15T05:03:21Zmagnolia61Switch "Online Pay now" functionality to payment create APIOverview
----------------------------------------
The Online Pay now functionality where a user can pay towards a contribution still used the old way of recording a payment. The new record payment form is currently only a backend form.
...Overview
----------------------------------------
The Online Pay now functionality where a user can pay towards a contribution still used the old way of recording a payment. The new record payment form is currently only a backend form.
It would be very helpful if the Pay Now switches to use that form but in a frontend user exposed way.
This will help customers to pay via the dashboard and checksum link. Also this will enable frontend customer payments towards partial paid contributions.
Example use-case
----------------------------------------
1. Go to user dashboard
2. Pay a contribution with status pending (status partially paid has no Pay button atm)
3. The contribution is handles via a contribution page and not the record payment form
Current behaviour
----------------------------------------
Online Pay now by user dashboard button or checksum link do not user payment create api
Proposed behaviour
----------------------------------------
Let the (frontend) Pay now use the record payment form but in a frontend way with live payment processors.
Comments
----------------------------------------
References to relevant issues and PR's:<br>
https://github.com/civicrm/civicrm-core/pull/12319<br>
https://github.com/civicrm/civicrm-core/pull/14673