Development issueshttps://lab.civicrm.org/groups/dev/-/issues2020-11-09T13:37:51Zhttps://lab.civicrm.org/dev/financial/-/issues/155Incorrect deductible shown in contribution summary report2020-11-09T13:37:51ZMonish DebIncorrect deductible shown in contribution summary reportSteps to replicate:
1. Ensure that there are multiple contributions with non-zero non-deductible amount.
2. Go to Contribution Summary Report
3. Select Non-Deductible amount column + Grouping on Receive Date - Month
Result: Total non-d...Steps to replicate:
1. Ensure that there are multiple contributions with non-zero non-deductible amount.
2. Go to Contribution Summary Report
3. Select Non-Deductible amount column + Grouping on Receive Date - Month
Result: Total non-deductible amount is incorrect against each month
On closer look, group function (- SUM) is not applied on non-deductible amount, thus the report column show random amount.
Here's a screencast that explains the issue, where I added two contributions this month w/o non-deductible amount respectively, but the Contribution summary report shows incorrect value:
![yhv](/uploads/e851d5c3b56e46c1de049d12d1f977ff/yhv.gif)
ping @JoeMurray @eileen @mattwire @EdselopezMonish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/2157Array to string conversion in DB_DataObject when doing on behalf of and no st...2023-05-26T16:13:04ZDaveDArray to string conversion in DB_DataObject when doing on behalf of and no state/provinceIf you submit a contribution on behalf of an org and leave the state/province blank, you get `Notice: Array to string conversion in DB_DataObject->_build_condition() (line 2903 of .../web/sites/all/modules/civicrm/packages/DB/DataObject....If you submit a contribution on behalf of an org and leave the state/province blank, you get `Notice: Array to string conversion in DB_DataObject->_build_condition() (line 2903 of .../web/sites/all/modules/civicrm/packages/DB/DataObject.php)`
(At the moment to see this you need to make the field not required on the profile, but it happens either way it's just there's currently a separate issue when the field is required and the country has no state/provinces.)
What happens is that at that code line `$this->name` and `$this->abbreviation` contain a big long list of numbers and letters, including, oddly, the strings "_A", "_B", "_C", etc, but ONLY up to "_P".https://lab.civicrm.org/dev/financial/-/issues/153Orange Paypal Pro button not redirecting properly after reCaptcha on Paypal2020-12-09T00:33:53ZStoobOrange Paypal Pro button not redirecting properly after reCaptcha on Paypal#151 related issue @eileen @seamuslee
The javascript errors are fixed but we have been able to reproduce other errors related to the reCaptcha system at Paypal.com. I am not sure if these can be fixed on CiviCRM's side or not but we sh...#151 related issue @eileen @seamuslee
The javascript errors are fixed but we have been able to reproduce other errors related to the reCaptcha system at Paypal.com. I am not sure if these can be fixed on CiviCRM's side or not but we should be aware of the following experience from user testing.
My guess is the from the Civi side we should confirm we are sending Paypal the proper auto-return URL to ensure that Paypal can find its way back to us after hitting us with the reCaptcha on their end.
In *Chrome and Safari* the Javascript errors are fixed -- when you click the Paypal button, there's no validation error requiring the user to input CC fields.
**But** when I go to Paypal, I'm asked to complete a ReCaptcha at this URL: https://www.paypal.com//cgi-bin/webscr?cmd=_express-checkout&token=EC-2JE64037K02097038. Once I complete the challenge, the page does not reload to the log-in screen. Instead it just sits with the challenge results accepted. If I then reload the page, it redirects me to the Paypal log-in page as it should at this URL: https://www.paypal.com//cgi-bin/webscr?cmd=_express-checkout&token=EC-2JE64037K02097038
In *Firefox*, the Javascript errors are fixed -- when I click the Paypal button, there's no validation error requiring the user to input CC fields. When you go to Paypal, I'm asked to complete a ReCaptcha. Once I complete the challenge, the Paypal experience is different page loads the sad dinosaur error screen "hmm we're having trouble finding that site"https://lab.civicrm.org/dev/core/-/issues/2021Contribution receipt has donor's name printed twice, once with non-printable ...2023-11-23T07:22:03ZBobSContribution receipt has donor's name printed twice, once with non-printable charactersOverview
----------------------------------------
Contribution receipts, notably those created with the Stripe extension, display the donor's information as follows:
```
Jane�Mary�Smith <$first . \x01 . $middle . \x01 . $last>
...Overview
----------------------------------------
Contribution receipts, notably those created with the Stripe extension, display the donor's information as follows:
```
Jane�Mary�Smith <$first . \x01 . $middle . \x01 . $last>
Jane Mary Smith <$first . \x20 . $middle . \x20 . $last>
123 Main St
...
```
The two \x01 characters (ASCII SOH, CRM_Core_DAO::VALUE_SEPARATOR) are displayed as boxes in some email clients, although they aren't displayable in this bug report.
The message template "Contributions - Receipt (on-line)" includes:
```
{if $billingName}
<tr>
<th {$headerStyle}>
{ts}Billing Name and Address{/ts}
</th>
</tr>
<tr>
<td colspan="2" {$valueStyle}>
{$billingName}<br />
{$address|nl2br}<br />
{$email}
</td>
</tr>
{elseif $email}
```
For Stripe contributions, $billingName contains the first/middle/last names separated by SOH characters, as found in civicrm_address.name. The {if $billingName} block therefore gets printed, including both $billingName and the $address variable which contains the second instance of the donor's name, followed by their address.
The SOH characters in the first line of $address (the donor's name) are replaced with spaces in CRM_Core_BAO_Address::addDisplay().
Contributions via Paypal standard, in contrast, do not display the $billingName block as addresses created that way store NULL in civicrm_address.name.
Reproduction steps
----------------------------------------
1. Create a contribution with CiviCRM Stripe extension v. 6.4.2.
1. Observe the Billing Name and Address section of the emailed receipt.
Current behaviour
----------------------------------------
The donor's name is printed twice. Once with SOH separators, and again with spaces. If the middle name is blank, the second instance contains two spaces between first and last name.
Expected behaviour
----------------------------------------
The name should be printed once, with a single space between non-blank name components.
Additional comments
----------------------------------------
1. Perhaps the fix is to simply remove "$billingName\<br \/\>" from the template(s). Ideally, the double spaces in the case of a null middle name should be corrected also.
2. Event and Membership templates seem to have the same structure as the template shown above.
3. The Thank You page displays the donor's name as expected -- only once, with a single \x20 character between first and last name.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __CiviCRM:__ 5.28.2
* __CiviCRM Stripe extension__ v. 6.4.2
* __mjwshared extension__ v. 0.8.1
* __PHP:__ 7.3
* __CMS:__ Drupal 7.72https://lab.civicrm.org/dev/financial/-/issues/138Broken bookkeeping records: no financial trxn from Accounts Receivable to rev...2020-06-29T04:05:27ZRichBroken bookkeeping records: no financial trxn from Accounts Receivable to revenue account.According to the [docs](https://docs.civicrm.org/dev/en/latest/financial/financialentities/), when a Pending Order is created it's supposed to create a financial trxn transferring the total sum to accounts receivable. I'm not seeing this...According to the [docs](https://docs.civicrm.org/dev/en/latest/financial/financialentities/), when a Pending Order is created it's supposed to create a financial trxn transferring the total sum to accounts receivable. I'm not seeing this happening.
@JoeMurray [pointed out](https://chat.civicrm.org/civicrm/pl/zs556c7xqjdtjciry8qnipw7rc) that *There's a setting in CiviContribute Compnent Settings now which iirc disables this by default.*
And @eileen suggested that the default should be the other way around.
But even with this turned ON, the trxn is not created.
```bash
# Set this to a contact that exists:
CID=202
cv api Order.create financial_type_id=Donation contact_id=$CID contribution_status_id=Pending \
total_amount=30 receive_date=2020-05-29\ 15:30:00
```
At this point we would expect (according to my understanding) to see:
- ✔ 1 contribution record.
- ✔ 1 line item: directly linked to the contribution.
- ✔ 1 financial item, linked to the line item, which specifies the CREDIT financial account (*Donation*) and status 3 (pending).
- ✖ 1 financial trxn:
- `from_account` (the CREDIT): The revenue (income) account for the *Donation* financial type.
- `to_account` (the DEBIT): Accounts Receiveable
- ✖ related entity financial trxn records
Without this we end up with bookkeeping problems:
- all financial trxns come *from* Accounts Recievable, but there's nothing going *to* Accounts Receivable.
- there are no bookkeeping transactions for the revenue accounts.
- So you get info like "some money went into your bank" but not "a donation went into your bank".JoeMurrayJoeMurrayhttps://lab.civicrm.org/dev/financial/-/issues/133Enhancements to Payment PropertyBag2021-04-12T10:46:20Zmattwiremjw@mjwconsult.co.ukEnhancements to Payment PropertyBagPayment PropertyBag was added in 5.20 but it is only when attempting conversion of payment code/processors that we find things that are missing or still need consideration. I'm adding some things here but would encourage @eileen @artful...Payment PropertyBag was added in 5.20 but it is only when attempting conversion of payment code/processors that we find things that are missing or still need consideration. I'm adding some things here but would encourage @eileen @artfulrobot and others to edit/update this description once we are in agreement.
1. The following parameters should be added:
* trxn_id -> Maps to `transactionID`.
* installments
* recur start/end dates?
2. To support a phased conversion to propertyBag we should allow exporting as an array: https://github.com/civicrm/civicrm-core/pull/17507 or similar. Alternatively we should document using reflection to access the propertyBag array eg.:
```
if ($propertyBag instanceof \Civi\Payment\PropertyBag) {
$reflectionClass = new ReflectionClass($propertyBag);
$reflectionProperty = $reflectionClass->getProperty('props');
$reflectionProperty->setAccessible(TRUE);
$params = $reflectionProperty->getValue($propertyBag)['default'];
}
else {
$params = $propertyBag;
}
```
3. Some parameters should be either be ignored or added to propertyBag in some form during `mergeLegacyInputParams` such as:
* qfKey
* entryURL
* qf_default..
Note that both `qfKey` and `entryURL` can be useful for guessing context though it would be nice if there was a better way to identify the context in which a payment processor was being used.
Eg. see https://lab.civicrm.org/extensions/stripe/-/blob/6.4.1/CRM/Core/Payment/Stripe.php#L1063 for an example of `qfKey` usage which shows that we don't really need `qfKey` but do need a more formal way of obtaining an errorURL or removing the need for it at all.https://lab.civicrm.org/dev/financial/-/issues/127Receipts for recurring transactions are missing links to modify future contri...2023-11-23T07:34:12ZEdselopezReceipts for recurring transactions are missing links to modify future contributionsOn a backoffice credit card contribution page, there is text indicating that the email sent for a recurring contribution will contain links to modify/cancel the recurring transaction. The receipt however, does not contain these links.On a backoffice credit card contribution page, there is text indicating that the email sent for a recurring contribution will contain links to modify/cancel the recurring transaction. The receipt however, does not contain these links.seamusleeseamusleehttps://lab.civicrm.org/dev/financial/-/issues/126Membership BAO does creepy stuff with line items2020-05-27T12:44:56ZeileenMembership BAO does creepy stuff with line itemsI've finally made sense of the code in the Membership BAO but it kinda scares me. The code is set up to create line items for memberships that do not have contributions.
It seems that a membership with no contribution will wind up creat...I've finally made sense of the code in the Membership BAO but it kinda scares me. The code is set up to create line items for memberships that do not have contributions.
It seems that a membership with no contribution will wind up creating a 'best effort' line item and deleting any line items already related to the membership.
In the code I'm looking at (the renewal form) the contribution is created later & the membership winds up with 2 line items (one with a NULL contribution id).
I used to think that line items had to have a contribution id but I've learnt that participants also support orphan line items. However, in this case they wind up with both.
I'm not clear that it was intentional that ALL memberships have line items - it looks from the code like it might have originally been for non-quick-config-only. However, I guess??? it's the model now - although I suspect it's inconsistent.....
I think we might need to start passing in skipLineItem a bit more.
I can replicate the MembershipRenewal one in a test so can process that onehttps://lab.civicrm.org/dev/core/-/issues/1761Should deprecate Financial Type on Contribution records2023-03-13T13:54:21ZRichShould deprecate Financial Type on Contribution recordsOverview
----------------------------------------
Contribution records have a **financial type**. They also have line items, each of which has a financial type. Typically, a contribution has a single line item, and the financial types o...Overview
----------------------------------------
Contribution records have a **financial type**. They also have line items, each of which has a financial type. Typically, a contribution has a single line item, and the financial types of each match. But it's quite possible to have different financial types e.g. contribution and only line item could have different types which does not make sense. Also if a contribution has multiple line items of different types, what should the financial type of the contribution be?
Having financial type on the contribution harks back to simpler times before we allowed line items. But for 90%(?) of cases it doesn't matter much because they're the same. And of course there's a thousand places in core that assumes a single finanical type per contribution, and there's a thousand more in custom code and extensions.
Currently (5.26) you get an api exception if you call Order.create without setting a contribution-level financial type, which is slightly irksome when you're providing line items, not least because it forces new code to do nonsense old stuff, which can lead to developer confusion.
Nb. all the UIs that create contribution records set a financial type to *something*. This may or may not make sense compared with line items (e.g. it's taken from the priceset).
Proposals
---------------
1. I would like to be able to call Order.create with line items and have it pick the financial type from the first line item to use for the Contribution record. This would not affect any existing processes (with the possible exception of processes that currently crash...!)
2. I propose that over time (it will be a long time!) we move all reports/searches etc. to go the extra JOIN and inspect the line items for info on financial types instead of using the contribution's single financial type value.
Comments
----------------------------------------
This is a place to discuss it. Discussion began in [mattermost](https://chat.civicrm.org/civicrm/pl/pjtag6uu1tr7fxaeua51cfhk8w)https://lab.civicrm.org/dev/core/-/issues/1726Allow financial types to not have Expense account defined2022-08-26T20:51:52ZJoeMurrayAllow financial types to not have Expense account definedThis is a proposal for discussion and refinement.
Overview
----------------------------------------
Simplify accounting configuration to remove requirement for, and default creation of, widely unused stuff. In particular, don't require ...This is a proposal for discussion and refinement.
Overview
----------------------------------------
Simplify accounting configuration to remove requirement for, and default creation of, widely unused stuff. In particular, don't require Expenses account for every financial type, nor create relations to Expense and Premium accounts by default when creating a financial type.
Example use-case
----------------------------------------
1. Click on **Administer > CiviContribute > Financial Types**.
1. Click **Add Financial Type**.
1. Enter **Name** and click **Save**.
1. In Financial Accounts, there are Banking Fees and Premiums accounts, which is **undesirable**.
1. Click **Accounts** on the new Financial Type row.
1. Beside the 'Expense Account is', click **Delete**, then confirm by clicking **Delete** again.
1. Click on **Contributions > New Contribution**.
1. Select the Financial Type created above that does not have an Expense Account set up for it anymore, fill in **Contributor** and **Total Amount**, and click **Save**.
1. Try to edit the contribution but not in a popup, for example, go to the contact's page, right click on the edit button for the contribution and Copy Link Address, then paste address into a new tab. You'll see "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.
One of parameters (value: ) is not of the type Integer". This is caused by missing Expense account, **even though it is not needed**.
Current behaviour
----------------------------------------
See above.
Proposed behaviour
----------------------------------------
On creation of Financial Type, no Expense or Premiums account relationship would be setup. On editing a contribution (with a line item) with a financial type without an Expense account relationship setup, no error would occur.
Comments
----------------------------------------
The expectation when this was implemented circa 2014 was that payment processors would all soon record banking fees. That hasn't been the case for a variety of reasons.Monish DebMonish Debhttps://lab.civicrm.org/dev/financial/-/issues/122Offer api support for failed payments2022-10-16T08:10:45ZeileenOffer api support for failed paymentsCurrently the support we have for failed payments is on the BaseIPN class - it should be moved to the BAO / api layer. In general BaseIPN should just call apis ....
I'm thinking about what the api call should look like
I *think* what w...Currently the support we have for failed payments is on the BaseIPN class - it should be moved to the BAO / api layer. In general BaseIPN should just call apis ....
I'm thinking about what the api call should look like
I *think* what we we want is to support the following in Payment.create api/BAO
- status_id = 'Failed'
- 'is_update_contribution_status' = TRUE/ FALSE
This would add a Failed payment to the contribution and optionally (default yes I think) do all the flow on things that currently happen. If the default for is_update_contribution_status then it is closer to the current expectations.
I realise that not everyone thinks we should fail those things in all scenarios - but they feel kinda baked in & like a bigger change to address.
I also thought about using 'is_fail_contribution' - but then if we have status_id = 'Cancelled' we don't want 'is_cancel_contribution' & is a cancel the same as a fail?
As a follow on thought - we should possibly have a message template that could be sent out when a fail occurs.
@JoeMurray @mattwire @monish.debhttps://lab.civicrm.org/dev/financial/-/issues/121Financial Type ACLs don't work on soft credits2022-08-17T22:07:10ZJonGoldFinancial Type ACLs don't work on soft creditsTo replicate:
* Create a soft credit on any contribution. Note the financial type.
* Enable Financial ACLs.
* Log in as a user who doesn't have permission to view the financial type noted above.
* If you're using `civicrm-buildkit`, an...To replicate:
* Create a soft credit on any contribution. Note the financial type.
* Enable Financial ACLs.
* Log in as a user who doesn't have permission to view the financial type noted above.
* If you're using `civicrm-buildkit`, any non-administrative user who can view CiviCRM (e.g. with `CiviCRM Webtest User` role) qualifies.
* View the contact with the soft credit.
### Expected Result
* The soft credit is not visible.
### Actual Result
* The soft credit is visible. Clicking `View` to view the original contribution returns a "permission denied", which is correct (but bad UX).JonGoldJonGoldhttps://lab.civicrm.org/dev/translation/-/issues/41Invoice for recurring contribution should be sent in the preferred language o...2022-11-25T16:01:21ZbgmInvoice for recurring contribution should be sent in the preferred language of the contactThe contact record has a "preferred language" field, which can be automatically set when people fill in Contribution or Event forms.
That field can be used in certain circumstances, such as in Mailings and in Scheduled Reminders.
Howev...The contact record has a "preferred language" field, which can be automatically set when people fill in Contribution or Event forms.
That field can be used in certain circumstances, such as in Mailings and in Scheduled Reminders.
However, it is not used in the following circumstances:
* In Administration > CiviContribute > Component settings, enable "tax and invoicing", and enable PDF invoices.
* In Administration > Localization > Languages, enable multilingual, and enable a second locale.
* Setup a form that supports recurring contributions, enable email receipts
* As an anonymous user, donate on that form in the second language (not the default global language), selecting a recurring (ex: daily) donation.
Double-check that the contact record that was created has the second-language. Change if it necessary (I forget where the setting is, for defining the pref. language).
Then, as time passes, notice that the recurring email receipts are in the default site language. This is because the cron or IPNs will usually run in the default site language.
`CRM_Core_BAO_ActionSchedule::setCommunicationLanguage()` would be a good implementation reference. We should probably move it to `CRM_Core_I18n` for clarity.https://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/1571New Contribution form gives fatal error when using ONLY_FULL_GROUP_BY2023-02-07T19:36:18ZDaveDNew Contribution form gives fatal error when using ONLY_FULL_GROUP_BYI'm not sure if this is something that's changed recently but my local setup has had mysql 5.7 with only_full_group_by for a while now so it seems like it would have come up, and I can't be the only one. The related code doesn't seem to ...I'm not sure if this is something that's changed recently but my local setup has had mysql 5.7 with only_full_group_by for a while now so it seems like it would have come up, and I can't be the only one. The related code doesn't seem to have changed though. Maybe it only comes up in a certain configuration.
I can see the PR test sites don't have only_full_group_by so I assume dmaster.demo also doesn't, so I can't easily double-check on those.
```
SELECT
DISTINCT ( price_set_id ) as id, s.title
FROM
civicrm_price_set s
INNER JOIN civicrm_price_field f ON f.price_set_id = s.id
INNER JOIN civicrm_price_field_value v ON v.price_field_id = f.id
WHERE
is_quick_config = 0 AND s.is_active = 1 AND s.extends LIKE '%2%' AND s.financial_type_id IN (3,1,4,2) AND v.financial_type_id IN (3,1,4,2) GROUP BY s.id [nativecode=1055 ** 'f.price_set_id' isn't in GROUP BY]
0 ...\sites\all\modules\civicrm\CRM\Core\Error.php(192): CRM_Core_Error::backtrace("backTrace", TRUE)
1 ...\sites\all\modules\civicrm\vendor\pear\pear-core-minimal\src\PEAR.php(922): CRM_Core_Error::handle(Object(DB_Error))
2 ...\sites\all\modules\civicrm\packages\DB.php(997): PEAR_Error->__construct("DB Error: unknown error", -1, 16, (Array:2), "\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...")
3 ...\sites\all\modules\civicrm\vendor\pear\pear-core-minimal\src\PEAR.php(575): DB_Error->__construct(-1, 16, (Array:2), "\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...")
4 ...\sites\all\modules\civicrm\vendor\pear\pear-core-minimal\src\PEAR.php(223): PEAR->_raiseError(Object(DB_mysqli), NULL, -1, 16, (Array:2), "\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...", "DB_Error", TRUE)
5 ...\sites\all\modules\civicrm\packages\DB\common.php(1925): PEAR->__call("raiseError", (Array:7))
6 ...\sites\all\modules\civicrm\packages\DB\mysqli.php(935): DB_common->raiseError(-1, NULL, NULL, "\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...", "1055 ** 'f.price_set_id' isn't in GROUP BY")
7 ...\sites\all\modules\civicrm\packages\DB\mysqli.php(405): DB_mysqli->mysqliRaiseError()
8 ...\sites\all\modules\civicrm\packages\DB\common.php(1231): DB_mysqli->simpleQuery("\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...")
9 ...\sites\all\modules\civicrm\packages\DB\DataObject.php(2691): DB_common->query("\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...")
10 ...\sites\all\modules\civicrm\packages\DB\DataObject.php(1829): DB_DataObject->_query("\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...")
11 ...\sites\all\modules\civicrm\CRM\Core\DAO.php(421): DB_DataObject->query("\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...")
12 ...\sites\all\modules\civicrm\CRM\Core\DAO.php(1420): CRM_Core_DAO->query("\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...", TRUE)
13 ...\sites\all\modules\civicrm\CRM\Price\BAO\PriceSet.php(403): CRM_Core_DAO::executeQuery("\n SELECT\n DISTINCT ( price_set_id ) as id, s.title\n FROM\n ...")
14 ...\sites\all\modules\civicrm\CRM\Contribute\Form\Contribution.php(716): CRM_Price_BAO_PriceSet::getAssoc(FALSE, "CiviContribute")
15 ...\sites\all\modules\civicrm\CRM\Core\Form.php(595): CRM_Contribute_Form_Contribution->buildQuickForm()
16 ...\sites\all\modules\civicrm\CRM\Core\QuickForm\Action\Display.php(76): CRM_Core_Form->buildForm()
17 ...\sites\all\modules\civicrm\packages\HTML\QuickForm\Controller.php(203): CRM_Core_QuickForm_Action_Display->perform(Object(CRM_Contribute_Form_Contribution), "display")
18 ...\sites\all\modules\civicrm\packages\HTML\QuickForm\Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contribute_Form_Contribution), "display")
19 ...\sites\all\modules\civicrm\CRM\Core\Controller.php(335): HTML_QuickForm_Page->handle("display")
20 ...\sites\all\modules\civicrm\CRM\Contribute\Page\Tab.php(316): CRM_Core_Controller->run()
21 ...\sites\all\modules\civicrm\CRM\Contribute\Page\Tab.php(372): CRM_Contribute_Page_Tab->edit()
22 ...\sites\all\modules\civicrm\CRM\Core\Invoke.php(268): CRM_Contribute_Page_Tab->run((Array:3), NULL)
23 ...\sites\all\modules\civicrm\CRM\Core\Invoke.php(68): CRM_Core_Invoke::runItem((Array:16))
24 ...\sites\all\modules\civicrm\CRM\Core\Invoke.php(36): CRM_Core_Invoke::_invoke((Array:3))
25 ...\sites\all\modules\civicrm\drupal\civicrm.module(456): CRM_Core_Invoke::invoke((Array:3))
26 ...\includes\menu.inc(527): civicrm_invoke("contribute", "add")
27 ...\index.php(21): menu_execute_active_handler()
28 {main}
```https://lab.civicrm.org/dev/user-interface/-/issues/13Offline receipt sending fields inconsistently handled2023-11-23T07:19:06ZAndie HuntOffline receipt sending fields inconsistently handledThe backend contribution, event registration, and membership forms each offer the ability to email a receipt to the contact. However, this parallel behavior is handled independently for each form and is done inconsistently. This has ca...The backend contribution, event registration, and membership forms each offer the ability to email a receipt to the contact. However, this parallel behavior is handled independently for each form and is done inconsistently. This has caused a handful of issues:
1. The admin can specify receipt text for memberships and event registrations but not for contributions. @alicefrumin wrote a fix for this in [PR 15605](https://github.com/civicrm/civicrm-core/pull/15605), but @bgm thought it required a Gitlab issue to discuss and @eileen was uncomfortable with any improvements to receipts until some code is cleaned up.
2. There is a regression in 5.21 where the backend new contribution form in "standalone" context (coming in cold, rather than from a contact) never allows you to send a receipt from the form. This appears to have been introduced by [PR 15757](https://github.com/civicrm/civicrm-core/pull/15757) which, ironically enough, was an attempt to make the new contribution form work consistently with member, participant, and grant forms.
I think it will be challenging to resolve all of the ways the forms are similar but inconsistent, but the receipts are a clear problem and perhaps somewhere to start.https://lab.civicrm.org/dev/financial/-/issues/112Add FormRule to force user to remove "&" from both "Billing First Name" and "...2019-12-19T08:39:04ZKarinGAdd FormRule to force user to remove "&" from both "Billing First Name" and "Billing Last Name" fields**Issue:**
First Name field can be filled out as e.g. "Jon & Mary";
That "&" can cause issues with Payment Processors when it's passed on as part of the Cardholder Name - resulting in rejecting properly entered Credit Card information....**Issue:**
First Name field can be filled out as e.g. "Jon & Mary";
That "&" can cause issues with Payment Processors when it's passed on as part of the Cardholder Name - resulting in rejecting properly entered Credit Card information.
Credit Card Payments with iATS Payments will get a REJ:23 failure code when the Cardholder name contains a "&" - I did some research to see if this is iATS Payments' specific, but I don't think it is.
I found e.g. CartPay -> also has error codes ERROR: 54043: "The Billing Firstname contains invalid characters."
I also found SagePay has such error codes - for every single text field actually:
```
"5037 : The Delivery Address contains invalid characters.","5037 : The Delivery Address contains invalid characters."
"5038 : The Delivery Phone contains invalid characters.","5038 : The Delivery Phone contains invalid characters."
"5039 : The Delivery City contains invalid characters.","5039 : The Delivery City contains invalid characters."
"5040 : The Billing Surname contains invalid characters.","5040 : The Billing Surname contains invalid characters."
"5041 : The Billing Firstname contains invalid characters.","5041 : The Billing Firstname contains invalid characters."
"5042 : The Billing Address1 contains invalid characters.","5042 : The Billing Address1 contains invalid characters."
"5043 : The Billing Address2 contains invalid characters.","5043 : The Billing Address2 contains invalid characters."
"5044 : The Billing City contains invalid characters.","5044 : The Billing City contains invalid characters."
"5045 : The Billing Phone contains invalid characters.","5045 : The Billing Phone contains invalid characters."
"5046 : The Delivery Surname contains invalid characters.","5046 : The Delivery Surname contains invalid characters."
"5047 : The Delivery Firstname contains invalid characters.","5047 : The Delivery Firstname contains invalid characters."
"5048 : The Delivery Address1 contains invalid characters.","5048 : The Delivery Address1 contains invalid characters."
"5049 : The Delivery Address2 contains invalid characters.","5049 : The Delivery Address2 contains invalid characters."
"5050 : The Billing Address contains invalid characters.","5050 : The Billing Address contains invalid characters."
"5051 : The Contact Number contains invalid characters.","5051 : The Contact Number contains invalid characters."
"5052 : The Customer Name contains invalid characters.","5052 : The Customer Name contains invalid characters."
"5053 : The Email Message contains invalid characters.","5053 : The Email Message contains invalid characters."
"5054 : The Cardholder Name contains invalid characters.","5054 : The Cardholder Name contains invalid characters."
"5055 : A Postcode field contains invalid characters.","5055 : A Postcode field contains invalid characters."
"5056 : The Contact Fax contains invalid characters.","5056 : The Contact Fax contains invalid characters."
```
This Image illustrates -> issue (on the left) -> no issue (on the right). Of course the checkbox for My billing address is the same as above is what copies the First Name and Last Name fields down into the Cardholder name bits. The form rule can look for "&" and then tell the user to remove it. Note the user can still leave "Mark & Karin" in the Name and Address Profile. But we would prevent it from going into the Billing details.
![image](/uploads/bd1131f6790be6d085fe3962d4017ffa/image.png)https://lab.civicrm.org/dev/financial/-/issues/110Discussion: Should you be able to edit a cancelled or completed Contribution ...2019-12-19T08:38:28ZseamusleeDiscussion: Should you be able to edit a cancelled or completed Contribution RecurAt present if someone cancels the contribution recur object or is cancelled for them (in the chris chilla eway extension this happens if the payment fails and the card file details that are retreived indicate the card has expired) you ca...At present if someone cancels the contribution recur object or is cancelled for them (in the chris chilla eway extension this happens if the payment fails and the card file details that are retreived indicate the card has expired) you cannot edit them as they are in the inactive section, I'm curious if people think its correct that those recur objects can't be edited say to re-activeate them etchttps://lab.civicrm.org/dev/core/-/issues/1195Links in PayPal Standard recurring contribution confirmation email don’t work2023-11-23T07:47:01ZBobSLinks in PayPal Standard recurring contribution confirmation email don’t workRef: https://lab.civicrm.org/dev/core/issues/760
Contribution confirmation emails for recurring PayPal Standard contributions contain three links that are non-functional.
**Link 1: “This is a recurring contribution. You can cancel futu...Ref: https://lab.civicrm.org/dev/core/issues/760
Contribution confirmation emails for recurring PayPal Standard contributions contain three links that are non-functional.
**Link 1: “This is a recurring contribution. You can cancel future contributions by visiting this web page.”**
* Two questions are shown which seem inappropriate for a front-end page:
1. Send cancellation request to PayPal Standard ?
2. Notify Contributor?
* On submit:
* If Send Cancellation = Yes:
* Green-background status message: "The recurring contribution could not be cancelled."
* No change to recurring status in Civi or PayPal.
* If Send Cancellation = No:
* Green-background status message: “The recurring contribution of 5.20, every 1 month has been cancelled.”
* Contact record shows recurring contribution is cancelled
* Merchant and donor PayPal accounts continue to show active recurring transaction.
**Link 2: “You can update billing details for this recurring contribution by visiting this web page.”**
* There are only Save and Cancel buttons, but no form fields.
* Submit: "There was some problem updating the billing details"
**Link 3: “You can update recurring contribution amount or change the number of installments for this recurring contribution by visiting this web page.”**
* Recurrence Period is indicated as "(every )" rather than ‘(every month)”.
* If not logged in:
* Popup: "Access is denied. Ensure that you are still logged in and have permission to access this feature."
* On submit: Blank screen.
* If logged in:
* On submit:
* Displays Find Contributions page with no error indicated.
* No change observed in either merchant or donor PayPal accounts. Both show an active recurring payment.
**Analysis**
(I’ll focus on link 2 as an example, and assume that none of these 3 links should appear as their functions are unsupported by PayPal (?) for PayPal Standard payments)
1. Sending of confirmation email is initiated by Paypal performing an IPN POST.
2. CRM_Contribute_BAO_Contribution->composeMessageArray calls CRM_Core_Payment_PayPalImpl->subscriptionURL to form the problematic URLs.
3. CRM_Core_Payment_PayPalImpl->subscriptionURL attempts to determine if the payment processor supports each operation by doing, for example “if (!$this->supports('updateSubscriptionBillingInfo'))” which in turn returns method_exists($this, supportsUpdateSubscriptionBillingInfo).
4. CRM_Core_Payment (parent class of CRM_Core_Payment_PayPalImpl) does indeed contain function supportsUpdateSubscriptionBillingInfo which returns “method_exists(CRM_Utils_System::getClassName($this), 'updateSubscriptionBillingInfo')”.
5. CRM_Core_Payment_PayPalImpl does include function updateSubscriptionBillingInfo, although it begins with “if ($this->isPayPalType($this::PAYPAL_PRO)) “ and therefore simply returns false for PayPal Standard or Express
6. Template "Contributions - Receipt (on-line)" includes the problematic URL section based on the existence of $updateSubscriptionBillingUrl (for example).
**Conclusion**
* Step 3 seems to be a problem as it tests only for the existence of supportsUpdateSubscriptionBillingInfo (found in the parent class) rather than calling that function to get a meaningful result.
* Step 4 seems to be a problem because while the function 'updateSubscriptionBillingInfo' does indeed exist, it does nothing if the payment processor is PayPal Standard.
Behavior confirmed in 5.13.4 and in master (5.18.alpha1).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)EdselopezEdselopez