Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-28T00:43:35Zhttps://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/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/1631Wrong behaviour on event Payment Information visibility for unpayed events2024-03-15T18:16:32ZfrancescbassasWrong behaviour on event Payment Information visibility for unpayed eventsOverview
----------------------------------------
When you edit an unpayed event registration, Payment Information section is visible by default even if "Record payment?" is unchecked.
Reproduction steps
--------------------------------...Overview
----------------------------------------
When you edit an unpayed event registration, Payment Information section is visible by default even if "Record payment?" is unchecked.
Reproduction steps
----------------------------------------
**Payment Information should be hidden**
1. Register a contact to an event without record any payment
2. Edit registration
3. Note that `Payment Information` section is visible
4. Check `Record Payment?` field
5. Note everything is still the same
6. Uncheck `Record Payment?` field
7. Note `Payment Information` section is hidden
**You may think that you are recording the contribution but the contribution is not recorded**
1. Register a contact to an event without record any payment
2. Edit registration
3. Note that `Payment Information` section is visible (with event fee set on the Amount field)
4. Click to save (without changing anything)
5. Note contribution was not recorded
Current behaviour
----------------------------------------
`Payment Information` section is visible for unpayed event registration editing form
![2020-03-04_17-13](/uploads/daacd3a4ce44727a748e1f8b94194a45/2020-03-04_17-13.png)
Expected behaviour
----------------------------------------
`Payment Information` section should be hidden for unpayed event registration editing forms and should appear when `Record Payment?` is checked.
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.26.alpha1/5.20.3/5.13.4/_https://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/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/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/3314Contribution pages with memberships don't validate correctly when using "quic...2024-02-27T01:10:05ZJonGoldContribution pages with memberships don't validate correctly when using "quick config" price fieldsIn `CRM_Contribute_Form_Contribution_Main::formRule`, there are multiple references to `$self->_useForMember`. `$self->_useForMember` is only `TRUE` if the price set is a "quick config" price set (and is explicitly used as such in the t...In `CRM_Contribute_Form_Contribution_Main::formRule`, there are multiple references to `$self->_useForMember`. `$self->_useForMember` is only `TRUE` if the price set is a "quick config" price set (and is explicitly used as such in the template). However, during `formRule` validation, it's used as a proxy for "this contribution page uses memberships". @mattwire correctly identified the problem on the confirmation class in [PR 15094](https://github.com/civicrm/civicrm-core/pull/15094).
As a result, several membership-specific validations are bypassed.
I attempted to move his methods to the shared `ContributionBase` class and make them protected, but I ran into deeper validation issues. I can't justify further work on this, but wanted to document for future folks who bang their heads against this.https://lab.civicrm.org/dev/financial/-/issues/176Billing fields aren't hidden even when they can2024-02-19T16:44:11ZcapoBilling fields aren't hidden even when they canThe **assignAddressField** function, implemented in [CRM/Core/BAO/UFField.php#L785](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/UFField.php#L785), is meant to return a boolean that tells if:
> Can the address block ...The **assignAddressField** function, implemented in [CRM/Core/BAO/UFField.php#L785](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/UFField.php#L785), is meant to return a boolean that tells if:
> Can the address block be hidden safe in the knowledge all fields are elsewhere collected (see CRM-15118)
But it only has one return statement when that covers some of the cases in which the fields can't be hidden. In other words, the function never returns true. It can let JavaScript know that all the necessary fields are present but it can't let know other PHP functions.
This issue might be related with #129.https://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/4798Online contribution flow - fix for php8.x, notices, smarty32024-02-06T05:45:17ZeileenOnline contribution flow - fix for php8.x, notices, smarty3This is an oversight issue for fixing up the online contribution form in php8.x with a view to
1) resolving all the smarty & php layer notices, including in the message templateb
2) fixing the places where it doesn't work with Smarty3 (...This is an oversight issue for fixing up the online contribution form in php8.x with a view to
1) resolving all the smarty & php layer notices, including in the message templateb
2) fixing the places where it doesn't work with Smarty3 (in the online membership receipt & I think I fixed one in Confirm.tpl maybe)
3) fixing it to work with php8.2 (no undeclared properties)
4) fixing the underlying line item handling mess (we have multiple different ways of setting & retrieving the line itesm + a whole lot of code that does stuff to the line items but ultimately alters variables that get discarded. The impact of that I found tax bugs as soon as I started looking at the code.
5) fixing the online membership receipt such that it is previewable in MessageAdmin Ui, and does not require complex code to call it & have it render correctly (ie. `composeMessageArray` & the form layer both do a lot of assigning that should be unnecessary)
Much of this work has been done in small steps with a few in 5.68 & the bulk in 5.69. The goal is to try to resolve all the most important parts in 5.69 & then not do any more & encourage lots of rc testing on 5.69.
Areas to think about when testing
- data input with different currency separators
- non deductible amount with tax
- checking tax in separate payment & non separate payment scenarios (this actually has modest test cover but should be extended)
- checking the receipts
- checking the contribution recur amount is correct - when there is an autorenew membership + a contribution & it is not separate payment the amount should be equal to the tax-inclusive amount for the membership part of the contribution
Issues
**Must fix regressions**
- [x] Form layer issue on other amount js - probably regression in rc or master https://lab.civicrm.org/dev/core/-/issues/4795
- [x] Disabled options showing up https://github.com/civicrm/civicrm-core/pull/28356
- [x] Membership type not selected as a default https://github.com/civicrm/civicrm-core/pull/28361
- [ ] Is something weird happening with pledge? I couldn't figure out how to enable & disable & see it there & not there - UPDATE - I think this is a demo site data issue - https://github.com/civicrm/civicrm-core/pull/28497
- [x] Is the other Amount js right when there is NOT a membership? Need to compare to an older version... This might also be a demo site data issue per ^^
**Regression?Improvement?**
- [x] Change in line items for membership + contribution https://lab.civicrm.org/dev/core/-/issues/4814
**Extension issues**
- [x] A couple of extensions are interacting with the no-longer-in-use `_lineItem` undeclared property. This undeclared property also causes php8 fails. Declaring it would give a false sense of security but an alternative is to add a magic `__GET` & `__SET`. In my digging so far taxcalculator would need some small changes to adapt to this as the undeclared property is passed-by-reference but other extensions are likely to be OK with it. PR to add magic methods https://github.com/civicrm/civicrm-core/pull/28276 PR on taxcalculator https://lab.civicrm.org/extensions/taxcalculator/-/merge_requests/9
**Pre-existing issues**
These are not necessarily going to be fixed but the process of verifying them provides a goodly amount of rc testing. In some cases they are suspected fully or partially fixed already
*Tax*
- [ ] Long term issue on tax not applying to separate membership payments, in my testing pre-cleanup the tax-not-applied seemed to go beyond separate payments. This needs re-testing & a list of issues confirmed https://lab.civicrm.org/dev/financial/-/issues/154
- [ ] Aha - here is the general tax issue I hit https://lab.civicrm.org/dev/core/-/issues/4524 - needs verification
- [x] How should tax apply to 'Other amount' - is the amount entered inclusive? https://lab.civicrm.org/dev/core/-/issues/4806
- [ ] possible bug - needs verification https://lab.civicrm.org/dev/financial/-/issues/182
- [ ] Now that we have standardised on publicly supported `getLineItems()` & `setLineItems()` how is our hook support https://lab.civicrm.org/dev/core/-/issues/2796
*Localisation*
- [x] Non-English currency formatting messes with other amount field https://lab.civicrm.org/dev/core/-/issues/4802
*Page flow*
- [ ] Membership amount + contribution issues (erm what did I mean when I wrote this?)
- [ ] Data issue when email fails https://lab.civicrm.org/dev/core/-/issues/4540
- [ ] Data issue on payment fail https://github.com/civicrm/civicrm-core/pull/26120
- [ ] ContributionRecurID not always passed to payment processor https://lab.civicrm.org/dev/core/-/issues/4019
- [ ] The stretch goal - create order before adding payment https://lab.civicrm.org/dev/financial/-/issues/76
- [ ] Also the stretch goal https://lab.civicrm.org/dev/financial/-/issues/53
- [ ] Another meta issue of unknown status https://lab.civicrm.org/dev/core/-/issues/928
*Validation*
- [ ] Contribution + membership + quick config https://lab.civicrm.org/dev/core/-/issues/3314
*On Behalf*
- [ ] Profile bug?? https://lab.civicrm.org/dev/financial/-/issues/124
- [ ] Onbehalf hide for orgs https://lab.civicrm.org/dev/core/-/issues/4725
*Presentation issues*
- [ ] Notices on form - undefined property https://lab.civicrm.org/dev/core/-/issues/4760
- [x] Currency incorrect on thank you / confirm pages https://lab.civicrm.org/dev/core/-/issues/3381
- [ ] Probably the same https://lab.civicrm.org/dev/core/-/issues/3917
- [ ] Probably the same https://lab.civicrm.org/dev/core/-/issues/411
- [ ] Problems at form layer with auto-renew handling https://lab.civicrm.org/dev/core/-/issues/3963
- [ ] Frequency units translation issues https://lab.civicrm.org/dev/translation/-/issues/53
- [ ] On behalf confusing https://lab.civicrm.org/dev/core/-/issues/2266
- [ ] PCP notices https://lab.civicrm.org/dev/drupal/-/issues/159
- [ ] Translation missin ghttps://lab.civicrm.org/dev/translation/-/issues/27
- [ ] Show hide billing doesn't work https://lab.civicrm.org/dev/financial/-/issues/129
- [ ] Email appears twice https://lab.civicrm.org/dev/core/-/issues/3858
- [ ] Translation issue https://lab.civicrm.org/dev/core/-/issues/4071
- [ ] Possible bug https://lab.civicrm.org/dev/core/-/issues/4293
- [ ] Bug? replicable https://lab.civicrm.org/dev/core/-/issues/4488
- [ ] Upload image does not show https://lab.civicrm.org/dev/core/-/issues/4817
- [x] Undefined array key "honoreeProfileFields" also "title" in ThankYou.tpl.php that appeared when payment incorrectly recorded as $0 https://lab.civicrm.org/dev/core/-/issues/4863
- [x] Edit contribution has about a dozen undefined array keys for defaultContribution, displayLineItemFinancialType, getTaxDetails, pricesetFieldsCount, hookDiscount https://lab.civicrm.org/dev/core/-/issues/4864
*Membership calculation*
- [ ] Membership term usage issue https://lab.civicrm.org/dev/core/-/issues/3344
- [ ] Probably the same thing https://lab.civicrm.org/dev/core/-/issues/3810
- [ ] Probably the same thing https://lab.civicrm.org/dev/core/-/issues/3339
- [ ] Autorenew deep dive https://lab.civicrm.org/dev/financial/-/issues/128
- [ ] My read of the code suggests that if 2 membership types are configured to offer auto-renew it will only work for one
*Premiums*
- [x] notices on manage premiums https://lab.civicrm.org/dev/core/-/issues/4793
- [x] need api support for premiums https://github.com/civicrm/civicrm-core/pull/28261
- [x] Smarty notices on premiums in Online form flow https://lab.civicrm.org/dev/core/-/issues/4794
- [ ] pre-existing brokenness on deductible amount https://lab.civicrm.org/dev/core/-/issues/1083
- [ ] More non-deductible amount issues https://lab.civicrm.org/dev/core/-/issues/2414
- [ ] non-deductible amount misconfiguration https://lab.civicrm.org/dev/core/-/issues/3083 (note we could add a system check as a low-risk step)
*Manage contribution pages*
- [x] issue saving renew options https://github.com/civicrm/civicrm-core/pull/24997
- [ ] Validation lacking https://lab.civicrm.org/dev/core/-/issues/2846
- [ ] Widget issue https://lab.civicrm.org/dev/core/-/issues/20
*Membership receipts*
- [x ] Remove text version of receipt - we are moving to relying on generated text version rather than maintaining both
- [ ] Membership data wrong https://lab.civicrm.org/dev/core/-/issues/2354
- [ ] Credit card info sometimes missing https://lab.civicrm.org/dev/core/-/issues/661
- [ ] Receipt text inconsistently handled https://lab.civicrm.org/dev/user-interface/-/issues/13
- [ ] Issue on upsell https://lab.civicrm.org/dev/core/-/issues/4332
- [ ] Proposal - remove trxn_id https://lab.civicrm.org/dev/financial/-/issues/217
- [ ] Missing recur links https://lab.civicrm.org/dev/financial/-/issues/127
*Contribution receipts*
- [ ] Somewhat obscure bug on on-behalf profiles (should be addressed if we get as far as moving the handling of that to the WorkflowMessage class) https://lab.civicrm.org/dev/core/-/issues/4779
- [x] Remove text version of receipt - we are moving to relying on generated text version rather than maintaining both
- [ ] Duplicate of donor name https://lab.civicrm.org/dev/core/-/issues/2021
- [ ] Not sent for paypal express https://lab.civicrm.org/dev/financial/-/issues/13
- [ ] PDF file name issue https://lab.civicrm.org/dev/core/-/issues/3068
- [ ] Broken links in contribution issue https://lab.civicrm.org/dev/core/-/issues/1195
- [ ] Likely fixed bug https://lab.civicrm.org/dev/core/-/issues/4185
- [ ] Checksum wiht on-behalf of https://lab.civicrm.org/dev/core/-/issues/4265
*Wordpress issue?*
- [ ] https://lab.civicrm.org/dev/wordpress/-/issues/120
Feature request
- [ ] Configurable confirm button - more than one request - like events - https://lab.civicrm.org/dev/user-interface/-/issues/10 https://lab.civicrm.org/dev/core/-/issues/4324https://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/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/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/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/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/1083Non-deductible amount not working2023-12-21T11:11:54ZJoeMurrayNon-deductible amount not workingOn 5.14 and dmaster 5.16.alpha1 when a price set is configured with an option that includes a non-deductible amount, then a purchase is made of that option, the non-deductible amount is not appearing on the contribution.
Price Set Field...On 5.14 and dmaster 5.16.alpha1 when a price set is configured with an option that includes a non-deductible amount, then a purchase is made of that option, the non-deductible amount is not appearing on the contribution.
Price Set Field with non-deductible $5 on $10 price:
![2019-06-27_14-44-40](/uploads/3954b396bb81d67c5f01cf5c6464b85a/2019-06-27_14-44-40.png)
Contribution for $10 with $0 non-deductible:
![2019-06-27_14-43-59](/uploads/9c43a1a6c2a0381ed94c403901228821/2019-06-27_14-43-59.png)EdselopezEdselopezhttps://lab.civicrm.org/dev/core/-/issues/4779Contribution page receipt does not include on behalf of profile information w...2023-12-08T08:43:34ZalicefruminContribution page receipt does not include on behalf of profile information when a contact contributes on behalf of an organization that they are not an employee ofOverview
----------------------------------------
This is a really really edge case situation. You can configure a contribution page so that you can contribute on behalf of an organization. The list of organizations you can select from ...Overview
----------------------------------------
This is a really really edge case situation. You can configure a contribution page so that you can contribute on behalf of an organization. The list of organizations you can select from is all the organizations you have a permissioned relationship to (regardless of what the relationship type is), however the receipt will not include the on behalf of profile information unless the relationship type is "Employee of". This is an issue for a client of ours that has a membership type that is inherited thru a custom relationship type.
I think that the problem is this code: https://github.com/civicrm/civicrm-core/blob/5.67/CRM/Contribute/BAO/Contribution.php#L2306
I have a patch that deals with this for our clients specific issue but Im not sure its the best fit for core.
Reproduction steps
----------------------------------------
1. Create a Contribution Page where:
- on behalf of is turned on
- receipts are turned on
- A payment processor is available to use (the problem cannot be recreated if you do a pending pay later contribution)
2. For your user, create a relationship:
- to an organization
- of any relationship type besides "Employee of"
- that has view/update permissions in both directions.
- If your user has an employer make sure you are selecting an organization that is different than your employer.
3. Go to the contribution page on the frond end
4. In the on behalf of section, select the organization you have a relationship to that is not thru an "Employee of" relationship (that you created in step 2)
5. Make a "live" payment (you can use the dummy payment processor, just don't use the invoice option)
Current behaviour
----------------------------------------
The receipt does not include the on behalf of profile information.
Expected behaviour
----------------------------------------
The receipt should include the on behalf of profile information.
Environment information
----------------------------------------
I am able to replicate this in civicrm 5.67https://lab.civicrm.org/dev/core/-/issues/4806Tax amount on 'other amount field' - not being added2023-12-06T23:04:26ZeileenTax amount on 'other amount field' - not being addedWhen you Configure a Contribution Page with tax that applies to the 'Other Amount' field it is not applied.
Note that the way the page appears I feel like the amount entered should be treated as inclusive rather than exclusive - the alt...When you Configure a Contribution Page with tax that applies to the 'Other Amount' field it is not applied.
Note that the way the page appears I feel like the amount entered should be treated as inclusive rather than exclusive - the alternative would be to improve the messaging to make it clearer on the page but it feels weird to ask people to enter a tax-exclusive amount
Screenshots from 5.60 with odd currency formatting configured
![image](/uploads/3ca803cb8846284f720063a253df407b/image.png)
Note tax is still $15
![image](/uploads/a54e7208521af056f0f958e152a4ff1b/image.png)
In the final screen the tax is ... interesting
![image](/uploads/074207531cc4cdb00fb56db499ca6421/image.png)
**Note**
1) there is code to say that if the membership recurs then the other amount should not be included