Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-22T14:38:36Zhttps://lab.civicrm.org/dev/core/-/issues/5100Payment appears as 123 units of $1 rather than one unit of $123 if using othe...2024-03-22T14:38:36ZwmortadaPayment appears as 123 units of $1 rather than one unit of $123 if using other amount fieldOverview
----------------------------------------
This appears to be a regression in CiviCRM 5.69 upwards. If you create a contribution pages that allows other amounts the amount in that field is recorded in the quantity field of the li...Overview
----------------------------------------
This appears to be a regression in CiviCRM 5.69 upwards. If you create a contribution pages that allows other amounts the amount in that field is recorded in the quantity field of the line item rather than the unit price.
It looks like the quantity and the unit price have been swapped.
Reproduction steps
----------------------------------------
1. Create a contribution page with the other amounts section enabled
2. Visit the contribution page and type an amount in 'Other amount' field
3. View the contact record - note that the quantity is the amount and the unit price is 1.00
![image](/uploads/c16ed4be20e97bb2f86d63d5842d481e/image.png)
![image](/uploads/2e27e1f53dfca423a63ef4d98a5f0042/image.png)
![image](/uploads/85840162f1fc088ddcd6de5c7565ea5d/image.png)
Current behaviour
----------------------------------------
The amount is recorded in the quantity field. The unit price is $1.00.
Expected behaviour
----------------------------------------
The quantity is 1. The amount is recorded in the unit price field.
Environment information
----------------------------------------
Tested in CiviCRM 5.69, 5.70 and 5.73alpha1 (current dmaster). It is an issue in all three versions.
I'm not sure when this stopped working, but think it is quite recent.5.71.2https://lab.civicrm.org/dev/core/-/issues/5085Incorrect fee level saved when editing event participant2024-03-18T19:23:47Zchrisgaraffachris@aghstrategies.comIncorrect fee level saved when editing event participantOverview
----------------------------------------
Editing an event participant changes the fee level and amount listed, seemingly at random.
Reproduction steps
----------------------------------------
- Register a contact for an event ...Overview
----------------------------------------
Editing an event participant changes the fee level and amount listed, seemingly at random.
Reproduction steps
----------------------------------------
- Register a contact for an event that uses a price set for fees (I'm using Summer Solstice Day Concert from dmaster in this example). Doesn't matter if they register online or an admin adds their registration
- Select Bass - $ 25.00
- Save the event registration
- Edit the event registration
- Change nothing
- Click Save
Current behaviour
----------------------------------------
The Fee level on the participant changes to something else - the specific value seems random on the first save, then doesn't seem to change.
Settings for adding the event registration:
![image](/uploads/04829e0ca7f423daf94a29b56883da07/image.png)
Display after creating the registration:
![image](/uploads/028cb9da80776075397f2df2541ee7a5/image.png)
Display after editing the registration, changing nothing, and saving:
![image](/uploads/5e63e0f24e9de983944a6c0e5873e577/image.png)
Expected behaviour
----------------------------------------
The fee level shouldn't change
Environment information
----------------------------------------
* __CiviCRM:__ Reproduced on 5.70.2, 5.71.0, dmaster (5.73.alpha1)https://lab.civicrm.org/dev/core/-/issues/5071TypeError when trying to use checkboxes with default non-membership options i...2024-03-08T04:07:50ZFrancis (Agileware)TypeError when trying to use checkboxes with default non-membership options in the Membership section of Contribution PagesOverview
----------------------------------------
If you have a PriceSet with a checkboxes field, that has default options set that **don't** have a membership type associated with them, trying to use it on a Contribution Page causes th...Overview
----------------------------------------
If you have a PriceSet with a checkboxes field, that has default options set that **don't** have a membership type associated with them, trying to use it on a Contribution Page causes that page to crash.
Observed on PHP 8.0, may not be an issue on 7.4 -
Reproduction steps
----------------------------------------
1. Create a membership price set
2. Include in this price set a Checkboxes fields with a default option that does not select a membership type, e.g.
Membership Type
[ ] General - $100
[ ] Student - $50
Be awesome
[ X ] Donate $150 to save the Northern White Rhino
3. Use this price set in the membership context of a Contribution page
4. View the contribution page on the front-end
Current behaviour
----------------------------------------
Contribution page does not load, crashes with TypeError:
```
PHP Fatal error: Uncaught TypeError: strtolower(): Argument #1 ($string) must be of type string, array given in /.../public_html/ontarget/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php:1419
```
Backtrace shows this is called from `CRM_Contribute_Form_Contribution_Main->setDefaultValues()`:
https://github.com/civicrm/civicrm-core/blob/4b75775/CRM/Contribute/Form/Contribution/Main.php#L270
(Ref 4b75775 is master at time of this report)
Expected behaviour
----------------------------------------
Contribution page should load, with defaults for all fields correctly applied
Environment information
----------------------------------------
* __CiviCRM:__ _Master, 5.70.2_
* __PHP:__ _8.0+_
Comments
----------------------------------------
I have a working patch for this, however I'm not sure the approach is entirely correct. The code in question appears to be trying to insinuate a Membership Type ID for, again an option (PriceFieldValue) which doesn't specify a membership type. Perhaps this line could... just be removed?5.72.0https://lab.civicrm.org/dev/core/-/issues/5070Contribution pending status wrong2024-03-07T18:16:21Zaydunsaidan.saunders@squiffle.ukContribution pending status wrong## Overview
After creating a Pending Contribution it lists as `Pending (Incomplete Transaction)`, not `Pending (Pay Later)`, but editing and saving with no changes causes it to show correctly.
## Reproduction steps
1. Choose a contact...## Overview
After creating a Pending Contribution it lists as `Pending (Incomplete Transaction)`, not `Pending (Pay Later)`, but editing and saving with no changes causes it to show correctly.
## Reproduction steps
1. Choose a contact.
2. `Actions` \> `Add Contribution` (or `Contributions` tab \> `Record Contribution`, or API4)
3. Choose any Financial Type and Amount, set Status to `Pending`
4. View the Contributions list
## Current behaviour
The status shows as `Pending (Incomplete Transaction)`
Then `Edit` the contribution, don't make any changes, just hit `Save`
Note that the status is now `Pending (Pay Later)`
## Expected behaviour
Should be `Pending (Pay Later)`
## Environment information
* **CiviCRM:** _Master & 5.70.0 - maybe others_
Reproducible on dmaster.demo.civicrm.org
## Comments
_See_ https://chat.civicrm.org/civicrm/pl/qcmoueddmfbm7bpfq4uauympcwhttps://lab.civicrm.org/dev/user-interface/-/issues/69Fix Additional Payment div tag issue in Accordion2024-03-07T13:40:03ZshaneonabikeFix Additional Payment div tag issue in AccordionBased on this discussion [here on pull 29448](https://github.com/civicrm/civicrm-core/pull/29448) we need to modify the divs to ensure that the Check is placed inside the Payment Details (rather than outside).
This problem existed in pr...Based on this discussion [here on pull 29448](https://github.com/civicrm/civicrm-core/pull/29448) we need to modify the divs to ensure that the Check is placed inside the Payment Details (rather than outside).
This problem existed in previous versions before. The issue lies in ```templates/CRM/Contribute/Form/AdditionalPayment.tpl``` and can be seen below.
![paymentdetails](/uploads/aea5250221b5177befc50ba34d82df5a/paymentdetails.png)
@nicol comments:
> This closing div closes the crm-accordion-body too soon so the check field is outside the border. This </div> should be removed, and the one below (line 106) brought back.
cc @nicol @noah @herbdoolhttps://lab.civicrm.org/dev/core/-/issues/5033Fatal error visiting event registration page with a disabled pricefield2024-02-28T17:30:52Zmagnolia61Fatal error visiting event registration page with a disabled pricefieldOverview
----------------------------------------
Opening a registration page with a priceset with one of the pricefields disabled results in a fatal error.
TypeError: Argument 1 passed to CRM_Event_Form_Registration::getUsedSeatsCount(...Overview
----------------------------------------
Opening a registration page with a priceset with one of the pricefields disabled results in a fatal error.
TypeError: Argument 1 passed to CRM_Event_Form_Registration::getUsedSeatsCount() must be of the type int, null given, called in /var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Event/Form/Registration.php on line 956 in CRM_Event_Form_Registration->getUsedSeatsCount() (line 1040 of /var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Event/Form/Registration.php).
The problem for us is somewhere in the function isOptionFullID.
Something in our priceset does not resolve to valid value for $optId = $option['id'];
when from IsOptionFullID the function getUsedSeatsCount is called it results in an error because it expects an int value for priceFieldValueID
protected function getUsedSeatsCount(int $priceFieldValueID) : int {
Reproduction steps
----------------------------------------
1. An event has a priceset with one of the pricefields disabled
2. Opening the registration page results in a fatal error
Current behaviour
----------------------------------------
![image](/uploads/041bb8c19666fc3f99c3f5bec78606bb/image.png)
![image](/uploads/2ff1b9c96e300515694d0a6930409328/image.png)
Expected behaviour
----------------------------------------
The registration page would show, with the pricefield disabled
Environment information
----------------------------------------
Current master / sandbox
Comments
----------------------------------------
My limited detective and coding skills enable me to reach this far, I have no clue on where to search further and what piece of code is the root cause of this.5.71.0https://lab.civicrm.org/dev/core/-/issues/5026Price Sets: total calculation wrong it decimal separator is different than "."2024-02-26T20:12:20ZmasettoPrice Sets: total calculation wrong it decimal separator is different than "."If I use price sets, when the decimal separator is "," and not "." the calculation of the total does not consider decimals.
Tested on dmaster:
![image](/uploads/beefe52fdfaeb4ff4ec06729528cfd25/image.png)
![image](/uploads/72de7f9df4...If I use price sets, when the decimal separator is "," and not "." the calculation of the total does not consider decimals.
Tested on dmaster:
![image](/uploads/beefe52fdfaeb4ff4ec06729528cfd25/image.png)
![image](/uploads/72de7f9df42afb6097e0e287c817c496/image.png)5.72.0https://lab.civicrm.org/dev/core/-/issues/5020Provide support for the Peppol standard to send invoices from CiviCRM to othe...2024-03-18T15:29:58Zjustinfreeman (Agileware)Provide support for the Peppol standard to send invoices from CiviCRM to other organisationsThis is just a placeholder to see if there is any interest in providing support for the Peppol standard. Did some searching and couldn't find any mentions about this in Lab.
Basically, the idea is to provide support for the Peppol stand...This is just a placeholder to see if there is any interest in providing support for the Peppol standard. Did some searching and couldn't find any mentions about this in Lab.
Basically, the idea is to provide support for the Peppol standard to send invoices from CiviCRM to other organisations. See https://peppol.org/ and participating organisations will be listed here, https://directory.peppol.eu/publichttps://lab.civicrm.org/dev/core/-/issues/5008[Enhancement] ContributionRecur edit activity should include more details2024-03-05T15:29:46ZElliott Eggleston[Enhancement] ContributionRecur edit activity should include more detailsOverview
----------------------------------------
When one edits a recurring contribution an activity is saved saying which user edited it. If the amount or the number of installments has been changed, that is included in the activity de...Overview
----------------------------------------
When one edits a recurring contribution an activity is saved saying which user edited it. If the amount or the number of installments has been changed, that is included in the activity details. However, no other changes are included (and the ContributionRecur row changes from log_contribution_recur are not in the contact change log), so it's impossible to tell in the UI if someone changed e.g. the next scheduled contribution date or the cycle day.
Example use-case
----------------------------------------
1. Edit a ContributionRecur
2. Look at the activity tab, and see all the changes you made
Current behaviour
----------------------------------------
Only changes to number of installments and amount are listed in the activity details
Proposed behaviour
----------------------------------------
Changes to other subscription properties are also listed in the activity details5.72.0https://lab.civicrm.org/dev/core/-/issues/4947Proposal: Store Contribution Page ID in the `civicrm_contribution_recur` table2024-02-01T10:23:33ZjaapjansmaProposal: Store Contribution Page ID in the `civicrm_contribution_recur` tableOverview
----------------------------------------
When a recurring contribution is created with a contribution page. Also store the contribution page ID in the `civicrm_contribution_recur` table.
This works already for 'normal' contrib...Overview
----------------------------------------
When a recurring contribution is created with a contribution page. Also store the contribution page ID in the `civicrm_contribution_recur` table.
This works already for 'normal' contribution.
Example use-case
----------------------------------------
1. CiviRules can be used when a new Contribution Recur is added and a condition can then be used which Contribution Page this came from.
Current behaviour
----------------------------------------
Currently for the 'normal' contributions the contribution page ID is stored in the `civicrm_contribution` table.
Proposed behaviour
----------------------------------------
1. Add a column to the `civicrm_contribution_recur` table called `contribution_page_id`
2. When a contribution recur is added through a Contribution Page then store the contribution page id into this column
3. Optional we can show the data from this field in the user interface when a user views a contribution recur
Workaround
----------------------------------------
There is a workaround with an extension: https://lab.civicrm.org/extensions/storecontributionpageidoncontribrecurjaapjansmajaapjansmahttps://lab.civicrm.org/dev/core/-/issues/4940Proposal to Change the Invoice date in the default Invoice message template t...2024-02-08T10:45:03ZeileenProposal to Change the Invoice date in the default Invoice message template to contribution.receive_dateThis spins off one discussion topic from https://lab.civicrm.org/dev/core/-/issues/1403 -
As part of our general effort to make the WorkflowMessage templates operate independently of the quickform layer (ie be available as actions from ...This spins off one discussion topic from https://lab.civicrm.org/dev/core/-/issues/1403 -
As part of our general effort to make the WorkflowMessage templates operate independently of the quickform layer (ie be available as actions from SearchKit etc) we should clarify which value is used for the invoice_date in the default message template that we ship from \`{$invoice_date}\`
```html
{domain.now|crmDate:"Full"}
or
{contribution.receive_date|crmDate:"Full"}
```
If we change the default it will affect new installs and un-customised templates. I'm not proposing any push upgrade on the customised templates at this stage so for most invoice-using sites this will be no change at this point. However, I am going to try to 'complete' the variable to token changes in this template so that anyone who is updating their customised template or installing a new site is using the tokens (& hence will be able to benefit from message previewability via MessageAdmin now & sending & rendering from outside QF if they install a relevant extension /when we add to core).
Potentially if we want to make it clear to people that they can change it we can use one of
```html
{domain.now|crmDate:"Full"}{* Code comment: - You can replace the domain.now token with this to show the contribution date instead {contribution.receive_date|crmDate:"Full"} *}
OR
{contribution.receive_date|crmDate:"Full"}{* Code comment: - You can replace the domain.now token with this to show the current date instead with {domain.now|crmDate:"Full"} *}
```
Note that the assumption in this gitlab is that any change would be opt in for existing sites (since basically everyone who uses invoices puts a logo in there). There is a proposal at https://github.com/civicrm/civicrm-core/pull/28630 that would force a change on everyone. I'm not convinced we should do a force update because it is pretty clear from the code & code history that the use of now was a deliberate attempt to meet a use case. However I have added an option to the emjoi poll below to allow people to vote for a forced update - basically a string_replace on upgrade.
EMOJI POLL Options
1) :boom: Change to {domain.now|crmDate:"Full"}
2) :man_dancing_tone2: Change to {contribution.receive_date|crmDate:"Full"}
3) :avocado: Change to 1 with additional in-code comments per above
4) :bellhop: Change to 2 with additional in code comments per above
5) :pick: Do 2 with a forced upgrade to replace {$invoice_date} with the above with {contribution.receive_date|crmDate:"Full"}https://lab.civicrm.org/dev/core/-/issues/4924CiviReport: Contribution Detail Report Joining Incorrectly on civicrm_note2024-03-01T20:08:18Zcrawford.morganCiviReport: Contribution Detail Report Joining Incorrectly on civicrm_noteOverview
----------------------------------------
When 'Contribution Note' is selected as a column in a Contribution Detail report, the join is treated as required and all contributions in the results without notes are filtered out.
Thi...Overview
----------------------------------------
When 'Contribution Note' is selected as a column in a Contribution Detail report, the join is treated as required and all contributions in the results without notes are filtered out.
This issue occurs when using the 'Contribution Detail' report, 'Extended Report - Contributions' report, and 'Extended Report - Bookkeeping with extra fields' report.
Thankfully, reports created in SearchKit function properly (all contributions are returned in the results) and contribution search exports are also functioning properly (including 'Contribution Note' in the exported fields does not affect the records exported).
Reproduction steps
----------------------------------------
1. example.com/civicrm/report/contribute/detail?reset=1
2. View results with Columns > Contribution Note toggled off
3. Toggle Contribution Note on, run report again, note that fewer records are returned
Environment information
----------------------------------------
* CiviCRM: 5.69.2
* PHP:8.1.27
* Drupal: 7.99
* MySQL: 8.0.33
Comments
----------------------------------------
This only recently became an issue after making a minor upgrade to 5.69.2https://lab.civicrm.org/dev/core/-/issues/4917Contribution Radio Buttons Incorrectly add other Amount2024-01-28T22:13:07ZtreseroContribution Radio Buttons Incorrectly add other Amount## Overview
With the focus fix for Contribution (Main.tpl), there is still an issue with the Other Amount being added to the original, default amount.
The Other Amount should not be adding to the original, unchecked amount.
## Reprodu...## Overview
With the focus fix for Contribution (Main.tpl), there is still an issue with the Other Amount being added to the original, default amount.
The Other Amount should not be adding to the original, unchecked amount.
## Reproduction steps
1. Click on your public facing Contribute page, civicrm/contribute/transact/?reset=1&id=1
2. Clicked in Other Amount text box and added $20
3. This added $20 to the default amount resulting in $70 for the amount, instead of $20
## Current behaviour
## Expected behaviour
This should clear the initial amount and only show the Other Amount, and move focus to the Other Amount button.
## Environment information
* **CiviCRM:** _5.69.2_
* **PHP:** _8.1_
* **CMS:** _Wordpress_
## Comments
![Screenshot 2024-01-16 161324.png](/uploads/68f7a46cac54e4256937d6d472a868c2/Screenshot_2024-01-16_161324.png)5.70.0https://lab.civicrm.org/dev/core/-/issues/4912Since civicrm 5.69, "Other amount" field cannot be filled on many themes.2024-01-27T18:38:38ZChabadrichmondSince civicrm 5.69, "Other amount" field cannot be filled on many themes.## Overview
Since upgrading to 5.69 users cannot fill out the other amount field on contribution pages on many themes, I tried, Divi, Blocksy, Kadence, Astra and all have the issue, I did notice that it works on 2023 and 2024)
EDIT (@k...## Overview
Since upgrading to 5.69 users cannot fill out the other amount field on contribution pages on many themes, I tried, Divi, Blocksy, Kadence, Astra and all have the issue, I did notice that it works on 2023 and 2024)
EDIT (@kcristiano ) Not CMS specific - see https://d10-master.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=4
https://chat.civicrm.org/civicrm/pl/nbsyhud8kiyd7nutzqiqcyfhzo
* **Browser:** _any_
* **CiviCRM:** _5.69+_
* **CMS:** _Any_
Screenshot posted below
![civi other amount.gif](/uploads/b4ff148f46514ade2106c07e56d2c0b8/civi_other_amount.gif)5.69.3https://lab.civicrm.org/dev/core/-/issues/4901financialacls has a missing dependency on civi_contribute2024-01-19T19:31:27Zfkohrtfinancialacls has a missing dependency on civi_contributeThis is just to report an anomaly I experienced on two separate CiviCRM instances.
After we updated our CiviCRM 5.68.0 running on Drupal 10.2.1 to version 5.69.1, I received the following extension error in the _CiviCRM System Status_:
...This is just to report an anomaly I experienced on two separate CiviCRM instances.
After we updated our CiviCRM 5.68.0 running on Drupal 10.2.1 to version 5.69.1, I received the following extension error in the _CiviCRM System Status_:
> "Financial ACLs" (`financialacls`) has a missing dependency on "CiviContribute" (`civi_contribute`)
It also says "To resolve any errors, go to __Manage Extensions__.", but after following that link I don't know what to do next.
We had the following extensions installed:
- AuthX
- CiviEvent
- CiviReport
- CKEditor4
- Contributor cancel actions
- Custom search framework
- Form Core
- FlexMailer
- SearchKit
After installing CiviContribute due to the extension error, I got the following full page error message:
> Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred.
>
> DB Error: already exists
CiviContribute is now also listed as installed extension.
Is there something I could/should have done different?https://lab.civicrm.org/dev/core/-/issues/4895Can't delete unused financial types2024-01-15T11:38:54ZJonGoldCan't delete unused financial typesOverview
----------------------------------------
Not a regression!
Financial types associated with quick config price sets can never be deleted.
Reproduction steps
----------------------------------------
1. Create a new financial typ...Overview
----------------------------------------
Not a regression!
Financial types associated with quick config price sets can never be deleted.
Reproduction steps
----------------------------------------
1. Create a new financial type.
1. Create a new event.
1. Select the financial type as the default for the event and save.
1. Delete the event.
1. Delete the financial type.
Current behaviour
----------------------------------------
Obtuse error.
```
The following tables have an entry for this financial type: CRM_Price_DAO_PriceSet, CRM_Price_DAO_PriceFieldValue
```
Expected behaviour
----------------------------------------
Financial type should be deletable.
When the warning `Deleting this event will also delete associated Event Registration Page and Event Fee configurations. This action cannot be undone. Do you want to continue?` appears - continuing should delete the price set if it's a quick-config. But since I hope quick config dies a painful death, let's generalize to "deleting an event
Comments
----------------------------------------
Tangentially - you can't delete a price set that has any payments associated with it. This should be doable IMO and I believe is an artifact of pre-CiviAccounts (Civi 4.3) behavior when line items didn't exist.https://lab.civicrm.org/dev/core/-/issues/4882Fatal error / incomplete form validation: Batch Data Entry for Contributions2024-01-15T11:27:43ZAllenShawFatal error / incomplete form validation: Batch Data Entry for Contributions**Summary:**
For Batch Data Entry of contributions, incomplete validation of the "Received" column value can lead to a fatal error and import of only a subset of batch entries.
**Repro:**
To reproduce on dmaster (currently "Powered b...**Summary:**
For Batch Data Entry of contributions, incomplete validation of the "Received" column value can lead to a fatal error and import of only a subset of batch entries.
**Repro:**
To reproduce on dmaster (currently "Powered by CiviCRM 5.70.alpha1"):
1. Create a new Batch (Contributions \> Batch Data Entry : New Data Entry Batch) containing 2 or more entries.
2. For the first entry, fill all relevant fields with sensible data; important for repro: leave the Contribution Date date/time at its default value (or enter any other date/time value)
3. For the second entry, fill all relevant fields with sensible data; important for repro: delete the date portion of the Contribution Date date/time value (but ensure there is a time component. E.g. NULL date, 10:20AM)
![received.png](/uploads/f7758c48d66461ea0d77c3dc2ae63d2e/received.png)
4. Submit the form with "Validate and Process the Batch"
**Expected (good) behavior:**
* Form validation should notice that date component is empty in the second entry and alert the user that this is required.
* No entries are processed (no new contributions are created)
**Actual (bad) behavior:**
* Form is submitted without any validation errors.
* User observes fatal error: "Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred. DB Error: unknown error"
* The first entry is fully processed (a new contribution is created), but no subsequent entries are processed.
* The SQL error here is:
```
"INSERT INTO `civicrm_contribution` (`contact_id` , `financial_type_id` , `payment_instrument_id` , `receive_date` , `total_amount` , `fee_amount` , `net_amount` , `invoice_id` , `invoice_number` , `currency` , `source` , `contribution_status_id` , `check_number` , `campaign_id` , `tax_amount` ) VALUES ( 45968 , 48 , 4 , 10 , 200 , 0 , 200 , NULL , 'INV_11998' , 'USD' , '2023 EOY gift' , 1 , '297' , 95 , 0 ) [nativecode=1292 ** Incorrect datetime value: '10' for column `hft_civicrm`.`civicrm_contribution`.`receive_date` at row 1]"
```
(Note that the '10' in `Incorrect datetime value: '10'` is the Hour part of the time component as submitted for the second entry.)
**Proposed fix:**
Form validation should ensure that a Date component is entered; a Time component without a Date component will result in the above misbehavior.https://lab.civicrm.org/dev/core/-/issues/4864Edit contribution Undefined array key on dmaster2024-03-12T17:47:47ZJoeMurrayEdit contribution Undefined array key on dmasterTrying to edit contribution created at https://lab.civicrm.org/dev/core/-/issues/4863 leads to page of php/smarty issues:
Warning: Undefined array key "defaultContribution" in include() (line 86 of /srv/buildkit/build/dmaster/.civibuild...Trying to edit contribution created at https://lab.civicrm.org/dev/core/-/issues/4863 leads to page of php/smarty issues:
Warning: Undefined array key "defaultContribution" in include() (line 86 of /srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/templates_c/en_US/%%6F/6F7/6F7BB438%%Contribution.tpl.php).
Warning: Undefined array key "displayLineItemFinancialType" in include() (line 24 of /srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/templates_c/en_US/%%F2/F21/F21A46C1%%LineItem.tpl.php).
Warning: Undefined array key "getTaxDetails" in include() (line 32 of /srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/templates_c/en_US/%%F2/F21/F21A46C1%%LineItem.tpl.php).
Warning: Undefined array key "getTaxDetails" in include() (line 37 of /srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/templates_c/en_US/%%F2/F21/F21A46C1%%LineItem.tpl.php).
Warning: Undefined array key "pricesetFieldsCount" in include() (line 44 of /srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/templates_c/en_US/%%F2/F21/F21A46C1%%LineItem.tpl.php).
Warning: Undefined array key "displayLineItemFinancialType" in include() (line 57 of /srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/templates_c/en_US/%%F2/F21/F21A46C1%%LineItem.tpl.php).
Warning: Undefined array key "getTaxDetails" in include() (line 70 of /srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/templates_c/en_US/%%F2/F21/F21A46C1%%LineItem.tpl.php).
Warning: Undefined array key "getTaxDetails" in include() (line 74 of /srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/templates_c/en_US/%%F2/F21/F21A46C1%%LineItem.tpl.php).
Warning: Undefined array key "pricesetFieldsCount" in include() (line 90 of /srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/templates_c/en_US/%%F2/F21/F21A46C1%%LineItem.tpl.php).
Warning: Undefined array key "getTaxDetails" in include() (line 102 of /srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/templates_c/en_US/%%F2/F21/F21A46C1%%LineItem.tpl.php).
Warning: Undefined array key "pricesetFieldsCount" in include() (line 124 of /srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/templates_c/en_US/%%F2/F21/F21A46C1%%LineItem.tpl.php).
Warning: Undefined array key "hookDiscount" in include() (line 151 of /srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/templates_c/en_US/%%F2/F21/F21A46C1%%LineItem.tpl.php).https://lab.civicrm.org/dev/core/-/issues/4863contribution ThankYou.tpl.php notice errors on dmaster, contribution total am...2023-12-19T22:08:35ZJoeMurraycontribution ThankYou.tpl.php notice errors on dmaster, contribution total amount $0Scenario 1: On dmaster, with default value for mug premium ($12.50), on live Donation page, choose $50 donation, ask for mug, complete credit card info, no honoree, no title for donor, then on thank you page you get errors below.
Simpli...Scenario 1: On dmaster, with default value for mug premium ($12.50), on live Donation page, choose $50 donation, ask for mug, complete credit card info, no honoree, no title for donor, then on thank you page you get errors below.
Simplifying scenario 2: on dmaster Donate page, leave default $10 amount, no premium, fill in required fields for Billing Name and Address as shown, credit card info, then on thank you page get errors below. Note that Title field is not provided on page, and honoree sections not on page. Need to change template to make them optional is my guess.
![2023-12-15_18-00-19](/uploads/05ba7c9c528596b757c01845da3e03ff/2023-12-15_18-00-19.png)
BUG: in both cases, it shows total paid was $0.00.
![2023-12-15_18-09-17](/uploads/f263bd2a81e8f222c4a8672dec0ad49b/2023-12-15_18-09-17.png)
Warning: fopen(/srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/ConfigAndLog/CiviCRM.1.daaf15586b7efa7b235b62c7.log): Failed to open stream: Permission denied in Log_file->open() (line 216 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/pear/log/Log/file.php).
Warning: fopen(/srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/ConfigAndLog/CiviCRM.1.daaf15586b7efa7b235b62c7.log): Failed to open stream: Permission denied in Log_file->open() (line 216 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/pear/log/Log/file.php).
Warning: Undefined array key "honoreeProfileFields" in include() (line 232 of /srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/templates_c/en_US/%%0D/0D2/0D2EEFAF%%ThankYou.tpl.php).
Warning: Undefined array key "title" in include() (line 377 of /srv/buildkit/build/dmaster/.civibuild/private/default/civicrm/templates_c/en_US/%%0D/0D2/0D2EEFAF%%ThankYou.tpl.php).
![2023-12-15_17-58-12](/uploads/2f7129203c925d45366ad241efc25eac/2023-12-15_17-58-12.png)5.69.0https://lab.civicrm.org/dev/core/-/issues/4817$imageURL is not available on membership contribution confirmation and thank ...2023-12-06T22:25:06Zfreeform.steph$imageURL is not available on membership contribution confirmation and thank you pagesThis was originally posted here: https://issues.civicrm.org/jira/browse/CRM-19983 in 2017 but I am not finding any indication that it was ever resolved, or this is a regression, not sure.
If you include the contact photo field (image_ur...This was originally posted here: https://issues.civicrm.org/jira/browse/CRM-19983 in 2017 but I am not finding any indication that it was ever resolved, or this is a regression, not sure.
If you include the contact photo field (image_url) in a profile on a membership contribution form and a user uses the field, the image is uploaded, however the image preview (thumbnail with option to delete) fails to display on the confirmation and thank you pages. This causes the users confusion because the field to upload an image appears in its place which leads the individuals to re-try uploading their image (which will cause their image to not be saved). It also fails to appear on the thank you page if you do not enable the confirmation page option.
If you include the smarty debug tag in templates/CRM/UF/Form/Fields.tpl where you'd expect the image to be output, you'll see that $imageURL is not defined.
If you use the same field on a standalone profile form, the preview does display on the last page (there is no confirmation page in this case), so it does appear to be limited to when the profile is included on a contribution form.
What we should see: (1) no upload field on confirmation or thank you pages, (2) include a preview of an image if one was uploaded.