CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2019-02-24T19:02:48Zhttps://lab.civicrm.org/dev/core/-/issues/190custom data with multiple records profile: after submission, profile view sho...2019-02-24T19:02:48Zlcdwebcustom data with multiple records profile: after submission, profile view shows first record instead of most recentTo reproduce:
* create a custom data set with multiple records enabled. create a field or two.
* create a profile that includes the fields and the email field (to enable duplicate matching). make sure "update contact" is selected in the...To reproduce:
* create a custom data set with multiple records enabled. create a field or two.
* create a profile that includes the fields and the email field (to enable duplicate matching). make sure "update contact" is selected in the advanced setting.
* open the profile in create view
* submit the form with values
* go back and submit the form a second time with different values
* notice that after submitting the second time, the profile view displays values from the first time you submitted the form, not the most recent5.12.0lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/397Dedupe for Individual Birth Date Results in Error2019-02-13T20:28:31ZjasonobrownDedupe for Individual Birth Date Results in Error```
civicrm: $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[code] => -1
[message] => DB Error: unknown error
[mode] => 16
[debug_in...```
civicrm: $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[code] => -1
[message] => DB Error: unknown error
[mode] => 16
[debug_info] => INSERT INTO dedupe (id1, id2, weight) SELECT t1.id id1, t2.id id2, 5 weight FROM civicrm_contact t1 JOIN civicrm_contact t2 USING (birth_date) JOIN dedupe_copy ON dedupe_copy.id1 = t1.id AND dedupe_copy.id2 = t2.id WHERE t1.contact_type = 'Individual' AND t2.contact_type = 'Individual' AND t1.id < t2.id AND t1.birth_date IS NOT NULL AND t1.birth_date <> '' GROUP BY id1, id2, weight ON DUPLICATE KEY UPDATE weight = weight + VALUES(weight) [nativecode=1292 ** Incorrect date value: '' for column 'birth_date' at row 1]
[type] => DB_Error
[user_info] => INSERT INTO dedupe (id1, id2, weight) SELECT t1.id id1, t2.id id2, 5 weight FROM civicrm_contact t1 JOIN civicrm_contact t2 USING (birth_date) JOIN dedupe_copy ON dedupe_copy.id1 = t1.id AND dedupe_copy.id2 = t2.id WHERE t1.contact_type = 'Individual' AND t2.contact_type = 'Individual' AND t1.id < t2.id AND t1.birth_date IS NOT NULL AND t1.birth_date <> '' GROUP BY id1, id2, weight ON DUPLICATE KEY UPDATE weight = weight + VALUES(weight) [nativecode=1292 ** Incorrect date value: '' for column 'birth_date' at row 1]
[to_string] => [db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::handle prefix="" info="INSERT INTO dedupe (id1, id2, weight) SELECT t1.id id1, t2.id id2, 5 weight FROM civicrm_contact t1 JOIN civicrm_contact t2 USING (birth_date) JOIN dedupe_copy ON dedupe_copy.id1 = t1.id AND dedupe_copy.id2 = t2.id WHERE t1.contact_type = 'Individual' AND t2.contact_type = 'Individual' AND t1.id < t2.id AND t1.birth_date IS NOT NULL AND t1.birth_date <> '' GROUP BY id1, id2, weight ON DUPLICATE KEY UPDATE weight = weight + VALUES(weight) [nativecode=1292 ** Incorrect date value: '' for column 'birth_date' at row 1]"]
)
```5.12.0https://lab.civicrm.org/dev/core/-/issues/449Bug: log_civicrm_group table grows insanely quickly2019-11-04T04:08:32ZAgilewareBug: log_civicrm_group table grows insanely quicklyBest demonstrated by example:
```
select count(id) `entries`, count(distinct id) `ids`, min(log_date) `since`, now() `now` from log_civicrm_group;
```
| entries | ids | since | now |
|---------|-----|-----...Best demonstrated by example:
```
select count(id) `entries`, count(distinct id) `ids`, min(log_date) `since`, now() `now` from log_civicrm_group;
```
| entries | ids | since | now |
|---------|-----|---------------------|---------------------|
| 31813 | 223 | 2018-10-16 14:14:51 | 2018-10-17 11:03:18 |
This is for a < 22hr period after I cleared this table to try and solve a data migration issue; before, this particular log table had grown to nearly 7 gigabytes (for the same 223 distinct group ids).
What appears to be happening is that every time the group_rebuild job is called, the cache_date is being NULLed and filled back in, creating two additional pointless log entries.
Per group id, I counted up to 250 log entries where only these fields had changed.
I think it should be possible to fix this by one of:
1. Disabling logging the the group_rebuild API call runs; or
2. excluding changes to just the cache_date and refresh_date fields from the civicrm_group triggers
Agileware ref CIVICRM-10015.12.0https://lab.civicrm.org/dev/core/-/issues/469Error on action "Email - schedule/send via CiviMail" with multiple event name...2019-08-29T08:33:46ZfrancescbassasError on action "Email - schedule/send via CiviMail" with multiple event names filterOriginal issue: https://issues.civicrm.org/jira/browse/CRM-21767
Affected versions: at least from 4.7.31
---
**Steps to reproduce**
1. Go to **Search > Advanced Search**
2. Select two events on **Event Name** field and click to **Sea...Original issue: https://issues.civicrm.org/jira/browse/CRM-21767
Affected versions: at least from 4.7.31
---
**Steps to reproduce**
1. Go to **Search > Advanced Search**
2. Select two events on **Event Name** field and click to **Search** button
3. Select **All records** and click **Actions** button
4. Click on **Email - schedule/send via CiviMail**
5. An error screen appears with a message like
`3,2 is not of the type Int`5.12.0https://lab.civicrm.org/dev/core/-/issues/475Cannot set custom field values to string 'NULL'2019-02-24T20:13:36ZjackrabbithannaCannot set custom field values to string 'NULL'Let's have a non-null conversation about saving string 'NULL' values.
While upgrading a site from 4.6 to 5.6 we noticed that one of the custom fields (select widget) which has an option value of the string 'NULL' was not being updated ...Let's have a non-null conversation about saving string 'NULL' values.
While upgrading a site from 4.6 to 5.6 we noticed that one of the custom fields (select widget) which has an option value of the string 'NULL' was not being updated on save.
Traced it down to:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/CustomValueTable.php#L222
This behavior came into the system back in 4.7-alpha1
https://github.com/civicrm/civicrm-core/commit/fd630ef95ece7c8f8005ddaf0e0e8cc391c1be43
Turns out any alphanumeric field type widget won't allow the string value of 'NULL' to be saved..it is converted to the really non-string NULL value.
Turns out it's an easy fix for us to just exclude this behavior by:
```
if (strtolower($value) === "null" && $value != "NULL") {
// when unsetting a value to null, we don't need to validate the type
// https://projectllr.atlassian.net/browse/VGQBMP-20
$set[$field['column_name']] = $value;
}
```
But I wonder, why is it that strings are converted to real NULLs?
Is this a bug or a feature?
What are the potential consequences of this patch?
Are there good reasons to convert strings to NULL ?
Would this patch break other expected behavior in Civi?
What about strings like 'Null' or 'nulL' etc...5.12.0https://lab.civicrm.org/dev/core/-/issues/580No groups displayed on Manage Groups when "All Groups" is selected2019-02-16T22:53:26ZJonGoldNo groups displayed on Manage Groups when "All Groups" is selectedGiven a user who:
* Doesn't have "View All Contacts" permission;
* DOES have an ACL that gives permission to Edit "All Groups";
The "Manage Groups" screen shows no groups. However, a `Group.get` API call works correctly.
This is becau...Given a user who:
* Doesn't have "View All Contacts" permission;
* DOES have an ACL that gives permission to Edit "All Groups";
The "Manage Groups" screen shows no groups. However, a `Group.get` API call works correctly.
This is because `CRM_ACL_BAO_ACL::group()` expects an argument `$allGroups` to be passed, with an array of all the groups for this particular context. The API code path populates this argument; the UI code path doesn't. Here are call stacks for each. I've marked where they converge with `**`:
### UI call stack
```
CRM/ACL/BAO/ACL.php.CRM_ACL_BAO_ACL::group:895
** CRM/ACL/API.php.CRM_ACL_API::group:179
CRM/Contact/BAO/Group.php.CRM_Contact_BAO_Group::getPermissionClause:603
CRM/Contact/BAO/Group.php.CRM_Contact_BAO_Group::whereClause:1249
CRM/Contact/BAO/Group.php.CRM_Contact_BAO_Group::getGroupList:826
CRM/Contact/BAO/Group.php.CRM_Contact_BAO_Group::getGroupListSelector:747
CRM/Group/Page/AJAX.php.CRM_Group_Page_AJAX::getGroupList:67
CRM/Core/Invoke.php.CRM_Core_Invoke::runItem:275
CRM/Core/Invoke.php.CRM_Core_Invoke::_invoke:84
CRM/Core/Invoke.php.CRM_Core_Invoke::invoke:52
drupal/civicrm.module.civicrm_invoke:445
/home/jon/local/groundswell/htdocs/includes/menu.inc.menu_execute_active_handler:527
/home/jon/local/groundswell/htdocs/index.php.{main}:21:
```
### API code path
```
CRM/ACL/BAO/ACL.php.CRM_ACL_BAO_ACL::group:895
** CRM/ACL/API.php.CRM_ACL_API::group:179
CRM/ACL/API.php.CRM_ACL_API::groupPermission:215
CRM/Contact/BAO/Group.php.CRM_Contact_BAO_Group::checkPermission:312
api/v3/Group.php.civicrm_api3_group_get:82
Civi/API/Provider/MagicFunctionProvider.php.Civi\API\Provider\MagicFunctionProvider->invoke:89
Civi/API/Kernel.php.Civi\API\Kernel->runRequest:169
Civi/API/Kernel.php.Civi\API\Kernel->runSafe:100
api/api.php.civicrm_api:23
CRM/Utils/REST.php.CRM_Utils_REST::process:311
CRM/Utils/REST.php.CRM_Utils_REST::ajax:548
CRM/Core/Invoke.php.CRM_Core_Invoke::runItem:275
CRM/Core/Invoke.php.CRM_Core_Invoke::_invoke:84
CRM/Core/Invoke.php.CRM_Core_Invoke::invoke:52
drupal/civicrm.module.civicrm_invoke:445
/home/jon/local/groundswell/htdocs/includes/menu.inc.menu_execute_active_handler:527
/home/jon/local/groundswell/htdocs/index.php.{main}:21
```
I have a PR to submit, but I'm not sure if my fix is at the correct layer of the call stack.5.12.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/639Note: No restriction of the Subject field length2019-03-01T00:19:08ZPradeep Nayakpradpnayak@gmail.comNote: No restriction of the Subject field length**STR:**
* Navigate to Search→Find Contacts
* Find any Individual/Organisation
* On the Search results page, click vertical ellipsis and select "Add Note"
* Fill in the Subject field with more than 255 chars
* Fill in the Body fields wi...**STR:**
* Navigate to Search→Find Contacts
* Find any Individual/Organisation
* On the Search results page, click vertical ellipsis and select "Add Note"
* Fill in the Subject field with more than 255 chars
* Fill in the Body fields with some text
* Click Save
* Navigate to the created Note
* Check the number of the characters in the Subject field
**Result:** the number of saved characters in the created Note is 255
**Expected result:** during Note creation, there should be a restriction to the field length (255 char max)
PR:https://github.com/civicrm/civicrm-core/pull/134035.12.0https://lab.civicrm.org/dev/core/-/issues/659Civi returning 500 errors to Paypal Pro request to civicrm/extern/ipn.php2020-11-15T14:55:09ZStoobCivi returning 500 errors to Paypal Pro request to civicrm/extern/ipn.phpCivi gathers all the information it needs from Paypal's request to ipn.php and DOES correctly update the status, fee_amount, etc. from the array given to Civi by Paypal. Note: This is for **ONE TIME (single) transactions**, *not for rec...Civi gathers all the information it needs from Paypal's request to ipn.php and DOES correctly update the status, fee_amount, etc. from the array given to Civi by Paypal. Note: This is for **ONE TIME (single) transactions**, *not for recurring* transactions.
However despite this, Civi is returning a 500 error back to Paypal, who in turn tries and tries again, and eventually turns off IPN entirely.
The original report is here: https://civicrm.stackexchange.com/questions/26603/anyone-getting-ipn-warning-emails-from-paypal and I've discussed the issue with @xurizaemon and @eileen
CiviCRM.log does list the array received from Paypal which appears intact, but there is no mention of any error, per se, in CiviCRM.log. However in the server php error_log I find the attached error for the same transaction. Note there are several 500 because Paypal, after the initial perceived failure repeats the request several times in the subsequent minutes.
[error_paypal_pro_one-time_ipn.php.txt](/uploads/8a2ef25be9db5bed41c710c6ccaf3984/error_paypal_pro_one-time_ipn.php.txt)
Note that comparatively the 'new URL' for IPN works fine, and returns 200 code: civicrm/payment/ipn/15.12.0https://lab.civicrm.org/dev/core/-/issues/684Case Manager not updating correctly (CiviCRM 5.8.2)2019-02-13T22:47:09ZGMCVO DatabasesCase Manager not updating correctly (CiviCRM 5.8.2)1. Set up case http://dmaster.demo.civicrm.org/civicrm/a/#/caseType. eg edit Housing Support
2. Add role ('test role')
3. Check 'Is Manager'
4. Add a new case (Housing support)
5. View the case Roles tab - get 'Homeless Services Coordina...1. Set up case http://dmaster.demo.civicrm.org/civicrm/a/#/caseType. eg edit Housing Support
2. Add role ('test role')
3. Check 'Is Manager'
4. Add a new case (Housing support)
5. View the case Roles tab - get 'Homeless Services Coordinator is (Case Manager)'. Test role is (not assigned).![Screenshot_2019-01-25_15.06.21](/uploads/978244ddc896d51ea3d4ba220f7809fc/Screenshot_2019-01-25_15.06.21.png)
The function which isn't working properly is in: - CRM/Case/XMLProcessor/Process.php
Line 199 was checking whether $relationshipTypeXML->manager was set, as opposed to whether $relationshipTypeXML->manager == 1
Case manager isn't shown in Find Cases and Cases dashboard.5.12.0https://lab.civicrm.org/dev/core/-/issues/691It is no longer possible to have the default country not set2019-02-13T18:06:46ZhowardshandIt is no longer possible to have the default country not setReported this previously at https://issues.civicrm.org/jira/browse/CRM-18100, and it was fixed, though I can't find the ticket for the fix.
Did a new install of 5.7.3 and default country is required. All sandboxes show the same requirem...Reported this previously at https://issues.civicrm.org/jira/browse/CRM-18100, and it was fixed, though I can't find the ticket for the fix.
Did a new install of 5.7.3 and default country is required. All sandboxes show the same requirement.5.12.0https://lab.civicrm.org/dev/core/-/issues/696Changes to copied event phone and email reflects in original event phone and ...2019-02-19T07:07:11ZyashodhaChanges to copied event phone and email reflects in original event phone and emailSteps to replicate:
1. Create an event X with location A, including email A and phone A
2. Create copy of event X say Y and go to location tab for event Y (which will now show location A).
3. Click *Create new location* radio and then c...Steps to replicate:
1. Create an event X with location A, including email A and phone A
2. Create copy of event X say Y and go to location tab for event Y (which will now show location A).
3. Click *Create new location* radio and then click new location B, including email B and phone B.
4. Check event X - email B and phone B will be listed5.12.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/705Disabling Alphabetical Pager is not respected for events and contribution pages.2019-05-07T20:27:12ZyashodhaDisabling Alphabetical Pager is not respected for events and contribution pages.Steps to replicate :
-------------------
* Go to *Admin > Search Preferences* and turn off *Include Alphabetical Pager*
* A to Z Pager is off for *Find Contacts*, *Find Contributions*, etc
* However it is still shown on *Manage Events *a...Steps to replicate :
-------------------
* Go to *Admin > Search Preferences* and turn off *Include Alphabetical Pager*
* A to Z Pager is off for *Find Contacts*, *Find Contributions*, etc
* However it is still shown on *Manage Events *and *Manage Contribution Pages*.5.12.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/708Advanced Search: The "Modified By" option was set instead of "Added by"2019-03-01T20:42:46ZPradeep Nayakpradpnayak@gmail.comAdvanced Search: The "Modified By" option was set instead of "Added by"Steps:
* Click "View contact record"
* Click "Search" -> "Advanced Search"
* Open the "Change Log" tab
* Choose the "Added" radio button
* Type e.g. "test" to the search field
* Click "Search"
**Actual result:** The "Modified By" optio...Steps:
* Click "View contact record"
* Click "Search" -> "Advanced Search"
* Open the "Change Log" tab
* Choose the "Added" radio button
* Type e.g. "test" to the search field
* Click "Search"
**Actual result:** The "Modified By" option was set instead of "Added by". Please, see screenshot
![2019-02-04_11h32_55](/uploads/f32fe780e73fdaa1a91f62964cb1568f/2019-02-04_11h32_55.png)
**Expected result:** The "Modified By" option was not set instead of "Added by".5.12.0https://lab.civicrm.org/dev/core/-/issues/3264Transaction Date filter in Bookkeeping Transactions report2022-04-22T15:53:09ZMWestergaardTransaction Date filter in Bookkeeping Transactions reportIn the Bookkeeping Transactions report, the filter for Transaction Date does not include time values and leads to missing data. For example, if today is February 10 and I filter Transaction Date on "Yesterday", the WHERE clause looks li...In the Bookkeeping Transactions report, the filter for Transaction Date does not include time values and leads to missing data. For example, if today is February 10 and I filter Transaction Date on "Yesterday", the WHERE clause looks like:
> ( financial_trxn.trxn_date >= '20190209') AND ( financial_trxn.trxn_date <= '20190209' )
Only transactions that occurred exactly at midnight are included. Contrast that with the filter for Date Received:
> ( contribution.receive_date >= '20190209000000') AND ( contribution.receive_date <= '20190209235959' )
I verified on dmaster and wpmaster.5.12.0https://lab.civicrm.org/dev/core/-/issues/714Manage groups: Error: "API permission check failed for Group/create call; ins...2019-02-13T19:30:24ZPradeep Nayakpradpnayak@gmail.comManage groups: Error: "API permission check failed for Group/create call; insufficient permission" when the user tries to edit some group's detailsSteps:
* Click "View contact record"
* Click "Contacts" -> "Manage Groups"
* Try to edit Name of the group from the precondition.
**Actual result:** There is an error: "API permission check failed for Group/create call; insufficient pe...Steps:
* Click "View contact record"
* Click "Contacts" -> "Manage Groups"
* Try to edit Name of the group from the precondition.
**Actual result:** There is an error: "API permission check failed for Group/create call; insufficient permission: require access CiviCRM and edit groups"
**Expected result:** User shouldn't be allowed to use inline edit for group update when they don't have permission.5.12.0https://lab.civicrm.org/dev/core/-/issues/716Add decimals in Contribution Amount on Repeat Contributions Report2019-02-22T00:33:16ZGhost UserAdd decimals in Contribution Amount on Repeat Contributions ReportThe Repeat Contributions Report automatically truncate the contribution amount
Here you can see the contribution with an amount with decimals
![Repeat_Contribution_Report_Error_1](/uploads/96c2fcd5deab7a10aeda90db133cc25f/Repeat_Contrib...The Repeat Contributions Report automatically truncate the contribution amount
Here you can see the contribution with an amount with decimals
![Repeat_Contribution_Report_Error_1](/uploads/96c2fcd5deab7a10aeda90db133cc25f/Repeat_Contribution_Report_Error_1.png)
While in the Report is truncated and doesn't show the decimals.
![Repeat_Contribution_Report_Error_2](/uploads/e3d4cdc65040cd54f34e0372dbb05376/Repeat_Contribution_Report_Error_2.png)5.12.0https://lab.civicrm.org/dev/core/-/issues/720Performance change approved - remove mode & median slow queries2019-02-19T04:53:15ZeileenPerformance change approved - remove mode & median slow queriesUpdate - simply removing per decision by @colemanw below....
---------------------------------------------------------------
Original
----------------------------------------------------------------
The calculations done for the summary...Update - simply removing per decision by @colemanw below....
---------------------------------------------------------------
Original
----------------------------------------------------------------
The calculations done for the summary statistics on the contribution search is currently the biggest point of slowness we are facing. The following stats are generated:
'count' (number completed)
'amount' (total amount of completed)
'avg' (average amount of completed)
'mode' (most common value of completed)
'median' (median value of complete)
'cancel_amount' (total of cancelled)
'cancel_count' (number cancelled)
'cancel_avg' (average amount of cancelled)
These are then grouped by currency.
Of these the count and total amount are highly useful whereas the usefulness of mode & median are more niche.
On the other hand it is possible to fix up MOST of these queries to perform well. Mode and median are pretty much impossible to make performant on a large result set, and are actually the main reason our users have to do carefully constrained queries that don't return more than around 50k of results.
Let's assume we do a query that returns 50,000 results and the criteria is the payment_instrument_id then ideally that field will be used as the index on the query and we get the main query returned pretty quickly.
However, in order to do a median query it is necessary to order the results by total_amount. We can't use both indexes, and we can't add combined indexes for every combination of total_amount & possible criteria so we are one way or another going to be either
- using the total_amount index to sort & doing an unindexed filter - on our whole DB....
- using the index to filter & doing an unindexed sort on 50k rows
- using a merged index (these take time to compile)
Some queries are possible to rewrite - I recently got the annual query down from 6 seconds to .02 seconds but the median query just isn't every going to scale well.
Which leaves us with 'how can we help sites that with users are not happy twiddling their thumbs while the median is calculated'.
There are a few options IMHO
1) just remove median & mean - no-one (by which I mean me) cares about them anyway
2) add a setting that allows a site to specify which contribution stats they want calculated
3) only calculate median & mean if the total number of rows is < 1000
4) add a hook to permit the queries that run to be altered
Of these both 1 & 3 are imposing change on people who might not want change.
Adding a setting seems like a hack. In general adding settings to tweak core behaviour for a different use case/ preferences is almost always a hack - although the use case 'I have a big database' is perhaps a bit more generic than the 'I'd like this page/search bar / widget to behave differently & the least hassle on me is to add a setting'
I do think, however, that 4 is probably the least hacky / most sensible and it will 'gracefully retire itself' when we finally get a better search screen that doesn't use the query object.
I think it would look like
```
hookAlterQuerySummary($entity, $context, &$callbacks);
```
(only Contribution is relevant at the moment but passing entity seems to make sense)
We would have to break out the existing queries to their own fns & then we'd get
$callbacks = [
'CRM_Contact_BAO_Query::getBasicStats',
'CRM_Contact_BAO_Query::getMedian',
'CRM_Contact_BAO_Query::getMean',
'CRM_Contact_BAO_Query::getCancelStats'
]
There would then be a call like
CRM_Contact_BAO_Query::getBasicStats($rowStats, $whereClause, $fromClause)
And $rowStats would be altered by the function adding values & labels so the tpl could iterate through them
Longer term - I would argue the slow stats should probably be ADDED rather than REMOVED by extension as I think shipping something that makes hard-to-justify performance trade-offs is a big call5.12.0https://lab.civicrm.org/dev/core/-/issues/739Field not found when sorting report by Case Type as a section header2019-02-25T20:47:12ZgrahamsmithField not found when sorting report by Case Type as a section headerAttempting to create a Case Detail report sorted by the field Case Type with the option "Section Header" checked does not work.
Error is:
> Unknown column 'case_civireport.case_type_name' in 'field list'
This is a probable regression,...Attempting to create a Case Detail report sorted by the field Case Type with the option "Section Header" checked does not work.
Error is:
> Unknown column 'case_civireport.case_type_name' in 'field list'
This is a probable regression, as addressed by: https://github.com/civicrm/civicrm-core/pull/114195.12.0https://lab.civicrm.org/dev/core/-/issues/3268Deprecate `getBasicContactFields` in favor of `getColumns('Contact')`2022-04-22T15:53:15ZJonGoldDeprecate `getBasicContactFields` in favor of `getColumns('Contact')`@eileen has ported some of the cleaner code for defining report specs from Extended Reports to core in the form of `getColumns()` and `getContactColumns()`. Since this appears to be the direction we're headed in, I think it makes sense ...@eileen has ported some of the cleaner code for defining report specs from Extended Reports to core in the form of `getColumns()` and `getContactColumns()`. Since this appears to be the direction we're headed in, I think it makes sense to deprecate `getBasicContactColumns()`, which does a similar job. However, `getBasicContactColumns()` adds a bunch of fields to core reports that `getContactColumns` doesn't.
My PR adds all the missing fields to `getContactColumns` (except for "Organization Name"; this seems unnecessary since it will virtually always match the display name). I also mark `getBasicContactFields()` as deprecated so future cleanup can target reports using it.5.12.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3232Soft Credit report fails when Only Full Group By is enabled2022-04-22T15:51:29ZJonGoldSoft Credit report fails when Only Full Group By is enabledThis is replicable by running the report with no changes to defaults on dmaster.
The cause is that the Soft Credit report overrides `CRM_Core_Form::postProcess()` and calls `CRM_Core_DAO::executeQuery()` directly instead of `CRM_Core_Fo...This is replicable by running the report with no changes to defaults on dmaster.
The cause is that the Soft Credit report overrides `CRM_Core_Form::postProcess()` and calls `CRM_Core_DAO::executeQuery()` directly instead of `CRM_Core_Form::buildRows()`, which the FGB safeguards exist. So even though the report is marked as not optimized for FGB, it makes no difference.5.12.0JonGoldJonGold