CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-10-25T11:48:10Zhttps://lab.civicrm.org/dev/core/-/issues/3898CiviCRM log triggers don't fire on CASCADE DELETE2022-10-25T11:48:10ZbrienneCiviCRM log triggers don't fire on CASCADE DELETEOverview
----------------------------------------
When there is a CASCADE DELETE on an entity record, it does not trigger the CiviCRM log for the records (such as from a custom field attached to an entity) that are deleted as a result of...Overview
----------------------------------------
When there is a CASCADE DELETE on an entity record, it does not trigger the CiviCRM log for the records (such as from a custom field attached to an entity) that are deleted as a result of the cascade. This behavior makes it difficult to restore custom data from the log tables when the entity it was attached to is deleted and then needs to be restored.
Reproduction steps
----------------------------------------
1. Create a custom field to be *Used For* Grants (**Administer > Custom data and Screens > Custom Fields > Add Set of Custom Fields**)
1. Create a new Grant record and be sure to fill out the custom field(s) (**CiviGrant > New Grant**)
1. Delete the grant record (**CiviGrant Dashboard > View > Delete**)
1. View the log table of the custom field and you will note that there is no delete log_action on the custom field in question
* If using the command line or a SQL editor like DBeaver, you can use the following command to note the lack of the delete action from the custom field civicrm_log table. (*Be sure to change tablename to the actual log table's name*).
```sql
SELECT id, log_date, log_action FROM tablename;
Current behaviour
----------------------------------------
If a record is deleted as a result of a CASCADE DELETE, then the action is not logged in the applicable civicrm_log table.
Expected behaviour
----------------------------------------
The log triggers should fire on records that are deleted, even if as a result of a CASCADE DELETE.
Comments
----------------------------------------
This issue has been previously noted on this [post](https://stackoverflow.com/questions/26328570/on-delete-cascade-not-firing-trigger) on Stack Overflow.https://lab.civicrm.org/dev/core/-/issues/3896api.Contact.create happy to create invalid employer relationship2022-10-20T07:25:22Zkonadaveapi.Contact.create happy to create invalid employer relationshipOverview
----------------------------------------
api.Contact.create does not check that the relationship between `employer_id` and the contact is valid.
Reproduction steps
----------------------------------------
Reproduced on dmaster....Overview
----------------------------------------
api.Contact.create does not check that the relationship between `employer_id` and the contact is valid.
Reproduction steps
----------------------------------------
Reproduced on dmaster.demo using combo of UI and API 3 Explorer. Showing as command line here to better illustrate.
```bash
$ cv api Contact.create first_name="Mickey" last_name="Mouse" email="mickey.mouse@example.com" contact_type="Individual"
{
"is_error": 0,
"version": 3,
"count": 1,
"id": 9,
"values": {...}
}
$ cv api Contact.create first_name="Minnie" last_name="Mouse" email="minnie.mouse@example.com" contact_type="Individual"
{
"is_error": 0,
"version": 3,
"count": 1,
"id": 10,
"values": {...}
}
$ cv api RelationshipType.getsingle name_b_a="Employer of" return="id,contact_type_b"
{
"id": "5",
"contact_type_b": "Organization"
}
$ cv api Relationship.create contact_id_a="9" contact_id_b="10" relationship_type_id="5"
{
"tip": "add debug=1 to your API call to have more info about the error",
"is_error": 1,
"error_message": "Invalid Relationship"
}
$ cv api Contact.create id="9" employer_id="10"
{
"is_error": 0,
"version": 3,
"count": 1,
"id": 9,
"values": {...}
}
$ cv api Relationship.get contact_id_a="9"
{
"is_error": 0,
"version": 3,
"count": 1,
"id": 5,
"values": {
"5": {
"id": "5",
"contact_id_a": "9",
"contact_id_b": "10",
"relationship_type_id": "5",
"is_active": "1",
"is_permission_a_b": "0",
"is_permission_b_a": "0",
"created_date": "2022-10-05 19:48:23",
"modified_date": "2022-10-05 19:48:23"
}
}
}
```
Current behaviour
----------------------------------------
An invalid relationship is created. On the contact summary screen, an employer may or may not be listed, but it's unlikely to be the invalid contact (i.e. it lists a unrelated org instead).
Expected behaviour
----------------------------------------
The API call should fail for the same reason as api.Relationship.create.
Environment information
----------------------------------------
Confirmed on dmaster.demo, and a local vanilla install of D9/Civi 5.48.2.https://lab.civicrm.org/dev/core/-/issues/3895SK/FB: Labelling a SK Form Builder form identically to a packaged search over...2022-10-25T11:48:33ZJonGoldSK/FB: Labelling a SK Form Builder form identically to a packaged search overwrites itIf you create two Search Forms with the same label, the machine name of the second one will automatically be changed. Eg. two forms labelled "Example" will create `afSearchExample` and `afSearchExample1`.
However, if one of the forms i...If you create two Search Forms with the same label, the machine name of the second one will automatically be changed. Eg. two forms labelled "Example" will create `afSearchExample` and `afSearchExample1`.
However, if one of the forms is a packaged form, this is NOT true.
### Steps to Replicate
* Enable an extension that provides a packaged SK form (e.g. CiviGrant provides `afSearchGrants`.
* Create a minimal Search Kit search.
* Create a form from that search and name it `Grants`.
### Expected Result
The new FB form is named `afSearchGrants1` and is separate from the packaged FB search form.
### Actual Result
The new FB form is named `afSearchGrants` and replaces the old form. You can't revert this without CLI access to rename the `.html` and `.json` files in `[civicrm.files]/ang`.
This came about when a client created a new FB search form and named it "Grants", causing their Grants tab to disappear.
I suspect that the naming behavior looks at other files in the same folder, and appends the `1` if it finds a file of the same name. It should be comparing against all `.aff.*` files. It should provide a warning that you're going to replace a core FB form.https://lab.civicrm.org/dev/core/-/issues/3882SearchKit - distinct values should be sorted by id2022-10-25T11:52:13ZvitiusSearchKit - distinct values should be sorted by idWhen we have List of contact name and dont use distinct. On output we get sorted list of names on contact id. And when we want have hyperlinks on contacts name, that works perfectly. But when we use distinct function, on output we get un...When we have List of contact name and dont use distinct. On output we get sorted list of names on contact id. And when we want have hyperlinks on contacts name, that works perfectly. But when we use distinct function, on output we get unsorted list of names. But links on contacts is sorted by contact id. That causes missmatch. First of display name have link to lowest contact id and last of display name have link to highest contact id.
I tried this on version 5.51.1 and 5.55.alpha1. And I tried this on case clients (you need enable multiple case clients) like you can see on images bellow. Also I tried this on event participants, where I use aggregation on event id and display participants names. On both distinct causes bad hyper links.
![image](/uploads/7fd977598194996923ddf3e1a698b261/image.png)
![image](/uploads/ac8b4684a84cc8da39b7179eff4ee749/image.png)https://lab.civicrm.org/dev/core/-/issues/3881Edit fields for invoicing information2022-10-25T11:52:40Zthoni56Edit fields for invoicing informationOverview
----------------------------------------
The form fields for invoicing information (in CiviEvent) seems to be hardcoded. E.g. it lacks company name and email. It does not seem possible to change or amend these fields.
Example u...Overview
----------------------------------------
The form fields for invoicing information (in CiviEvent) seems to be hardcoded. E.g. it lacks company name and email. It does not seem possible to change or amend these fields.
Example use-case
----------------------------------------
1. Create an event and enable web registrations
1. Make invoicing mandatory
2. Make a registration and notice what the only available fields are
Current behaviour
----------------------------------------
Hard coded fields
Proposed behaviour
----------------------------------------
Possiblity to use a profile, or custom form.
Comments
----------------------------------------
There is a StackExchange question around this: https://civicrm.stackexchange.com/questions/42202/how-can-i-add-company-to-billing-pay-later-fields but the proposed "solution" is hard and really not a solution.https://lab.civicrm.org/dev/core/-/issues/3875Pressing return on additional participants page for event registration goes b...2023-06-03T19:57:34ZlarsssandergreenPressing return on additional participants page for event registration goes back to previous page instead of forwardThere are three buttons on the additional participant page: Go Back, Continue, Skip Participant. Since all three are type="submit", when you press the return/enter key, the first button of type="submit" is clicked, so you go back one pag...There are three buttons on the additional participant page: Go Back, Continue, Skip Participant. Since all three are type="submit", when you press the return/enter key, the first button of type="submit" is clicked, so you go back one page. Contrast with the primary participant registration page, where return does take you to the next page because there is only one button or with a contribution page where return takes you to the confirmation page, again because there is only one button.
The easiest fix would be to change the types of the other buttons to "button". The button type [is set here](https://github.com/civicrm/civicrm-core/blob/c94963f7637912571ce62b33de60f7d5ce640f69/CRM/Core/Form.php#L758) for all buttons as "submit" unless type="reset" is passed to addButtons. So I propose to review button types in use, setting those that make sense as "submit" (next, done, submit, upload, process, etc) and others as "button" (cancel, refresh). Any buttons without a type will be left as "submit" so as to avoid breaking anything.
There is also a class default added to buttons that have isDefault, but it's unclear to me what this does.https://lab.civicrm.org/dev/core/-/issues/3874APIv4 Relationships refused if duplicated2022-11-26T20:59:14ZshaneonabikeAPIv4 Relationships refused if duplicated**Backlog**
I see that @samuelsov already reported this, but the bot closed the issue #451.
**Disabled Relationships**
I came across a scenario where if a Contact Relationship was disabled, and you attempt to create a new one (that ma...**Backlog**
I see that @samuelsov already reported this, but the bot closed the issue #451.
**Disabled Relationships**
I came across a scenario where if a Contact Relationship was disabled, and you attempt to create a new one (that matches dates) it is refused. Ironically, the UI let's me add the Relationship.
+ Create a Relationship with a start / end date
+ Disable relationship
+ Create a new Relationship with the same start / end date via UI (works)
+ Create a new Relationship with the same start / end date via APIv4 (fails with Duplicate Exception)
**Cases**
Today, I came across another scenario where we are using ActivityProfile with CiviRules. The gist is that when someone submits a CiviCase then CiviRules assigned the Case Coordinator to their case. It's the same person each time.
In this scenario, the APIv4 is also refused the submission because of the duplicated Relationship. But really I think it makes sense to have multiple cases open for one person with the same case coordinator managing them all right?
My scenario can be replicated without ActivityProfile
+ Create a Case for test user A and Coordinator X
+ Create a new Case for Test User A
+ Use the APiv4 to setup a relationship to Coordinator X
It should throw an exception Duplicate Relationship on relationship.create.
Thoughts?https://lab.civicrm.org/dev/core/-/issues/3868Link contribution view with asssociated entity2023-05-18T23:37:57ZyashodhaLink contribution view with asssociated entityWhen you view a contribution, there's no way to know whether this contribution was done as a part of membership, pledge or an event registration.
I propose provide this additional data. Display this under total amount
e,g
![Screens...When you view a contribution, there's no way to know whether this contribution was done as a part of membership, pledge or an event registration.
I propose provide this additional data. Display this under total amount
e,g
![Screenshot_from_2022-09-23_19-15-29](/uploads/24028770f5b17e20ab40334973061b05/Screenshot_from_2022-09-23_19-15-29.png)
Membership will be a link to membership view page.
(depending on the related entity we display the link)yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3858Email displays twice on Contribution Confirmation/Thank-you pages2023-11-23T07:47:00ZJonGoldEmail displays twice on Contribution Confirmation/Thank-you pagesOverview
----------------------------------------
If you have a profile on your contribution page that includes an email field, the email appears twice on the Confirmation and Thank-You pages.
Reproduction steps
------------------------...Overview
----------------------------------------
If you have a profile on your contribution page that includes an email field, the email appears twice on the Confirmation and Thank-You pages.
Reproduction steps
----------------------------------------
1. Create a contribution page.
1. Add a profile to the page that contains an email.
1. Submit a contribution.
Current behaviour
----------------------------------------
![Selection_1638](/uploads/e0bfd95675953dadba161aa20e658a99/Selection_1638.png)
Expected behaviour
----------------------------------------
![Selection_1637](/uploads/9c06ec7dc2f1537c860e904ba02f76d4/Selection_1637.png)
Comments
----------------------------------------
When an email field is present in a profile, we correctly hide the email field from the main contribution page. This extends that behavior to the confirmation and thank-you.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3539When communcating with external network services, detect transient failures a...2024-02-12T13:57:20ZmfbWhen communcating with external network services, detect transient failures and queue for retryFor improved resiliency, CiviCRM should detect transient failures when communicating with external network services and queue for retry. e.g.
* Transactional email: Queue for sending rather than sending during the request process?
* Bul...For improved resiliency, CiviCRM should detect transient failures when communicating with external network services and queue for retry. e.g.
* Transactional email: Queue for sending rather than sending during the request process?
* Bulk mail: Catch transient failures and ensure that they are retried. PRs: https://github.com/civicrm/civicrm-core/pull/11838 https://github.com/civicrm/civicrm-core/pull/11840 (and there are additional failure scenarios possible)
* ...https://lab.civicrm.org/dev/core/-/issues/3302Add accessible fieldset for checkboxes and radio buttons2023-11-28T12:49:35ZMonish DebAdd accessible fieldset for checkboxes and radio buttonsAs per https://www.w3.org/WAI/tutorials/forms/grouping , grouped form controls like radio buttons/checkboxes must be enclosed in ```<fieldset>``` and the ```<legend>``` element act as a header to identify the group of elements. Currently...As per https://www.w3.org/WAI/tutorials/forms/grouping , grouped form controls like radio buttons/checkboxes must be enclosed in ```<fieldset>``` and the ```<legend>``` element act as a header to identify the group of elements. Currently, when we review such block with WAVE accessibility tool, it complains about:
![Screen_Shot_2018-06-01_at_6.53.18_PM](/uploads/0782446dde4a776d6ec4a8f5c51edf47/Screen_Shot_2018-06-01_at_6.53.18_PM.png)
## Proposal
1. Enclose the checkbox/radio button block in a fieldset
2. Add a special class to that fieldset say `crm-sr-fieldset` which hides it in front-end forms (public and backoffice forms)
3. Use label of checkbox/radio buttons as its legend header.
Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3301Contrast ratios2024-02-28T11:51:33ZJoeMurrayContrast ratiosWCAG 2.0 specifies various minimum contrast ratios between foreground and background for different sizes of fonts, and for bolded and non-bolded fonts [https://www.w3.org/TR/WCAG20-TECHS/G18.html](https://www.w3.org/TR/WCAG20-TECHS/G18.h...WCAG 2.0 specifies various minimum contrast ratios between foreground and background for different sizes of fonts, and for bolded and non-bolded fonts [https://www.w3.org/TR/WCAG20-TECHS/G18.html](https://www.w3.org/TR/WCAG20-TECHS/G18.html).
> ...Priority 2 (AA), and Priority 3 (AAA). Whether or not you need to reach an AAA conformance depends on your target audience. Read more about this [on the w3 site](http://www.w3.org/TR/2005/WD-WCAG20-20051123/intro.html#conformance). For large text (over 18 points) the contrast ratio for AA is 3:1 and for AAA 5:1. For small text it's 5:1 for AA and 7:1 for AAA. ([http://www.colorsontheweb.com/Color-Tools/Color-Contrast-Analyzer](http://www.colorsontheweb.com/Color-Tools/Color-Contrast-Analyzer))
More exact ratios and translations of font sizes to px directly from the WCAG first mentioned for bold and non-bold text are:
* **BOLD and < 14pt (18.5px):** 7:1 contrast ratio
* Not bold and < 18pt (24px): 7:1 contrast ratio
*
* **BOLD and >= 14pt (18.5px):** 4.5:1 contrast ratio
* Not bold and >= 18pt (24px): 4.5:1 contrast ratio
Using the contrast analyzer provided on the page above, the current Shoreditch contrast ratios are not sufficient in some contexts.
For example, on pages like New Contact and New Activity we get the following ratios:
Blue font #2786c2 on tan #efefe5 in 13px: 3.44:1 (below 5:1)
Dimmed grey #999999 on offwhite #fff in 13px: 2.85:1 (below 5:1)
![2018-12-04_09-16-41](/uploads/efe32b9def1089f434b0cf1c11ef1b6e/2018-12-04_09-16-41.png)
![2018-12-04_09-33-52](/uploads/171119a46775a677bd44664497507def/2018-12-04_09-33-52.png)
![2018-12-04_09-51-12](/uploads/1a9006ebddb3d210f2b326d41d29f8cc/2018-12-04_09-51-12.png)
We should meet a 5:1 ratio for all text < 18pt.https://lab.civicrm.org/dev/core/-/issues/3295Make datepicker accessible2023-11-28T12:49:35ZMonish DebMake datepicker accessibleThe Civi datepicker field aren't accessible which means that other than cursor actions, you can select date from calendar using control keys.
This is about making datepicker accessible and here's a working example how it will look like ...The Civi datepicker field aren't accessible which means that other than cursor actions, you can select date from calendar using control keys.
This is about making datepicker accessible and here's a working example how it will look like after completing changes-
https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker
A user should be able to use datepicker with the help of control keys, not just cursor actions, and tasks involved are:
1. Tab to select date input field
2. On date field select calendar dialog, focus on current or default date.
3. Tab action switches to previous/next/month/year button
4. Show a close button on down right corner that has a tabstop.
5. Left/Right/Up/Down to change day/month/year.
6. Enter to selectMonish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3292Upgrade select2 to stable version 4.0.4 and fix compatibility issues in Civi2024-02-23T17:58:01ZMonish DebUpgrade select2 to stable version 4.0.4 and fix compatibility issues in CiviCurrently, Civi is using select2 3.5 which we need to upgrade to latest stable 4.0.4 (https://github.com/select2/select2/releases) and also resolve compatibility issues with CiviCRM.
Major issues:
1. Auto appending values doesn't work a...Currently, Civi is using select2 3.5 which we need to upgrade to latest stable 4.0.4 (https://github.com/select2/select2/releases) and also resolve compatibility issues with CiviCRM.
Major issues:
1. Auto appending values doesn't work anymore
Error: Uncaught TypeError: Cannot read property 'prop' of undefined
LOC - https://github.com/civicrm/civicrm-core/blob/master/js/crm.searchForm.js#L9
Reference - https://select2.org/upgrading/migrating-from-35#select2-val
2. Placeholder broken
Error: Uncaught TypeError: Cannot read property 'id' of undefined
As per 3.5 - placeholderOption is used to set the placeholder value for select2 widget
As per 4.0.4 - placeholder option can now accept placeholder value both in string and object
Reference - https://select2.org/upgrading/migrating-from-35#more-flexible-placeholders
3. EntityRef select2 fields are broken
Error: Uncaught Error: No select2/compat/initSelection
As per 4.0.4 - Removed the requirement of 'initSelection'
Reference - https://select2.org/upgrading/migrating-from-35#removed-the-requirement-of-initselection
4. Navigation menu style is not applied
Error: Uncaught TypeError: Cannot read property 'prop' of undefined
As per 4.0.4 - $("select").val("1").trigger("change"); // instead of $("select").select2("val", "1");
Reference - https://select2.org/upgrading/migrating-from-35#select2-val
5. Broken entityRef field
There are multiple issues with an entityRef field which are listed below:
1. Placeholder doesn't show
2. Unable to populate data via REST API link
3. Create contact dialog box doesn't render below the search field
4. Escape text doesn't show up
6. Action-menu select2 doesn't work on selecting record(s) in a search list
It throws an error `Uncaught TypeError: Cannot read property 'apply' of undefined` after Search and also action-menu field doesn't behave on selecting a record.
7. The native crm CSS styling doesn't apply on select2/4.0+ widget
Minor issues
1. Multi select2 widget doesn't show downarrow placeholder icon
2. select2 css style aren't applied after upgradehttps://lab.civicrm.org/dev/core/-/issues/2929Geocoding failures kill contributions2023-10-23T16:08:42ZandrewcormickdockeryGeocoding failures kill contributionsOverview
----------------------------------------
Last night between about 6pm and midnight AEDT, it appears that Nominatim (the Open Street Map API provider) had an intermittent outage. Some requests were receiving a 502 error. We hav...Overview
----------------------------------------
Last night between about 6pm and midnight AEDT, it appears that Nominatim (the Open Street Map API provider) had an intermittent outage. Some requests were receiving a 502 error. We have configured this as our Geocoding provider in CiviCRM under /civicrm/admin/setting/mapping?reset=1
People who were using CiviCRM in ways which caused the Geomapping provider to be called were receiving fatal errors as a result. This included people who were making donations (i.e. entering their address on the form which in turn was handed to the Geomapping provider for geocoding).
Current behaviour
----------------------------------------
When a request to the Geomapping provider fails (for example with a 502 error), the generating transaction within CiviCRM returns a fatal error and does not complete. This includes financial transactions, and indeed any administrative function that involves adding or updating a contact's address.
Expected behaviour
----------------------------------------
A Geomapping provider failure should never cause financial transactions to fail. I can't think of any reason why adding or updating an address should fail either. Fatal errors should only occur when an issue occurs which genuinely prevent a transaction from succeeding. A payment can still be processed regardless of whether that person's address can be geocoded or not. I expect a 502 Bad Gateway error from Nominatim would be logged, but never cause an address to fail to be added/updated. Obviously that would occur without the latitude/longitude being recorded. I can't even see the utility in informing the user. It's a system admin problem.
Environment information
----------------------------------------
* __CiviCRM:__ _5.35.2_
* __PHP:__ _7.3__
* __CMS:__ _Drupal 7.82_
* __Database:__ _MariaDB 10.4.21_
* __Web Server:__ _Nginx 1.10.3_
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/2290Look at REMOVING id column from cache tables2022-12-13T11:58:44ZjitendraLook at REMOVING id column from cache tablesThis is a continuation of the "In Progress" JIRA https://issues.civicrm.org/jira/browse/CRM-19385
which aimed at removing the id from the cache tables but unfortunately was never completed since I see we still have id column in all the ...This is a continuation of the "In Progress" JIRA https://issues.civicrm.org/jira/browse/CRM-19385
which aimed at removing the id from the cache tables but unfortunately was never completed since I see we still have id column in all the cache tables.
```
civicrm_acl_cache
civicrm_acl_contact_cache
civicrm_cache
civicrm_group_contact_cache
civicrm_prevnext_cache
civicrm_relationship_cache
```
Related PRs -
- https://github.com/civicrm/civicrm-core/pull/9743 (Closed)
- https://github.com/civicrm/civicrm-core/pull/9801 (Closed)
- https://github.com/civicrm/civicrm-core/pull/10019 (Merged) - This removed the dependency in the code so think we can start by removing the column directly.
Thoughts @eileen @johnkhttps://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/core/-/issues/1403Change "Contribution Received Date" to be "Contribution date" where is exists...2024-01-28T01:17:26ZJamie Novick - CompucoChange "Contribution Received Date" to be "Contribution date" where is exists and basically sort this Contribution dates mess out once and for allOk... sorry if this comes across as a bit of a rant but as a qualified accountant this has been driving me crazy for years and I think we've been skirting around this issue for sometime. I wanted to put in a gitlab to start a discussion ...Ok... sorry if this comes across as a bit of a rant but as a qualified accountant this has been driving me crazy for years and I think we've been skirting around this issue for sometime. I wanted to put in a gitlab to start a discussion to allow us to sort this out once and for all.
**Overview:**
----------------------------------------
CiviCRM has a core field on the contribution called "receive_date". This shows up on various screens and has led to significant debate about whether it should be a required field or not, and what it's real use case is. For example discussions below where debate has raged on how it should work:
https://lab.civicrm.org/dev/core/issues/1057
https://lab.civicrm.org/dev/core/issues/680
https://lab.civicrm.org/dev/core/issues/1140 - slightly different but related re: accruals accounting
https://lab.civicrm.org/dev/core/issues/1402
**The issue:**
----------------------------------------
So... there are a few problems with this field:
a) The idea of a "received date" is a bit meaningless (and confusing to users) when you have a pending contribution. You haven't quite received anything yet.
b) The idea of a "received date" conflicts with the payments dates if you have multiple payments (or could even be made to be different from the payment date) again which is nonsensical.
I assume contribution received date was a field that pre-dated the CiviCRM accounting implementation and hence perhaps hasn't kept up with the reality of the situation. In any case I believe this is causing some real issues now and should be sorted out.
Note the field is used:
1) As the date when initial accounting transactions are made. i.e. create a new pending contribution it will be the date of the Debit and Credits / transaction recorded in CiviCRM and hence by default it is the "revenue recognition date" for account purposes for the income.
This then leads to a multitude of other issues:
a) If I "complete" a pending membership contribution for a new membership by recording a payment, what should the start date of the membership be? (see: https://lab.civicrm.org/dev/core/issues/1402)
b) We've then introduced another field called "revenue_recognition_date", which should actually be field 1 above - as that is when we are recognising the transactions. We shouldn't have another field for this.
c) For some reason we now have a field on the invoice called "invoice date" which prints todays date which again is incorrect as it should be the same as item 1 above. The invoice should reflect the revenue recognition date. https://civicrm.stackexchange.com/questions/21128/how-do-i-print-the-received-date-on-an-invoice
**Proposed solution:**
----------------------------------------
The solution is relatively simple. We should change the "received_date" field to simply be the "Contribution date".
| Invoicing? | Contribution status | What the field means | Changes required to CiviCRM |
| ------ | ------ | ------ | ------ |
| Not using invoices | Pending | Represents the date the contribution was recorded on the system. | When later marking the contribution as completed give users the option to update the date or better still don't offer the option to complete a contribution and simply only allow users to enter the payment separately.
| Not using invoices | Completed | Represents the date the contribution was recorded on the system but also record a payment on the same date.
| Using invoices | Pending | Represents the date the invoice was recorded on the system and hence the invoice date and the revenue recognition date. | We should update the invoices to use this date as the invoice date. This field should not be updated when marking the invoice as complete (or better still don't offer the option to complete a contribution and simply only allow users to enter the payment separately.)
| Using invoices | Completed | Represents the date the invoice was recorded on the system but also the date the payment for that invoice was received. Ideally we would split the invoice and payment sections from each other on the "create new" form.
**Future:**
----------------------------------------
At some date in the future it would then be good to properly decouple payments from contributions and get rid of the terrible contribution status field once and for all.
Basically the contribution would reflect an order or invoice object, i.e. the obligation to pay for something. The payment transaction then would be separate and would represent the actual payment of that obligation. Accounting software has done this correctly for years so it's about time CiviCRM did too!
@mattwire @eileen @KarinG @dylan-circle @jaapjansma @JoeMurray @ErikHommel @fabian_SYSTOPIA and a few Compucorp names also - @omar_compucorp @Miya27
I'm sure you will all have opinions on this...https://lab.civicrm.org/dev/core/-/issues/1125Custom fieldsets participants added twice2023-02-15T15:13:29ZwdecraeneCustom fieldsets participants added twiceWhen editing a participant, some custom fieldsets are added twice to the participant edit form. When saving, only the data in the second fieldset is saved (so users think nothing happened when they added the data in the first instance of...When editing a participant, some custom fieldsets are added twice to the participant edit form. When saving, only the data in the second fieldset is saved (so users think nothing happened when they added the data in the first instance of the fieldset).
This only happens with fieldsets linked to a specific event type.
In templates/CRM/Event/Form/Participant.tpl:
```smarty
CRM.buildCustomData( '{$customDataType}', null, null );
{if $eventID}
CRM.buildCustomData( '{$customDataType}', {$eventID}, {$eventNameCustomDataTypeID} );
{/if}
{if $eventTypeID}
CRM.buildCustomData( '{$customDataType}', {$eventTypeID}, {$eventTypeCustomDataTypeID} );
{/if}
```
* First buildCustomData : adds all custom field sets, except those linked to a specific event id
* Second buildCustomData : adds all custom field sets linked to a event id
* Third buildCustomData : adds all custom field sets linked to a specific event type id
So the combination of the first and third one is the cause of fieldsets added twice.
Solution? Altering template, changing arguments, fixing getTree() in CRM/Core/BAO/CustomGroup.php, ... ?
See also
* https://issues.civicrm.org/jira/browse/CRM-10983
* https://issues.civicrm.org/jira/browse/CRM-20633https://lab.civicrm.org/dev/core/-/issues/1036Deprecate Tell a Friend2022-12-06T23:14:44ZAndie HuntDeprecate Tell a FriendWho tells their friends anymore? This really should be removed or deprecated.
@JonGold came up with this idea and @bgm thought it would be worth opening an issue for it.Who tells their friends anymore? This really should be removed or deprecated.
@JonGold came up with this idea and @bgm thought it would be worth opening an issue for it.