Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-05-30T22:23:24Zhttps://lab.civicrm.org/dev/core/-/issues/4257Allow editing of payment method on contribution edit form when no payments ar...2023-05-30T22:23:24ZlarsssandergreenAllow editing of payment method on contribution edit form when no payments are associatedCurrently, the contribution edit form does not allow editing of the payment method for a pending contribution. This may be useful for users, for example if someone fills out a contribution page with pay later and so their contribution pa...Currently, the contribution edit form does not allow editing of the payment method for a pending contribution. This may be useful for users, for example if someone fills out a contribution page with pay later and so their contribution payment method is set to check, but they will actually pay with an etransfer and we want to note this. It is also potentially confusing because the user can mark the payment as completed and record the payment two ways, by clicking Record Payment or by changing the status to completed, but only the first of these allows the user to change the payment method.
I think we can safely allow editing of the payment method when there are no payments associated with a contribution.https://lab.civicrm.org/dev/core/-/issues/4244"Invoice.pdf" filename not translatable2023-04-18T06:49:02Zmmyriam"Invoice.pdf" filename not translatableWhen "Automatically email invoice when user purchases online" is enabled in CiviContribute Component Settings a pdf invoice is sent to the user who makes an online contribution.
The attached invoice's filename is not translated/translat...When "Automatically email invoice when user purchases online" is enabled in CiviContribute Component Settings a pdf invoice is sent to the user who makes an online contribution.
The attached invoice's filename is not translated/translatable from Invoice.pdf because it is hardcoded:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Task/Invoice.php#L613
```
public static function putFile($html, $name = 'Invoice.pdf', $format = NULL) {
return CRM_Utils_Mail::appendPDF($name, $html, $format)['fullPath'] ?? '';
}
```
The `putFile` function allows for a filename for when the invoice is sent by an admin from the contribution record.
In that case the invoice gets its name from the contribution invoice number which is created using the invoice prefix configured in CiviContribute Component Settings: https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Task/Invoice.php#L434
Reproduction steps
----------------------------------------
1. Enable "Automatically email invoice when user purchases online" in CiviContribute Component Settings
1. Make an online contribution on a contribution form
* where the receipt is enabled
* in a different language than English
1. Receive an email with Invoice.pdf attachedhttps://lab.civicrm.org/dev/core/-/issues/4223To edit price sets CiviContribute access needed2023-04-12T07:25:37ZMariaVTo edit price sets CiviContribute access neededOverview
----------------------------------------
A user has limited permissions without access to CiviContribute but has access to CiviEvent and needs to set up price sets. It is possible to view price sets but they can not be edited or...Overview
----------------------------------------
A user has limited permissions without access to CiviContribute but has access to CiviEvent and needs to set up price sets. It is possible to view price sets but they can not be edited or created because of the financial type.
Reproduction steps
----------------------------------------
1. Create price set for Events (with a user without CiviContribute access)
2. Create price field (radio buttons)
3. Add options to this price field
4. Fill all needed information
5. Save
6. Error "financial type is mandatory"
Current behaviour
----------------------------------------
When I open a price set option it shows me this:
![image](/uploads/f5b1e1b6648bb6beb30cf36b3ab2fe7a/image.png)
(Zuwendungsart = financial type)
With administrator this:
![image](/uploads/b6fc64b239dad54bbf4ba68c72434241/image.png)
If I give "CiviContribute access" it works.
Expected behaviour
----------------------------------------
When CiviEvent access is given, users are allowed to create price sets.
Environment information
----------------------------------------
* __CiviCRM:__ _5.58.1
* __CMS:__ _Drupal 7https://lab.civicrm.org/dev/core/-/issues/4185Single quote in contribution amount label breaks text receipt emails2023-11-23T07:47:01Zchrisgaraffachris@aghstrategies.comSingle quote in contribution amount label breaks text receipt emailsSteps to reproduce:
- Configure a confirmation page to use contribution amounts without a price set.
- Have a single quote in a Contribution Label. Example: "Provides a family with a month's worth of groceries"
- Make a contribution sele...Steps to reproduce:
- Configure a confirmation page to use contribution amounts without a price set.
- Have a single quote in a Contribution Label. Example: "Provides a family with a month's worth of groceries"
- Make a contribution selecting that contribution option
Expected result:
- Contribution receipt email is sent
Actual result:
- PHP error: `"Message was not parsed due to invalid smarty syntax : Smarty error: [in evaluated template line 55]: syntax error: (secure mode) 's' not allowed in if statement (Smarty_Compiler.class.php, line 1398)"`
Can also be triggered by finding the contribution and sending a receipt email.
Full PHP error details from ConfigAndLog: https://lab.civicrm.org/-/snippets/86
Observations:
- This line in the default Contributions - Receipt (on-line) text template seems to be the issue: `{ts}Amount{/ts}: {contribution.total_amount} {if '{contribution.amount_level}'} - {contribution.amount_level}{/if}`
- Adding `{assign var="contributionAmountLevel" value="{contribution.amount_level}"}` and then changing that line to `{ts}Amount{/ts}: {contribution.total_amount} {if $contributionAmountLevel} - {contribution.amount_level}{/if}` is a workaround
- Doesn't seem to be an issue if a Price Set is used where the label has the same character.
- I was able to reproduce on 5.59.2, 5.58.1, 5.56.2, 5.49.5https://lab.civicrm.org/dev/core/-/issues/4177Auto-generation of recurring contribution template ignores recurring amount2023-07-20T09:34:15ZAlanDixonAuto-generation of recurring contribution template ignores recurring amountOverview
----------------------------------------
When a recurring contribution does not have a corresponding template, sometimes one is generated implicitly (e.g. when viewing the 'template' and clicking 'done').
That 'implicit generat...Overview
----------------------------------------
When a recurring contribution does not have a corresponding template, sometimes one is generated implicitly (e.g. when viewing the 'template' and clicking 'done').
That 'implicit generation' does not pay attention to the amount in the recurring contribution record.
Reproduction steps
----------------------------------------
1. As an administrator, create a new recurring contribution for $1.
1. Observe that only the recurring contribution and contribution record are created, no recurring template contribution (requires mysql access to see this!).
1. Edit the recurring amount to $2. Note that there is still no recurring template.
1. View the recurring 'template' and click done. This implicitly creates the recurring record based on the $1 contribution, ignoring the $2 recurring contribution record amount, and as a side effect, modifies the recurring contribution record amount back to $1.
Current behaviour
----------------------------------------
The implicit generation of the recurring template does not respect the amount in the recurring record total.
Expected behaviour
----------------------------------------
It should! Of course, it's complicated. e.g. maybe that recurring template should get generated when the original recurring contribution is created?
I would note that I've only described one way that the template gets created, it appears there may be others. So regardless of whether we avoid this specific way of implicitly-generating the template, it should behave better than it does ...
Environment information
----------------------------------------
CiviCRM version: likely all versions since last June 2022.
Relevant docs link https://docs.civicrm.org/dev/en/latest/financial/recurring-contributions/https://lab.civicrm.org/dev/core/-/issues/4064Off-line Contribution receipts are sent to on hold emails2023-04-22T16:38:36ZlarsssandergreenOff-line Contribution receipts are sent to on hold emailsIf you record an off-line contribution for a contact with an email on hold, the option to send them a receipt at their on-hold email address is shown (with no indication that the email is on hold).
I would think the expected behaviour w...If you record an off-line contribution for a contact with an email on hold, the option to send them a receipt at their on-hold email address is shown (with no indication that the email is on hold).
I would think the expected behaviour would be to not show the receipt option if the contributor's email is on hold.https://lab.civicrm.org/dev/core/-/issues/4034CRM Builder - Profiles allow multiple Formatting Free HTML fields in forms2023-01-03T14:46:14ZJonny ToomeyCRM Builder - Profiles allow multiple Formatting Free HTML fields in formsOverview
----------------------------------------
When building a conribution form, or altering the profile for a form, the Javascript rightly detects duplciate fields and prevents saving. Would like to make an exception for Free HTML fi...Overview
----------------------------------------
When building a conribution form, or altering the profile for a form, the Javascript rightly detects duplciate fields and prevents saving. Would like to make an exception for Free HTML fields (could be expanded to anything from the Formatting section if that section should expand)
Current workaround
----------------------------------------
Saving after each change gets around this for now
Proposed behaviour
----------------------------------------
alter the markDuplicates() method so that is_duplicate class is only applied when the ufFieldModel does not have the label 'Free HTML'. This will allow multiple Free HTML fields for formatting forms
Proposed solution
----------------------------------------
civicrm/js/model/crm.uf.js
![markDuplicates](/uploads/fe6b7f9c7da464418d2bd6a27f75639a/markDuplicates.PNG)https://lab.civicrm.org/dev/core/-/issues/4019Contribution page with recurring payment and Separate membership payment fail...2023-11-23T06:52:26ZshaneonabikeContribution page with recurring payment and Separate membership payment fails to pass contributionRecurIDOverview
----------------------------------------
_Sorry for the long title_
Contribution pages which are setup with recurring memberships, additional contribution amounts, and separate membership payment result in no ```contributionRec...Overview
----------------------------------------
_Sorry for the long title_
Contribution pages which are setup with recurring memberships, additional contribution amounts, and separate membership payment result in no ```contributionRecurID``` being setup and therefore (in the case of [iATS](https://github.com/iATSPayments/com.iatspayments.civicrm/issues/397)) no recurring payment setup.
In the case of iATS, and probably other payment processors, this ID is actually used to setup the recurring payment. Ironicaly, the is_recur is being passed so this seems clearly a bug.
Reproduction steps
----------------------------------------
1. Create a Membership Contribution page
2. Check-off Contribution Amounts section enabled
2. Add a few additional contribution amounts
3. Don't set recurring for the Contribution Amounts (although another interesting testing scenario)
4. Add a Membership with the option to renew
5. Check off Separate Membership payment_ <== this is the key
6. Use this form (test or live)
7. Choose not to add an additional contribution
8. Choose your membership and check-off auto-renew
9. Process the form
10. No client code is returned, client is set as auto-renew but there is no payment token setup (```contributionRecurID```)
![201234614-daaba710-a38d-4628-a843-951a2152dcf8](/uploads/886562673d42fb45f1e1ebb38903b971/201234614-daaba710-a38d-4628-a843-951a2152dcf8.png)
Current behaviour
----------------------------------------
The following occurs:
+ Membership transaction is made with ```is_recur``` set, but no ```contributionRecurID``` set
+ Transaction completes, but no recurring account is created (at least for iATS) because of missing ID
Ironically, turning off the ```Separate Contribution Amount``` results in the ID to be created, and everything runs smoothly. The problem with this scenario is there are loads of people who might want to do a one-time donation, but not have that repeat each year.
```
nov. 10 19:06:12 [warning] params array (
'qfKey' => 'cut',
'entryURL' => 'cut',
'email-Primary' => 'cut',
'first_name' => 'Administrateur',
'last_name' => 'SymbioTIC',
'street_address-1' => '312312',
'city-1' => '312',
'postal_code-1' => '312',
'country-1' => '1039',
'state_province-1' => '1110',
'phone-Primary-1' => '321312',
'preferred_language' => 'fr_CA',
0 => '',
1 => '',
'group' =>
array (
2 => '',
3 => '',
),
'custom_11' => 'test',
'contact_sub_type_hidden' => 'Membre_ami',
'hidden_processor' => '1',
'credit_card_number' => 'testcc',
'cvv2' => '123',
'credit_card_exp_date' =>
array (
'm' => '5',
'Y' => '2032',
),
'credit_card_type' => 'Visa',
'billing_first_name' => 'Administrateur',
'billing_middle_name' => '',
'billing_last_name' => 'SymbioTIC',
'billing_street_address-5' => '312312',
'billing_city-5' => '312',
'billing_state_province_id-5' => '1110',
'billing_postal_code-5' => '312',
'billing_country_id-5' => '1039',
'payment_processor_id' => '4',
'auto_renew' => true,
'priceSetId' => '9',
'price_16' => '60',
'price_18' => '-1',
'selectProduct' => '',
'MAX_FILE_SIZE' => '83886080',
'ip_address' => 'cut',
'amount' => '30.000000000',
'amount_level' => 'null',
'selectMembership' => '4',
'year' => '2032',
'month' => '5',
'card_type_id' => 1,
'pan_truncation' => '2220',
'currencyID' => 'CAD',
'is_pay_later' => 0,
'is_recur' => 1,
'frequency_interval' => '1',
'frequency_unit' => 'year',
'invoiceID' => 'cut',
'is_quick_config' => 1,
'email-5' => 'cut',
'description' => 'Contribution en ligne: Adhésion Membre Ami',
'accountingCode' => NULL,
'is_test' => 1,
'campaign_id' => NULL,
'middle_name' => '',
'email' => 'cut',
'street_address' => '312312',
'city' => '312',
'state_province' => 'QC',
'postal_code' => '312',
'country' => 'CA',
'cms_contactID' => '2',
'skipLineItem' => 1,
'total_amount' => '30.000000000',
'tax_amount' => 0.0,
'contactID' => '2',
'financialTypeID' => '2',
'trxn_id' => NULL,
'contributionID' => 384,
)
nov. 10 19:06:12 [warning] is_recur: false
```
Expected behaviour
----------------------------------------
+ Choosing ```Separate Contribution Amount``` should not lead to a missing ContributionRecurID
+ ID is passed and a recurring account is created properlyhttps://lab.civicrm.org/dev/financial/-/issues/211Sending receipt auto when editing a payment (editing financial trx payment)2023-01-18T20:26:40Zlevi.kSending receipt auto when editing a payment (editing financial trx payment)@JoeMurray
Steps to reproduce
1. Add a contribution
2. Edit the payment (the edit needs to be of the sort that will create a minus and plus transaction) like changing a payment method
(This does not happen when editing the financial...@JoeMurray
Steps to reproduce
1. Add a contribution
2. Edit the payment (the edit needs to be of the sort that will create a minus and plus transaction) like changing a payment method
(This does not happen when editing the financial type on the contribution eventhough it effects a plus and minus transaction (when the account is different))
3. The system will then send a unwanted email receipt (think its using the payment receipt (not contribution receipt)
Drupal 7
civicrm 5.53.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3917Incorrect currency displayed for contribution2023-11-23T07:47:00ZKurund JalmiIncorrect currency displayed for contributionCreate a contribution page and set the currency other than default currency.
Confirm and thank you page displays default currency instead of one that's configured.Create a contribution page and set the currency other than default currency.
Confirm and thank you page displays default currency instead of one that's configured.Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/3858Email displays twice on Contribution Confirmation/Thank-you pages2023-11-23T07:47:00ZJonGoldEmail displays twice on Contribution Confirmation/Thank-you pagesOverview
----------------------------------------
If you have a profile on your contribution page that includes an email field, the email appears twice on the Confirmation and Thank-You pages.
Reproduction steps
------------------------...Overview
----------------------------------------
If you have a profile on your contribution page that includes an email field, the email appears twice on the Confirmation and Thank-You pages.
Reproduction steps
----------------------------------------
1. Create a contribution page.
1. Add a profile to the page that contains an email.
1. Submit a contribution.
Current behaviour
----------------------------------------
![Selection_1638](/uploads/e0bfd95675953dadba161aa20e658a99/Selection_1638.png)
Expected behaviour
----------------------------------------
![Selection_1637](/uploads/9c06ec7dc2f1537c860e904ba02f76d4/Selection_1637.png)
Comments
----------------------------------------
When an email field is present in a profile, we correctly hide the email field from the main contribution page. This extends that behavior to the confirmation and thank-you.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3819Contribution type specific custom data not shown on Pledge Payment form2022-08-30T09:25:36ZyashodhaContribution type specific custom data not shown on Pledge Payment formSteps to replicate :
- Create custom data for entity Contribution of financial type Donation.
![custom_fields](/uploads/cc517d654e574b63686b40c640306c0b/custom_fields.png)
- Check when you create a contribution and set the financial t...Steps to replicate :
- Create custom data for entity Contribution of financial type Donation.
![custom_fields](/uploads/cc517d654e574b63686b40c640306c0b/custom_fields.png)
- Check when you create a contribution and set the financial type Donation, the field is loaded on form.
![donation_only](/uploads/2cf7222d745b53268d403ab4b082fe75/donation_only.png)
- Create a pledge of financial type Donation.
- Record pledge payment and it should take to contribution with financial type Donation pre-filled
![new_pledge_payment](/uploads/c6952707b12344500e3252281f687a11/new_pledge_payment.png)
- The custom data fields (donation only) are missing though on load. On change of financial type, the custom data loads. It should work on on load as well.https://lab.civicrm.org/dev/core/-/issues/3807Download invoice button on contribution fails to attach it to activity on win...2024-03-28T00:43:35ZDaveDDownload invoice button on contribution fails to attach it to activity on windowsEverything else works, but the attachment doesn't get attached to the activity.
In https://github.com/civicrm/civicrm-core/blob/2aaf9d423288b5acb322379eb135324f380faca4/CRM/Core/BAO/File.php#L117-L130, it uses DIRECTORY_SEPARATOR when i...Everything else works, but the attachment doesn't get attached to the activity.
In https://github.com/civicrm/civicrm-core/blob/2aaf9d423288b5acb322379eb135324f380faca4/CRM/Core/BAO/File.php#L117-L130, it uses DIRECTORY_SEPARATOR when it should just always use '/', and in the one place it does need to use DIRECTORY_SEPARATOR it only checks '/':
```php
$path = explode('/', $data); // <--- THIS IS WRONG
$filename = $path[count($path) - 1];
// rename this file to go into the secure directory
if ($entitySubtype) {
$directoryName = $config->customFileUploadDir . $entitySubtype . DIRECTORY_SEPARATOR . $entityID;
}
else {
$directoryName = $config->customFileUploadDir;
}
CRM_Utils_File::createDir($directoryName);
if (!rename($data, $directoryName . DIRECTORY_SEPARATOR . $filename)) {
```https://lab.civicrm.org/dev/financial/-/issues/203False-positive duplicate detection caused by webform not passing correct par...2024-01-16T19:36:50ZAllenShawFalse-positive duplicate detection caused by webform not passing correct parameters to Authorize.net - it needs to pass contributionID(Joinery internal reference: "Trello#142: Membership Application and Payment Process Not Working")
From what I understand so far, it seems there's a well-thought effort to use propertybag to standardize parameter names in payment proces...(Joinery internal reference: "Trello#142: Membership Application and Payment Process Not Working")
From what I understand so far, it seems there's a well-thought effort to use propertybag to standardize parameter names in payment processors. Here's one area where this effort seems incomplete and easily improved:
There are a few places in `CRM_Core_Payment_AuthorizeNet::doPayment()` where directly accessing `$params` could (and does) cause problems; it seems right to switch these to `$propertybag`. (BTW I think that usage of `propertybag` in the context of alterPaymentProcessorParams hook is still not appropriate, so I'm not suggesting changes to that usage within this method.)
**Specific observable problem:**
(I can create a more detailed and stripped-down recipe if needed, but hoping to avoid the effort.)
- On a site with: D7, civicrm 5.49.5, webform_civicrm.module, and contributiontransactlegacy extension
- We have a webform which accepts membership signups, payable through the core Authorize.net payment processor.
- Payments made through this webform are actually transacted in Authorize.net, but the user is given the error, 'It appears that this transaction is a duplicate. Have you already submitted the form once? If so there may have been a connection problem. Check your email for a receipt from Authorize.net. If you do not receive a receipt within 2 hours you can try your transaction again. If you continue to have problems please contact the site administrator.'
- FWIW I have observed that the below corrective measure fixes this problem for this site.
**Why this error happens:**
- `CRM_Core_Payment_AuthorizeNet::doPayment()` calls `$this->checkDupe($authorizeNetFields['x_invoice_num'], $params['contributionID'] ?? NULL)` (see [line 171](https://github.com/civicrm/civicrm-core/blob/a1278f71bd804c8013600793916a692b4345e4a2/CRM/Core/Payment/AuthorizeNet.php#L171)) to detect a duplicate transaction.
- However, `$params['contributionID']` is undefined. (On the other hand, `$params['contribution_id']` is defined, as is `$propertyBag->getContributionID( )`).
- Since `checkDup()` gets a NULL value for `$contributionId`, it always thinks the contribution is a duplicate, so we get the above error message.
**Corrective measueres**
1. Seems like the intent of `propertybag` is to clear up exctly this kind of naming inconsistency. I suggest changing Line 171 to use `$propertyBag->getContributionID( )` instaed of `$params['contributionID']`.
2. [Line 146](https://github.com/civicrm/civicrm-core/blob/a1278f71bd804c8013600793916a692b4345e4a2/CRM/Core/Payment/AuthorizeNet.php#L146), which tries to read `$params['is_recur']` and `$params['contributionRecurID']`, is probably also a good candidate for similar cleanup?
Should I go head with a PR or is more discussion needed?https://lab.civicrm.org/dev/financial/-/issues/202Unable to update recurring amount when using Sales Tax2022-08-03T15:19:05ZKarinGUnable to update recurring amount when using Sales TaxHitting Edit on the template contribution (with or without line item editor extension - June 2022 version) -> saving it [multiple times] -> does not update the amount in the recurring series -> note the mismatches of amounts:
![image](/...Hitting Edit on the template contribution (with or without line item editor extension - June 2022 version) -> saving it [multiple times] -> does not update the amount in the recurring series -> note the mismatches of amounts:
![image](/uploads/8280ff94ddb4e66ba1368e64c1d4b72a/image.png)https://lab.civicrm.org/dev/financial/-/issues/201Stop adding 'In Progress' and 'Overdue' statuses to civicrm_contribution.cont...2022-09-15T21:47:08ZeileenStop adding 'In Progress' and 'Overdue' statuses to civicrm_contribution.contribution_status_id option groupThis has been around as a back burner project for a while but didn't have it's own gitlab ... tada
A long long time ago contribution, contribution recur, payments, pledges and pledge payments shared the same option group for their statu...This has been around as a back burner project for a while but didn't have it's own gitlab ... tada
A long long time ago contribution, contribution recur, payments, pledges and pledge payments shared the same option group for their status & some nasty magic massaged values in and out. Overdue and In progress 'leaked' from these other entities onto the contribution in a long-ago regression but was never intended as a contribution status option value in core.
The plan is to stop adding those statuses on NEW installs. (We might add a message on non-new installs that have them but we don't really want to remove them).
Unfortunately this has been a slow-burner as the tests found code places referencing the wrong option group list in many cases - I've slowly been whittling these down & as of writing three tests are failing
https://github.com/civicrm/civicrm-core/pull/23074
Note that this was notified in a long-ago dev-digest and steps have been taken in the Sepa extension (the only one identified as using these statuses) to ensure they are presenthttps://lab.civicrm.org/dev/financial/-/issues/200Contribution status’s are ambiguous (WIP)2022-09-10T05:42:18ZJamie Novick - CompucoContribution status’s are ambiguous (WIP)**Background:**
Contribution status’s are ambiguous in CiviCRM and can lead to confusion over the current state of an invoice or contribution and whether there are amounts owed or owing to the contributor. This leads to a wealth of prob...**Background:**
Contribution status’s are ambiguous in CiviCRM and can lead to confusion over the current state of an invoice or contribution and whether there are amounts owed or owing to the contributor. This leads to a wealth of problems about what the intention of the user really is in a number of scenarios when they change the contribution status.
Examples:
| Example | Narrative | Video |
| ------ | ------ | ------ |
| Example 1a: Overpayment / pending refund | A contribution which is created for $100 donation, but pending. We then record an overpayment of $120. Hypothetically the contribution is overpaid by $20 and should be pending refund. This is not shown in CiviCRM. There is nothing showing the user that there is an overpayment of $20.| ![1-Overpayment](/uploads/74eca492a8d044aa17033dd681922c4a/1-Overpayment.webm)
| Example 1b: Change contribution status to refunded | We can further demonstrate this by taking the same contribution and then changing the status of the contribution to refunded. This raises the question of what this means? Does this reflect the users intention to: Cancel the original debt of $100 (i.e. to credit note the original amounts owed and clear the balance Or reflect the fact a refund was made for the payment of $120, but that they are still owed the original $100 Or both? CiviCRM has refunded the original value of the invoice, i.e. $100, even though the payment of $120 was received. As such we still owe $20 but this is not shown in CiviCRM.|![2-Change_status_to_refunded](/uploads/bf9eae010687771d440b4baa0d528d1e/2-Change_status_to_refunded.webm)
| Example 2: A typo entered in the wrong contribution amount | Add a contribution for $100 and set as completed. Realised that actually the contribution was $120. System will automatically add the additional $20 payment. Note: If this was a change in the line items of an invoice, it would not be safe to assume we received the additional payment. The aim of the user might be to state the obligation to pay was $120. Also it probably wasn’t 2 separate payments and hence we should reverse out the first payment (-100) and then make a second payment for the full amount (+120) | ![Updating_a_contribution_amount_error](/uploads/bda0cc37c9c5911b54bb429367bdffbf/Updating_a_contribution_amount_error.webm)
Much of this stems from the contribution status field being both be the driver of changes to the contribution (i.e. by changing the status to completed or refunded) or changed itself (i.e. the result of changes to the position of the contribution) by recording payments or refunds.
As such this is a proposal to simplify this workflow so that the the contribution status is only the result of the status of the contribution, and can no longer be used to change the status of the contribution.
We would retain the ability to make changes to the contribution status via the API for backwards compatibility until extensions can adopt the new model.
**Further ramblings (feel free to skip this part if you are not too interested in accounting principles)**
Accounting has simple and sounds principles for dealing with all of this.
“Obligations” are managed by 2 documents: Invoices and Credit notes. An invoice would stipulate what is obligated. This can be reduced by creating a credit note, which would then reduce the obligated amount.
It’s worth noting that for sales tax (for example VAT) purposes invoices should be sequentially numbered and should not be edited once they are generated. Hence usually you would not just simply delete an invoice to reduce the obligated amount, you would create a credit note for some or all of the amount, apply it to the invoice and send that to the customer to show the reduce in their balance owed to you.
As such I think in CiviCRM we need to fully enforce the split of concepts of the “obligation” and the actual payments (or refunded) amounts. Currently we have started on the journey towards that where Contributions (and line items on them) represent the obligations in most cases, and payments (or financial transactions of type payment) are the payments.
The contribution status should be a reflection of the net of that position. Does the customer owe us money (= pending or partially paid*) or is the balance settled (= completed) or do we owe them money (= pending refund)?
</details>
**Proposed changes:**
1. Recalculate the contribution status whenever a contribution is created or updated
We should recalculate the contribution status whenever a contribution is created or updated based on the following rules:
| Ref | Calculation | Status |
| ------ | ------ | ------ |
| 1 | If there are no payments or refunds | Pending (arguably there would be a better label for this but in order to avoid making actual changes to the contribution status options this would seem to be the best fit) |
| 2 | If the sum of the line items (including any tax line items) > (sum of payments received - sum of refunds paid out) | Partially paid |
| 3 | If the sum of the line items (including any tax line items) < (sum of payments received - sum of refunds paid out) | Pending refund |
| 4 | If the sum of the line items (including any tax line items) = (sum of payments received - sum of refunds paid out) | Completed |
2. Changes to the User interface:
| Screen | How it looks currently | How it will work | Changes required |
| ------ | ------ | ------ |------ |
| New contribution screen | ![image](/uploads/568a11ebd7cc0b44edc36077d06f62d8/image.png) | ![Create_new_contribution](/uploads/cb028a89f3c3cc2c3798128efaa4e0d6/Create_new_contribution.png) | We split the "obligation" with the "payment". As such we remove the contribution status field from this screen and instead allow people to decide whether they want to record the "payment" at the same time as recording the "obligation" by checking the "Record payment" checkbox. The contribution status would then be calculated using the logic above. i. |
| View contribution screen (one line item) | ![Screenshot_2022-08-29_at_11.26.55](/uploads/02854f20d41d8ffec5159fa1977627e0/Screenshot_2022-08-29_at_11.26.55.png) | | No Changes |
| View contribution screen (multiple line items) || | |
| Edit contribution screen (one line item) | ![Screenshot_2022-08-29_at_11.30.42](/uploads/6faaed62b313698c1a4346956f48e719/Screenshot_2022-08-29_at_11.30.42.png)| ![Screenshot_2022-08-29_at_11.37.56](/uploads/68293bdc8d48c548606793c6a64d159d/Screenshot_2022-08-29_at_11.37.56.png)| Status field becomes read only and we introduce a button to cancel the contribution. See below for new screen for cancelling a contribution|
| Edit contribution screen (multiple line items) || | |
| New membership screen | ![image](/uploads/568a11ebd7cc0b44edc36077d06f62d8/image.png) | cell | ------ |
| View membership screen (one line item) | | ||
| View membership screen (multiple line items) | | ||
| Edit membership screen (one line item) | | ||
| Edit membership screen (multiple line items) | | ||
| New event participant screen | ![image](/uploads/568a11ebd7cc0b44edc36077d06f62d8/image.png) | ![New_participant](/uploads/7837cf2271b10bb5824d11483221037a/New_participant.png) | Change the checkbox "Record Payment" to "Record Contribution" OR have a toggle to allow the admin to decide whether they are recording a "Paid" or "Free ticket". We only need the financial type and contribution date if we are only recording the contribution (note in https://lab.civicrm.org/dev/core/-/issues/1403 we have agreed to change label of contribution received date to contribution date). The amounts / lines should come from above. |
| View event participant screen (one line item) | | ||
| View event participant screen (multiple line items) | | ||
| Edit event participant screen (one line item) | | ||
| Edit event participant screen (multiple line items) | | ||
- Removehttps://lab.civicrm.org/dev/core/-/issues/3068PDF filename on Pay later contributions is receipt.pdf2023-11-23T07:47:01Zluke.stewartPDF filename on Pay later contributions is receipt.pdfOverview
----------------------------------------
Currently if attach PDF copies to receipts is enabled and a contact completes a "pay later" contribution an email is sent with a pdf named 'receipt.pdf'
As a quick fix it is trivial to...Overview
----------------------------------------
Currently if attach PDF copies to receipts is enabled and a contact completes a "pay later" contribution an email is sent with a pdf named 'receipt.pdf'
As a quick fix it is trivial to detect in CRM/Contribute/BAO/ContributionPage::sendMail whether the payment is pay later or not and use this to change the PDF name.
We also need to check other workflows that trigger pdfs receipts.
These look to be CRM/Contribute/BAO/ContributionSoft.php which should be a similar fix to above - and also consider workflows for resending "receipts" where this is hardcoded as well.
Long term this value wouldn't be hard coded in this file but exposed through the UI as either a global setting - or potentially having a per contribution page override.
Additionally as it is currently this is not a translateable string either.
Reproduction steps
----------------------------------------
1. Enable "Attach PDF copy to receipts" via Admin -> System Settings -> Misc
1. Create a contribution page with a pay later and payment processor (dummy processor is fine) and add a $1 payment.
1. Under the Receipt options -> "Email Receipt to Contributor?" set true.
Current behaviour
----------------------------------------
When submitting the contribution form with "Pay Later" the email has "Invoice" in the subject - but the attachment filename is "receipt.pdf"
Expected behaviour
----------------------------------------
When submitting the contribution form with "Pay Later" the email has "Invoice" in the subject - but the attachment filename is "receipt.pdf"
Environment information
----------------------------------------
* __CiviCRM:__ _Master ( and Current Stable 5.46.2.)https://lab.civicrm.org/dev/user-interface/-/issues/45Introduce a way to link event participants from the associated booking.2023-06-20T22:57:12ZBradley TaylorIntroduce a way to link event participants from the associated booking.When an event booking is made, the booking is stored across two primary entities:
- One or more participants
- One contribution
When you view an event participant, the list of associated payments is listed at the bottom of that screen:...When an event booking is made, the booking is stored across two primary entities:
- One or more participants
- One contribution
When you view an event participant, the list of associated payments is listed at the bottom of that screen:
![Screenshot_2022-02-04_at_08.46.02](/uploads/e8b76fabe84694810861ace5ecfef8b9/Screenshot_2022-02-04_at_08.46.02.png)
However, the reverse is not true. There is no way to easily get to the participants, when viewing a contriubtion:
![Screenshot_2022-02-04_at_08.46.41](/uploads/a1e19956ed2bda850fea737ca2eca33e/Screenshot_2022-02-04_at_08.46.41.png)
This can make it harder for administrators to see what a contribution has been used to purchase, and harder to see what additional participants the primary booker booked.
I've not looked into the feasability of either approach, but I can see a couple of obvious ways of fitting this into the UI.
**Option 1.** Link each event line item in the line items table to the relevant participant:
![Screenshot_2022-02-04_at_08.48.17](/uploads/cba5c2fb9239c82ecedaefe02adaa31d/Screenshot_2022-02-04_at_08.48.17.png)
(I'm not sure how this option would work with the line item editor extension)
**Option 2.** Introduce a new table of participants:
![Screenshot_2022-02-04_at_08.53.53](/uploads/c3565698dff7fae04900f47226526643/Screenshot_2022-02-04_at_08.53.53.png)
Similar thinking could be employed to link to the associated membership to a membership payment, but I thought I'd get the conversation going in relation to event bookings first.https://lab.civicrm.org/dev/core/-/issues/3050Error thrown when 'remove'ing from CiviContribute Batch2022-11-02T00:48:39ZmarshError thrown when 'remove'ing from CiviContribute BatchOverview
----------------------------------------
Civi throws an error when working with Accounting Batches. It's kind of hard to pin down - the front end gives the default / standard / very helpful
No response from the server. Check yo...Overview
----------------------------------------
Civi throws an error when working with Accounting Batches. It's kind of hard to pin down - the front end gives the default / standard / very helpful
No response from the server. Check your internet connection and try reloading the page.
Reproduction steps
----------------------------------------
- add a new accounting Batch (Contributions > Accounting Batches > New Batch)
- Assign a contribution to the batch
- try to remove the contribution from the batch
- at this point the message is displayed:
message, although ConfigAndLog does give a bit more, i.e.:
$Fatal Error Details = array:3 [
"message" => "Cannot delete EntityBatch with no id."
"code" => null
"exception" => CRM_Core_Exception {#2039
-errorData: array:1 [
"error_code" => 0
]
#cause: null
-_trace: null
#message: "Cannot delete EntityBatch with no id."
#code: 0
#file: "/var/www/html/drupal7/sites/all/modules/civicrm/CRM/Core/DAO.php"
#line: 958
trace: {
/var/www/html/drupal7/sites/all/modules/civicrm/CRM/Core/DAO.php:958 {
› if (empty($record['id'])) {
› throw new CRM_Core_Exception("Cannot delete {$entityName} with no id.");
› }
}
/var/www/html/drupal7/sites/all/modules/civicrm/CRM/Batch/BAO/EntityBatch.php:39 { …}
/var/www/html/drupal7/sites/all/modules/civicrm/CRM/Financial/Page/AJAX.php:207 { …}
/var/www/html/drupal7/sites/all/modules/civicrm/CRM/Utils/REST.php:266 { …}
/var/www/html/drupal7/sites/all/modules/civicrm/CRM/Utils/REST.php:550 { …}
/var/www/html/drupal7/sites/all/modules/civicrm/CRM/Core/Invoke.php:279 { …}
/var/www/html/drupal7/sites/all/modules/civicrm/CRM/Core/Invoke.php:69 { …}
/var/www/html/drupal7/sites/all/modules/civicrm/CRM/Core/Invoke.php:36 { …}
/var/www/html/drupal7/sites/all/modules/civicrm/drupal/civicrm.module:458 { …}
/var/www/html/drupal7/includes/menu.inc:527 { …}
/var/www/html/drupal7/index.php:21 { …}
}
}
]
This has alr3eady been [raised on stackechange](https://civicrm.stackexchange.com/questions/41126/entitybatch-with-no-id-error-when-remobing-items-from-accounting-batches?noredirect=1#comment48386_41126)
Current behaviour
----------------------------------------
![image](/uploads/f3431d6145caa54bbd5c96dec58ac3cf/image.png)
![image](/uploads/4dae3c200fc6696f0ecd6f5b25fd6747/image.png)
Expected behaviour
----------------------------------------
The item is removed from the batch
Environment information
----------------------------------------
- reproduced on dmaster
- using Chromium locally on a Debian box