Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-11-23T07:47:01Zhttps://lab.civicrm.org/dev/core/-/issues/4265Checksum sent to Organization will not fill in "on behalf of" profile fields2023-11-23T07:47:01ZStoobChecksum sent to Organization will not fill in "on behalf of" profile fieldsScope the different [checksum token](https://docs.civicrm.org/user/en/latest/common-workflows/tokens-and-mail-merge/) behavior 'on behalf of' Org contribution page for
- an Individual related to an Organization https://civiteacher.com/c...Scope the different [checksum token](https://docs.civicrm.org/user/en/latest/common-workflows/tokens-and-mail-merge/) behavior 'on behalf of' Org contribution page for
- an Individual related to an Organization https://civiteacher.com/civicrm/contribute/transact?reset=1&id=9&cs=e8ecaad83d04439f381e4f2bf35d9322_1682576643_504&cid=102&mid=
- that Organization itself https://civiteacher.com/civicrm/contribute/transact?reset=1&id=9&cs=45ce7efc7d44ed07e8fd4097357ddc74_1682576099_504&cid=112&mid= with no contact info in org profile yet placing the org email in the individual email field
Should it not be the case that a checksum sent to an organization should fill out the 'on behalf of' section and leave the individual contact info blank to be filled out later? There are two good use cases where this may occur:
1. emails sent to the primary member organization _and_ the related contact individual(s) for maximum chance of renewal and/or in case contact person has quit
2. the organization primary member does not have a related contact indvidual at all. maybe it was entered incomplete or org imported without contact individual
But I cannot tell if it is a regression or if it has always been this way. @AllenShaw thoughts?https://lab.civicrm.org/dev/core/-/issues/4288Price set option limit = 0 should mean no spaces, rather than no limit2023-05-15T08:16:42ZlarsssandergreenPrice set option limit = 0 should mean no spaces, rather than no limitIf you set a price set option limit to 0, this is the same as not specifying a limit. I would expect that a limit of 0 would mean there are no spaces. Setting the limit to 0 is different than disabling the price set option, as disabling ...If you set a price set option limit to 0, this is the same as not specifying a limit. I would expect that a limit of 0 would mean there are no spaces. Setting the limit to 0 is different than disabling the price set option, as disabling makes it so the option does not appear on public forms, while I expect setting the limit to 0 would just make it sold out, but still appear. I can't think of a good reason you would want 0 to be the same as no limit, but maybe others can?
Will submit PR unless there are objections. Otherwise, will add help text.https://lab.civicrm.org/dev/core/-/issues/4299Send contribution receipt when contribution completed by recording payment on...2023-08-01T14:42:08ZlarsssandergreenSend contribution receipt when contribution completed by recording payment on the backendThrough discussion in this [PR](https://github.com/civicrm/civicrm-core/pull/26247), it has become clear that there is an inconsistency in which message templates are sent when completing a pending contribution with a payment, depending ...Through discussion in this [PR](https://github.com/civicrm/civicrm-core/pull/26247), it has become clear that there is an inconsistency in which message templates are sent when completing a pending contribution with a payment, depending on where the payment is recorded.
If the payment is recorded via API and the receipt has not yet been set, a contribution receipt template is sent.
If the payment is recorded via a Search Action and the receipt has not been sent, a contribution receipt template is sent.
If the payment is recorded via Record Payment in the UI, there is an option to send to send a receipt, but if selected a "Additional Payment Receipt or Refund Notification" template is sent.
I think that in the third case, for consistency, we should send a contribution receipt template as long as the contribution is now completed. The same logic works with membership receipt templates.https://lab.civicrm.org/dev/core/-/issues/4312Undefined array key and deprecated warnings on contributions overview page2023-06-06T05:55:19ZTobias KrauseUndefined array key and deprecated warnings on contributions overview pageWhen going to /civicrm/contact/view/contribution many "array undefined" warnings appear in watchdog:
```
Warning: Undefined array key "selectedChild" in include() (Zeile 11 in C:\wamp64\www\civicrm\httpdocs\sites\default\files\private\c...When going to /civicrm/contact/view/contribution many "array undefined" warnings appear in watchdog:
```
Warning: Undefined array key "selectedChild" in include() (Zeile 11 in C:\wamp64\www\civicrm\httpdocs\sites\default\files\private\civicrm\templates_c\en_US\%%6F\6FD\6FDADEDF%%TabSelected.tpl.php)
Warning: Undefined array key "type" in include() (Zeile 17 in C:\wamp64\www\civicrm\httpdocs\sites\default\files\private\civicrm\templates_c\en_US\%%3D\3D4\3D44E36C%%Selector.tpl.php)
**(I think this warning appears once for each contribution in the list)**
Warning: Undefined array key "softCredit" in include() (Zeile 93 in C:\wamp64\www\civicrm\httpdocs\sites\default\files\private\civicrm\templates_c\en_US\%%84\843\843D5262%%Tab.tpl.php)
Warning: Undefined array key "payment_processor" in include() (Zeile 12 in C:\wamp64\www\civicrm\httpdocs\sites\default\files\private\civicrm\templates_c\en_US\%%1B\1B6\1B6ACE3B%%ContributionRecurSelector.tpl.php)
Warning: Undefined array key "recurId" in include() (Zeile 12 in C:\wamp64\www\civicrm\httpdocs\sites\default\files\private\civicrm\templates_c\en_US\%%1B\1B6\1B6ACE3B%%ContributionRecurSelector.tpl.php)
Deprecated function: str_replace(): Passing null to parameter #2 ($replace) of type array|string is deprecated in smarty_modifier_replace() (Zeile 25 in C:\wamp64\www\civicrm\vendor\civicrm\civicrm-packages\Smarty\plugins\modifier.replace.php)
```https://lab.civicrm.org/dev/core/-/issues/4318Contributions sometimes lack line items, leads to fatal error upon "Download ...2023-06-21T00:11:44ZAllenShawContributions sometimes lack line items, leads to fatal error upon "Download Invoice"Originally reported at https://civicrm.stackexchange.com/questions/44907/contribution-has-no-line-items-shouldnt-that-be-impossible
**Problem and observation:**
On several sites I have found contributions which have no line items -- th...Originally reported at https://civicrm.stackexchange.com/questions/44907/contribution-has-no-line-items-shouldnt-that-be-impossible
**Problem and observation:**
On several sites I have found contributions which have no line items -- that is, rows in civicrm_contribution that have no corresponding rows in civicrm_line_item.
![no-line-items](/uploads/0f3958d00084586a43d7c04419a29ab7/no-line-items.png)
Responses at the above-linked SE question indicate that this is not normal.
This situation leads to a fatal error ("Return value of CRM_Financial_BAO_Order::getPriceSetID() must be of the type int, null returned") when attempting to generate a PDF invoice with "Download Invoice" for the given contribution, apparently on the assumption that this situation is not expected by core code.
**Detecting ffected sites:**
I've observed this on several sites (all currently running CiviCRM 5.58.1 but all having existed much longer), including one local dev site that sees relatively light usage.
This SQL query identifies contributions lacking line items:
```
SELECT count(*)
FROM
civicrm_contribution ctr
left join civicrm_line_item li on li.contribution_id = ctr.id
where li.id is null;
```
**Unable to repro:**
I'm unable to reproduce this situation at will, except by manually deleting rows in civicrm_line_item via API or SQL. It seems any contribution record will, by design, have at least one line_item, even if using a quick-config contribution instead of a visible price set, or if manually creating even a zero-dollar contribution in the back-end.
**Moving forward:**
Until we have a solid set of steps to repro, I'm not sure there's much we can do here. Hopefully this issue can serve as a place for others to share their findings (and hopefully we'll get to some repro steps at some point).https://lab.civicrm.org/dev/core/-/issues/4324Add Contribution Page settings for Review and Make Contribution button text2023-11-23T07:47:54ZlarsssandergreenAdd Contribution Page settings for Review and Make Contribution button textContribution Pages can be important to some organizations who do a lot of fundraising. It would be nice if the buttons were customizable, so they could say 'Donate', 'Give', 'Get Membership' or whatever the user might want.
Proposal: Ad...Contribution Pages can be important to some organizations who do a lot of fundraising. It would be nice if the buttons were customizable, so they could say 'Donate', 'Give', 'Get Membership' or whatever the user might want.
Proposal: Add two fields to Contribution Pages: review_button_text and submit_button_text. These settings could live on the main settings tab, underneath "Use a confirmation page?" with review_button_text hidden and shown conditionally. If these are populated, use these values, if not, fall back to the default (Contribute or Review your contribution followed by Make Contribution).https://lab.civicrm.org/dev/core/-/issues/4332Error in membership status after a) changing membership type followed by b) p...2023-11-23T07:23:38ZJoeMurrayError in membership status after a) changing membership type followed by b) payment failure## Overview
Using a pay later payment when renewing a membership can lead to problems with the membership status, membership end date and membership type being changed at the time of the renewal being initiated ; these fields are update...## Overview
Using a pay later payment when renewing a membership can lead to problems with the membership status, membership end date and membership type being changed at the time of the renewal being initiated ; these fields are updated without a payment being recorded. It is possible that a payment will never be received, or its processing may fail. It is not easy to revert the data to its former state, or what it would have become through time from date of update to when the correction is attempted. For example, a renewal with a delayed payment might change the status from Grace to Current, the End Date from May 14, 2023 to May 14, 2024, and the Membership Type from General to Student.
These are very old problems dating to at least 2013 I believe.
The problem only occurs when both membership types have the same parent organization, and only for paid memberships. It occurs whether the membership period is Rolling or Fixed, and whether a membership type is being changed or not.
## Proposal
Refactor the current implementation so that a second, temporary membership is created that can store the new information without overwriting the old information until a payment is received for it. The new temporary membership would have a status of Pending. The Pending contribution would be related to the temporary rather than existing membership. When the payment is received (status=complete), the Pending membership's information is used to update the permanent membership, and the temporary membership record is deleted.
## Relevant code
In the Contribution Confirmation page postProcess call [legacyProcessMembership](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Confirm.php#L1623), various fields are updated before the doPayment call is processed [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Confirm.php#LL1702C42-L1702C51). As a result, the existing membership record is updated with selected membership type/end date/status after user submits a payment but before the code makes payment request, e.g. to a payment processor. This works if the payment went successfully.
In the case of a payment failure such as for IPN payment processors like Paypal Standard (occasionally when there is a delay on getting IPN callback or if the IPN response is not handled properly like https://lab.civicrm.org/dev/core/-/issues/1931) or for a manual Pay Later payment that isn't received, it leaves the selected membership in current/active state with a changed end date and possibly a different membership type. There is no fallback code written to revert the membership state or set it to Pending, and it isn't easy to reconstruct the data.
## New Behaviour
1. When initiating the Payment for Membership Renewal, create a new membership record and link the contribution in pending status to it. Add a new field, renewing_membership_id, to civicrm_membership to hold a reference from this 'temporary' pending membership to the existing membership that is being renewed. The existing membership record remains unchanged.
2. When the contribution status of the related contribution changes to Complete, update the original membership with the information from the temporary membership and delete the temporary membership.
Recommendation: delay the creation of activities for Membership Renewal (id=8), Change Membership Status (id=35) and Change Membership Type (id=36) until the contribution is completed.
Recommendation: create a new Activity Type, Membership Renewal Pending, to be created when the renewal request is received. In its body, provide: "ID of Membership being renewed: xx, Number of Periods: yy, Membership Type: [Label of Membership Type".
## Implementation:
1. Modify [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Confirm.php#L2900), CRM_Member_BAO_Membership::getContactMembership and [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Confirm.php#L2939).
2. Add / update new / existing unit tests on these new scenarios.EdselopezEdselopezhttps://lab.civicrm.org/dev/core/-/issues/4334Remove Event Info link from Manage Event (and same from Manage Contribution P...2023-06-21T14:55:10ZlarsssandergreenRemove Event Info link from Manage Event (and same from Manage Contribution Page)![image](/uploads/dd822bae24450b2001a604f392198a89/image.png)
I'm not sure this is needed, since it just replicates the link available in the Event Links above, except less completely, as it doesn't include Online Registration, so users...![image](/uploads/dd822bae24450b2001a604f392198a89/image.png)
I'm not sure this is needed, since it just replicates the link available in the Event Links above, except less completely, as it doesn't include Online Registration, so users tend to think this is the only option (some organizations do not use Event Info, preferring to link straight to Registration).
There is a similar thing at the bottom of the first Manage Contribution Page tab that could also be removed, in my opinion. These look kind of weird and aren't really necessary, so I think they can go without losing anything, but am looking for further opinions on this.https://lab.civicrm.org/dev/core/-/issues/4341Users without batch permissions may create and run batches2023-06-09T08:53:44ZGavin SmalleyUsers without batch permissions may create and run batchesOverview
----------------------------------------
Users without permission to create batches can not only create batches but also validate and run them.
Reproduction steps
----------------------------------------
1. From a default insta...Overview
----------------------------------------
Users without permission to create batches can not only create batches but also validate and run them.
Reproduction steps
----------------------------------------
1. From a default install of CiviCRM in WordPress access the "WordPress Access Control" page
2. For a given userclass remove all of the following permissions:
- CiviCRM: create manual batch Create an accounting batch (with Access to CiviContribute and View Own/All Manual Batches)
- CiviCRM: edit own manual batches Edit accounting batches created by user
- CiviCRM: edit all manual batches Edit all accounting batches
- CiviCRM: close own manual batches Close accounting batches created by user (with Access to CiviContribute)
- CiviCRM: close all manual batches Close all accounting batches (with Access to CiviContribute)
- CiviCRM: reopen own manual batches Reopen accounting batches created by user (with Access to CiviContribute)
- CiviCRM: reopen all manual batches Reopen all accounting batches (with Access to CiviContribute)
- CiviCRM: view own manual batches View accounting batches created by user (with Access to CiviContribute)
- CiviCRM: view all manual batches View all accounting batches (with Access to CiviContribute)
- CiviCRM: delete own manual batches Delete accounting batches created by user
- CiviCRM: delete all manual batches Delete all accounting batches
- CiviCRM: export own manual batches Export accounting batches created by user
- CiviCRM: export all manual batches Export all accounting batches
3. Create a user for that userclass and login
4. Click "Batch Data Entry" from the Memberships menu
5. Create a batch and press validate.
Current behaviour
----------------------------------------
The batch will run.
Expected behaviour
----------------------------------------
If the user has none of the permissions above they should not be able to create, validate or run a batch.
Environment information
----------------------------------------
* __Browser:__ _Chrome Version 114.0.5735.90 (Official Build) (64-bit)_
* __CiviCRM:__ _5.52.2_
* __CMS:__ _WordPress 6.0.5_
Comments
----------------------------------------
The user can also "save for later" but can never access those saved batches again, as they are (quite correctly) prohibited from seeing the list.https://lab.civicrm.org/dev/core/-/issues/4361Add Pay now link to Invoice template2023-06-28T06:58:22ZlarsssandergreenAdd Pay now link to Invoice templateIt would be nice to have the link to pay online included in the Invoice template. Currently, a user would have to guess this is possible, find the correct link on SE and add it to the template (then maintain it as the template is updated...It would be nice to have the link to pay online included in the Invoice template. Currently, a user would have to guess this is possible, find the correct link on SE and add it to the template (then maintain it as the template is updated).
I think if default_invoice_page is set, we could simply include a Pay Now link in the Payment Advice section (which is only shown if the Contribution is pending and pay later). If an org doesn't want to include a link for online payment, they can simply leave default_invoice_page empty (Edit: They cannot currently do this for newer installs, will have to make it possible). I think it would be very rare for an org to want to have a default_invoice_page for payments from the User Dashboard, but not to include a link for online payments in invoices (and in that case, they can edit the template).
Will do this and add docs if supported.https://lab.civicrm.org/dev/core/-/issues/4367Apiv4 Order api2023-12-02T04:28:01ZeileenApiv4 Order api
There is general agreement that the biggest issue with the v3 api is the confusing arrays it requires. My preference in fact is for a fairly non-standard Order api - ie
```
Order::create()
->setContributionParameters([
'conta...
There is general agreement that the biggest issue with the v3 api is the confusing arrays it requires. My preference in fact is for a fairly non-standard Order api - ie
```
Order::create()
->setContributionParameters([
'contact_id' => 56,
'financial_type_id:name' => 'Donation',
])
->addLineItem([
'price_field_value_id:name' => 'student_rate',
'entity_id.role_id:name' => 'Attended',
'entity_id.contact_id' => 87,
'entity_id.event_id' => 6,
'entity_table' => 'civicrm_participant',
])
->execute();
```
On update we would have actions like `addLineItem`, `removeLineItem`
Obviously this starts to highlight a whole lot of issues
**1) at the contribution params level**
there are some parameters that we have long-standing discussions around - financial_type_id, receive_date, payment_instrument_id. I think we should probably not start with talking about those as we might never get any further
**2) line items**
- one specific thing I think we all agree on is that we don't want line items to have to belong to the same price set. There will be some fighting with the code to get there but it's probably an issue that lives outside the bike shed
- in the example above the entity_table is passed in. For memberships that can be inferred from the price_field_value_id, but for event participants there is nothing on the price field or price_field_value that declares something as being event related
- for line items we kinda want to require the minimum required info which varies a bit.... ie
**-- if we have only the line_total (in the line item or just the contribution.total_amount) we can assume**
- the price field id is the default contribution price field
- the quantity is 1
- the unit_price is the line_total
**-- if we have only the qty and the unit_price we can assume**
- the price field id is the default contribution price field
- the line_total is unit_price * qty
**-- if we have only the line_total and the entity_table, which is civicrm_membership we can assume**
- the price field id is the default membership field
**but we require one of membership_type_id or price_field_value_id, from which we can determine amounts **
**-- if we have only the price_field_value id we can assume**
- the amount & price field can be looked up from it. We can assume qty to be 1 unless provided
- We need some way of specifying relevant entity values. (I suspect this is where the rubber hits the brake pads in the bikeshedding process). In the above example I have leveraged `entity_id` in the way we do for other apiv4 related entities. The v3 order api had some ideas about entity parameters which didn't align with our specification that closely - I think they were effectively 'sub-participants' and if we want to add that it might be `'entity_id.registered_participants' => []` perhaps. It's also rather tempting to refer to use `participant_id` to stand in for `entity_id` when it reflects the line....
**3) the add payment.**
We currently chain this - I did include above in the first iteration of this but removed based on the discussion. The world won't end if we don't do that.https://lab.civicrm.org/dev/core/-/issues/4378Schema support for rounding2023-08-30T04:05:32ZeileenSchema support for roundingWe have an ongoing issue with rounding which I essentially believe is because our schema does not adequately support the variations on rounding in use, and I think we need to add additional fields to support this. The principle I think w...We have an ongoing issue with rounding which I essentially believe is because our schema does not adequately support the variations on rounding in use, and I think we need to add additional fields to support this. The principle I think we need to work to is:
**Can we calculate the 'missing' values with the data we have, if not we need to store it not treat it as calculable**
Our exising code assumes that if you have 2 out of 3 of tax_amount, tax_rate and one of tax_inclusive or tax_exclusive you can calculate the third. However, if what you have stored is numbers with some rounding applied you actually can't reverse engineer them.
**Specific proposal**
I propose we add to the schema
- civicrm_contribution.total_amount_exclusive
- civicrm_line_item.line_total_inclusive
- civicrm_line_item.tax_rate (note this CAN be calculated from the price field value id but could change over time either because of legislative changes such as sales tax increases - it only ever increases - or configuration changes.)
- civicrm_price_field_value.amount_inclusive
These would be calculated, if not provided, at the point of save. v4 Order api and Form Builder & BAO layer would support more nuanced usage of these but I don't anticipate any immediate changes to existing contribution or configuration quick forms to accommodate these. Search kit would expose them.
There is a bit of a gotcha around not-exposing them & being able to edit them on forms - so it is likely the contribution edit form would need to be adjusted to avoid re-saving in a way that causes problems. Possibly we need to get the ability to edit amount off the main form & into a sub-form which incorporates line item editor - this is something we have talked about before.
**Current situation**
The variations of rounding approaches we have people reporting using are
1) start with tax inclusive
2) start with tax exclusive
e.g
|Version| Tax exclusive | tax rate | tax amount | tax inclusive|
|----|----|----|----|----|
|start from inclusive| 869.57 | 15% | 130.43 | 1000|
|start from exclusive| 869.57 | 15% | 130.44 | 1000.01|
3) Round each line item before totalling (I think we are doing this) - apply tax as a % of the rounded amount, round the tax on each line
3) Store each line item un-rounded - apply tax per line item & add up
4) Total and then round the sum of the line items - apply tax to the total as a %, the amount that does not fit the line items is a rounding line item ?
The relevant existing tables /fields are
civicrm_contribution
- total_amount (inclusive)
- tax_amount
~~ - non_deductible_amount~~
civicrm_line_item
- line_total (exclusive)
- tax_amount
~~ - non_deductible_amount~~
civicrm_price_field_value
- amount (exclusive)
~~ - non_deductible_amount~~
civicrm_financial_account
- tax_rate
**Related issues**
https://lab.civicrm.org/dev/core/-/issues/3714
https://lab.civicrm.org/dev/financial/-/issues/189
https://lab.civicrm.org/dev/financial/-/issues/52
**Other**
Api v4 contribution.get supports returning `tax_exclusive_amount` for the field proposed as total_amount_exclusive abovehttps://lab.civicrm.org/dev/core/-/issues/4488Supporter Profile is a required field2023-11-23T07:48:29Zkiwi_BrogrammerSupporter Profile is a required fieldOverview
----------------------------------------
When editing contribution pages, if you click on the personal campaign tab and save (without changes) you get a warning about supporter profile being required field.
replicated this on d...Overview
----------------------------------------
When editing contribution pages, if you click on the personal campaign tab and save (without changes) you get a warning about supporter profile being required field.
replicated this on dmaster site.
civichat discussion : https://chat.civicrm.org/civicrm/pl/b8gp5g6u63dr7d6d8oqrrrc5nr
Environment information
----------------------------------------
* __CiviCRM:__ 5.62.1.
* __PHP:__ 8.1.20
* __CMS:__ Drupal 10.1.1
* __Database:__ MariaDB 10.5.19https://lab.civicrm.org/dev/core/-/issues/4499Undefined array key 0 when sending offline event receipt2023-10-13T01:01:38ZDaveDUndefined array key 0 when sending offline event receiptIt seems to be $lineItem[0] at https://github.com/civicrm/civicrm-core/blob/44efaf52507df2445908e02c30caef62ada0100a/CRM/Event/Form/Participant.php#L1353. It looks like it might not always be defined if editing an existing participant. B...It seems to be $lineItem[0] at https://github.com/civicrm/civicrm-core/blob/44efaf52507df2445908e02c30caef62ada0100a/CRM/Event/Form/Participant.php#L1353. It looks like it might not always be defined if editing an existing participant. But it's also confusing because it looks like sometimes it will be 0 and sometimes the array is keyed on price set id.https://lab.civicrm.org/dev/core/-/issues/4503Localization: Report contribution_details doesn't respect money settings for ...2023-08-17T14:22:38ZDetlev SieberLocalization: Report contribution_details doesn't respect money settings for additional fields## Reproduction steps
1. Set localization settings: **decimal separator** to `,` and **thousand separator** to `.`
2. Click on **Reports -\> Contribution Detail**
3. Select Non-deductible Amount, Fee Amount, Net Amount, Soft Credit Amou...## Reproduction steps
1. Set localization settings: **decimal separator** to `,` and **thousand separator** to `.`
2. Click on **Reports -\> Contribution Detail**
3. Select Non-deductible Amount, Fee Amount, Net Amount, Soft Credit Amount
4. Click on "Refresh results"
## Current behaviour
For the contribution amount, the localisation settings are interpreted correctly.
The other amounts don't respect the localisation settings.
See screenshot:
![2023-08-16_21-13.png](/uploads/ea63065ddba5bb00ce85c2cd77074cae/2023-08-16_21-13.png)
## Expected behaviour
All amounts should be displayed in the selected localisation format.https://lab.civicrm.org/dev/core/-/issues/4505Localisation: Report contribution_details doesn't respect date format settings2023-08-17T14:24:07ZDetlev SieberLocalisation: Report contribution_details doesn't respect date format settings## Overview
_see_ #4503 for similar issue
## Reproduction steps
1. Set localization settings **date format** to "%d.%m.%Y %H:%M" / "%d.%m.%Y"
2. Click on **Reports -\> Contribution Detail**
3. Click on "Refresh results" and/or downloa...## Overview
_see_ #4503 for similar issue
## Reproduction steps
1. Set localization settings **date format** to "%d.%m.%Y %H:%M" / "%d.%m.%Y"
2. Click on **Reports -\> Contribution Detail**
3. Click on "Refresh results" and/or download pdf
## Current behaviour
For the header, the localisation settings are interpreted correctly.
For the report lines, the date format don't respect the localisation settings.
See screenshot:
![contribution details date format.png](/uploads/453ea5f2249edac6e89ff322862c7a8d/contribution_details_date_format.png)
## Expected behaviour
All dates should be displayed in the selected localisation format.
##https://lab.civicrm.org/dev/core/-/issues/4540Email issues can cause new membership contributions to fail with pending/inco...2023-11-23T06:38:55ZTOCM_MMatthewsEmail issues can cause new membership contributions to fail with pending/incomplete.Overview
----------------------------------------
On a self hosted WordPress (currently 6.3) / CiviCRM (currently 5.64.0) site, when we had an SMTP server outage (not sending email from our virtual server directly, as that causes other s...Overview
----------------------------------------
On a self hosted WordPress (currently 6.3) / CiviCRM (currently 5.64.0) site, when we had an SMTP server outage (not sending email from our virtual server directly, as that causes other spam-related problems), any attempt to sign up as a member to our site would end in a failure state (contribution pending/incomplete), after processing payment but failing to send the receipt email. Could be related to the request timing out from php-fpm, but whatever that email timeout was, it was longer than 120s when I gave up trying to adjust php-fpm's timeout value. Settings within CiviCRM (outbound mail) have always just used mail(). But we use the WP Mail SMTP plugin for all WordPress related email to go through the trusted mailers directly. And when that was pointing to mail servers that timed out our connections, we'd see the pending/incomplete failures. Flipping that to default/none so it would use the host mailer as well, things started to work again (with the caveat of some emails not getting through because our server's IP will never be fully trusted by all the major mailers, given that it's within a virtual IP range that apparently triggered some alarms before).
https://civicrm.stackexchange.com/questions/45428/email-timeouts-breaking-contributions?noredirect=1#comment53603_45428
Reproduction steps
----------------------------------------
Set your WordPress mailer up to a host that times out the SMTP connection with WP Mail SMTP (we use the free version, non-profit, can't justify Pro upgrade). Key point probably being SMTP connection timeout being longer than php-fpm timeout, as the process terminates ungracefully.
Set up membership contribution page that sends credit card processing receipt. Maybe it was the password reset link from WordPress, but, can't see how?
Current behaviour
----------------------------------------
Users would not get any receipt or password reset email, transaction -- while processed via our provider (Stripe) would show as pending/incomplete transaction.
Expected behaviour
----------------------------------------
The transaction should continue. Maybe emails will get delayed/queued/lost depending on the mailer situation, but this should not break recording of a successful payment, so we'd just have to resend emails instead of go in and mark the transaction as complete after verifying payment has been received and then resend emails.
Environment information
----------------------------------------
* __Browser:__ Every. Testing confirmed with Safari 16.5.2 / Chrome 116.0.x on macOS Ventura 13.4.1(c).
* __CiviCRM:__ 5.64.0 at the time of SMTP failure
* __PHP:__ 8.0.30
* __CMS:__ WordPress 6.3
* __Database:__ MySQL 8.0.32
* __Web Server:__ Apache 2.4.57
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/financial/-/issues/217Proposal: Remove Transaction ID from message templates2023-11-23T07:28:45ZlarsssandergreenProposal: Remove Transaction ID from message templatesSix message templates (event online and offline, contribution online and offline, membership and payment/refund) include Transaction #. I don't think this is useful information for the recipient, as it is just a long string of characters...Six message templates (event online and offline, contribution online and offline, membership and payment/refund) include Transaction #. I don't think this is useful information for the recipient, as it is just a long string of characters. So my proposal is to remove it, to simplify the templates and only send pertinent information to the recipient.
The only potential use I can think of would be in some edge case where perhaps you can't find a contribution for some reason and you could in that case search by transaction ID, but that seems rare and easily covered by having the exact time, amount, etc. If we did want to have something for that purpose, contribution ID would make a lot more sense, but I don't think we need either. Has anyone ever used the transaction ID from a receipt for any purpose?https://lab.civicrm.org/dev/core/-/issues/4579Importing contribution with same transaction id as an existing contribution h...2023-09-18T21:27:34ZDaveDImporting contribution with same transaction id as an existing contribution hijacks the initial contribution1. Create a contribution.
2. Give it a trxn id, or note the trxn id if it was automatic.
3. Do a contribution import, choosing to insert new records, where you make the trxn id in the file the same as the one just created, and with some ...1. Create a contribution.
2. Give it a trxn id, or note the trxn id if it was automatic.
3. Do a contribution import, choosing to insert new records, where you make the trxn id in the file the same as the one just created, and with some different particulars.
4. Notice that the contribution with that transaction id has now moved to whatever contact was in your import file, and the details updated.
What I would expect is that it says it's a duplicate and doesn't import it.
----
Edited since originally it came up with a recurring contribution but it applies to all.https://lab.civicrm.org/dev/user-interface/-/issues/55Clarify "Pay Later", "Execute real-time transactions"2023-09-26T12:15:02ZbgmClarify "Pay Later", "Execute real-time transactions"From [a thread](https://chat.civicrm.org/civicrm/pl/xz1pm9p31jr93ehespfnq643or) started by @guyiac
- [ ] Manage Contribution Pages: "execute real-time transactions", unchecking this really is only about free memberships, not about in-k...From [a thread](https://chat.civicrm.org/civicrm/pl/xz1pm9p31jr93ehespfnq643or) started by @guyiac
- [ ] Manage Contribution Pages: "execute real-time transactions", unchecking this really is only about free memberships, not about in-kind donations, which is a vague concept that CiviCRM never really explains. There are many scenarios where we want to use a PriceSet but the total amount will be 0$ and we still want a contribution
- [ ] Pay Later: we should clarify that this is also a suitable option when we expect the total amount to be 0$, in which case, the payment will be status=complete
- [ ] Pay Later: the instructions should be optional. Maybe it's clear enough, maybe you don't need them, maybe you want to specify it by some other means
Some of the above also applies to Manage Events, although things like "Execute real-time transactions" is called "Paid Event yes/no".