CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2019-03-27T02:24:04Zhttps://lab.civicrm.org/dev/core/-/issues/821Activity: Assigned to: It is not possible to search by the "refine search" dr...2019-03-27T02:24:04ZPradeep Nayakpradpnayak@gmail.comActivity: Assigned to: It is not possible to search by the "refine search" drop-downSteps:
* Find and open a profile of the contact from the precondition
* Click "Actions" → "Meeting"
* Open the "Assigned to" drop-down
* Choose e.g. the "Contact Type" option to the "refine search" list
* Try to choose some option to th...Steps:
* Find and open a profile of the contact from the precondition
* Click "Actions" → "Meeting"
* Open the "Assigned to" drop-down
* Choose e.g. the "Contact Type" option to the "refine search" list
* Try to choose some option to the "select" drop-down (e.g. Individual)
**Actual result:** It is not possible to search by the "refine search" drop-down.
**Expected result:** It is possible to search by the "refine search" drop-down
Possible regression : https://lab.civicrm.org/dev/core/issues/6775.12.0https://lab.civicrm.org/dev/core/-/issues/801Thank You letters have an invalid 'from' when sending from the contact's emai...2019-03-25T21:48:33ZbgmThank You letters have an invalid 'from' when sending from the contact's email addressTo reproduce:
* Record a contribution for a contact
* Find Contributions, select the contribution, Send Thank You Letters
* Select the option to send emails
* Use the default from of the contact, which should be the email on their conta...To reproduce:
* Record a contribution for a contact
* Find Contributions, select the contribution, Send Thank You Letters
* Select the option to send emails
* Use the default from of the contact, which should be the email on their contact record.
When sending the emails, CiviCRM will throw an error that there is no 'from' in the email, which sounds like this SE question: https://civicrm.stackexchange.com/questions/21780/civicontribute-thank-you-letter-not-emailed-using-cividesk-sparkpost/24948
Inspecting the form html reveal's this:
![Capture_d_écran_de_2019-03-14_12-45-04](/uploads/04998410f1c204cb52310c0dbb6da0fc/Capture_d_écran_de_2019-03-14_12-45-04.png)
It seems very familiar to issue #3575.12.0https://lab.civicrm.org/dev/core/-/issues/770View Case Activity page displays disabled custom fields2019-03-03T20:07:09ZjitendraView Case Activity page displays disabled custom fieldsReplicate it by -
- Creating a custom group for case activity
- Add 2 fields to the set - active and disabled.
![image](/uploads/e7e5f00520f821ab4f7a96a85cac2026/image.png)
- Create a case activity and enter value in the active custom...Replicate it by -
- Creating a custom group for case activity
- Add 2 fields to the set - active and disabled.
![image](/uploads/e7e5f00520f821ab4f7a96a85cac2026/image.png)
- Create a case activity and enter value in the active custom field.
- Click `View` link in the activity row and notice the disabled field shown on the page.
![image](/uploads/80a7755dbd1c30a100304aa3a4d1197b/image.png)5.12.0jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/769ZIP Archive for multiple batch exports fail2019-03-01T00:27:09ZEdselopezZIP Archive for multiple batch exports failThere is an issue with the ZipArchive class' open() method. In previous versions of PHP when the only flag passed to the method was the ZipArchive::OVERWRITE, the method also created non-existing archives.
Since PHP 5.6 the OVERWRITE fl...There is an issue with the ZipArchive class' open() method. In previous versions of PHP when the only flag passed to the method was the ZipArchive::OVERWRITE, the method also created non-existing archives.
Since PHP 5.6 the OVERWRITE flag alone cannot create new archives which breaks compatibility.
Test script:
---------------
// Open new archive in cwd based on timestamp
$zip = new ZipArchive();
$open = $zip->open(time() . '.zip', ZipArchive::OVERWRITE);
echo $open;
Expected result:
----------------
Expected behavior: The new archive is opened as in the previous version.
Actual result:
--------------
In PHP 5.5 an empty archive is opened.
In PHP 5.6 ZipArchive::ER_OPEN error code is returned (cannot open zip file).5.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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/904PR 13333 breaks the Save and New button on a new case2019-05-07T23:05:09ZDaveDPR 13333 breaks the Save and New button on a new caseIf I take out the second "submitOnce" line in CRM/Case/Form/Activity/OpenCase.php then it works again.If I take out the second "submitOnce" line in CRM/Case/Form/Activity/OpenCase.php then it works again.5.13.0