Development issueshttps://lab.civicrm.org/groups/dev/-/issues2019-10-24T19:14:29Zhttps://lab.civicrm.org/dev/financial/-/issues/55Support storing IPNs in `civicrm_system_log` for processors that send JSON data2019-10-24T19:14:29ZJonGoldSupport storing IPNs in `civicrm_system_log` for processors that send JSON dataCurrently, `CRM_Core_Payment::logPaymentNotification()`, the method which logs to `civicrm_system_log` uses `$_REQUEST` to grab the POST data. However, `$_REQUEST` doesn't handle raw POST data, it assumes it's form-encoded. This patch ...Currently, `CRM_Core_Payment::logPaymentNotification()`, the method which logs to `civicrm_system_log` uses `$_REQUEST` to grab the POST data. However, `$_REQUEST` doesn't handle raw POST data, it assumes it's form-encoded. This patch handles JSON-encrypted POST requests, notably Stripe, so they can be stored in `civicrm_system_log`.5.16.0JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/79Deprecate Contribute.transact api2019-10-24T21:15:57ZeileenDeprecate Contribute.transact apiThe minimum we should do is deprecate from api explorer & I will do that in this PR. (Agreed in Barcelona)
I think we probably should do a noisier deprecation than that but that will stale-out some PRs currently under discussionThe minimum we should do is deprecate from api explorer & I will do that in this PR. (Agreed in Barcelona)
I think we probably should do a noisier deprecation than that but that will stale-out some PRs currently under discussion5.20.0https://lab.civicrm.org/dev/financial/-/issues/80Noisily deprecate transact api2019-10-24T21:16:11ZeileenNoisily deprecate transact apiWe should add in deprecation warnings using CRM_Core_Error::deprecatedFunctionWarning - these show on dev sites but not live
First step is https://lab.civicrm.org/dev/financial/issues/79We should add in deprecation warnings using CRM_Core_Error::deprecatedFunctionWarning - these show on dev sites but not live
First step is https://lab.civicrm.org/dev/financial/issues/795.20.0https://lab.civicrm.org/dev/core/-/issues/1316Workflow templates - Update 'Thank You' & other text corrections2019-10-24T21:27:09Zmagnolia61Workflow templates - Update 'Thank You' & other text correctionsThere are a few texts in the workflow message templates that are too specific for use in different circumstances. Since we are making changes to the system workflow templates I would like to address these in this round
Specifically I wo...There are a few texts in the workflow message templates that are too specific for use in different circumstances. Since we are making changes to the system workflow templates I would like to address these in this round
Specifically I would like to adjust the templates dealing with contribution and membership
These templates have the text: "**Thank you for your support**". But this is too specific. The contribution offline-receipt could be sent because someone paid for a workshop they are attending. They are not supporting anything, they just paid for what the registered for. The same with the membership. Not all memberships are to support the cause of the organisation. It would be better to describe the object of the gratitude more general.
Some examples of proposed changes.
1. The contribution receipt template had:
`'Thank you for your support',`
But the status can be anything, also pending (which does make the thanks a bit confusing)
Better and more neutral would be:
`'Below you will find a receipt for this contribution.',`
(It would even be better if the table would include the contribution status here)
2. Another example. The event online receipt had:
`Thank you for your participation.`
But the status can also be pending, and anyway chances are high this is all still before the event.
Better and more neutral would be:
`Thank you for your registration.`
3. Thirdly, the membership receipts had:
`Thank you for your support.`
But the membership could also just be something people pay for on a regular basis, without the notion of supporting the 'cause' of the organisation. There are many variations of the membership function.
Better and more neutral here would be:
`Thank you for this contribution.`
4. Finally, the participant confirm template
I added {ts} to the 'click here to confirm text' in https://github.com/civicrm/civicrm-core/pull/15491
But the mail itself is lacking an introductory text. I would propose the following:
`Your registration was waitlisted but we can confirm you can now complete the registration process.`
I believe all these changes (and also some grammar corrections will benefit the readability of the standard texts and make these of more general use for more scenarios.
Cheers, Richard5.20.0magnolia61magnolia61https://lab.civicrm.org/dev/financial/-/issues/90Add new api Order functionality to update line items2019-10-25T08:12:07ZeileenAdd new api Order functionality to update line itemsI'm pretty sure that despite @JoeMurray's optimism the current apiv3 Order.create doesn't support this. @monish.deb & I discussed adding it back here
https://github.com/civicrm/civicrm-core/pull/11380
I don't think we should add it o a...I'm pretty sure that despite @JoeMurray's optimism the current apiv3 Order.create doesn't support this. @monish.deb & I discussed adding it back here
https://github.com/civicrm/civicrm-core/pull/11380
I don't think we should add it o apiv3 now - I think we should write a v4 api that does it. I think the object oriented approach will allow us to come up with cleaner methods. I'm kinda keen to try to build those up on a ORDER pseudoBAO class & play a bit before we expose in the api so we can learn about about what works & doesn't before locking it inhttps://lab.civicrm.org/dev/financial/-/issues/91Discuss / maybe resolve schema issue on changing line items2019-10-25T22:17:31ZeileenDiscuss / maybe resolve schema issue on changing line itemsPer
https://docs.civicrm.org/dev/en/latest/financial/financialentities/
If the line items change then the items financial items have to be updated. Generally the rule is to zero-out the current line items
and reverse their financial ite...Per
https://docs.civicrm.org/dev/en/latest/financial/financialentities/
If the line items change then the items financial items have to be updated. Generally the rule is to zero-out the current line items
and reverse their financial items and create new ones. This is a pretty standard accounting approach.
Unfortunately there are some scenarios where the schema does not permit this which has resulted in
adjustment line items being created in these cases. The issue is that the civicrm_line_item table has a unique index for
entity_table + entity_id + contribution_id + price_field_value_id + price_field_id.
This means that if a line item with no price_field_values (ie a text / enter quantity line item) is altered it is not possible
to create a reversal line a new line within the schema. The same problem occurs when changing a line item with price_field_values
BACK to a price_field_value it previously held. In both these scenarios the work around is to have more than one 'valid' financial_item
against the resulting line item with an 'adjustment' entry - ie an additional financial_item.
I don't have any good answers except maybe add an 'is_current' field & add that to the index. Perhaps the current pain is unavoidable but it feels a bit like an own goal
@JoeMurray @monish.deb @lcdweb @kcristiano @pradeephttps://lab.civicrm.org/dev/core/-/issues/1320Workflow templates - Include displayname in subject2019-10-26T20:33:11Zmagnolia61Workflow templates - Include displayname in subjectMany email providers group emails with the same subject which leads to time-consuming processes for many organisations, and many additional unnecessary clicks.
Some system workflow template subjects include the display name.
Also it mak...Many email providers group emails with the same subject which leads to time-consuming processes for many organisations, and many additional unnecessary clicks.
Some system workflow template subjects include the display name.
Also it makes the email more personal as it is clear who it is addressed to.
This is proven to be beneficial for open-rates of transactional mails.
The messages will be upgraded in 5.20alpha1 by #15491
https://github.com/civicrm/civicrm-core/pull/155135.20.0magnolia61magnolia61https://lab.civicrm.org/dev/core/-/issues/1324Customfields attached to addresses break the profile page2019-10-28T08:08:37ZVangelisPCustomfields attached to addresses break the profile page## General
When we set an address customfield on an address and then we add that field into a profile, the profile page breaks on edit mode.
Returning error: `DB Error: no such field`
## How to reproduce
On https://dmaster.demo.civicrm...## General
When we set an address customfield on an address and then we add that field into a profile, the profile page breaks on edit mode.
Returning error: `DB Error: no such field`
## How to reproduce
On https://dmaster.demo.civicrm.org (CiviCRM 5.20.alpha1) :
* Create a new CustomGroup and assign it to the entity 'Address'
* Create a new customfield (for example of type textfield)
* Populate the field with some dummy information
* Create a new profile and add 2 fields:
* Street Address
* Your newly created customfield
* Click on 'More -> Use edit mode'
* The page should break with error `DB Error: no such field`
## Background
It seems that the issue starts here: https://lab.civicrm.org/dev/core/blob/master/CRM/Contact/BAO/Contact.php#L1784
and then goes here: https://lab.civicrm.org/dev/core/blob/master/CRM/Contact/BAO/Query.php#L1036
and the actual join should take place somewhere here: https://lab.civicrm.org/dev/core/blob/master/CRM/Contact/BAO/Query.php#L1307
In short: There is an additional field, the id of the customtable that is holding the customfield in the select query that is not being joined properly (join is actually missing) from the constructed query.5.20.0https://lab.civicrm.org/dev/core/-/issues/752Add cid parameter in custom group form url & set it for Activity form2019-10-28T13:47:29ZeileenAdd cid parameter in custom group form url & set it for Activity formOverview
----------------------------------------
Custom group forms are usually loaded by AJAX, in the parent entities forms they extend from.
The class `CRM_Custom_Form_CustomDataByType` is the one that manages custom group form, but ...Overview
----------------------------------------
Custom group forms are usually loaded by AJAX, in the parent entities forms they extend from.
The class `CRM_Custom_Form_CustomDataByType` is the one that manages custom group form, but doesn't contain the **contact_id** attribute which is essential for performing tasks such as set a default value based on Contact's data, validate values against Contact's data, etc.
Now a days, theses tasks are hard to code, and most of them must rely on JQuery scripts or too complex workarounds to be achieved
From https://github.com/civicrm/civicrm-core/pull/13191
Before
----------------------------------------
class `CRM_Custom_Form_CustomDataByType` doesn't store **contact_id** value
After
----------------------------------------
class `CRM_Custom_Form_CustomDataByType` stores **contact_id** value, which is sent by the parent Entity through url parameter **cid** (when is available)
Technical Details
----------------------------------------
The url is called from this function:
https://github.com/civicrm/civicrm-core/blob/master/templates/CRM/common/customData.tpl#L29
```js
CRM.buildCustomData = function (type, subType, subName, cgCount, groupID, isMultiple, onlySubtype) {
var dataUrl = CRM.url('civicrm/custom', {type: type}),
prevCount = 1,
fname = '#customData',
storage = {};
. . . .
```
then there are **42 php/tpls** files that use this function and must be adapted to send the **cid** when is available
List of 42 files [here](https://gist.github.com/sluc23/a83cb45c05c784747b4d8b0c16a19af7)
Comments
----------------------------------------
This is the first iteration of an incremental change that must be performed to adapt every Entity in CiviCRM.
MM discussion [here](https://chat.civicrm.org/civicrm/pl/gcfhwf9g77fstcbupq3ynwhgce)https://lab.civicrm.org/dev/financial/-/issues/34Incorrect allocation of payment on an edited multi-line item event registration2019-10-29T19:27:12ZJoeMurrayIncorrect allocation of payment on an edited multi-line item event registrationOn default data set on dmaster, create new Financial Type Event Fees 2. At Administer > Financial Accounts, navigate to the Financial Account this creates also called Event Fees 2 and enter 4301 as the Accounting Code.
Create event wit...On default data set on dmaster, create new Financial Type Event Fees 2. At Administer > Financial Accounts, navigate to the Financial Account this creates also called Event Fees 2 and enter 4301 as the Accounting Code.
Create event with priceset with two fields, first with financial Type Event fees, second with FT of Event Fees 2. Register in event with payment of say $25 for first ticket (Event Fees) and $10 for second ticket (Event fees 2), total $35.
Edit Event registration. Click Change selections. Change quantity for second field from 1 to 5, line item total of $50, contribution total of $75, total paid $35. Save. Balance is $40. Click Record Payment.
Under Contributions > Accounting Batches > New Batch, create a batch, assign the relevant transactions of $35 (original payment), $40 (edit with implied purchase with pay later) and $40 (payment of outstanding balance) to the new batch and export to csv.
At Contributions > Accounting Batches > Open Batches, select the batch just created and export as csv, open and view the resulting transactions:
[Financial_Transactions_3_20180807210702.csv](/uploads/0cccae0ceba1707701f9cf699f52a3e3/Financial_Transactions_3_20180807210702.csv)
The initial purchase (first two lines) and the edit of the order to increase the number of event fees from $10 to $50 are (the third line) are all correct. However, the payment of the outstanding balance is incorrect. Instead of a single line with a $40 payment (Debit Bank Account 1150, Credit Accounts Receivable 1200), there are two lines:
Debit Bank Account 1150, Credit Accounts Receivable 1200: $16.67, Item description: Member
Debit Bank Account 1150, Credit Accounts Receivable 1200: $23.33, Item description: Guest
It seems the payment is being equally allocated to the two line items in proportion to their current line item total. If there had been a simple partial payment, this would be correct. The algorithm for determining the allocation should not be based on the line item totals (or more accurately, their corresponding financial_item.amount), but on the amount of each financial item that has been paid so far (entity_financial_trxn.amount for the entries linking financial_trxn records to these financial_item records.
We should first verify that the entity_financial_trxn.amount fields are being properly recorded. Then it will be apparent that sum(entity_financial_trxn.amount) pointing to first financial_item is $25, the same as its financial_item.amount, while sum(entity_financial_trxn.amount) pointing to second financial_item is $10, which is $40 less than the financial_item.amount. So all of the second payment would be allocated to a single new entity_financial_trxn.amount of $40 pointing to the second financial_item.
This is not a high priority since the two entries add up to the same as the proposed single entry from an accounting perspective. Having two general journal entries is confusing, and the item description of one is inaccurate, so a fix would be good.Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/893Print Merge document from case search doesn't file on correct contact.2019-10-29T19:27:12ZRayWrightPrint Merge document from case search doesn't file on correct contact.With Record generated letters set to "Multiple activities (one per contact)" when you print/merge documents, they don't file on the correct contact.
Replicated on dmaster - Search for all cases (I created 3 random dummy cases) select a...With Record generated letters set to "Multiple activities (one per contact)" when you print/merge documents, they don't file on the correct contact.
Replicated on dmaster - Search for all cases (I created 3 random dummy cases) select all and then Print/merge document. I tested with a token in the letter so I could tell in what order the letters were being generated. The letters are generated in case ID order but they are filed in the order your search screen was last sorted.
For example, the letters are issued in this order:
* Case 1 - Lawrence Ivanov
* Case 2 - Carlos Jacobs
* Case 3 - Sanford Blackwell
But, the default sort if alpha by contact last name:
* Sanford Blackwell (gets Lawrence Ivanov's - case 1 activity)
* Lawrence Ivanov (gets Carlos Jacob's - case 2 activity)
* Carlos Jacobs (gets Sanford Blackwell's - case 3 activity)
![act02-printmergedoc](/uploads/0acbc34d41abfd3f09654dac4d808139/act02-printmergedoc.png)
![act03-incorrectcontact](/uploads/03e8d5b8daa9ec3096728a89f862b7cd/act03-incorrectcontact.png)5.20.0RayWrightRayWrighthttps://lab.civicrm.org/dev/core/-/issues/1336CRM_ACL_BAO_Cache::updateEntry is bonkers and possibly even broken2019-10-30T01:35:14ZseamusleeCRM_ACL_BAO_Cache::updateEntry is bonkers and possibly even brokenThe function mentioned seems to be written in such a way as it is trying to do two jobs at once which seems very very odd indeed.
Firstly the $id param isn't clearly spelled out however when it calls the deleteEntry() function it seems ...The function mentioned seems to be written in such a way as it is trying to do two jobs at once which seems very very odd indeed.
Firstly the $id param isn't clearly spelled out however when it calls the deleteEntry() function it seems that the $id is of the contact being viewed.
however later on when it calls getAllACLs for contact and also build the cache table it is now believing that $id is the contact id of the user trying to access the contacts. Which makes more sense but still feels very much odd ball.5.20.0seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/1348Find Activities not working in 5.19beta1 and master2019-10-30T01:36:30ZDaveDFind Activities not working in 5.19beta1 and masterIt's working in 5.18.4. In 5.19+ it just always returns all activities.
It's because of a change in CRM_Core_Form_Search::setFormValues(). This now calls $this->getFormValues(), but for activity search all that does is return NULL, so n...It's working in 5.18.4. In 5.19+ it just always returns all activities.
It's because of a change in CRM_Core_Form_Search::setFormValues(). This now calls $this->getFormValues(), but for activity search all that does is return NULL, so no form values get set.5.19.0DaveDDaveDhttps://lab.civicrm.org/dev/core/-/issues/375Incorrect event fee Balance & Total Paid in Participant Listing report2019-10-30T18:35:54Zmagnolia61Incorrect event fee Balance & Total Paid in Participant Listing reportScenario nr.1:
1. Event registration with Price Set
2. fee is 20 euro and is paid
3. Price set is changed. 30 euro more is required
4. The Contribution tab shows correct amounts for Amount and Balance Due
![Screenshot_from_2018-09-04_13-...Scenario nr.1:
1. Event registration with Price Set
2. fee is 20 euro and is paid
3. Price set is changed. 30 euro more is required
4. The Contribution tab shows correct amounts for Amount and Balance Due
![Screenshot_from_2018-09-04_13-48-10](/uploads/f1b5ba92e6facd678504ba1ac8e878dc/Screenshot_from_2018-09-04_13-48-10.png)
5. The Participant Listing report shows something different (Fee = 50 Total Paid = 50 Balance = 0)
![Screenshot_from_2018-09-04_13-41-10](/uploads/2df16a82cdd7439160eb542630d09d1b/Screenshot_from_2018-09-04_13-41-10.png)
Scenario nr.2
1. Event registration with Price Set
2. fee is 50 euro and is not paid
3. payment of 20 euro is recorded
4. Both the contribution tab and the Participant listing report show correct figures.
It seems to me there is a bug in the calculation of the Total Paid and Balance due in the Participant Report. Because at all other places in CiviCRM in scenario 1 the Balance is correct.5.20.0https://lab.civicrm.org/dev/core/-/issues/1347Warning: array_key_exists(): The first argument should be either a string or ...2019-10-30T18:47:09ZDaveDWarning: array_key_exists(): The first argument should be either a string or an integer in CRM_Contact_Form_Search::getModeValue()When opening the address accordion on advanced search (e.g. /civicrm/contact/search/advanced?qfKey=blah_blah&searchPane=location&snippet=json), drupal watchdog logs this warning:
Warning: array_key_exists(): The first argument should be...When opening the address accordion on advanced search (e.g. /civicrm/contact/search/advanced?qfKey=blah_blah&searchPane=location&snippet=json), drupal watchdog logs this warning:
Warning: array_key_exists(): The first argument should be either a string or an integer in CRM_Contact_Form_Search::getModeValue() (line 305 of .../CRM/Contact/Form/Search.php)
It doesn't seem to affect search results, and oddly isn't displaying a red box on the screen even if you have drupal set to display them.
Seeing it in 5.19beta1 and on master. It looks like it was in 5.14.0 at least too.5.20.0https://lab.civicrm.org/dev/financial/-/issues/93Agree / implement handling of failure for doPayment/ doRefund / params for do...2019-11-01T11:58:47ZeileenAgree / implement handling of failure for doPayment/ doRefund / params for doRefundCurrently both doPayment and doRefund throw a PaymentProcessorException if there is a failure either in terms of config or in terms of processing. The flow we agreed back when we implemented this in 4.6 is we should be working towards
`...Currently both doPayment and doRefund throw a PaymentProcessorException if there is a failure either in terms of config or in terms of processing. The flow we agreed back when we implemented this in 4.6 is we should be working towards
```
Order.create.... status=pending
try {
$result = $paymentObject->doPayment();
if ($result['payment_status_id') === 1) {
Payment.create.....
}
}
else {
\\ Add code here to add failed payment
}
```
Currently the CRM_Core_Payment doPayment converts failed results for old processors to exceptions and throws them and new processors have been expected to throw exceptions.
Some of the forms implement things similar to the above although in other cases the exception is caught much further from the call to doPayment and in some cases we are still not creating the order before processing the payment.
Note that in this flow a payment that did not fail but was not successful would not result in a payment being created.
@mattwire is proposing that we change this for doRefund and stop throwing exceptions for failed payments (or any types) and instead return a status for failed for user-related reasons and an exception for system related reasons.
The options as I see them are
1) implement the same pattern for doRefund as doPayment
2) implement and extend the pattern - ie add a couple of things we probably would have done if implementing from scratch such as
- a PaymentProcessorException_PaymentFailed Exception which extends the existing PaymentProcessorException & can be throwing when the payment relates to card failure rather than a config error. Calling code can choose to catch these separately if it chooses. (we could use this for doPayment too)
- add a getter for the outcome ie. start a transition from returning 1 / the value that maps to contributionStatus = Completed (which is not actually a payment status) to ```$paymentObject->isCompleted()``` or ``` $paymentObject->isSuccessful()```. (Note Omnipay uses isSuccessful()). We could transition doPayment to this over time.
- add a property / getter for getRefundTrxnResult
- add a property / getter for 'processor_result' / 'passthrough_params' which is something that @mattwire has suggested although I have no specifics / examples.
- encourage the use of getters & setters rather than passing in params - ie ```$paymentObject->setAmount(20.40);``` Notte we have just added getters & setters to the class in general https://lab.civicrm.org/dev/financial/issues/82 - implement this in the api call & new core interactions with the class
3) switch to the pattern matt proposes - ie. for doRefund
```
return [
// refund_status_id would normally return the contribution_status_id Completed or Failed
'refund_status_id' => CRM_Core_PseudoConstant::getKey('CRM_Contribute_BAO_Contribution', 'contribution_status_id', 'Completed'),
// The refund trxn_id may be different from the trxn_id of the original payment.
// If it is the same then trxn_id should be copied to refund_trxn_id
'refund_trxn_id' => NULL,
// Array of params returned by the payment processor. The contents of this will vary by processor and should not be relied on.
// However, they can be very useful for logging or providing specific feedback.
'processor_result' => [],
];
```https://lab.civicrm.org/dev/financial/-/issues/95Update Payment.create api handling of payment instrument2019-11-01T12:04:03ZeileenUpdate Payment.create api handling of payment instrumentAt the moment the passed in payment_instrument_id will take precedent over the one associated with the relevant processor. I don't think that is how the design was intended and in other places we use the paymnet_processor_id.
Note that...At the moment the passed in payment_instrument_id will take precedent over the one associated with the relevant processor. I don't think that is how the design was intended and in other places we use the paymnet_processor_id.
Note that I think that the Payment.create api should require either the payment_instrument_id or the payment_processor_id.
Logically this is something 'known' when making a payment & not something we should 'guess'. Transitionally we would deprecate NOT passing in one of those values rathe than requiring it.
I do think we should add some handling to Order.create so that specifically when chaining Payment.create it automatically sets some values - this being one.
@JoeMurray @monish.deb @artfulrobothttps://lab.civicrm.org/dev/financial/-/issues/92Change signature of CRM_Core_Payment::doRefund(&$params) to not receive $para...2019-11-01T12:04:35ZeileenChange signature of CRM_Core_Payment::doRefund(&$params) to not receive $params as a referenceThis is a proposal by @mattwire which is mostly stylistic
pros - we have been moving away from receiving as reference
- less scope for people to try to achieve odd things in there
cons - less consistent with doPayment
- would...This is a proposal by @mattwire which is mostly stylistic
pros - we have been moving away from receiving as reference
- less scope for people to try to achieve odd things in there
cons - less consistent with doPayment
- would need to do a civi universe or whatever that things is of Tims to find what processors might need to be patched to cope
- less opportunity for payment processors to tweak thingshttps://lab.civicrm.org/dev/financial/-/issues/83Barcelona sprint financials2019-11-01T12:05:38ZeileenBarcelona sprint financialsI'm creating this issue to document & track the discussions we had at the Barcelona sprint.
We had a financial team of @mattwire @JoeMurray @ayduns @artfulrobot @BjoernE @andrei @ejegg present
Main issues
1. Ensuring there were ...I'm creating this issue to document & track the discussions we had at the Barcelona sprint.
We had a financial team of @mattwire @JoeMurray @ayduns @artfulrobot @BjoernE @andrei @ejegg present
Main issues
1. Ensuring there were no blockers to people using the Order.create->PaymentProcessor.pay->Payment.create flow https://lab.civicrm.org/dev/financial/issues/76
1. Making the poor performance associated with the creditnote_id field opt in rather than opt out https://lab.civicrm.org/dev/financial/issues/84
1. Addressing Stripe's need to store some Stripe generated information for which there is no suitable field. We resolved this at the data level by adding the field civicrm_financial_trxn.result_code. However docs pending! https://lab.civicrm.org/dev/financial/issues/57
1. Having a plan to get off our broken contribution.template model https://lab.civicrm.org/dev/financial/issues/6
1. UI for permitting refunds processing for payments. https://lab.civicrm.org/dev/financial/issues/85
Not actually from the sprint but topical from discussions - add getters & setters to payment processor base class https://lab.civicrm.org/dev/financial/issues/82https://lab.civicrm.org/dev/financial/-/issues/81Update Contribution Payment Instrument Id to match first payment when the st...2019-11-01T20:59:49ZeileenUpdate Contribution Payment Instrument Id to match first payment when the status is PendingIf we are asking people to create a pending Order they may not know the payment instrument at that time. We should adjust Payment.Create to update it when a payment comes in & it is the first one.
(Alternatively we could always update ...If we are asking people to create a pending Order they may not know the payment instrument at that time. We should adjust Payment.Create to update it when a payment comes in & it is the first one.
(Alternatively we could always update it so it becomes the latest - probably an edge case)