Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-11-23T07:09:31Zhttps://lab.civicrm.org/dev/core/-/issues/928Membership and Auto-Renew issues2023-11-23T07:09:31Zmattwiremjw@mjwconsult.co.ukMembership and Auto-Renew issuesOverview
WORK IN PROGRESS Parts of this are gradually being extracted into smaller, easier to review PRs. Once this is fully reviewed and merged documentation will also need updating.
Ref: https://github.com/civicrm/civicrm-core/pull/123...Overview
WORK IN PROGRESS Parts of this are gradually being extracted into smaller, easier to review PRs. Once this is fully reviewed and merged documentation will also need updating.
Ref: https://github.com/civicrm/civicrm-core/pull/12315
This is mostly code cleanup and an attempt to understand exactly what happens when a membership is automatically renewed!
# Fixes (and this needs adding to Civi docs somewhere as it's currently undocumented and unclear what it does):
## Before
* Membership will be renewed when contribution is in ANY state except "Pending."
* All parameters of recurring contribution are ignored, ie installments, frequency mismatch (eg. monthly recurring, annual membership) so every new contribution will trigger a membership renewal.
* When repeattransaction is called ONLY the membership linked to the original contribution will be renewed (if the contribution is in the correct state (ie. Completed - see Before/After)). loadRelatedObjects only loads one membership but the code is expected all memberships to be loaded so does handle multiple memberships if passed in.
## After
* Membership will be renewed ONLY when contribution is in state "Completed".
* Membership will be renewed ONLY if the recurring and membership type frequencies match. Installments parameter has no effect.
* When repeattransaction is called: If the contribution has a recurring contribution ID then ALL memberships linked to that recurring contribution will be renewed. If the contribution has no recurring contribution then the membership linked to the original contribution will be renewed (if the contribution is in the correct state (ie. Completed - see Before/After) AND the other conditions are met (ie. state, frequency)).
## Documentation (After)
* Membership will be renewed ONLY when contribution is in state "Completed" - https://github.com/civicrm/civicrm-core/pull/12315 (5.5.0)
* Membership will be renewed ONLY if the recurring and membership type frequencies match (Installments are ignored).
* When repeattransaction is called any linked memberships will be renewed if the contribution is in the correct state. If there is a recurring contribution then the frequencies must also match (installments are ignored).
* A recurring contribution can be linked to multiple memberships and all memberships will be updated/renewed if all other conditions are met - https://github.com/civicrm/civicrm-core/pull/12542 (pending merge)https://lab.civicrm.org/dev/financial/-/issues/53Always create contribution before processing payment2023-11-23T07:09:31Zmattwiremjw@mjwconsult.co.ukAlways create contribution before processing paymentCurrently there are various different workflows within CiviCRM that handle the creation of contributions in different ways. Sometimes a contribution is created before calling the payment processor BUT sometimes a contribution is only cr...Currently there are various different workflows within CiviCRM that handle the creation of contributions in different ways. Sometimes a contribution is created before calling the payment processor BUT sometimes a contribution is only created after the call to the payment processor - leaving no trace if the payment fails. It is agreed that the *correct* process is to always create a contribution *before* calling the payment processor but it will take some time before CiviCRM core actually does this in all cases.
To process a payment we call `doPayment()` on the payment processor. Any processor that still implements `doTransferCheckout()` or `doDirectPayment()` should be updated to use `doPayment()`.
doPayment
---------
Payment processors should set `payment_status_id` (which is really `contribution_status_id`) in the returned array. The default is assumed to be Pending. In some cases the IPN will set the payment to "Completed" some time later.
This function adds some historical defaults ie. the assumption that if a 'doDirectPayment' processors comes back it completed the transaction & in fact doTransferCheckout would not traditionally come back.
Payment processors should throw exceptions and not return Error objects as they may have done with the old functions.
Contribution Records
---------
Creating a contribution record is inconsistent! We should always create a contribution BEFORE calling doPayment. However currently:
* Contribution Pages: Creates a contribution before calling doPayment.
* Contribution Pages with Membership: Does NOT create a contribution. UNLESS auto-renew=TRUE in which case both a recurring contribution and a contribution is created before calling doPayment.
* Event Registration: Creates a contribution before calling doPayment from CiviCRM 5.14 (see https://github.com/civicrm/civicrm-core/pull/13763, https://github.com/civicrm/civicrm-core/pull/13837 and https://github.com/civicrm/civicrm-core/pull/14435)
* Contribution.transact API - is a mess! And does NOT create a contribution before doPayment, also does NOT use/save the parameters returned from doPayment - see https://github.com/civicrm/civicrm-core/pull/15340 for a proposed patch.
* If we DO have a contribution ID, then the payment processor can (and should) update parameters on the contribution record as necessary.
* `$params['payment_status_id']` (alias for 'contribution_status_id') should be set to the ID (via pseudoconstant getkey) of Pending/Failed/Completed depending on the outcome of the payment.
*Warning*: Anything other than Pending/Completed may not get handled correctly.
* If we DO NOT have a contribution ID, then the payment processor should return a $params array containing:
```
$params[
'payment_status_id' => {as above}
'trxn_id' => {trxn ref to link to record at payment processor}
'fee_amount' => {optional fee charged by processor}
'net_amount' => {optional / discouraged net amount (ie. amount minus fee))}
];
```https://lab.civicrm.org/dev/translation/-/issues/27Translation option missing for "on behalf of label"2021-06-02T18:01:34ZMartinTranslation option missing for "on behalf of label"I might be misunderstanding how this is supposed to work, but here's the situation that I'm seeing. I have multilingual for civi turned on, and have a contribution page. For the text/longtext fields there is a translation icon next to th...I might be misunderstanding how this is supposed to work, but here's the situation that I'm seeing. I have multilingual for civi turned on, and have a contribution page. For the text/longtext fields there is a translation icon next to the field label in the admin when configuring the page. But when I enable the "allow on behalf of" option, the "on behalf of label" does not have this translation option showing (see screenshot). So it seems that we're not able to provide the right text to the end user in this case.
In addition, when displaying the translated page the following Drupal error shows:
> Notice: Undefined index: for_organization in CRM_Contribute_Form_ContributionBase->buildComponentForm() (line 976 of /home/mysite/public_html/sites/all/modules/civicrm/CRM/Contribute/Form/ContributionBase.php).
Running civicrm 5.12.4 on drupal 7.66 with php 5.6 (I know, I know). Issue was also seen previously on civi 4.7.31.
[civi_trans_issue_1](/uploads/a300619c6ab7cbcabb43e521f7bd46ed/civi_trans_issue_1.jpg)https://lab.civicrm.org/dev/financial/-/issues/52Rounding differences between Contribution and Bookkeeping reports2023-06-18T23:49:12ZmfuggleRounding differences between Contribution and Bookkeeping reportsThere is a small difference between the total of a Contribution report and a Bookkeeping report using the same filters and therefore intended to produce an identical result. However under certain circumstances there are small rounding er...There is a small difference between the total of a Contribution report and a Bookkeeping report using the same filters and therefore intended to produce an identical result. However under certain circumstances there are small rounding errors between the two reports.
Take the following example. A payment of $155.00 is paid via a payment gateway in three monthly instalments. The first instalment is $51.68 and shown in the contribution report correctly (as an aside the next two payments will be $51.66).
However in the Bookkeeping report the first payment is shown as $51.67 which is the rounded up value of $155.00 divided by three which gives $51.66 recurring. In the following month the contribution report will no doubt show the payment to be $51.66 and the Bookkeeping report will display $51.67.
This error also finds its way into the Extended Reports extension. I realise that this is not a big issue but it would be nice if the reports displayed identical totals.Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/902KAM keyboard shortcuts2023-12-02T15:32:23ZJoeMurrayKAM keyboard shortcutsAlthough there had been extensive testing of the KAM extension keyboard shortcuts (https://lab.civicrm.org/dev/accessibility/issues/1#note_11279), I'm not sure how extensive it was of the integration into core. This is a list of items th...Although there had been extensive testing of the KAM extension keyboard shortcuts (https://lab.civicrm.org/dev/accessibility/issues/1#note_11279), I'm not sure how extensive it was of the integration into core. This is a list of items that are needed to make the menu accessible according to WCAG 2.0 AA, so far as I can determine from various sites that provide suggestions on implementations for compliant menus, mainklyt WAI tutorials.
* [ ] The menu should receive the tab focus first, before other page elements. Currently, one has to tab through other page elements before entering the menu. On wpmaster, it takes 4 tabs, on dmaster it takes 24 tabs in order to get to QuickSearch.
* [ ] When focus is in QuickSearch, tab incorrectly moves next to browser address line. It should move forward to the menu item represented by the CiviCRM icon (I don't know its name).
Previous notes from when tabbing worked in the menu:
* [ ] When on a menu item with submenu open, space and return as well as escape should close it. Not a priority, but behaviour seems to be non-standard.
* [ ] When on an open sub-submenu (eg Contributions > Accounting Batches with Open Batches with focus), using left arrow correctly moved focus to Accounting Batches, but it did not close the sub-submenu. Not a huge priority for usability.https://lab.civicrm.org/dev/drupal/-/issues/58Add Contact ID operator to the contact reference filter added in drupal view2019-04-24T06:50:11ZjitendraAdd Contact ID operator to the contact reference filter added in drupal viewContact Reference filter in a Drupal view only lets user to filter on sort_name. This field can have duplicate values on multiple contact records. It might be helpful if we could filter the results based on contact id.
Use-case
- Add a...Contact Reference filter in a Drupal view only lets user to filter on sort_name. This field can have duplicate values on multiple contact records. It might be helpful if we could filter the results based on contact id.
Use-case
- Add a contact ref custom field on a custom set extending individual. Eg `Alternate Contact Person`
- Add value to this field eg "Ashlie Adams".
- Suppose the db have more than one contact having the same sort name. eg id 203 and 206
- I need to create a Drupal view filtering values which have `Alternate Contact Person` set to contact id 203.
- The current set of filters will list all contacts for 203 and 206.
- This ticket is to address that limitation.jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/863Functionality of Remove Case Role activity type is messed up2022-10-23T16:00:50ZDaveDFunctionality of Remove Case Role activity type is messed upI think it's been like this for a few years. I can look into it later but recording here for reference. Examples of stuff below, and I can reproduce on dmaster.demo.
1. In the case roles section on manage case, click the trash can icon ...I think it's been like this for a few years. I can look into it later but recording here for reference. Examples of stuff below, and I can reproduce on dmaster.demo.
1. In the case roles section on manage case, click the trash can icon at the end of a row to remove a case role. It does remove the role, but there's supposed to be a Remove Case Role activity filed on the case.
2. In the Other Relationships section on manage case, add a new relationship. It gets correctly added but adds a Remove Case Role activity to the case. Besides being the wrong activity, no activity should be added here since that add button is just a shortcut to adding a regular relationship in the usual way, that exists outside of the life of the case.https://lab.civicrm.org/dev/core/-/issues/852Provide wysiwyg editor for additional confirmation email text2023-08-05T04:15:04ZyashodhaProvide wysiwyg editor for additional confirmation email textProvide wysiwyg editor for additional confirmation email text for online and offline event registrations. (In other words, this is the text from the text area widget on the Manage Event page, not the event template itself.)
https://civi...Provide wysiwyg editor for additional confirmation email text for online and offline event registrations. (In other words, this is the text from the text area widget on the Manage Event page, not the event template itself.)
https://civicrm.stackexchange.com/questions/21255/confirmation-email-providing-a-wysiwyg-so-users-can-add-html-ified-contentyashodhayashodhahttps://lab.civicrm.org/dev/financial/-/issues/49No way to customize contribution receipt based on individual entering data wh...2021-11-23T17:28:26ZJonGoldNo way to customize contribution receipt based on individual entering data when giving "On behalf of" an organizationWhen giving on behalf of an organization, we don't store the contact ID of the person who actually entered the contribution, nor do we pass it to the receipt in `$tplParams`. My PR will resolve the latter issue, since it's a safe fix th...When giving on behalf of an organization, we don't store the contact ID of the person who actually entered the contribution, nor do we pass it to the receipt in `$tplParams`. My PR will resolve the latter issue, since it's a safe fix that doesn't affect folks who don't choose to use its functionality.JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/47Payment Instrument not set on Pending Contributions' payments when marked "Co...2019-12-17T22:10:48ZJonGoldPayment Instrument not set on Pending Contributions' payments when marked "Completed".There's an inconsistency in how payments are recorded in CiviCRM depending on how you mark them completed.
#### Scenario 1
* Record a pending contribution for a contact with whatever payment instrument you like.
* Complete the payment b...There's an inconsistency in how payments are recorded in CiviCRM depending on how you mark them completed.
#### Scenario 1
* Record a pending contribution for a contact with whatever payment instrument you like.
* Complete the payment by selecting **More » Record Payment** and entering the payment.
* Click the **pencil** to edit the resulting payment. Everything looks fine.
#### Scenario 2
* Record a pending contribution for a contact with whatever payment instrument you like.
* Complete the payment by selecting **Edit** and changing the contribution status to **Completed**.
* Click the **pencil** to edit the resulting payment. The payment instrument is blank. Moreover, any attempt to change the payment instrument results in a fatal error (similar to core#264). See below.
The backtrace below seems like a symptom of the root cause, which is in the second step (changing the contribution status) not the third step.
```
CiviCRM_API3_Exception: "Mandatory key(s) missing from params array: payment_instrument_id"
#0 /example.org/sites/all/modules/civicrm/CRM/Financial/Form/PaymentEdit.php(213): civicrm_api3("FinancialTrxn", "create", (Array:9))
#1 /example.org/sites/all/modules/civicrm/CRM/Financial/Form/PaymentEdit.php(181): CRM_Financial_Form_PaymentEdit->submit((Array:5))
#2 /example.org/sites/all/modules/civicrm/CRM/Core/Form.php(489): CRM_Financial_Form_PaymentEdit->postProcess()
#3 /example.org/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Submit.php(74): CRM_Core_Form->mainProcess()
#4 /example.org/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Submit->perform(Object(CRM_Financial_Form_PaymentEdit), "submit")
#5 /example.org/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Financial_Form_PaymentEdit), "submit")
#6 /example.org/sites/all/modules/civicrm/CRM/Core/Controller.php(351): HTML_QuickForm_Page->handle("submit")
#7 /example.org/sites/all/modules/civicrm/CRM/Utils/Wrapper.php(113): CRM_Core_Controller->run()
#8 /example.org/sites/all/modules/civicrm/CRM/Core/Invoke.php(283): CRM_Utils_Wrapper->run("CRM_Financial_Form_PaymentEdit", NULL, NULL)
#9 /example.org/sites/all/modules/civicrm/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:14))
#10 /example.org/sites/all/modules/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:3))
#11 /example.org/sites/all/modules/civicrm/drupal/civicrm.module(345): CRM_Core_Invoke::invoke((Array:3))
#12 [internal function](): civicrm_invoke("payment", "edit")
#13 /example.org/includes/menu.inc(350): call_user_func_array("civicrm_invoke", (Array:2))
#14 /example.org/index.php(22): menu_execute_active_handler()
#15 {main}
```https://lab.civicrm.org/dev/translation/-/issues/25Unselecting from 'Available languages' doesn't drop respective locale views f...2021-08-12T19:25:28ZMonish DebUnselecting from 'Available languages' doesn't drop respective locale views from DBSteps to replicate the issue:
1. Add more than one language from 'Add Language' list say English and French(Canada)
2. Then change civi instance to multilingual
3. DB creates views with locale suffix en_US and fr_CA
4. Now unselect Frenc...Steps to replicate the issue:
1. Add more than one language from 'Add Language' list say English and French(Canada)
2. Then change civi instance to multilingual
3. DB creates views with locale suffix en_US and fr_CA
4. Now unselect French(Canada) and save
Bug: This doesn't drop the fr_CA views from DB as it is not required.https://lab.civicrm.org/dev/translation/-/issues/24On New Event, allow translations to be entered before first save2019-03-08T17:14:15ZJoeMurrayOn New Event, allow translations to be entered before first saveCurrently, on multilingual sites, it is only possible to enter text for the current language on the first form presented for Events > New Event (civicrm/event/add?reset=1&action=add). After that form is saved, translations can be entered...Currently, on multilingual sites, it is only possible to enter text for the current language on the first form presented for Events > New Event (civicrm/event/add?reset=1&action=add). After that form is saved, translations can be entered for any translatable field on any tab.
Proposed enhancement: allow translations to be entered for the text fields on the first form as well, prior to first save.
This enhancement idea is currently unfunded.https://lab.civicrm.org/dev/drupal/-/issues/52Drupal8: getUrlPath: avoid relying on the deprecated 'q' variable2020-05-27T12:49:03ZbgmDrupal8: getUrlPath: avoid relying on the deprecated 'q' variableContext: Symbiotic has an extension for theming that uses this trick to detect whether it's running in a frontend or backend form (to avoid loading our CSS on the frontend):
```
function adminimore_civicrm_config(&$config) {
$path = C...Context: Symbiotic has an extension for theming that uses this trick to detect whether it's running in a frontend or backend form (to avoid loading our CSS on the frontend):
```
function adminimore_civicrm_config(&$config) {
$path = CRM_Utils_System::getUrlPath();
$item = CRM_Core_Menu::get($path);
$resources = CRM_Core_Resources::singleton();
// if item is not known, assume it's public (e.g. wordpress shortcode)
if ($item && !CRM_Utils_Array::value('is_public', $item)) {
$resources->addStyleFile(ADMINIMORE_RESOURCE, 'css/civicrm-admin.css', 15, 'html-header');
$resources->addStyleFile(ADMINIMORE_RESOURCE, 'css/civicrm-buttons.css', 15, 'html-header');
}
$resources->addStyleFile(ADMINIMORE_RESOURCE, 'css/civicrm-menu.css', 15, 'html-header');
_adminimore_civix_civicrm_config($config);
}
```
In Drupal8, we were having weird problems where the CSS would sometimes not load. If we refreshed, it loaded, but after some time, the bug would appear again and we would stumble on a screen using the default CiviCRM CSS.
After some poking around, it seems that Drupal8 deprecated the 'q' variable, which CiviCRM is still using in `CRM_Utils_System::getUrlPath()`.
I did a quick patch to test a workaround, which so far seems to be working:
```
public static function getUrlPath() {
if (CRM_Core_Config::singleton()->userFramework == 'Drupal8') {
if (class_exists('Drupal') && \Drupal::hasContainer()) {
$path = \Drupal::service('path.current')->getPath();
// Remove '/' prefix. Ex: '/civicrm/contribute' becomes 'civicrm/contribute'.
if ($path) {
$path = substr($path, 1);
// Remove the language prefix, if present
// The URL returned by Drupal randomly includes the language prefix, sometimes not.
if (preg_match('/^\w\w\//', $path)) {
$path = substr($path, 3);
}
return $path;
}
}
}
if (isset($_GET[CRM_Core_Config::singleton()->userFrameworkURLVar])) {
return $_GET[CRM_Core_Config::singleton()->userFrameworkURLVar];
}
return NULL;
}
```
A cleaner solution might be to check if the `$config->userSystem->getUrlPath()` function exists, and if it does, call it?https://lab.civicrm.org/dev/translation/-/issues/23Angular asset cache and multi-lingual2024-01-29T10:06:18ZbgmAngular asset cache and multi-lingualAngular extensions, such as CiviMail (classic) or Mosaico, will not always be displayed in the correct language when the Angular asset cache is enabled/auto (Admin > System Settings > Debugging). Tested on Drupal 7 (in case that makes a ...Angular extensions, such as CiviMail (classic) or Mosaico, will not always be displayed in the correct language when the Angular asset cache is enabled/auto (Admin > System Settings > Debugging). Tested on Drupal 7 (in case that makes a different with the "auto" setting of that cache).
How to reproduce on dmaster:
* Make sure you have the civicrm-l10n.tar.gz translation files (it's the case on dmaster.demo.civicrm.org)
* Go to Administer > Localisation, and enable another language, such as French (you don't need to enable multi-lingual).
* Use the CiviCRM Language Switch to set the language to French
* Go to Mailing > New Mailing (classic or mosaico, same bug)
* Now go back to the dashboard, set the language to English
* Go to Mailing > New Mailing, and notice that the UI is still in French.https://lab.civicrm.org/dev/core/-/issues/719can't delete profile pre- post- field help on multilinguage sites2022-08-26T00:20:44ZJoeMurraycan't delete profile pre- post- field help on multilinguage sitesIf you add field pre and post help to profiles on a single language site, you can then delete it and save successfully. On a site with more than 1 language, trying to delete the help leads to it being resaved (I believe from the alternat...If you add field pre and post help to profiles on a single language site, you can then delete it and save successfully. On a site with more than 1 language, trying to delete the help leads to it being resaved (I believe from the alternative language's copy of the help).
Verified on dmaster 5.12.alpha1.Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/712Submiting a form to join multiple groups should send one email, not one per g...2022-09-30T18:34:42ZIan KellingSubmiting a form to join multiple groups should send one email, not one per grouphttps://docs.civicrm.org/user/en/latest/email/set-up/ says: "When users
subscribe to multiple groups at once, a confirmation email is sent for
each group separately."
This should be changed to send a single email. They entered their ema...https://docs.civicrm.org/user/en/latest/email/set-up/ says: "When users
subscribe to multiple groups at once, a confirmation email is sent for
each group separately."
This should be changed to send a single email. They entered their email
address 1 time into 1 form, then get multiple emails that ask to confirm
their email address. Some will think that it's unnecessary to click each
link since their email address is confirmed by just clicking one. Some
will think there is a bug in the system. It really just doesn't make
sense to users.https://lab.civicrm.org/dev/financial/-/issues/45Custom fields ignored when searching in "Accounting Batch" mode2019-02-11T21:15:55ZJonGoldCustom fields ignored when searching in "Accounting Batch" modeSteps to replicate on a sandbox server:
* Go into Custom Fields, set **How long have you been a donor?** to be searchable.
* In **Find Contributions**, use **How long have you been a donor?** as a search criteria. Note correct results.
...Steps to replicate on a sandbox server:
* Go into Custom Fields, set **How long have you been a donor?** to be searchable.
* In **Find Contributions**, use **How long have you been a donor?** as a search criteria. Note correct results.
* Go to **Contributions » Accounting Batches » New Batch**. Perform the same search. The custom field criterium is ignored.https://lab.civicrm.org/dev/financial/-/issues/44Modifying contribution amount records a fake payment for difference2019-06-20T19:11:11ZAndie HuntModifying contribution amount records a fake payment for difference1. Create a contribution for $50 on the back end, leaving the status as `Completed` and the payment method as `Check`.
2. Edit the contribution to be $70.
3. Go back to view the contribution and see that a new $20 payment by check has be...1. Create a contribution for $50 on the back end, leaving the status as `Completed` and the payment method as `Check`.
2. Edit the contribution to be $70.
3. Go back to view the contribution and see that a new $20 payment by check has been recorded.
There's no way to remove the $20 payment, though you can edit the payment method and so forth.
I suspect this is a consequence of partial payments not being fully implemented for contributions, but the effect is unexpected and undocumented.
Another, more troubling outcome:
1. Create a contribution for $100 on the back end, setting the status as `Pending` and leaving the payment method as `Check`.
2. Record a $90 payment with cash.
3. Edit the contribution amount to be $150.
4. Go back to view the contribution and see that there is now a $50 payment by check with the status "partially paid".
5. Go to record a payment and see that the balance owed is $60. Record that payment with EFT as the payment method.
6. See that the contribution now has three payments, for $90 (Cash), $50 (Check), and $60 (EFT) despite only being for a $150 contribution. A "Record refund" link appears, but clicking it causes an error:
> Sorry but we are not able to provide this at the moment.
Finally, fake negative payments can be recorded:
1. Create a contribution for $100 on the back end, leaving the status as `Completed` and the payment method as `Check`.
2. Edit the contribution to be $70.
3. Go back to view the contribution and see that a new -$30 payment by check has been recorded.https://lab.civicrm.org/dev/financial/-/issues/43Find Contributions searches on inaccurate, redundant payment fields2020-07-09T00:48:18ZAndie HuntFind Contributions searches on inaccurate, redundant payment fieldsThis problem is somewhat related to dev/financial#37 in that there are redundant payment-related fields on the contribution record. That issue covers a record updating problem--when the contribution record isn't updated accurately to re...This problem is somewhat related to dev/financial#37 in that there are redundant payment-related fields on the contribution record. That issue covers a record updating problem--when the contribution record isn't updated accurately to reflect the payment information. This issue is that the Find Contributions search looks only for the value in the contribution record.
When there are multiple payments by check, the check number field on the contribution is updated to have both numbers, separated by a comma. So, the check number is `111,222` if the first check is `111` and the second is `222`. Searching for a contribution with check numbers `111` or `222` will yield nothing, but searching for `111,222` finds it. Obviously this is a bug, but it might properly be considered a bug in search--the search should look among the payments, not the value on the contribution.
Again, like dev/financial#37, the real solution is to ditch the redundant fields. However, in the meantime we should stop relying upon them.
It appears that card number works properly:
* Record contribution, pending pay later (setting payment method to be `Credit Card` to sidestep the problem in dev/financial#37)
* Record payment for part of the amount, payment method `Credit Card` with the card ending in `1234`
* Record payment for the remainder of the amount, payment method `Credit Card` with the card ending in `6789`
* Find contributions, payment method `Credit Card`, card number `1234`, retrieves the contribution.
* Find contributions, payment method `Credit Card`, card number `6789`, retrieves the contribution.
Since there is no card number on the contribution, the search is forced to work the right way.https://lab.civicrm.org/dev/financial/-/issues/41PSD2 support needed for PayPal by Sept 20192019-07-22T22:24:16ZAndrew WestPSD2 support needed for PayPal by Sept 2019PayPal will require PSD2 support by September 2019 - in Europe, anyway (https://www.paypal.com/uk/webapps/mpp/psd2). So Civi will need to support SCA via 3-D Secure when using PayPal - Website Payments Pro (and presumably for any other p...PayPal will require PSD2 support by September 2019 - in Europe, anyway (https://www.paypal.com/uk/webapps/mpp/psd2). So Civi will need to support SCA via 3-D Secure when using PayPal - Website Payments Pro (and presumably for any other payment methods where Civi hosts the payment fields). In practice I think this'll mean an intermediary page after payment, where people can verify their card details.
We are happy to chip in on development of this, but we can't fund it entirely.