CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2020-01-15T11:43:46Zhttps://lab.civicrm.org/dev/core/-/issues/1456Major search limitations and inconsistency2020-01-15T11:43:46Zmagnolia61Major search limitations and inconsistencyOverview
----------------------------------------
I have been using CiviCRM for some 7 years nowm more as a implementer and casual small and simple pr creator.
Something we have run into since using CiviCRM is the inconsistency in using...Overview
----------------------------------------
I have been using CiviCRM for some 7 years nowm more as a implementer and casual small and simple pr creator.
Something we have run into since using CiviCRM is the inconsistency in using the search functions to create smart groups.
We have found workarounds but these are mostly resource expensive.
Example use-case
----------------------------------------
**Advanced Search (AS)**
+ intuitive interface
- Is not able to do advanced logic like '= NULL'
**Search Builder (SB)**
+ great overall flexibility
- Is not able to use relative date filters
Current behavior
----------------------------------------
For creating some of the smart groups we need, we now usually create 3 smartgroups.
1. smartgroup AS with participant info with relative date filter
2. smartgroup SB with some value = (NOT) NULL
3. An include/exclude search group to combine the two
This is very resource intensive but the only workaround we know of today
Proposed behavior
----------------------------------------
enable the following search logic Advanced Search:<br>- IS NULL / IS NOT NULL for select and date fields<br>
enable the following search logic for Search Builder:<br>- relative date filters for date fields
Comments
----------------------------------------
I will try to come up with some more comprehensive examples which I think will enhance both functionality and performance of CiviCRM.
Related issues, pr's and stackexchange topics:
----------------------------------------
Proposal to add is empty / is not empty to AS date field filters https://lab.civicrm.org/dev/core/issues/1211<br>
Api4 Search Builder Vision by Eileen: https://lab.civicrm.org/dev/core/issues/1106 https://lab.civicrm.org/dev/core/-/issues/1452Recurring contributions label on contribution pages is unstylable text, leadi...2021-05-03T11:44:27ZlarsssandergreenRecurring contributions label on contribution pages is unstylable text, leading to problems with themesOn a contribution page with recurring contributions enabled, the label for the recurring selection shows up as:
`<label for="is_recur">I want to contribute this amount</label>
every month
...On a contribution page with recurring contributions enabled, the label for the recurring selection shows up as:
`<label for="is_recur">I want to contribute this amount</label>
every month
`
(including some odd spacing around between the label and the word every). If you allow more than one option (e.g. weeks and months), only the word every is outside the label tags.
Because of this, any theme that changes the styling of the labels ends up looking very bad, as the words "every month" will be in a different font, size, etc. and there can also be some weird spacing. It seems like the fix would be to apply additional label tags around the words.
This is fixable on individual sites by applying styles to the divs that contain this label, but that's obviously not a great solution.
Confirmed on latest demo.5.38.0https://lab.civicrm.org/dev/core/-/issues/1446Find Activities search has no link to return to search results2023-01-16T05:03:34ZandyburnsFind Activities search has no link to return to search resultsIf you run Find Activities Search and click on the Name of the Contact, when you get to the Contact Summary Screen and do whatever it was you meant to do, there is no way to Return To the Search Results of the Find Activities Search, lik...If you run Find Activities Search and click on the Name of the Contact, when you get to the Contact Summary Screen and do whatever it was you meant to do, there is no way to Return To the Search Results of the Find Activities Search, like there is in Advanced Search. You have to rerun the Find Activities Search if you want to continue reviewing the selected records.
Find Activities Search:
![no_return_to_search_results](/uploads/7837e790055427f3db3b6b4a902697c0/no_return_to_search_results.PNG)
Advanced Search:
![search-results-link](/uploads/a6a308144f95216548f8e56e34d7b3d0/search-results-link.PNG)
There is also no `previous` or `next` paging when on the contact summary screen.https://lab.civicrm.org/dev/core/-/issues/1442Use "Active Membership" to describe a "current member" to avoid confusion wi...2022-10-25T21:30:07Zjustinfreeman (Agileware)Use "Active Membership" to describe a "current member" to avoid confusion with the "current" membership statusOverview
----------------------------------------
Use "**Active Membership**" to describe a "current member" to avoid confusion with the "current" membership status. Using the same word for two different meanings is confusing to users a...Overview
----------------------------------------
Use "**Active Membership**" to describe a "current member" to avoid confusion with the "current" membership status. Using the same word for two different meanings is confusing to users and problematic on the screens as the purpose is not explicit.
As being discussed here, https://civicrm.stackexchange.com/questions/33946/search-find-memberships-difference-between-membership-status-current-and-curr/33948
Example use-case
----------------------------------------
1. User wants to find all contacts with membership.
2. Goes to the Find Memberships screen.
3. Unable to decide if they select "membership status = current" or "Current Member? Yes"
4. User selects both options and is shown an **incorrect** list of contacts.
5. The selection has excluded "New" and "Grace" statuses.
Having "**Active Membership**" is a clearer choice in this case.
Current behaviour
----------------------------------------
Same terminology is being used to refer to the membership status and a grouping of multiple membership statuses.
Proposed behaviour
----------------------------------------
Use "**Active Membership**" to describe a "current member" to avoid confusion with the "current" membership status
Screenshots of current situation
----------------------------------------
![chrome_XmRm57E4cR](/uploads/ae20f559b5f222e87a6148b4a3936b76/chrome_XmRm57E4cR.png)
![chrome_8XPF55uH7x](/uploads/dafd5cbb0fa31067cd2b1e6d18ddc82f/chrome_8XPF55uH7x.png)
![chrome_6ieI5PVZOZ](/uploads/8222442650219bedebfeb0ca6eb39f4c/chrome_6ieI5PVZOZ.png)
Agileware Ref: CIVICRM-1388https://lab.civicrm.org/dev/core/-/issues/1439No way to identify 'deceased' contacts when viewing or reporting on relations...2023-01-15T05:03:21Zellen_compucorpNo way to identify 'deceased' contacts when viewing or reporting on relationshipsOverview
----------------------------------------
Marking a contact record as 'is_deceased' doesn't currently appear to have any impact on the contact's relationships, which makes sense overall (for example, if a contact was marked as de...Overview
----------------------------------------
Marking a contact record as 'is_deceased' doesn't currently appear to have any impact on the contact's relationships, which makes sense overall (for example, if a contact was marked as deceased and then a scheduled job were to automatically expire all it's relationships, it would be very manual and annoying to reverse that if 'is_deceased' had been added by accident. However, it would be extremely useful (a) when viewing relationships on contact records and (b) when reporting on relationships, to know whether one of the contacts involved in the relationship is deceased.
Example use-case
----------------------------------------
On a contact record:
1. Create a contact (contact A)
1. Add a relationship to another contact (contact B)
1. Mark contact A as deceased
1. View relationships tab on contact record for contact B
Within reports:
1. Go to create new relationships report (/civicrm/report/instance/5?reset=1&output=criteria)
1. View columns/ filters tabs; no configurations available relating to 'is_deceased'
Current behaviour
----------------------------------------
On a contact record:
- No change to relationship (or relationship display) when one of the contacts is marked as deceased
Within reports:
- As described above
Proposed behaviour
----------------------------------------
On a contact record:
- Propose that - on the relationships tab of the contact record - after the name of the contact that is deceased is added in red "(deceased)" in the same way that it is added next to the main display name at the top of the contact record for a deceased contact currently.
![3DC980F2-DC13-440B-A9D3-6875552B2006](/uploads/fb62f7fa05eeaa9002a9298cff5813d5/3DC980F2-DC13-440B-A9D3-6875552B2006.png)
On reports:
- Propose that a filter is added so that 'deceased' contacts can be excluded from relationships reports
Comments
----------------------------------------https://lab.civicrm.org/dev/core/-/issues/1438when importing contributions, can't match contact on phone number2020-02-17T15:27:10Zjamiewhen importing contributions, can't match contact on phone numberOverview
----------------------------------------
When importing contributions, you can't match an existing contact using a phone number, even when the default unsupervised rule specified the phone field. It is because the dedupe rule ca...Overview
----------------------------------------
When importing contributions, you can't match an existing contact using a phone number, even when the default unsupervised rule specified the phone field. It is because the dedupe rule calls the phone field "phone_numeric" yet the contact list of importable fields lists the field as "phone" - so no match is every made.
Reproduction steps
----------------------------------------
1. Click on **Contacts -> Find and Merge Duplicate Contacts**.
1. Click **Add rule for Individuals**.
1. Rule Name: Phone, Used: Unsupervised, Select field Phone and enter weight: 1, Threshhold: 1 and **Save**
1. Click **Contributions -> Import Contributions**
1. Upload any CSV file, choose defaults
1. Click Next
1. See that Phone is not listed in fields to import
Current behaviour
----------------------------------------
When the field mapper screen appears and you have an supervised dedupe rule with a phone field, you get a missing index error, a phantom "match to contact" option in the field list, and the phone field is not listed.
![phone-import-error](/uploads/26b39da7bed124937c3666d4fb275a03/phone-import-error.png)
Expected behaviour
----------------------------------------
The phone field should be listed (with "match to contact").
Environment information
----------------------------------------5.24.0https://lab.civicrm.org/dev/core/-/issues/1433CRM_Case_XMLProcessor::allActivityTypes() doesn't do caching right2020-06-16T11:13:35ZDaveDCRM_Case_XMLProcessor::allActivityTypes() doesn't do caching rightThis isn't recent. The function looks like this:
```php
public static function &allActivityTypes($indexName = TRUE, $all = FALSE) {
if (self::$activityTypes === NULL) {
self::$activityTypes = CRM_Case_PseudoConstant::caseActiv...This isn't recent. The function looks like this:
```php
public static function &allActivityTypes($indexName = TRUE, $all = FALSE) {
if (self::$activityTypes === NULL) {
self::$activityTypes = CRM_Case_PseudoConstant::caseActivityType($indexName, $all);
}
return self::$activityTypes;
}
```
So it works fine the first time in any given page run, but then if you call it again with different parameters it just returns the thing it cached last time regardless of the parameters. It isn't used very often and so I guess it doesn't come up in a typical page run, but it was driving me a bit nuts while trying to write a unit test and not getting what I was expecting.
PR coming, just debating whether it's worth trying to eliminate completely since it isn't used in that many places, i.e. deprecate it and replace everywhere it's used in core with CRM_Case_PseudoConstant::caseActivityType which does its own caching anyway.5.28.0https://lab.civicrm.org/dev/core/-/issues/1431Feature: Ability to filter relationship tab by relationship type in a very si...2023-01-12T05:03:21ZlolcodeFeature: Ability to filter relationship tab by relationship type in a very similar way to the activity tabOverview
----------------------------------------
It would be great to have the ability to filter relationship tab by relationship tab in a very similar way to the activity tab.
Example use-case
----------------------------------------
...Overview
----------------------------------------
It would be great to have the ability to filter relationship tab by relationship tab in a very similar way to the activity tab.
Example use-case
----------------------------------------
1. View a contact with hundreds or thousands of relationships
2. Some staff are only concerned with one or two relationship types that have low quantities.
Current behaviour
----------------------------------------
The staff have to page through all relationships or sort by relationship type and then guess a page number if the type sorts into the middle.
Proposed behaviour
----------------------------------------
A filter with relationship types, start_date and end_date is available in a similar way as it is for the activity tab. The `CRM_Contact_BAO_Relationship::getContactRelationshipSelector` function would ideally have a relationshipTypeIds filter or something similar.https://lab.civicrm.org/dev/core/-/issues/1424Export doesn't work in Excel with diacritic chars2020-07-12T03:19:04ZeileenExport doesn't work in Excel with diacritic charsPROPOSAL - prepend the BOM for UTF8 "\xEF\xBB\xBF" so csv's exported from excel
Discussion (note this is the same writeup on the PR - creating a gitlab too as I suspect there might be discussion).
There is a long-standing issue ...PROPOSAL - prepend the BOM for UTF8 "\xEF\xBB\xBF" so csv's exported from excel
Discussion (note this is the same writeup on the PR - creating a gitlab too as I suspect there might be discussion).
There is a long-standing issue whereby files exported from CiviCRM with diacritic characters - eg.
ę are mangled when opened in MS Excel.
The underlying issue is that the characters are UTF-8 encoded & MS Excel by default does not assume UTF8.
In order to do so it needs a BOM - Byte Order Marker - which is a few hex characters at the start of
the csv.
The BOM indicator is 'not recommended' .... unless you want your csv to work with
MS Excel. Since MS Excel is a major use case for csvs I think it's pretty clear that all
things being equal we want to support it... I note that there are extensions to export to excel
natively but I don't think that replaces this. The number one reason to want to export
a csv is to work with it in a spreadsheeting programme & unless we can't safely make it
work in core we shouldn't require an extension for that.
There are various recommendations over time but it seems things have improved in the MS
Excel world and what works on Windows now appears to work on Mac too - at least on a recent version.
This link https://donatstudios.com/CSV-An-Encoding-Nightmare is a pretty good discussion.
While the above link and others say that you need a different BOM for MAC than Windows my
testing shows that the one recommended for Windows works fine on Mac Excel (while you would need
to convert to UTF 16 to follow the Mac recommendation. (https://csv.thephpleague.com/9.0/interoperability/encoding/)
Other links
https://stackoverflow.com/questions/35294443/does-excel-for-mac-2016-properly-import-unicode-in-csv-files
https://stackoverflow.com/questions/2223882/whats-the-difference-between-utf-8-and-utf-8-without-bom/2223926#2223926
Notably this summary :
" When should you encode with a BOM?
If you're unable to record the metadata in any other way (through a charset tag or file system meta), and the programs being used like BOMs, you should encode with a BOM. This is especially true on Windows where anything without a BOM is generally assumed to be using a legacy code page. The BOM tells programs like Office that, yes, the text in this file is Unicode; here's the encoding used.
When it comes down to it, the only files I ever really have problems with are CSV. Depending on the program, it either must, or must not have a BOM. For example, if you're using Excel 2007+ on Windows, it must be encoded with a BOM if you want to open it smoothly and not have to resort to importing the data."
So the argument for a BOM is - if you want it to be compatible with MS Excel use a BOM. This seems to apply.
The risk is that perhaps there is some variant of csv viewing programme that can't cope - the risk of this is rather mitigited by
1) the fact that MS Excel adds the BOM to the start of any files it saves as UTF-8 encoded csv so any programme that expects to open MS Excel generated
csvs would need to be able to cope with it. In addition it is a standard, if not required, file indicator so it feels like the programmes
that were legacy in 2016 writeups might be of no concern now.
2) There really is no programatic way to export these csvs so the risk that this is being parsed by code is close to zero
There are 2 other things we could do to mitigate
1) test on more platforms - I've tested with MS Excel for Mac (Office 365 v 16.31) and Libre Office and MS Numbers
& MS word, cot editor & notes
2) We could add a setting. I'm generally a bit loath on settings as they are a bit of a maintenance nightmare.
However, perhaps it would be a setting like 'export csvs in legacy format & there could be a link
to the gitlab to explain your use-case if you feel the need to set it. If no-one does then we could later remove.
Final note - csv tables are created with the CRM_Core_Report_Excel (spot the irony) from 3 places
- the main export, the export for custom fields & a third place which I believe to be unreachable. This is one path
only but I can look at centralising for the custom fields export path.5.22.0https://lab.civicrm.org/dev/core/-/issues/1423civicrm_contribution_recur.is_email_receipt is ignored2020-01-15T17:02:54ZRichcivicrm_contribution_recur.is_email_receipt is ignoredOverview
----------------------------------------
The recur table has a `is_email_receipt` column. To me this means that this is a per-recurring-contrib preference, but this does not appear to be honoured.
Reproduction steps
---------...Overview
----------------------------------------
The recur table has a `is_email_receipt` column. To me this means that this is a per-recurring-contrib preference, but this does not appear to be honoured.
Reproduction steps
----------------------------------------
(I've written a test in a PR to follow.)
1. Create a contribution recur record with `is_email_receipt = 1`
1. add a completed contrib
1. expect an email, don't get one.
Expected behaviour
----------------------------------------
I think the behaviour *should* be:
1. was `is_email_receipt` passed in to the API call? If so, use that.
*if not*...
2. is the contrib part of a recurring contribution, and is the recur record's `is_email_receipt` set (to 0 or 1)? If so, use that.
*if not*...
3. is the contrib linked to a contribution page? If so, use the contribution page's setting.
*if not*...
4. send one by default
Environment information
----------------------------------------
* __CiviCRM:__ _Master @ 38891c5df7
[possibly linked issue](https://lab.civicrm.org/dev/core/issues/1245)https://lab.civicrm.org/dev/core/-/issues/1417Default view on Constituent details wastes space with unneeded headers2023-01-11T05:03:27ZCoreyBurgerDefault view on Constituent details wastes space with unneeded headersThe default Constituent Detail report wastes huge amounts of space on pages, while the Constitient Summary report, which is nicely organized, lacks key details like membership.
My use case is as follows: I want to print off the high lev...The default Constituent Detail report wastes huge amounts of space on pages, while the Constitient Summary report, which is nicely organized, lacks key details like membership.
My use case is as follows: I want to print off the high level details for a committee meeting. My contacts are organized into a group. What I want to be able to view for that meeting is the following: Name, Email, Address and Membership Status.
There are three reports I could use for this:
1. Constituent Summary - no membership
2. Constituent Details - wasted space
3. Membership Summary - misses all non-members
The simplest solution to this problem is to edit the Constituient Details template to remove unneeded headers. I'm happy to help make this change, but I honestly have no idea where in the code I would find the needed templates to edithttps://lab.civicrm.org/dev/core/-/issues/1416Export to PDF with useful filename2023-11-22T05:03:22ZCoreyBurgerExport to PDF with useful filenameIf you export a report to PDF, the file name is "CiviReport.PDF". That is a major headache if you are exporting multiple reports. Ideally, the report should be exported with some kind of useful title, likely a shortening of the report titleIf you export a report to PDF, the file name is "CiviReport.PDF". That is a major headache if you are exporting multiple reports. Ideally, the report should be exported with some kind of useful title, likely a shortening of the report titlehttps://lab.civicrm.org/dev/core/-/issues/1415No easy way to see campaign activities2023-01-10T05:03:25ZCoreyBurgerNo easy way to see campaign activitiesOn the campaign dashboard, there is no way to see data related to that campaign. Ideally, there should be a View Activities link that is a search that lists all activities associated with that campaign.
As a secondary goal, this should...On the campaign dashboard, there is no way to see data related to that campaign. Ideally, there should be a View Activities link that is a search that lists all activities associated with that campaign.
As a secondary goal, this should be expanded to be a "dashboard" showing goals: revenue, membership, etc. along with a list of latest activities below that.https://lab.civicrm.org/dev/core/-/issues/1413Search the contacts modified in a period of time by a user2023-01-09T05:03:22ZdmunioSearch the contacts modified in a period of time by a userOverview
----------------------------------------
Possibility to search the contacts added or modified in a period of time by a particular user.
Example use-case
----------------------------------------
1. Click on **Search -> Advanced ...Overview
----------------------------------------
Possibility to search the contacts added or modified in a period of time by a particular user.
Example use-case
----------------------------------------
1. Click on **Search -> Advanced Search**.
2. In set **Change log**, enter time period and sort name of the user who added or modified the contacts sought.
3. Click on **Search button**.
Current behaviour
----------------------------------------
Currently it is only possible to search for contacts added or modified in a certain period. And separately, you can filter the contacts added and modified by a specific user. In the current version of civicrm (5.20) a note is displayed that clarifies this functionality in the **Modified By** field: **Note this field just filters on who made a change no matter when that change happened, It doesn't have any link to the modified date field.**
Proposed behaviour
----------------------------------------
Having the possibility to search for contacts added or modified in a period of time and by a specific user, constitutes a fundamental functionality in the monitoring of change logs.
For this improvement we have made the following pull request: https://github.com/civicrm/civicrm-core/pull/15913
Comments
----------------------------------------https://lab.civicrm.org/dev/core/-/issues/1404Test assertions should include message describing the assertion2020-09-17T22:58:00ZFrancis (Agileware)Test assertions should include message describing the assertionWhile checking test failures for a PR, received the test error:
> Failed asserting that true is false.
On quick review of the refs in the phpunit tests directory, I found that almost none of the assertFalse calls in the test suite use ...While checking test failures for a PR, received the test error:
> Failed asserting that true is false.
On quick review of the refs in the phpunit tests directory, I found that almost none of the assertFalse calls in the test suite use the second argument to provide a descriptive message about the assertion. The assumption is then that the other assertion types are in the same situation.
The provides a less than stellar testing environment, as you have to check a source code reference to understand your test failure.
We should improve the tests so that they explain (summarise) the assertion that failed.https://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/1402Inconsistent behaviour when paying/completing a pending contribution with lin...2023-12-30T05:03:27ZJamie Novick - CompucoInconsistent behaviour when paying/completing a pending contribution with linked membershipOverview
----------------------------------------
CiviCRM has inconsistent behaviour when completing a pending contribution with linked pending membership either by a) completing the contribution or b) recording a payment.
This applie...Overview
----------------------------------------
CiviCRM has inconsistent behaviour when completing a pending contribution with linked pending membership either by a) completing the contribution or b) recording a payment.
This applies to both a "new/pending" membership or when renewing an expired membership.
Reproduction steps
----------------------------------------
Scenario 1: New membership
----------------------------------------
Create a membership with start date 1/1/2019 and term 1 year.
Set the membership status to anything.
Set the contribution status to pending.
Save
Scenario 1.1: Record payment
If you completed the payment using “Record Payment” and no matter what you set the receive date to during completing the payment the end date and the start date will remain the same (start date = 1/1/2019 , end date = 31/12/2019).
Scenario 1.2: “Edit Contribution -> change status to completed"
While completing the payment using “Edit Contribution -> change status to completed” will result in changing the membership start date to equal the contribution receive date and the end date to be 1 term away from the receive date, so if you set the receive date for example to 1/3/2019 then the start date will become 1/3/2019 and the end date 29/2/2020
Scenario 2. Renew membership that has expired (end date in the past)
----------------------------------------
Create a membership with start date 1/1/2018 and term 1 year.
Set the membership status to anything. It will be created as an expired membership.
Set the contribution status to completed.
Save
Scenario 2.1: Record payment
If you complete the renewal pending payment using “Record Payment” option, then no matter what you set the payment receive date to, the start date will change to “today's date” and the end date will be one 1 term after the start date
Scenario 2.2: “Edit Contribution -> change status to completed"
If you complete the payment with “edit contribution -> change status to completed” then also here Civi ignores the the receive date and it will always set the start date to “today's date” and the end date to 1 term after the start date.
Expected behaviour
----------------------------------------
Well, they should at least be consistent... but perhaps this is our opportunity to make CiviCRM less opaque and give users control over how the system should work?
| Scenario no | Situation | Recording payment approach | Current behaviour | Suggested behaviour |
| ------ | ------ | ------ | ------ | ------ |
|1.1| New | Record payment | Start date will remain as before | Message 1 below
|1.2| New | Edit Contribution -> change status to completed | Changes the membership start date to equal the contribution receive date | Message 1 below
|2.1| Renew expired | Record payment | The start date will change to “today's date” and the end date will be one 1 term after the start date | Message 2 below
|2.2| Renew expired | Edit Contribution -> change status to completed | Set the start date to “today's date” and the end date to 1 term after the start date. |Message 2 below
Message 1:
Show a message / popup to tell ask the user "The membership payment has been made in full, but the membership's start date is different to the payment date. Would you like to set the membership start date to the payment date?
1. Option 1: Yes - Set Membership Start Date to the payment date (**Show the proposed start date if using the payment date**) This would be the date of the last payment if recording the payment OR the contribution received date if completing the contribution by changing the status.
1. Option 2: No - Do not change the membership start date (**Show the existing start date**)
Message 2:
Show a message / popup to tell ask the user "The membership payment has been made in full. Please select a start date:
1. Option 1: Set Membership Start Date to the previous membership term end date
1. Option 2: Set Membership Start Date to the payment date (**Show the proposed start date if using the payment date**) This would be the date of the last payment if recording the payment OR the contribution received date if completing the contribution by changing the status.
1. Option 3: Create a new membership line with Membership start date on the payment date (**Show the proposed start date if using the payment date**) This would be the date of the last payment if recording the payment OR the contribution received date if completing the contribution by changing the status.
In future we could allow admin to have a setting to set the defaults and hide the message to define the behaviour.
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:__ _Master/5.21 etc
Comments
----------------------------------------
This isn't the place for the long discussion about it but just to reiterate that I think the contribution "received" date field needs the label changed to be something more generic like "contribution date" as the field is used as the invoice date when generating an invoice (and cannot mean received date when the contribution is pending...). It also leads to inconsistencies with the above - the date of the last payment could be different from the contribution received date which is a meaningless statement. We should decouple "payment" from the order or invoice object (the contribution) and make the payments mean what they mean - when we got the payment - and the order/invoice mean what is means - when the contact entered into the obligation to pay from an accounting perspective.
Oh well seems I started a discussion on that here: https://lab.civicrm.org/dev/core/issues/1403#note_27422 and a decision on how the above should work should be done once the contribution date field usage is confirmed.https://lab.civicrm.org/dev/core/-/issues/1398Option to open navigation item in new window (if present)2019-11-26T20:25:31ZMonish DebOption to open navigation item in new window (if present)Currently, the ```target``` attribute of submenus are ignored whereas the menu item adds this property in the anchor links [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/Navigation.php#L443)Currently, the ```target``` attribute of submenus are ignored whereas the menu item adds this property in the anchor links [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/Navigation.php#L443)5.21.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/1392Auto-fix missing system message templates2023-01-08T05:03:30ZbgmAuto-fix missing system message templatesDuring [PR#15844](https://github.com/civicrm/civicrm-core/pull/15844), we discussed that the upgrader can fail when there are missing message templates in the database. Their absence can go unnoticed when their related features are not u...During [PR#15844](https://github.com/civicrm/civicrm-core/pull/15844), we discussed that the upgrader can fail when there are missing message templates in the database. Their absence can go unnoticed when their related features are not used.
Since the upgrader can detect missing templates, it could also automatically re-create them.
Do we have all the required metadata in order to re-create them automatically?https://lab.civicrm.org/dev/core/-/issues/1388civicrm_group is missing important indexes on cache fields2023-01-10T05:03:25Zeileencivicrm_group is missing important indexes on cache fieldsWe had a recent server degradation where queries ran a lot slower and I spotted a non-indexed query that the small table size would normally cause to fly under the radar - basically we need to add these indexes:
```
$tables = ['civicr...We had a recent server degradation where queries ran a lot slower and I spotted a non-indexed query that the small table size would normally cause to fly under the radar - basically we need to add these indexes:
```
$tables = ['civicrm_group' => ['cache_date', 'refresh_date']];
CRM_Core_BAO_SchemaHandler::createIndexes($tables);
```
Note I'm just logging, rather than doing a PR, at this stage as I'm pretty snowed under.
@seamuslee @mattwire FYI - you might get benefit from indexing this