CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2018-07-24T20:41:10Zhttps://lab.civicrm.org/dev/core/-/issues/244Allow use of custom fields of type select without specifying an optiongroup2018-07-24T20:41:10Zmattwiremjw@mjwconsult.co.ukAllow use of custom fields of type select without specifying an optiongroupFor an extension I had a requirement to add a "Select Month" custom field. The options are populated dynamically using hook_civicrm_fieldOptions and there is no need for an option group to be associated with them (manually specifying th...For an extension I had a requirement to add a "Select Month" custom field. The options are populated dynamically using hook_civicrm_fieldOptions and there is no need for an option group to be associated with them (manually specifying the months of the year in an optiongroup means they won't be updated to match the current locale).
Additionally, if populated dynamically using the hook_civicrm_fieldOptions and there is an optiongroup associated with the field, the "Edit options" element is automatically added to the UI which is not desirable and does not work properly as the optiongroup is not populated.
There is a single line in CRM_Core_BAO_CustomField::getOptions which causes the function to return before calling hooks if the element is a Select and doesn't have an option group defined which makes it impossible to populate the field using hooks. Removing this allows the hook to populate the custom field values and everything works.
For an example see https://github.com/mattwire/uk.co.mjwconsult.variablerecurpayments (Edit a Membership Type and select the Pro-Rata Start Month).
https://github.com/civicrm/civicrm-core/pull/12439 is also required.
PR: https://github.com/civicrm/civicrm-core/pull/124405.0.0https://lab.civicrm.org/dev/core/-/issues/68DB Error on 'Find Participant' page when MySQL FULL_GROUP_BY_MODE is enabled2018-05-17T11:38:27ZMonish DebDB Error on 'Find Participant' page when MySQL FULL_GROUP_BY_MODE is enabledSteps to replicate:
1. Ensure that FULL_GROUP_BY_MODE is enabled in MySQL
2. Go to 'Find Participant' search form and do a simple search
This leads to
DB Error - https://pastebin.com/jxbaAbpSSteps to replicate:
1. Ensure that FULL_GROUP_BY_MODE is enabled in MySQL
2. Go to 'Find Participant' search form and do a simple search
This leads to
DB Error - https://pastebin.com/jxbaAbpS5.1.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/477Print Summary is missing some contact info2018-10-29T20:49:47ZJonGoldPrint Summary is missing some contact infoFrom Stack Exchange: https://civicrm.stackexchange.com/q/27063/12
To replicate:
* Open any individual's contact.
* From the "Actions" button, select "Print Summary".
**Expected**
The contact's employer/job title should be in the print...From Stack Exchange: https://civicrm.stackexchange.com/q/27063/12
To replicate:
* Open any individual's contact.
* From the "Actions" button, select "Print Summary".
**Expected**
The contact's employer/job title should be in the print summary.
**Actual**
It's not.
The last line of `<civiroot>/templates/CRM/Contact/Page/View/Print.tpl` is:
```js
cj('#contact-summary' ).children(':first').remove();
```
The reason for this is lost to the ages, but I suspect this referred to some other DOM element that's long since been removed.
Personally I'd deprecate this whole functionality - but apparently folks are using it, so let's make it work.
If someone wants to mark this "concept: approved" I'll submit the PR.5.8https://lab.civicrm.org/dev/core/-/issues/474Missing log table warning on status page even if logging is disabled.2018-10-27T04:12:13ZjitendraMissing log table warning on status page even if logging is disabled.This is a rare case except the one raised in https://lab.civicrm.org/dev/core/issues/462.
The flow which can lead to this error is -
- Logging is enabled on the site which generates a list of log tables in the database.
- User now dis...This is a rare case except the one raised in https://lab.civicrm.org/dev/core/issues/462.
The flow which can lead to this error is -
- Logging is enabled on the site which generates a list of log tables in the database.
- User now disables the logging functionality on the site which now stops generating any more log tables.
- User create a custom set on the site which creates a new table in the database.
- The system status page notices a missing log table for the above and displays a warning.
The last step should also check if the logging is enabled on the site even if it is able to find some core log tables already present in the db.5.8jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/463Add in support for Extension Utils when generating DAO files for Extensions2018-11-03T07:18:48ZseamusleeAdd in support for Extension Utils when generating DAO files for Extensions5.8https://lab.civicrm.org/dev/core/-/issues/460Fix malformed redirect URLs2018-11-09T01:01:30ZhaystackFix malformed redirect URLsThis is a bit of an edge case, but I have run into it once or twice. The `perform` method of `CRM_Core_QuickForm_Action_Jump` can produce invalid URLs. This happens when `$current->getAttribute('action')` is a URL ending in `?`. The resu...This is a bit of an edge case, but I have run into it once or twice. The `perform` method of `CRM_Core_QuickForm_Action_Jump` can produce invalid URLs. This happens when `$current->getAttribute('action')` is a URL ending in `?`. The resulting URL has `?&` in it, e.g.
`https://civicrm.latest/civicrm/event/register/?&_qf_ThankYou_display=true&qfKey=<some-key>`
This seems to cause Chrome to "fix" the URL and then redirect to the "fixed" URL:
`https://civicrm.latest/civicrm/event/register/?_qf_ThankYou_display=true&qfKey=<some-key>`
I'm not certain about this - particularly as I haven't tested in all browsers - but this redirect could be the cause of missing sessions in the Event Registration process. If the "fix" behaviour changed from browser to browser, this might also account for the slipperiness of repeating the issue.
Either way, the method shouldn't produce invalid URLs.5.8https://lab.civicrm.org/dev/core/-/issues/459Fix `crmURL` parameters in various templates2018-11-29T10:02:12ZhaystackFix `crmURL` parameters in various templatesIn Smarty templates, when the `q` parameter is prefixed with an ampersand, for example:
`{crmButton p='civicrm/contact/view/delete' q="&reset=1&delete=1&cid=$contactId" class="delete" icon="trash"}`
the resulting URL contains `&&` like...In Smarty templates, when the `q` parameter is prefixed with an ampersand, for example:
`{crmButton p='civicrm/contact/view/delete' q="&reset=1&delete=1&cid=$contactId" class="delete" icon="trash"}`
the resulting URL contains `&&` like this:
`http://civicrm.local/wp-admin/admin.php?page=CiviCRM&q=civicrm/contact/view/delete&&reset=1&delete=1&cid=202`
This happens in a number template files. PR to follow.5.8https://lab.civicrm.org/dev/core/-/issues/457Add new hook exportIds2018-10-27T04:12:13ZscardiniusAdd new hook exportIdsBecause of GDPR rules we have to save information that some data were exported.
Current hook https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_export/ is not enough because it returns data without id columns. It's hard to implem...Because of GDPR rules we have to save information that some data were exported.
Current hook https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_export/ is not enough because it returns data without id columns. It's hard to implement any sophisticated feature without id of objects.
One of such example you can find here https://github.com/veda-consulting/uk.co.vedaconsulting.gdpr/issues/157
The solution is new type of hook:
```php
CRM_Utils_Hook::exportIds($ids, $componentTable, $exportMode);
```5.8https://lab.civicrm.org/dev/core/-/issues/436API Get action lookups for alphanumeric custom fields with option values with...2018-10-24T22:17:40ZjackrabbithannaAPI Get action lookups for alphanumeric custom fields with option values with uppercase characters fails to find contactsReplicable on https://dmaster.demo.civicrm.org
Create a custom field on a contact that is Alphanumeric and uses a Multi-Select widget (may be a condition for other custom field types / widgets as well)
Add a few options, but make at le...Replicable on https://dmaster.demo.civicrm.org
Create a custom field on a contact that is Alphanumeric and uses a Multi-Select widget (may be a condition for other custom field types / widgets as well)
Add a few options, but make at least one of the option values contain at least one uppercase character.
Update a contact, give the custom field value one of the options that has an uppercase character in the value.
Use the API anywhere, or use the API explorer, and do a Contact, get call, where custom_[id] = the option with the uppercase character.
No contacts will be returned.
Here where the custom field query is built, the param value for the custom field is made lowercase:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/CustomQuery.php#L338
In this file
https://github.com/civicrm/civicrm-core/blob/master/CRM/Contact/BAO/Query.php#L5687
The operator RLIKE is updated to include the BINARY operator option
Which makes the clause case sensitive...
Introduced in this commit:
https://github.com/civicrm/civicrm-core/commit/a047568869892f9af65002c1709af1931f5f4b0d
This PR: https://github.com/civicrm/civicrm-core/pull/12364
So it looks like a fix for the search builder regex search, has broken the API Contact Get for custom fields with option values with uppercase characters.
This could affect other things?
I'm not sure how to make these two things gel, but surely querying via the CiviCRM API should work, or take precedence.
I'm happy to make a PR, but I'm not sure what is the best thing to do...
Do we really need to make the option value lowercase when building the custom field query where clause?5.8https://lab.civicrm.org/dev/core/-/issues/418Can't add relationship to group of search results if relationship type is any...2018-10-09T16:11:32ZjamieCan't add relationship to group of search results if relationship type is any to anyIf you create a relationship type that relates a contact of any type to a contact of any type, that relationship will not be available to select when adding a relationship to a group of search results.If you create a relationship type that relates a contact of any type to a contact of any type, that relationship will not be available to select when adding a relationship to a group of search results.5.8https://lab.civicrm.org/dev/core/-/issues/4065.5.2: Import is not happy on PHP-7.2 (Countable)2019-01-08T02:47:10ZDmitry Smirnov5.5.2: Import is not happy on PHP-7.2 (Countable)~~~~
2018/09/25 18:15:04 [error] 33#33: *451 FastCGI sent in stderr: "PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 375
P...~~~~
2018/09/25 18:15:04 [error] 33#33: *451 FastCGI sent in stderr: "PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 375
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 387
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 396
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 408
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 417
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 426
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 435
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 444
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 455
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 464
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 476" while reading response header from upstream, client: 192.168.0.2, server: civicrm.local, request: "POST /wp-admin/admin.php?page=CiviCRM&q=civicrm/impor
~~~~5.8https://lab.civicrm.org/dev/core/-/issues/357Email signature stopped working since ??? 4.6 ??2019-06-24T20:27:12ZPradeep Nayakpradpnayak@gmail.comEmail signature stopped working since ??? 4.6 ??After upgrade from 4.6 to 5.3 email signature stopped working
To replicate:
![After](/uploads/d7ae5b98c59b8ce410fa3a396ddb9ce1/After.gif)
In 4.6
![Before](/uploads/f6c9ce58dd46f9228f3a41a99a32e227/Before.gif)
Related PR that might h...After upgrade from 4.6 to 5.3 email signature stopped working
To replicate:
![After](/uploads/d7ae5b98c59b8ce410fa3a396ddb9ce1/After.gif)
In 4.6
![Before](/uploads/f6c9ce58dd46f9228f3a41a99a32e227/Before.gif)
Related PR that might have caused regression: https://github.com/civicrm/civicrm-core/commit/669f45efe5f5.8https://lab.civicrm.org/dev/core/-/issues/355Style improvement of radio form elements2019-11-29T20:27:27ZcalbasiStyle improvement of radio form elementsHi,
Radio inputs are too close to their labels, I think a **simple** improvement would be:
```
input.crm-form-radio + label{
margin-left: 7px;
}
```
If you agree, I can do a pull request at github.
Ps: First time summiting an issue ...Hi,
Radio inputs are too close to their labels, I think a **simple** improvement would be:
```
input.crm-form-radio + label{
margin-left: 7px;
}
```
If you agree, I can do a pull request at github.
Ps: First time summiting an issue at "new" gitlab instance, please, I beg your perdon if I'm not using the correct project :-)5.8https://lab.civicrm.org/dev/core/-/issues/287Child groups with all parents disabled shows in group list2018-11-09T00:32:42ZmadhaviChild groups with all parents disabled shows in group listI'am currently using Civicrm version 5.3.1 with drupal 7.59.
Steps to replicate:
1. Create one group, parent A.
2. Create a one group, child A and assign parent A group created above as parent.
3. Disable parent A group.
4. Go to conta...I'am currently using Civicrm version 5.3.1 with drupal 7.59.
Steps to replicate:
1. Create one group, parent A.
2. Create a one group, child A and assign parent A group created above as parent.
3. Disable parent A group.
4. Go to contacts->manage groups. You are unable to see both parent and child groups.
5. Click on any search criteria. Unclick it. You can see the child A group with title as Child A Child of: With null value for parent
![grp](/uploads/68ad5d2a88e11fda53e63b1512868e13/grp.png)
**How it works currently:** If a child group has multiple parent groups and one of them is disabled, the child group should to show up on group selector lists. This has been fixed here https://issues.civicrm.org/jira/browse/CRM-20934.
If all parent group(s) are disabled the child group still shows up in search mode.
**How it should work:** If a child group has multiple or single parent group and all of them are disabled, should the child group be removed from the selector lists.
For more insights please see the discussion on stack exchange here https://civicrm.stackexchange.com/questions/25855/child-groups-with-all-parents-disabled-shows-in-group-list5.8https://lab.civicrm.org/dev/core/-/issues/66Refactor addAddressColumns in the report2018-11-04T20:34:30ZjaapjansmaRefactor addAddressColumns in the reportAs the discussion in this closed pr (https://github.com/civicrm/civicrm-core/pull/11980) there is a need to refactor addAddressColumns in the reports in core.
The extended report extension has a working implementation.As the discussion in this closed pr (https://github.com/civicrm/civicrm-core/pull/11980) there is a need to refactor addAddressColumns in the reports in core.
The extended report extension has a working implementation.5.8https://lab.civicrm.org/dev/core/-/issues/745Smart groups broken when "Enable multiple bulk email address for a contact" s...2019-03-07T19:43:17ZscardiniusSmart groups broken when "Enable multiple bulk email address for a contact" setting is offWhen setting "Enable multiple bulk email address for a contact" is off then ALL smart groups have additional condition (Email On Hold) because of false-positive effect of code:
https://github.com/civicrm/civicrm-core/pull/12942/files
``...When setting "Enable multiple bulk email address for a contact" is off then ALL smart groups have additional condition (Email On Hold) because of false-positive effect of code:
https://github.com/civicrm/civicrm-core/pull/12942/files
```php
elseif ($id == 'email_on_hold') {
if ($onHoldValue = CRM_Utils_Array::value('email_on_hold', $formValues)) {
$onHoldValue = (array) $onHoldValue;
$params[] = array('on_hold', 'IN', $onHoldValue, 0, 0);
}
}
```
For such case `email_on_hold` has value:
```php
$formValues['email_on_hold'] = [
'on_hold' => NULL,
];
```
which is false-positive in condition5.11https://lab.civicrm.org/dev/core/-/issues/693On contact summary page, on submitting a 'New Case' form doesn't redirect to ...2019-02-04T22:04:19ZMonish DebOn contact summary page, on submitting a 'New Case' form doesn't redirect to 'Manage Case' screenSteps to replicate:
1. Go to Case tab in Contact summary page.
2. Click on 'Add Case' button which opens the 'New Case' backoffice form in a popup.
3. Fill and submit the form which simply closes the popup and does not redirect to the 'M...Steps to replicate:
1. Go to Case tab in Contact summary page.
2. Click on 'Add Case' button which opens the 'New Case' backoffice form in a popup.
3. Fill and submit the form which simply closes the popup and does not redirect to the 'Manage Case' screen. Although the redirect url is declared in [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/Case/Form/Activity/OpenCase.php#L355)
Solution:
Add 'no-popup' class to 'Add Case' button so that 'New Case' backoffice form always opens in a new window and thus redirects to 'Manage Case' on submit5.11Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/692Unable to use url search arguments in 'Advanced Search' using force=12023-02-25T05:03:38ZMonish DebUnable to use url search arguments in 'Advanced Search' using force=1Currently, it is not possible to use URL search arguments in 'Advanced Search' using force=1 to load search results. This is no longer working except for mailing params which are manually handled [here](https://github.com/civicrm/civicrm...Currently, it is not possible to use URL search arguments in 'Advanced Search' using force=1 to load search results. This is no longer working except for mailing params which are manually handled [here](https://github.com/civicrm/civicrm-core/blob/5.10/CRM/Contact/Form/Search.php#L636L647).
Following are the steps to support URL search arguments Civi component-wise:
1. All the search forms extends the parent class ```CRM_Core_Form_Search``` that will define a new function ```loadSearchParamsFromUrl()```. Definition as follows
```php
function loadSearchParamsFromUrl() {
// In case no component is defined then lookout for basic contact search fields + all enanbled components search fields
if (!$this->_component) {
if (method_exists('CRM_Contact_Form_Search', 'setSearchParamFromUrl')) {
CRM_Contact_Form_Search::setSearchParamFromUrl($this);
}
foreach ($enabledComponents as $component) {
$searchClass = $component->namespace . '_Form_Search';
if (method_exists($searchClass, 'setSearchParamFromUrl')) {
$searchClass::setSearchParamFromUrl($form);
}
}
}
elseif (array_key_exists($this->_component, $enabledComponents)) { // $_component = 'CiviMail'
$searchClass = $enabledComponents[$this->_component]->namespace . '_Form_Search';
if (method_exists($searchClass, 'setSearchParamFromUrl')) {
// call CRM_Mailing_Form_Search::setSearchParamFromUrl()
$searchClass::setSearchParamFromUrl($form);
}
}
}
```
2. This function will be called by respective search form to find the search arguments from URL and set them accordingly. And will be handled in ```SearchClass::setSearchParamFromUrl($form);``` as:
```php
class CRM_Contact_Form_Search {
...
public static function setSearchParamFromUrl(&$form) {
foreach (CRM_Contact_Form_Search_Criteria::getBasicSearchFields() as $name => $type) {
if ($value = CRM_Utils_Request::retrieve($name, $type)) {
$form->_formValues[$name] = $value;
}
}
$form->_params = CRM_Contact_BAO_Query::convertFormValues($form->_formValues);
$form->set('formValues', $form->_formValues);
$form->set('queryParams', $form->_params);
}
}
```
The intent is to generalize the workflow and let each component's search form decide and hosts its list of search arguments (on basis of enabled component) rather than manually handling them in different places.5.11Monish DebMonish Debhttps://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/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.0