Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-12-21T16:04:38Zhttps://lab.civicrm.org/dev/core/-/issues/4027Crash when viewing contact's contribution tab and a contribution has no line ...2022-12-21T16:04:38ZJonGoldCrash when viewing contact's contribution tab and a contribution has no line itemsContributions are *supposed* to all have line items, but this isn't universally true - in particular, it seems like imported contributions don't all have them. This caused no issues until Civi 5.53, specifically PR [#24142](https://gith...Contributions are *supposed* to all have line items, but this isn't universally true - in particular, it seems like imported contributions don't all have them. This caused no issues until Civi 5.53, specifically PR [#24142](https://github.com/civicrm/civicrm-core/pull/24142).
### Steps to replicate
* Manually delete (in the db) the line item for the "template" contribution for a recurring contribution. I thought that this would be the first contribution in the series, but apparently it's the most recent.
* Attempt to view the contact's contribution tab containing that contribution
### Expected Result
View the contribution tab normally.
### Actual Result
```
PHP Fatal error: Uncaught TypeError: CRM_Financial_BAO_Order::setPriceSetID(): Argument #1 ($priceSetID) must be of type int, null given, called in /home/jon/local/mysite/web/wp-content/plugins/civicrm/civicrm/CRM/Financial/BAO/Order.php on line 841 and defined in /home/jon/local/mysite/web/wp-content/plugins/civicrm/civicrm/CRM/Financial/BAO/Order.php:472"
```5.56.1JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4000only update `contributionRecur` when `templateContribution` is updated IF it ...2023-03-16T21:47:09Zeileenonly update `contributionRecur` when `templateContribution` is updated IF it is actively marked as suchIn https://github.com/civicrm/civicrm-core/pull/21473 code was added to update the Currency and Amount of the template contribution is updated. However, the code appears to me to be too aggressive and updating the amount or currency of A...In https://github.com/civicrm/civicrm-core/pull/21473 code was added to update the Currency and Amount of the template contribution is updated. However, the code appears to me to be too aggressive and updating the amount or currency of ANY contribution in the series causes it to update. There are good reasons to update individual contributions without any implicit template update.5.61.0https://lab.civicrm.org/dev/core/-/issues/3918Contribution in Australia returns yellow error banner with "setBillingCountry...2022-11-22T22:57:09ZjhungerfordContribution in Australia returns yellow error banner with "setBillingCountry expects ISO 3166-1 alpha-2 country code"Overview
----------------------------------------
After upgrading to CiviCRM 5.54.0, test donations result in a yellow error banner with the message ```setBillingCountry expects ISO 3166-1 alpha-2 country code```. I haven't tried a real ...Overview
----------------------------------------
After upgrading to CiviCRM 5.54.0, test donations result in a yellow error banner with the message ```setBillingCountry expects ISO 3166-1 alpha-2 country code```. I haven't tried a real donation. We are located in Australia, and we use Stripe as the payment processor.
I asked a question about this issue here: https://chat.civicrm.org/civicrm/pl/atwjzr4ozf8fbdkokzegze9iiw
Reproduction steps
----------------------------------------
1. Upgrade a CiviCRM site to 5.54.0
2. Navigate to a Test-drive contribution page
3. Attempt to make a test contribution
Current behaviour
----------------------------------------
A yellow error banner appears with the message ```setBillingCountry expects ISO 3166-1 alpha-2 country code```.
Expected behaviour
----------------------------------------
The test contribution should be processed, and the donor should be redirected to the thank-you page.
Environment information
----------------------------------------
* __Browser:__ Chromium 105.0.5195.125 (Official Build) Arch Linux (64-bit)
* __CiviCRM:__ 5.54.0 (upgraded from 5.53.0)
* __PHP:__ 7.4.30
* __CMS:__ Drupal 7.92, also tested on Drupal 9.4.7
* __Database:__ 10.3.36-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
* __Web Server:__ Apache 2.4
* __civicrm-Stripe version:__ 6.7.11, also tested on 6.7.10
* __Payment Shared version:__ 1.2.9, also tested on 1.2.8
Comments
----------------------------------------
I'll post an example of a failing test contribution page in the chat linked above.
Reverting to CiviCRM 5.53.0 results in a working contribution page.5.55.1https://lab.civicrm.org/dev/core/-/issues/3790Pledge status is missing on View Pledge page2022-09-09T23:27:08ZyashodhaPledge status is missing on View Pledge pageWhen clicking on View Pledge, pledge status is blank.
![pledge_Status_missing](/uploads/7a9246fce9427cdc7a23c2b6fe11ddfd/pledge_Status_missing.png)
Fix this bug to display the pledge status.When clicking on View Pledge, pledge status is blank.
![pledge_Status_missing](/uploads/7a9246fce9427cdc7a23c2b6fe11ddfd/pledge_Status_missing.png)
Fix this bug to display the pledge status.5.54.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3774Can't submit backend credit card contribution unless you have at least one pa...2022-08-04T21:07:47ZJonGoldCan't submit backend credit card contribution unless you have at least one payment processor that supports a future start dateIf you don't have a payment processor that supports a future start date, you can't submit a credit card contribution.
### Steps to replicate
* On a buildkit site, add a PayPal Pro payment processor. The creds don't have to be valid.
* S...If you don't have a payment processor that supports a future start date, you can't submit a credit card contribution.
### Steps to replicate
* On a buildkit site, add a PayPal Pro payment processor. The creds don't have to be valid.
* Submit a backend credit card contribution with PayPal Pro. Should go through (or tell you invalid credentials).
* Delete the default processor of type "Dummy Payment Processor".
* Submit another backend credit card contribution with PayPal Pro.
### Expected Result
Absence of a dummy test processor shouldn't affect the ability to submit a credit card processor.
### Actual result
```
Please correct the following errors in the form fields below:
Date Received is a required field.
```
### Why
In `CRM_Contribution_Form_AbstractEditPayment::assignProcessors()` is this line:
```
$this->assign('processorSupportsFutureStartDate', CRM_Financial_BAO_PaymentProcessor::hasPaymentProcessorSupporting(['FutureRecurStartDate']));
```
This will return `TRUE` if *any* payment processor supports a future start date. Which in turn causes the `receive_date` to appear on `templates/CRM/Contribute/Form/Contribution.tpl`.
Without the `receive_date` on the form, even hidden, you can't submit the form.
The workaround is to create a dummy processor on your site. I have to run, but tomorrow I'll try to put together a PR that fixes this at the template level.
Is this a regression? I mean, technically yes, but it's two years old. And tricky to catch because the test suite creates the dummy processor in `setUp()`. To catch this we might have to move that out of `setUp()` and into its own helper function.5.52.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3460AuthX breaks Contribution Batch functionality (and more)2022-12-21T16:04:08ZJonGoldAuthX breaks Contribution Batch functionality (and more)A number of core CiviCRM pages call the `civicrm/ajax/rest` endpoint. When AuthX is enabled, these functions fail with an "Invalid Credential" error.
### Steps to replicate
* enable AuthX.
* Create a new Contribution Batch (you don't n...A number of core CiviCRM pages call the `civicrm/ajax/rest` endpoint. When AuthX is enabled, these functions fail with an "Invalid Credential" error.
### Steps to replicate
* enable AuthX.
* Create a new Contribution Batch (you don't need to add anything to it).
* Go to **Contributions » Accounting Batches » Open Batches**.
* Select **more » Delete**.
### Expected Result
Batch is deleted (which is what happens when AuthX is disabled)
### Actual Result
"An error occurred while processing your request.". Dev tools show `FATAL: Invalid credential`.
A search of the codebase shows several references to `civicrm/ajax/rest` - mostly in out-of-the-way areas like Premiums or Accounting Batches.
I'm not sure what the correct approach is - my sense from my reading was that @totten had accounted for this, so I'd appreciate his eyes on this. I assume creating a second endpoint that replicates the original behavior defeats the purpose here. I also see that `CRM_Utils_REST::ajax()` has `self::isWebServiceRequest()` which does its own AuthX checking, but the request never reaches `CRM_Utils_REST::ajax()` because the request is denied when `CRM_Core_Invoke::_invoke()` calls `civi.invoke.auth`.5.56.1https://lab.civicrm.org/dev/core/-/issues/3413setAmount requires a numeric amount value2022-05-05T06:27:07Zmagnolia61setAmount requires a numeric amount valueOverview
----------------------------------------
Since https://github.com/civicrm/civicrm-core/pull/21583 our installation has a problem with making contribution payments through the contribution checksum link fails if the Thousands Sep...Overview
----------------------------------------
Since https://github.com/civicrm/civicrm-core/pull/21583 our installation has a problem with making contribution payments through the contribution checksum link fails if the Thousands Separator and Decimal Delimiter are different than default.
Reproduction steps
----------------------------------------
1. create a pending contribution
2. set locale to the following:<br>
![Screenshot_2022-04-23_112132](/uploads/890f07b518c9102b2eb551b5de5311c3/Screenshot_2022-04-23_112132.png)<br>
(common in the Netherlands)
3. pay through a contribution link with checksum<br> (example: https://www.example.nl/civicrm/contribute/transact?reset=1&id=7&ccid=123&cid=456&cs=9982c0a392534059a7ae6b4f970f394c_1650623762_5648)
4. payment fails with:
setAmount requires a numeric amount value (reproduced on the sandbox)
![Screenshot_2022-04-23_112051](/uploads/db41c7e3c5c6544f4c91883dbcf43347/Screenshot_2022-04-23_112051.png)
Current behaviour
----------------------------------------
With Thousands Separator set to . and Decimal Delimiter set to , (as we do in the Netherlands) contribution checksum link payments fail
Expected behaviour
----------------------------------------
The payments should succeed :-)
Environment information
----------------------------------------
- CiviCRM: 5.48
- CMS: Drupal 7.89
- PHP: 7.4.29 (fpm-fcgi)
- Database: 10.5.15-MariaDB-0+deb11u1 engine: InnoDB 10 row format: Dynamic
- Webserver: Apache/2.4.53 (Debian)
- OS: Linux
Comments
----------------------------------------
First I thought this had to do with omnipaymultiprocessor but this morning I tested with some more different payment methods
We found https://github.com/civicrm/civicrm-core/pull/21583 to be the change that caused our problem.
Specifically in Civi/Payment/PropertyBag.php the line about 'total_amount'
```
protected static $propMap = [
'amount' => TRUE,
'total_amount' => 'amount',
```
When we remove the 'total_amount' line payments work fine, even with our decimal separator settings.
I am not sure if that would be the solution or only helps to find a real solution.
NOTE: integral payments with event registrations work fine. It is the payment links that are affected.
@mattwire would you be able to look into this?5.49.0https://lab.civicrm.org/dev/core/-/issues/3410Registering a participant with Pending event payment gives misleading informa...2023-09-06T00:16:18ZspalmstromRegistering a participant with Pending event payment gives misleading information.1. Register a participant for an event.
1. Record a payment as pending, not complete.
The payment is not recorded in the database, but is displayed in the receipt emailed to that participant. Surely the receipt should not show that mone...1. Register a participant for an event.
1. Record a payment as pending, not complete.
The payment is not recorded in the database, but is displayed in the receipt emailed to that participant. Surely the receipt should not show that money has been paid when it is not recorded on the system?
No record of payment here:
![image](/uploads/cd696e04f6227e4446e142e35ffa81a0/image.png)
but here is the body of the email.
Dear First_1003,
===========================================================
Event Information and Location
===========================================================
Conference 2022
13th May, 2022 12:00 AM-15th May, 2022 12:00 AM
xxxxxxx
xxxxxx
xxx, xxxe xxx xxx
xxx xxx
Event Contacts:
Phone: xxxx
Email: xxxxx
===========================================================
Registered Email
===========================================================
first_1003.last_1003@somedomain.com
===========================================================
Event Fee(s)
===========================================================
---------------------------------------------------------
Item Qty Each Total
----------------------------------------------------------
En suite double 1 £ 150.00 £ 150.00
**Total Paid: £ 20.00
Balance: £ 130.00**
Registration Date: 31st January, 2022 4:40 PM
Transaction Date: 31st January, 2022 4:41 PM
Financial Type: Conference Fee
Paid By: Online payment
==========================================================
Conference Fields
==========================================================
Dietary Requirements:
Music:
Other:
Subsidy Fund (Optional):
==========================================================
Conference Payment
==========================================================
Payment options: Deposit of £20 per person online
Notice the payment is recorded.5.66.0https://lab.civicrm.org/dev/core/-/issues/3377Why are unique labels for price fields required?2022-04-22T16:22:10ZStoobWhy are unique labels for price fields required?This is a question not a proposal or bug report. Should a unique label for price fields be enforced (seen attached)?
Here are two use cases:
* event registration where the price of attendance changes over time (early bird) but the e...This is a question not a proposal or bug report. Should a unique label for price fields be enforced (seen attached)?
Here are two use cases:
* event registration where the price of attendance changes over time (early bird) but the event itself or the nature of the registration doesn't change
* membership registration 'special' where prior to a certain date memberships are on sale
It seems in these cases a unique label is not necessary.
![why](/uploads/5b0f604ac6fba41973e16fcfd865932b/why.png)5.47.0AllenShawAllenShawhttps://lab.civicrm.org/dev/core/-/issues/3283Contribution Summary Report: The "general total" row does not take the curren...2022-04-22T15:53:43ZdmunioContribution Summary Report: The "general total" row does not take the currency filteredWhen the contribution summary report is used by filtering for a currency other than the site's default currency, the "grand total" row shows the sign of the default currency instead of the filtered currency.
![image](/uploads/e65afcbdde...When the contribution summary report is used by filtering for a currency other than the site's default currency, the "grand total" row shows the sign of the default currency instead of the filtered currency.
![image](/uploads/e65afcbdde35490ab7602d21161c13f0/image.png)
This issue is resolved by changing the code of the following line: https://github.com/civicrm/civicrm-core/blob/2235525e475edd2573a1ad71897cd42d2ea3cdfd/templates/CRM/Report/Form/Layout/Table.tpl#L139
By the following code:
```php
{if $currencyColumn}
{$grandStat.$field|crmMoney:$row.$currencyColumn}
{else}
{$grandStat.$field|crmMoney}
{/if}
```5.29.0https://lab.civicrm.org/dev/core/-/issues/3252View Payment owned by Different contact on Membership and Participant View.2022-04-22T15:52:43ZsunilView Payment owned by Different contact on Membership and Participant View.Overview
----------------------------------------
Using Webform, we can set that, contribution assigned to contact A and Membership record will be assigned to Contact B and C (based on number Contact selected in webform). IF we visit the...Overview
----------------------------------------
Using Webform, we can set that, contribution assigned to contact A and Membership record will be assigned to Contact B and C (based on number Contact selected in webform). IF we visit the Membership Record of B and C, we can not see the linked Payment, because its owned by another contact. and there is NO way to check who own the payment record.
Current behaviour
----------------------------------------
Currently it does not show linked payment record if payment is not present on same contact.
Expected behaviour
----------------------------------------
Linked Payment record should show, irrespective of who own the payment record as long as payment is belong the respective Membership.
In this case, webform create membership payment link between each contact membership and contribution id in `civicrm_membership_payment` table.
As long as we have linking between membership and contribution id, then it shows linked payment on Membership View. Same apply to participant.
----------------------------------------
https://github.com/civicrm/civicrm-core/pull/182815.31.0https://lab.civicrm.org/dev/core/-/issues/3238Graphs on Contribution Summary report replace final row with grand total value2022-04-22T15:51:46ZAndrew WestGraphs on Contribution Summary report replace final row with grand total valueGraphs on the Contribution Summary report will include the grand total in some circumstances. To replicate on demo site:
1. Using demo data, launch the Contribution Summary report
2. Leave all settings as default
3. Refresh results a...Graphs on the Contribution Summary report will include the grand total in some circumstances. To replicate on demo site:
1. Using demo data, launch the Contribution Summary report
2. Leave all settings as default
3. Refresh results and note the grand total. Current data shows this:
![Annotation_2020-05-20_211434](/uploads/17d1b5942dde265bf0076d857396e46b/Annotation_2020-05-20_211434.png)
4. Switch to a bar chart in the top right and click 'View'. Hover over the final column and you'll see it's the grand total number:
![barchart](/uploads/3454788b2eecfc7ea4b8d44538b371d6/barchart.png)
I'm not terribly familiar with reports, but my initial fix was to add this to the top of CRM_Report_Form_Contribute_Summary::buildChart()
if ($this->_rollup) {
array_pop($rows);
}
If this makes sense I can make it a PR.5.28.0https://lab.civicrm.org/dev/core/-/issues/3105Event Registration Confirmation from waitlist crashes payment processors that...2022-06-09T01:23:08ZFrancis (Agileware)Event Registration Confirmation from waitlist crashes payment processors that expect to be able to pull contact information from the doPayment parameters (Stripe via PropertyBag)Overview
----------------------------------------
When a participant returns to the site after moving from the waitlist to a pending status, the contactID parameter is not passed through to the payment processor.
On Stripe in particular...Overview
----------------------------------------
When a participant returns to the site after moving from the waitlist to a pending status, the contactID parameter is not passed through to the payment processor.
On Stripe in particular, this causes the form to crash, payment to not be made, the Participant record to remain in pending from waitlist state, and any additional details entered into the form to be lost.
There's the potential for this to cause problem with other payment processors where contactID is expected to be passed through also.
It seems like this information should be set by the Confirmation form before handing off to the payment processor, so filing as a core bug.
Reproduction steps
----------------------------------------
1. Enable waitlist statuses in CiviCRM
2. Create an Event with Waitlist enabled, setting the payment processor to Stripe
3. Register a "Pending From Waitlist" attendee (e.g. fill the waitlist then try to register one more)
4. Attempt to use the generated link /civicrm/event/register/confirm?reset=1&participantId={id}&cs={checksum}
5. Note that the previously filled details are loaded
6. Fill in all details and confirm the registration
Current behaviour
----------------------------------------
The Form throws up the unfriendly yellow error box with `Property 'contactID' has not been set.`
Trace also appears in CiviCRM.HASH.log:
```
$Fatal Error Details = array:3 [
"message" => "Property 'contactID' has not been set."
"code" => null
"exception" => BadMethodCallException {#12711
#message: "Property 'contactID' has not been set."
#code: 0
#file: "/.../httpdocs/wp-content/plugins/civicrm/civicrm/Civi/Payment/PropertyBag.php"
#line: 291
trace: {
/.../httpdocs/wp-content/plugins/civicrm/civicrm/Civi/Payment/PropertyBag.php:291 {
› }
› throw new \BadMethodCallException("Property '$prop' has not been set.");
› }
}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/Civi/Payment/PropertyBag.php:625 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/ext/com.drastikbydesign.stripe/CRM/Core/Payment/Stripe.php:556 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Event/Form/Registration/Confirm.php:1264 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Event/Form/Registration/Confirm.php:533 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php:565 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Core/StateMachine.php:144 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Next.php:43 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php:203 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Page.php:103 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Core/Controller.php:353 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:319 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:69 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:36 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm.php:1170 { ...}
/.../httpdocs/wp-content/plugins/civicrm/includes/civicrm.basepage.php:366 { ...}
/.../httpdocs/wp-includes/class-wp-hook.php:307 { ...}
/.../httpdocs/wp-includes/class-wp-hook.php:331 { ...}
/.../httpdocs/wp-includes/plugin.php:522 { ...}
/.../httpdocs/wp-includes/class-wp.php:771 { ...}
/.../httpdocs/wp-includes/functions.php:1310 { ...}
/.../httpdocs/wp-blog-header.php:16 { ...}
/.../httpdocs/index.php:17 { ...}
}
}
]
```
Expected behaviour
----------------------------------------
Event registration is confirmed, Payment is received, email is sent, and so on
Environment information
----------------------------------------
* __Browser:__ _Any browser_
* __CiviCRM:__ _5.46.2_ (Did not see any relevant changes in 5.47.0)
* __PHP:__ _7.4_
* __CMS:__ _WordPress 5.9.1_
* __Database:__ _MariaDB 10.3_
* __Web Server:__ _Apache 2.4, Nginx latest docker_
Comments
----------------------------------------
Note that everything works up until the confirmation step.
Agileware Ref: CIVICRM-19355.51.0https://lab.civicrm.org/dev/core/-/issues/3038Import contribution fails to update payment instrument in update mode2022-05-31T13:09:04ZKurund JalmiImport contribution fails to update payment instrument in update modeSteps to replicate:
* Add a contribution record with payment method `Cheque`
* Import contribution in update mode.
Here is the sample CSV
| Total Amount | Financial Type | Payment Method | Contribution ID |
|--------------|----------...Steps to replicate:
* Add a contribution record with payment method `Cheque`
* Import contribution in update mode.
Here is the sample CSV
| Total Amount | Financial Type | Payment Method | Contribution ID |
|--------------|----------------|-----------------|-----------------|
| 100 | Donation | Cash | 10 |
Current behavior: Payment method is still `Cheque`
Expected behavior: Payment method should be `Cash`5.50.0https://lab.civicrm.org/dev/core/-/issues/2989Import of contribution fails when invalid campaign id is provided2022-02-01T23:27:10ZKurund JalmiImport of contribution fails when invalid campaign id is providedCurrently, we do not validate campaign id hence contribution import silently fails to import.Currently, we do not validate campaign id hence contribution import silently fails to import.5.47.0https://lab.civicrm.org/dev/core/-/issues/2862Support additional token entities for email letter task2021-10-12T04:23:43ZeileenSupport additional token entities for email letter taskWe've finished getting the email task to use the token processor for existing tokens (contact, contribution) and with a bit more cleanup it is 'easy' to add other entities.
However, there is a gotcha that I discovered on the contributio...We've finished getting the email task to use the token processor for existing tokens (contact, contribution) and with a bit more cleanup it is 'easy' to add other entities.
However, there is a gotcha that I discovered on the contribution task.
If I have 2 contributions in the search and you select to send me emails for both I will get 1 email - with details from only 1 of the contributions. This seems wrong. OTOH if the letter had NO contribution specific tokens it would make sense.....5.43.0https://lab.civicrm.org/dev/core/-/issues/2843Can we re-order the 'recur links'2021-09-21T22:43:40ZeileenCan we re-order the 'recur links'@jaapjansma @mattwire we went out with 5.42 to our users & have had the feedback that the new 'view template' link isn't necessarily a problem but it is a problem having it high up in the order - such that it pushes the useful links into...@jaapjansma @mattwire we went out with 5.42 to our users & have had the feedback that the new 'view template' link isn't necessarily a problem but it is a problem having it high up in the order - such that it pushes the useful links into the drop down
- can we re-order them so there is less impact on users?
![image](/uploads/3422899494fc935881979facdc8e93a2/image.png)5.42.0https://lab.civicrm.org/dev/financial/-/issues/184Using GHC as a default currency causes a fatal error with Brick/Money2022-08-31T15:25:46ZbgmUsing GHC as a default currency causes a fatal error with Brick/MoneyTo reproduce:
* Go to dmaster
* Admin > Localisation > Language etc
* Set the default currency to "GHC"
Result:
> Brick\Money\Exception\UnknownCurrencyException: Unknown currency code: GHC in Brick\Money\Exception\UnknownCurrencyExcep...To reproduce:
* Go to dmaster
* Admin > Localisation > Language etc
* Set the default currency to "GHC"
Result:
> Brick\Money\Exception\UnknownCurrencyException: Unknown currency code: GHC in Brick\Money\Exception\UnknownCurrencyException::unknownCurrency() (line 19 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/brick/money/src/Exception/UnknownCurrencyException.php).
And CiviCRM is ironically bricked, i.e. CiviCRM will systematically fatal.
The ISO code for Ghana is "GHS", which is what Brick/Money uses.
https://en.wikipedia.org/wiki/Ghanaian_cedi5.45.0https://lab.civicrm.org/dev/financial/-/issues/1805.41 rc - order api stores totals incorrectly when line items not passed in2021-08-27T05:28:36ZKarinG5.41 rc - order api stores totals incorrectly when line items not passed inReproduced on automated testing ->
5.41rc fails ->
![image](/uploads/9b90e5365869ca73f41a5f32b53ff22d/image.png)
We'll need to check if 5.40 is ok - more later!Reproduced on automated testing ->
5.41rc fails ->
![image](/uploads/9b90e5365869ca73f41a5f32b53ff22d/image.png)
We'll need to check if 5.40 is ok - more later!5.41.0https://lab.civicrm.org/dev/core/-/issues/2624Line items not visible on recurring contribution2021-07-28T14:48:48ZjaapjansmaLine items not visible on recurring contributionWhen creating a new contribution recur with a contribution page and a price set with multiple line items. The line items are not stored within the contribution recur entity.
**Steps to reproduce**
1. Create a new price set (Financial t...When creating a new contribution recur with a contribution page and a price set with multiple line items. The line items are not stored within the contribution recur entity.
**Steps to reproduce**
1. Create a new price set (Financial type donation)
2. Create a price set field (Financial type Campaign donation)
3. Create a second price set field (Financial type Products)
4. Create a contribution page:
Financial type: donation
Amounts tab: Payment Processor: test processor
Amounts tab: Contributions amount section enabled: checked
Amounts tab: Price set: _select the created price set_
Amounts tab: Recurring contributions: check
5. Create a new contribution recur through the contribution page
6. Lookup the contribution recur on the Contact Summary
**Expected result**
Showing the line items. The total amount is correct.
**Actual result**
Line items are not visible at the contribution recur.
Below a screenshot of the contribution
![Screenshot_20210520_211830](/uploads/2447b95df431002e4405559a72fec4b5/Screenshot_20210520_211830.png)
And of the recurring contribution
![Screenshot_20210520_211918](/uploads/4036a932904649bbaa7c0d93b13879fb/Screenshot_20210520_211918.png)
**Possible solution**
I have looked up the line items in the database and there are no line items linked to the recurring contribution.
So the possible solution would exists of two steps:
1. Connect the line items to contribution recur
2. Make the line items visible in a similar way as on the contribution.
**Remarks**
Creating a new contribution with the `contribution.repeattransaction` api based on the first contribution and the recurring contribution correctly creates the line items at the contribution level.
**Funding**
I have some funding to work on this. So PR's might follow soon.
**PRs**
* ~~Fix for saving line items at the recurring contribution: https://github.com/civicrm/civicrm-core/pull/20398~~
* Fix for showing the line items from the template contribution: https://github.com/civicrm/civicrm-core/pull/20399
* Fix for excluding template contributions from reports: https://github.com/civicrm/civicrm-core/pull/20450
* Fix for searching template contributions: https://github.com/civicrm/civicrm-core/pull/20451
* Fix for excluding template contributions on the contact summary tab: https://github.com/civicrm/civicrm-core/pull/20452
* Fix for adding a button view template on the recurring contributions tab: https://github.com/civicrm/civicrm-core/pull/20685
* ~~Fix for creation of template contributions: https://github.com/civicrm/civicrm-core/pull/20453~~
**To do**
* Update user documentation
* Make sure an upgrade path exists
See also financial#65.41.0jaapjansmajaapjansma