Development issueshttps://lab.civicrm.org/groups/dev/-/issues2018-11-09T20:25:39Zhttps://lab.civicrm.org/dev/core/-/issues/289CiviCase Dashboard link to edit an activity status broken2018-11-09T20:25:39ZGMCVO DatabasesCiviCase Dashboard link to edit an activity status brokenThere is a bug with the CiviCase dashboard
When you click to edit the case activity pencil it crashes with 'required params missing'
Also replicated on the demo site https://dmaster.demo.civicrm.org/civicrm/case?reset=1There is a bug with the CiviCase dashboard
When you click to edit the case activity pencil it crashes with 'required params missing'
Also replicated on the demo site https://dmaster.demo.civicrm.org/civicrm/case?reset=15.5.0https://lab.civicrm.org/dev/core/-/issues/290If locationType name/label are different, for non-billing locations, the cont...2022-09-10T05:03:24ZbgmIf locationType name/label are different, for non-billing locations, the contribution form will not pre-populate known fieldsHow to reproduce:
* Login on https://dmaster.demo.civicrm.org
* Go to the contact record of the demo user, and enter a "Home" address
* https://dmaster.demo.civicrm.org/civicrm/contact/view?reset=1&cid=203
* Configure this contrib for...How to reproduce:
* Login on https://dmaster.demo.civicrm.org
* Go to the contact record of the demo user, and enter a "Home" address
* https://dmaster.demo.civicrm.org/civicrm/contact/view?reset=1&cid=203
* Configure this contrib form, in Profiles, select the "Name and Address" profile (it includes the 'Home' address):
* https://dmaster.demo.civicrm.org/civicrm/admin/contribute/custom?reset=1&action=update&id=1
* Witness how it will correctly pre-populate the Home address on the contrib form:
* https://dmaster.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=1
![Capture_d_écran_de_2018-07-27_17-50-57](/uploads/aa17899d9a177a0f4b1e482d2308d8fc/Capture_d_écran_de_2018-07-27_17-50-57.png)
That works because the name = label. Let's change the label of the Location Type:
* Change the Location Type label of "Home" to "Home2"
* https://dmaster.demo.civicrm.org/civicrm/admin/locationType?reset=1
* Go back to the contribution form and witness how it does not show the address anymore :-)
![civi-location-types](/uploads/8faf552cccd52706f6c782f72fd60ae8/civi-location-types.png)
![Capture_d_écran_de_2018-07-27_17-52-23](/uploads/97e1f638b9a92c80c06aa63526a58140/Capture_d_écran_de_2018-07-27_17-52-23.png)
:tada: :grimacing:https://lab.civicrm.org/dev/core/-/issues/291Allow password field sizes to be set in props a la text fields2018-07-30T00:43:07ZseamusleeAllow password field sizes to be set in props a la text fieldshttps://lab.civicrm.org/dev/core/-/issues/292Search builder stops working after 5.3.1 (due accents on custom set fields ti...2019-02-05T22:12:59ZfrancescbassasSearch builder stops working after 5.3.1 (due accents on custom set fields titles)After 5.3.1 upgrade Search Builder jQuery interaction stops working. I could find the reason, seems that custom set title with accents break the Search Builder form.
How to test?
On dmaster go to https://dmaster.demo.civicrm.org/civicrm...After 5.3.1 upgrade Search Builder jQuery interaction stops working. I could find the reason, seems that custom set title with accents break the Search Builder form.
How to test?
On dmaster go to https://dmaster.demo.civicrm.org/civicrm/admin/custom/group?reset=1 and edit a custom set title for example with "Cancelación Suscripción" and save it. Then go to https://dmaster.demo.civicrm.org/civicrm/contact/search/builder?reset=1 and select some -record type- you will notice that no type of operator related to the selected type is suggested.
On the browser console appears this error:
![search-builder-break](/uploads/705047a221ee4fce997ade35a44e645d/search-builder-break.png)5.5.0https://lab.civicrm.org/dev/core/-/issues/3606send test email may create duplicate contacts2022-06-11T14:55:49Zlcdwebsend test email may create duplicate contactsto reproduce:
1. construct a new email
2. in the "send test email to:" field list two email addresses that match existing contacts. separate them with a comma and space
3. trigger the test email
the first email will match the existi...to reproduce:
1. construct a new email
2. in the "send test email to:" field list two email addresses that match existing contacts. separate them with a comma and space
3. trigger the test email
the first email will match the existing contact. the second email will result in a new duplicate contact getting created. the issue is if you have a space after the comma separating the email addresses. the values are not trimmed when parsed, causing a failed match and the creation of a duplicate.5.6lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/293Error log is filled with geocoding configuration errors when no provider is set2018-07-30T19:55:41ZtschuettlerError log is filled with geocoding configuration errors when no provider is setIf no geocoding provider is configured, the civicrm log file is flooded with error messages:
```
[error] Configured geocoder is invalid, must provide a format method
Array
(
[geocode_class] =>
)
```If no geocoding provider is configured, the civicrm log file is flooded with error messages:
```
[error] Configured geocoder is invalid, must provide a format method
Array
(
[geocode_class] =>
)
```5.5.0https://lab.civicrm.org/dev/core/-/issues/294Bulk updated primary memberships don't updated related memberhips.2022-09-03T05:03:49ZtommyboboBulk updated primary memberships don't updated related memberhips.When bulk updating from advanced search a set of primary memberships the update of those memberships does trigger the related memberships to update.
To test.
1. Set up a small number of related memberships.
2. Create a profile to upd...When bulk updating from advanced search a set of primary memberships the update of those memberships does trigger the related memberships to update.
To test.
1. Set up a small number of related memberships.
2. Create a profile to update their end date.
3. Search for the primary memberships.
4. Use the profile to add 1 year to each membership.
5. Look up related memberships, they will not have been updated.
Strangely the related membership will have the correct status for the primary membership, but the wrong date.https://lab.civicrm.org/dev/core/-/issues/295Default 'from' mail address is not the default one showing in 'send email'2018-08-27T11:18:09ZjitendraDefault 'from' mail address is not the default one showing in 'send email'SE Post - https://civicrm.stackexchange.com/questions/25562/why-does-the-default-from-email-address-not-show-as-the-first-option-when-usin
If I add a second email address to the list of "from" emails at /civicrm/admin/options/from_email...SE Post - https://civicrm.stackexchange.com/questions/25562/why-does-the-default-from-email-address-not-show-as-the-first-option-when-usin
If I add a second email address to the list of "from" emails at /civicrm/admin/options/from_email_address?reset=1 and set it to default, i expect it to be selected as the first option when using "Send an Email' but it continues to be the second in the list.
If i change the Order of the From emails so my default is first, it continues to show as the second when using "Send an Email' (though perhaps a clear of caches would fix it, but fundamentally something seems wrong here.jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/296api - CustomValue::get - return multiple fields fails via api explorer2018-08-02T09:25:10Ztschuettlerapi - CustomValue::get - return multiple fields fails via api explorerThe API call fails with error message when using the api explorer:
![image](/uploads/142b60a1551c11bf34f32b47bd9ae42e/image.png)
```
{
"is_error": 1,
"error_message": "'name' specified in OR group but not added to params"
}
```...The API call fails with error message when using the api explorer:
![image](/uploads/142b60a1551c11bf34f32b47bd9ae42e/image.png)
```
{
"is_error": 1,
"error_message": "'name' specified in OR group but not added to params"
}
```
The generated PHP-Code however does produces the expected results.https://lab.civicrm.org/dev/core/-/issues/297permission "access my cases and activities" is broken by CRM-214612018-08-28T01:29:10ZDaveDpermission "access my cases and activities" is broken by CRM-21461See https://civicrm.stackexchange.com/questions/25950/problem-with-civicase. CRM_Case_BAO_Case::getCases() used to return a list keyed on case_id. Now it returns a sequentially keyed list. I'm not sure if anything new is depending on the...See https://civicrm.stackexchange.com/questions/25950/problem-with-civicase. CRM_Case_BAO_Case::getCases() used to return a list keyed on case_id. Now it returns a sequentially keyed list. I'm not sure if anything new is depending on the new keys, but since that seems unlikely, replacing "$key" with "$case['case_id']" around line 680 and later instances would fix this?https://lab.civicrm.org/dev/core/-/issues/298API Explorer shows incorrect syntax for arrays via drush/cv2023-06-24T05:03:19ZJonGoldAPI Explorer shows incorrect syntax for arrays via drush/cvThe problem I'm seeing is displayed in the attached screenshot. When you create an API call with API Explorer that requires the use of an array, API Explorer adds the array, JSON-encoded, to the argument list. However, neither drush no...The problem I'm seeing is displayed in the attached screenshot. When you create an API call with API Explorer that requires the use of an array, API Explorer adds the array, JSON-encoded, to the argument list. However, neither drush nor cv (and I assume wp-cli) will parse the argument as an array. This has tripped up multiple folks on Stack Exchange ([1](https://civicrm.stackexchange.com/questions/10887/can-i-chain-api-calls-through-drush), [2](https://civicrm.stackexchange.com/questions/16423/passing-json-objects-to-drush-cvapi)).
As answers to those SE questions point out, it IS possible to use drush/cv and encode arrays. Instead of:
```
cv api Contact.create contact_type="Individual" first_name="Jon" options={"match":"first_name"}
```
We could do:
```
echo '{"contact_type":"Individual","first_name":"Jon","options":{"match":"first_name"}}' | cv api Contact.create --in=json
```
There are three solutions of increasing effort, depending on how important folks think this is. I'm willing to do the first one, and someone else can do 2 or 3 if they feel it's important.
1) Patch API Explorer so drush/cv/wp always show the (more complex) `echo foo | cv api bar.baz --in=json` syntax.
2) Patch API Explorer so drush/cv/wp show the more complex syntax when an array is present (I can do this if it's simple, I'd have to look).
3) Patch drush/wp/cv to match API Explorer.
![Selection_544](/uploads/1335415c85a5e6aaf9f185c023ce4c25/Selection_544.png)https://lab.civicrm.org/dev/core/-/issues/299Decimal point error.2018-08-28T21:41:11ZmarcineqDecimal point error.When I try to register a payment for contribute "pending", automatically in the "amount" field instead of the set decimal point "," "." Appears.
The problem hinders the work, because I have to manually correct it with "," although it app...When I try to register a payment for contribute "pending", automatically in the "amount" field instead of the set decimal point "," "." Appears.
The problem hinders the work, because I have to manually correct it with "," although it appears correctly next to it.
The error also appears when I want to edit the "completed" payment - by changing the payment method - the problem with writing, because the wrong separator.
I tried to change to "." but then it does not pass "," written from habit in Poland.
I noticed the error on Drupal 7.59, CiviCRM 5.3.1 on two independent versions.
I also played it right after installing "fresh" and changing the decimal separator in the location settings.
Please forgive me for passing with Polish translation, but my English is not very good, I prefer to use CiviCRM in my language.
![1](/uploads/2b98e3a599901c060afac3eaf17203fa/1.png)
![2](/uploads/da7181c616936e0bc1bd34f278b548ed/2.png)
Second issue with decimal pointer.
![b2_1](/uploads/c0e6a8688af063e5b14b8c520d639682/b2_1.png)
![b2_2](/uploads/cbb75f1a1ca00fa9f4aedbf2da9c4721/b2_2.png)
![b2_3](/uploads/d15d726313e38e75097ebed1f902a04c/b2_3.png)
![b2_4](/uploads/06257bd92c0577065ffcf01bdf0b78d6/b2_4.png)5.6https://lab.civicrm.org/dev/core/-/issues/300Proposal - Attach cross-cms "page identifier" class to <body>2022-11-30T05:03:31ZAkA84Proposal - Attach cross-cms "page identifier" class to <body>## Problem
Currently there is no consistent way in Civi to tell which page you are on by querying the DOM. Usually this is done by having a class attached to the `<body>` tag that identifies the current page. Unfortunately each CMS use d...## Problem
Currently there is no consistent way in Civi to tell which page you are on by querying the DOM. Usually this is done by having a class attached to the `<body>` tag that identifies the current page. Unfortunately each CMS use different naming conventions, or attaches no class at all.
For example: this is the Contact Summary page's `<body>` tag on each CMS
```html
<!-- Drupal: .page-civicrm-contact-view -->
<body class="html not-front ... page-civicrm page-civicrm-contact page-civicrm-contact-view">
<!-- Joomla: .task-civicrmcontactview -->
<body class="admin com_civicrm ... task-civicrmcontactview">
<!-- Wordpress: none :( -->
<body class="wp-admin wp-core-ui ... customize-support svg”>
```
## Proposed solution
Civi should attach "proprietary" classes to `<body>`, independent from the underlying cms, so we would have something like
```html
<!-- Drupal -->
<body class="html not-front ... page-civicrm page-civicrm-contact page-civicrm-contact-view civi-page-contact-view">
<!-- Joomla -->
<body class="admin com_civicrm ... task-civicrmcontactview civi-page-contact-view">
<!-- Wordpress -->
<body class="wp-admin wp-core-ui ... customize-support svg civi-page-contact-view”>
```
## Why
It would open new cross-cms customization avenues for devs: styles applied only a specific page, JS plugins that use the body class to bootstrap itself or perform an action only on certain pages, etc.
Of course currently one can already inject a css/js file on specific pages by using `hook_civicrm_pageRun()`, but this approach lacks the flexibility that the proposed solution would instead provide.
## Technical challenges
I figured that there would be at least two:
1. Find a way in all 3 cms to alter the list of classes attached to `<body>` that _doesn't_ involve using a theme hook, given that this solution should be both cms and theme agnostic (you don't want those classes to disappear the moment an admin decides to change the administration theme)
2. Figure out how to programmatically generate the class name for each individual civi page
---
Before opening the issue I asked in the dev channel if there was already a way to identify a page that I wasn't aware of (https://chat.civicrm.org/civicrm/pl/of6xsr17sidujmm1tuasr8bupy), but apparently there isn't, at least not the in the way I'm proposing herehttps://lab.civicrm.org/dev/core/-/issues/301Dedupe ignores phone number from Drupal-Webforms and Contact Import depending...2020-12-03T23:49:48ZBobSDedupe ignores phone number from Drupal-Webforms and Contact Import depending on Civi version at rule creationOld rules found in table civicrm_dedupe_rule specify the rule_field 'phone', while rules created in more recent versions of Civi specify 'phone_numeric'.
In addition, there is some inconsistency in how the phone value is received in the...Old rules found in table civicrm_dedupe_rule specify the rule_field 'phone', while rules created in more recent versions of Civi specify 'phone_numeric'.
In addition, there is some inconsistency in how the phone value is received in the $params arguement of CRM/Dedupe/Finder.php:dupesByParams:
* webform_civicrm passes:<br>
`$params['civicrm_phone']['phone'] = "123-456-7890" (raw text string)`
* Contact import passes:<br>
`$params['civicrm_phone']['phone_numeric'] = "123-456-7890" (raw text string)`
In the dupesByParams function, there is a block which replaces the ['phone_numeric'] value with its numeric version, but there is no creation of ['phone_numeric'] if there exists only ['phone'].
This results in two conditions in which dedup ignores the phone number:
1. Webform submissions with new rules, because the rule specifies['phone_numeric'].
2. Contact import with old rules, because the rule specifies ['phone'].
I propose two changes to solve both these problems:
1. Upon upgrade, replace all occurences of 'phone' in civicrm_dedupe_rule.rule_field with 'phone_numeric'.
2. If passed only ['phone'] and not ['phone_numeric'], create the latter as shown in the following patch (based on the current Jun 11 917acf6 commit):
```
--- 917acf6/CRM/Dedupe/Finder.php
+++ new/CRM/Dedupe/Finder.php
@@ -146,6 +146,9 @@
}
$params['check_permission'] = CRM_Utils_Array::value('check_permission', $params, TRUE);
+ if (isset($params['civicrm_phone']['phone']) && !isset($params['civicrm_phone']['phone_numeric'])) {
+ $params['civicrm_phone']['phone_numeric'] = $params['civicrm_phone']['phone'];
+ }
if (isset($params['civicrm_phone']['phone_numeric'])) {
$orig = $params['civicrm_phone']['phone_numeric'];
$params['civicrm_phone']['phone_numeric'] = preg_replace('/[^\d]/', '', $orig);
```
Problems identified and solution tested in Civi 5.4.0.https://lab.civicrm.org/dev/core/-/issues/302End of life plans for 5.x php versions & planning for 7.0 EOL2020-01-30T02:01:26ZeileenEnd of life plans for 5.x php versions & planning for 7.0 EOLWe have had some discussion about EOL on php 5.x versions. The text below is a proposed blog post:
**End of life plans for 5.x php versions & planning for 7.0 EOL **
This blog serves as advance notice of our intention to stop supportin...We have had some discussion about EOL on php 5.x versions. The text below is a proposed blog post:
**End of life plans for 5.x php versions & planning for 7.0 EOL **
This blog serves as advance notice of our intention to stop supporting php versions 5.5, 5.6 and our ongoing evaluation of 7.0.
For php 5.5 we intend to end support in January 2019. This is already unsupported by php and we strongly recommend you upgrade off it as soon as possible. The release in February 2019 will be the first release that does not support php 5.5
For php 5.6 our TARGET is to end support in September 2019 (Oct release would support php 7.0+). 5.6 and 7.0 will unsupported by php from the end of this year. Usage of these versions is still pretty high amongst CiviCRM users http://stats.civicrm.org/?tab=sites so we will review this target in the first quarter of next year & extend it if we feel it will cause undue pain. Supporting 5.6 has downsides in that it restricts the external packages and versions of those packages we can use. As time goes on the risk of it leaving us without a secure option increases, as well as reducing opportunities to use more modern packages and to improve our code and product.
For php 7.0 our TARGET is the end of 2019. We will be reviewing this in March as well to see how reasonable that is. There is less to gain from dropping 7.0 than 5.6 so we will take that into account.
**What version of php should you be using?**
In general you should aim to be on php 7.1 or 7.2. For drupal 7 users you may find that there are extensions that you rely on that do not yet support php 7.1 - although this will be less and less likely over time. See https://www.drupal.org/docs/7/system-requirements/drupal-7-php-requirements#php_required for more information.
Note that as of writing there are only a small number of sites on 7.2 http://stats.civicrm.org/?tab=technology so you may wish to check php 7.2 adoption stats before choosing php 7.1 over php 7.2 in case there are any remaining issues.https://lab.civicrm.org/dev/core/-/issues/303Print/Merge Document to HTML uses PHPWord to process the HTML - is this meant...2022-08-28T05:03:34ZAndrew WestPrint/Merge Document to HTML uses PHPWord to process the HTML - is this meant to happen?In 'Print/Merge Document' you can select to output to HTML. In practice, this processes the HTML via PHPWord. This seems to mangle it quite badly: div tags get converted into text (it literally says 'div'), styling gets removed, etc. I'm...In 'Print/Merge Document' you can select to output to HTML. In practice, this processes the HTML via PHPWord. This seems to mangle it quite badly: div tags get converted into text (it literally says 'div'), styling gets removed, etc. I'm not sure whether this is deliberate or not, but there's an easy alternative that seems to work well.
The conversion starts in CRM_Contact_Form_Task_PDFLetterCommon. If we want to export anything other than a PDF it's sent to CRM_Utils_PDF_Document::html2doc(), which uses PHPWord. But I'm wondering if it makes more sense to actually use the PDF route for HTML - this goes via CRM_Utils_PDF_Utils::html2pdf().
html2PDF works by generating HTML pages for the PDF processor. So it produces an elegant HTML document by itself anyway. It does some basic processing like removing header tags, applying the appropriate margins, and applying print.css. But other than that the HTML is untouched. It's very easy just to output the HTML before the final step of converting to PDF.
I have this working here, and I can make it into an extension easily enough (though it'd need to override core files). But as the HTML output functionality doesn't really seem to work like I'd expect, I thought I'd flag it here. I can put the changes into a PR if that'd help.https://lab.civicrm.org/dev/core/-/issues/304Upgrade from 4.7.27 to 5.4.0 failed on activity_default_assignee (also 5.3.2 ...2018-08-22T13:29:57ZdavejUpgrade from 4.7.27 to 5.4.0 failed on activity_default_assignee (also 5.3.2 failed on Monmouthshire)Trying to upgrade a test site from 4.7.27 using drush cvupdb. D7, PHP 5.6.36, MySQL 5.5.60 . Cleared templates_c/en_* before upgrading.
4.7.27 to 5.4.0 fails with:
```
CiviCRM_API3_Exception: "'activity_default_assignee' is not a valid ...Trying to upgrade a test site from 4.7.27 using drush cvupdb. D7, PHP 5.6.36, MySQL 5.5.60 . Cleared templates_c/en_* before upgrading.
4.7.27 to 5.4.0 fails with:
```
CiviCRM_API3_Exception: "'activity_default_assignee' is not a valid option for field option_group_id"
#0 .../sites/all/modules/civicrm/CRM/Core/BAO/OptionValue.php(560): civicrm_api3("OptionValue", "get", (Array:4))
#1 .../sites/all/modules/civicrm/CRM/Upgrade/Incremental/php/FiveFour.php(108): CRM_Core_BAO_OptionValue::ensureOptionValueExists((Array:5))
#2 [internal function](): CRM_Upgrade_Incremental_php_FiveFour::addActivityDefaultAssigneeOptions(Object(CRM_Queue_TaskContext))
#3 .../sites/all/modules/civicrm/CRM/Queue/Task.php(88): call_user_func_array((Array:2), (Array:1))
1:31 PM
```
version in civicrm_domain at this point is 5.4.alpha1.upgrade . I re-tried, dropping db & restoring from pre-upgrade dump, same result.
Also a less serious issue, as presumed due to someone manually adding Monmouthshire to db in the past...
4.7.27 to 5.3.2 fails with:
```
PEAR_Exception: "DB Error: already exists"
* ERROR TYPE: DB_Error
* ERROR CODE: -5
* ERROR MESSAGE: DB Error: already exists
* ERROR MODE: 16
* ERROR USERINFO: INSERT INTO civicrm_state_province (country_id, abbreviation, name)
VALUES (@UKCountryId, 'MON', 'Monmouthshire') [nativecode=1062 ** Duplicate entry 'Monmouthshire-1226' for key 'UI_name_country_id']
* ERROR DEBUGINFO: INSERT INTO civicrm_state_province (country_id, abbreviation, name)
VALUES (@UKCountryId, 'MON', 'Monmouthshire') [nativecode=1062 ** Duplicate entry 'Monmouthshire-1226' for key 'UI_name_country_id']
#0 [internal function](): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#1 .../sites/all/modules/civicrm/packages/PEAR.php(921): call_user_func((Array:2), Object(DB_Error))
#2 .../sites/all/modules/civicrm/packages/DB.php(985): PEAR_Error->__construct("DB Error: already exists", -5, 16, (Array:2), "INSERT INTO civicrm_state_province (country_id, abbreviation, name)\nVALUES (...")
```
version in civicrm_domain is 5.3.0.upgrade at this point.
I suspect Monmouthshire had previously been added manually. Resolved by manually removing it, setting the existing address records using it to state_province_id NULL, then to the new id.
Then tried 5.3.2 to 5.4.0 and it worked.https://lab.civicrm.org/dev/core/-/issues/305Event contribution cancellation should cancel all guest participants' registr...2018-08-07T10:14:06Zrita_compucorpEvent contribution cancellation should cancel all guest participants' registration recordWhen you register multiple participants for an event and then you cancel the contribution, you would expect all related guest participants' event registration record to be cancelled, not only the main contact's registration since you hav...When you register multiple participants for an event and then you cancel the contribution, you would expect all related guest participants' event registration record to be cancelled, not only the main contact's registration since you have cancelled the whole payment.
Steps:
- create an event with a fee
- enable the multiple participant registration for the event
- then as anonymous person go and register multiple people for the event (participant 1 - main contact, participant 2 - guest contact)
- then go to the main contact (who has paid for the event) and Cancel the contribution
- ![multi_event_reg](/uploads/5e5d2c41f8e9699c58fd9ef27e0bb013/multi_event_reg.gif)after this the main contact's event registration record gets cancelled automatically
--> you would expect to get all related participants' registration get cancelled (both (participant 1 - main contact, participant 2 - guest contact 1 should get cancelled)https://lab.civicrm.org/dev/core/-/issues/306Main payment method is not getting updated after modifying it in payment details2023-01-22T05:03:42Zrita_compucorpMain payment method is not getting updated after modifying it in payment detailsWhen you create a contribution with payment method A and then go and change the payment method to B, on the main contribution it will still show the payment method A instead of B.
Steps:
- create a new contribution with Payment Method:...When you create a contribution with payment method A and then go and change the payment method to B, on the main contribution it will still show the payment method A instead of B.
Steps:
- create a new contribution with Payment Method: Check http://nimb.ws/3HN4qv
- then go and edit the contribution, change the payment method using the Pen icon on the payment detail
- change the payment method to Cash
- save it, and save the contribution too
- then open to View the contribution and you can see the changed payment details, but the main contribution's payment method is still Check and not Cash http://nimb.ws/FOUCj9
--> the main Payment Method field should reflect the modified payment method, not the original onehttps://lab.civicrm.org/dev/core/-/issues/307Error on Contribution API 'transact' action2021-02-01T01:10:25ZjackrabbithannaError on Contribution API 'transact' actionAt least with the Dummy payment processor, Contribution API, transact action calls are failing with:
ResponseText: Fatal error: Call to a member function doPayment() on null in ..../civicrm/api/v3/Contribution.php on line 435
line 434
...At least with the Dummy payment processor, Contribution API, transact action calls are failing with:
ResponseText: Fatal error: Call to a member function doPayment() on null in ..../civicrm/api/v3/Contribution.php on line 435
line 434
$paymentProcessor = CRM_Financial_BAO_PaymentProcessor::getPayment($params['payment_processor'], $params['payment_processor_mode']);
returns null instead of an object
This is accompanied with a notice:
Notice: Undefined offset: 1 in CRM_Financial_BAO_PaymentProcessor::getPayment() (line 221 of ...../civicrm/CRM/Financial/BAO/PaymentProcessor.php).
Testing against Version 5.4.0, not sure if this was around in previous 5.x versions, but worked in 4.7.30
Parameters being passed to transact call:
```
Array
(
[receive_date] => 20180806133730
[skipLineItem] => 1
[sequential] => 1
[financial_type_id] => 2
[total_amount] => 25.5
[contact_id] => 203
[payment_processor] => 1
[payment_processor_id] => 1
[credit_card_number] => 4111111111111111
[cvv2] => 123
[month] => 8
[year] => 2020
[invoice_id] => 33ef9bcca73cfa8ebb142da3e7b22433
[source] => CiviCRM Entity Price Set Field -- Event Registration
[billing_first_name] => Mark
[billing_last_name] => Hanna
[currencyID] => USD
[currency] => USD
[is_test] => 1
[version] => 3
[payment_processor_mode] => test
[amount] => 25.5
[net_amount] => 25.5
[invoiceID] => 33ef9bcca73cfa8ebb142da3e7b22433
)
```