CiviCRM Core issues
https://lab.civicrm.org/dev/core/-/issues
2022-10-12T05:04:03Z
https://lab.civicrm.org/dev/core/-/issues/641
Case Activity Assignment Restriction
2022-10-12T05:04:03Z
shitijg
Case Activity Assignment Restriction
**Overview:**
We have had a few security complaints from a few clients using cases. They mistakenly assigned an activity to a contact who was not supposed to see the details of the activity.
**How it works right now**
Currently, a us...
**Overview:**
We have had a few security complaints from a few clients using cases. They mistakenly assigned an activity to a contact who was not supposed to see the details of the activity.
**How it works right now**
Currently, a user can create and assign an activity to any CiviCRM contact. This in turn sends an email notification to the assignee. However, some users have reported that they mistakenly assigned activities to contacts with similar names which meant that someone who should not have access to any details of the activity got a link stating some basic details of the activity.
Whilst, the contact who received the email wasn't a CiviCRM user, so they couldn't not login and edit the activity, just some basic details in this case acted as a security breach as the table in the email already revealed more about the activity.
**New Implementation:**
We want to add the ability to restrict the assignment of case activities to a group.
Points to note- (UPDATED ON 07/01 to have this setting on the case type)
- This can live in the case type settings ie the user can define which group can an activity be assigned to per case type (civicrm/a/#/caseType/n where 'n' is the ID of the case type)
- We can have 2 options for the field "Case activity assignment to" - 1. All Users (DEFAULT) 2. Restricted by group
- On selecting 2. - the user will be able to select a group
- Once a group is selected, the user will only be able to assign a case activity to contacts within the selected group
- If an activity from outside cases is "Filed" on case - and if the assignee is not a part of that group - there should not be any new notifications going to the assignee (this is already working this way ie no notifications are sent to the assignee on filing an out of case activity to a case)
Feel free to reach out to me on Mattermost if you need any clarifications.
Thanks
https://lab.civicrm.org/dev/core/-/issues/647
Not all unit tests classes are used by jenkins
2019-03-11T13:34:15Z
tschuettler
Not all unit tests classes are used by jenkins
I discovered in https://github.com/civicrm/civicrm-core/pull/13396#issuecomment-451433721 that the test class was not actually used for unit testing.
When checking for further cases I made a script for the `api` and `CRM` test folder t...
I discovered in https://github.com/civicrm/civicrm-core/pull/13396#issuecomment-451433721 that the test class was not actually used for unit testing.
When checking for further cases I made a script for the `api` and `CRM` test folder that checks if there are other occurences where the filename and classname that does not match:
- [x] Filename: api_v3_UserTest Class: api_v3_UserWebsiteTest
- [x] Filename: CRM_Contact_SelectorTest Class: CRM_Contact_Form_SelectorTest
- [x] Filename: CRM_Contribute_Form_TaskTest Class: CRM_Contribute_Form_Tasktest
- [x] Filename: CRM_Custom_Page_AjaxTest Class: CRM_Custom_Page_AJAXTest
- [x] Filename: CRM_Import_DataSource_CsvTest Class: CRM_Import_Datasource_CsvTest
- [x] Filename: CRM_Event_Form_Registration_RegisterTest Class: CRM_Event_Form_RegistrationTest
It looks to me like none of the tests are used by jenkins when they actually should be?
https://lab.civicrm.org/dev/core/-/issues/650
Use popups for links
2019-01-24T18:14:59Z
Don Wijesooriya
Use popups for links
Update links on following 2 templates to work as popups:
1. templates/CRM/Contribute/Page/ContributionRecur.tpl Membership link
2. templates/CRM/Member/Form/MembershipView.tpl Recurring Contribution link
# Steps to reproduce:
1. Creat...
Update links on following 2 templates to work as popups:
1. templates/CRM/Contribute/Page/ContributionRecur.tpl Membership link
2. templates/CRM/Member/Form/MembershipView.tpl Recurring Contribution link
# Steps to reproduce:
1. Create a recurring contribution manually
```php
$result = civicrm_api3('ContributionRecur', 'create', [
'contact_id' => contact_id_of_your_choosing,
'amount' => 50,
'frequency_interval' => 1,
]);
```
2. Create a membership
3. Link the recurring contribution to the membership
```php
$result = civicrm_api3('Membership', 'create', [
'id' => id_of_the_membership,
'contribution_recur_id' => id_of_the_recurring_contribution,
]);
```
### Recurring Contribution View (CRM_Contribute_Page_ContributionRecur)
Clicking on the link to membership opens it in a new page
![recur](/uploads/ffcec3eda0092de1b6da55f50cc3e145/recur.png)
### Membership View (CRM_Member_Form_MembershipView)
Clicking on the link to recurring contribution opens it in a new page
![membership](/uploads/ed50a7f1e857d298b7a169cbab2ddde4/membership.png)
## Fix
* In templates/CRM/Contribute/Page/ContributionRecur.tpl added class `crm-popup` to the hyperlink in following code block
```
{if $recur.membership_id}
<tr>
<td class="label">{ts}Membership{/ts}</td>
<td><a class="crm-hover-button" href='{crmURL p="civicrm/contact/view/membership" q="action=view&reset=1&cid=`$contactId`&id=`$recur.membership_id`&context=membership&selectedChild=member"}'>{$recur.membership_name}</a></td>
</tr>
{/if}
```
* In templates/CRM/Member/Form/MembershipView.tpl added class `crm-popup` to the hyperlink in following code block
```
{if $contribution_recur_id}
<tr>
<td class="label">{ts}Recurring Contribution{/ts}</td>
<td>
<a class="crm-hover-button" href='{crmURL p="civicrm/contact/view/contributionrecur" q="reset=1&id=`$contribution_recur_id`&cid=`$contactId`&context=contribution"}'>View Recurring Contribution
</a>
</td>
</tr>
{/if}
```
https://lab.civicrm.org/dev/core/-/issues/654
Contribution Field Map not saving Soft Credit Type
2022-11-30T19:39:36Z
philmorbru
Contribution Field Map not saving Soft Credit Type
When importing Contributions with Soft Credits and saving a field mapping, the Soft Credit fields do not save the type of soft credit in the mapping. When reusing the saved mapping, the user must change the "Matching CiviCRM Field" to a ...
When importing Contributions with Soft Credits and saving a field mapping, the Soft Credit fields do not save the type of soft credit in the mapping. When reusing the saved mapping, the user must change the "Matching CiviCRM Field" to a field other than Soft Credit, and then change it back to Soft Credit to select the proper choice. Compare attached files of incorrect and expected/correct behavior.
![wrong](/uploads/ef41cb0ec6cf2b02a40a0a3cbbdfa6ed/wrong.jpeg)
![right](/uploads/185289c1c32fde58999381d14aefee65/right.jpeg)
Replicated on clean install of 5.7.0 on Joomla 3.9.
https://lab.civicrm.org/dev/core/-/issues/657
Add filter for country on Repeat Contributions Report
2022-10-01T08:45:39Z
francescbassas
Add filter for country on Repeat Contributions Report
Add the hability to filter by country on the Repeat Contributions Report.
Add the hability to filter by country on the Repeat Contributions Report.
https://lab.civicrm.org/dev/core/-/issues/662
Mail accounts don't work if the password contains "
2022-10-08T05:03:32Z
johnff
Mail accounts don't work if the password contains "
Mail accounts cannot be read by the activities processor if the password contains "
The fix for this is simple - put addslashes before the password is read, and this fix is working in our production instance.
Mail accounts cannot be read by the activities processor if the password contains "
The fix for this is simple - put addslashes before the password is read, and this fix is working in our production instance.
https://lab.civicrm.org/dev/core/-/issues/663
Deprecate ARCHIVE format for CiviCRM Database Logging
2021-05-11T16:45:30Z
xurizaemon
Deprecate ARCHIVE format for CiviCRM Database Logging
The ARCHIVE format seemed like a good idea at the time (it takes less space), but my sense is that very few organisations actively involved with CiviCRM choose to use ARCHIVE. I believe the experience of most has been that ARCHIVE storag...
The ARCHIVE format seemed like a good idea at the time (it takes less space), but my sense is that very few organisations actively involved with CiviCRM choose to use ARCHIVE. I believe the experience of most has been that ARCHIVE storage format is unreliable and the cause of various issues affecting site performance, backup reliability and other issues.
I propose that we switch the default storage format for sites activating Database Logging to the current default for that site's database.
Alternative approach might be to ship [nz.co.fuzion.innodbtriggers](https://github.com/eileenmcnaughton/nz.co.fuzion.innodbtriggers) activated by default on new installs (but this feels like it could add more complexity than just removing the ARCHIVE statements on new logging activation).
> "The INNODB format is arguablly a better format for CiviCRM logging. Although INNODB tables take more space, they can be queried much more effectively, which is useful when you want to consult the logs. Consulting the change log for ARCHIVE tables is phohibitivley slow once your logging has been running a while." - [Fuzion InnoDB Triggers extension README](https://github.com/eileenmcnaughton/nz.co.fuzion.innodbtriggers).
IMO this could be a "missing stair" situation - a known issue to those familiar with CiviCRM, but a gotcha for those unfamiliar, and therefore something which can go unfixed for a long time and has impact primarily on those new to the community/userbase.
Of particular consideration is the risk to sites who would be impacted by InnoDB using more diskspace - we don't want to ship a change which triggers disk outages as ARCHIVE tables are unzipped. I propose that we not do that.
I'm interested to hear from CiviCRM community members who do prefer the ARCHIVE format?
Related:
* https://github.com/civicrm/civicrm-sysadmin-guide/pull/142
* https://github.com/eileenmcnaughton/nz.co.fuzion.innodbtriggers
* https://civicrm.stackexchange.com/questions/2137/what-causes-periodic-database-errors-while-using-logging-and-what-should-i-do-a
* https://civicrm.stackexchange.com/questions/17733/db-error-unknown-error-when-adding-custom-field/17743#17743
* https://civicrm.stackexchange.com/questions/17770/archive-not-enabled-by-default-on-mariadb-10-1
* https://civicrm.stackexchange.com/questions/23075/any-other-way-to-disable-db-logging-civicrm-4-6x
* https://civicrm.stackexchange.com/questions/25318/large-civicrm-logs
https://lab.civicrm.org/dev/core/-/issues/664
Add new indexes when updating log table schema regardless of engine change
2019-03-18T00:07:09Z
Patrick Figel
pfigel@greenpeace.org
Add new indexes when updating log table schema regardless of engine change
While working on [at.greenpeace.advancedlogtables](https://github.com/greenpeace-cee/at.greenpeace.advancedlogtables), I noticed that the `System.updatelogtables` API call only adds new indexes set by the `alterLogTables` hook when it's ...
While working on [at.greenpeace.advancedlogtables](https://github.com/greenpeace-cee/at.greenpeace.advancedlogtables), I noticed that the `System.updatelogtables` API call only adds new indexes set by the `alterLogTables` hook when it's accompanied by an engine change.
That's generally fine when the indexes don't change, but once new ones are added you'd have to temporarily change the engine or apply the new ones manually.
Is there a particular reason why we'd want to keep that behaviour, or can we change it so that new indexes are added regardless of the engine?
I have [a patch](https://github.com/civicrm/civicrm-core/commit/eababeabc1d0e97a809c7c534ce7e5a73a065c65#diff-e0d65cfb03f2d6f003eb4d598ef7e50b) ready for this, but wanted to check if there's agreement on this first.
5.13.0
https://lab.civicrm.org/dev/core/-/issues/669
Custom Field is_required and is_view set to NULL instead of 0 if checkboxes n...
2022-09-28T05:03:35Z
jackrabbithanna
Custom Field is_required and is_view set to NULL instead of 0 if checkboxes not checked on edit form
May need two separate issues created for this, depends on if we think these are bugs or new expected behavior.
Noticed doing a 'get' API call, CustomField entity, that the is_required and is_view properties are no longer present in API ...
May need two separate issues created for this, depends on if we think these are bugs or new expected behavior.
Noticed doing a 'get' API call, CustomField entity, that the is_required and is_view properties are no longer present in API results if they are not checked via the standard custom field edit form.
replicable on dmaster.demo.civicrm.org
Create a custom field, and use the API explorer to look at it's properties
```
$result = civicrm_api3('CustomField', 'get', [
'sequential' => 1,
'id' => 13,
]);
```
I made a field on dmaster.demo, with id 13
Immediately after field creation, is_required showed 0
Went back and edited the custom field and saved, is_required is not present in the values at all
In the past is_required and is_view properties were present in the results, but had a value of 0.
2 things about this.
1) The value stored in the database is now NULL and not 0, I think this is a bug, but IDK. Especially after the field has been edited, the user made a decision that the field is not required, so the data in the database should represent that decision. NULL to me represents no decision.
2) If a value is NULL is the API not including the property in the results? This is inconsistent with the 'getfields' call for an entity...the properties returned for a 'get' api action by the 'getfields' request, should match, that is even if the value is NULL, then the API should return 'is_required' => NULL .
Code down the line may depend on this property being set...like CiviCRM Entity or other API consumers...In the case of CiviCRM Entity, we specifically set up Drupal entity type metadata based on the 'getfields' call and it is expecting the properties to be there when a 'get' call is made...
for 1) this must be a problem with form post process, to be saving the value as NULL and not 0. Do people see this as a bug, are we setting the is_required and is_view columns to NULL instead of 0 on purpose?
2) Do people agree that the expected behavior should be as I describe for the API?
https://lab.civicrm.org/dev/core/-/issues/672
Allow users to print their own receipts from dashboard
2022-10-17T05:03:55Z
yashodha
Allow users to print their own receipts from dashboard
Allow users to print their own receipts from dashboard
Allow users to print their own receipts from dashboard
yashodha
yashodha
https://lab.civicrm.org/dev/core/-/issues/673
Add filter for deleted contacts on Repeat Contributions Report
2019-01-23T08:30:46Z
francescbassas
Add filter for deleted contacts on Repeat Contributions Report
By default Repeat Contributions Report shows contributions for contacts in trash. It is a behavior that can lead to problems and, in our view, should be just the opposite.
By default Repeat Contributions Report shows contributions for contacts in trash. It is a behavior that can lead to problems and, in our view, should be just the opposite.
https://lab.civicrm.org/dev/core/-/issues/682
Add basic contact filters to Summary Contributions Report
2022-09-27T09:41:13Z
francescbassas
Add basic contact filters to Summary Contributions Report
Contributions of deleted contacts are shown on Summary Contributions Report. Adding basic contact filters to the Summary Contributions Report will prevent these "deleted" contributions from being included. In addition it will enable new ...
Contributions of deleted contacts are shown on Summary Contributions Report. Adding basic contact filters to the Summary Contributions Report will prevent these "deleted" contributions from being included. In addition it will enable new possibilities when applying contact filters to the report.
It can be considered a continuation of the work begun in https://issues.civicrm.org/jira/browse/CRM-20545
https://lab.civicrm.org/dev/core/-/issues/683
Incorrectly encoded state and country names
2019-02-15T16:47:10Z
mfb
Incorrectly encoded state and country names
Civi 4.3.alpha1 added some new states:
```
(@country_id, '072', 'Pļaviņu novads'),
(@country_id, '046', 'Kokneses novads'),
(@country_id, '065', 'Neretas novads'),
(@country_id, '092', 'Skrīveru novads'),
(@country_id, '007', 'Alūks...
Civi 4.3.alpha1 added some new states:
```
(@country_id, '072', 'Pļaviņu novads'),
(@country_id, '046', 'Kokneses novads'),
(@country_id, '065', 'Neretas novads'),
(@country_id, '092', 'Skrīveru novads'),
(@country_id, '007', 'Alūksnes novads'),
(@country_id, '009', 'Apes novads'),
(@country_id, '015', 'Balvu novads'),
(@country_id, '108', 'Viļakas novads'),
(@country_id, '014', 'Baltinavas novads'),
(@country_id, '082', 'Rug�ju novads'),
etc.
```
but according to the install schema these should be:
```
(NULL, 1119, "072", "Pļaviņu novads"),
(NULL, 1119, "046", "Kokneses novads"),
(NULL, 1119, "065", "Neretas novads"),
(NULL, 1119, "092", "Skrīveru novads"),
(NULL, 1119, "007", "Alūksnes novads"),
(NULL, 1119, "009", "Apes novads"),
(NULL, 1119, "015", "Balvu novads"),
(NULL, 1119, "108", "Viļakas novads"),
(NULL, 1119, "014", "Baltinavas novads"),
(NULL, 1119, "082", "Rugāju novads"),
...
```
I also found one wrongly-encoded country name in my instance. I didn't look into why but maybe no character encoding was specified in the sql commands and it fell back to (wrong) default?
```
mysql> SET NAMES utf8;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT name FROM civicrm_country WHERE name LIKE '%Saint Barth%';
+---------------------+
| name |
+---------------------+
| Saint Barthélemy |
+---------------------+
1 row in set (0.00 sec)
mysql> SELECT CONVERT(BINARY CONVERT(name USING latin1) USING utf8) FROM civicrm_country WHERE name LIKE '%Saint Barth%';
+-------------------------------------------------------+
| CONVERT(BINARY CONVERT(name USING latin1) USING utf8) |
+-------------------------------------------------------+
| Saint Barthélemy |
+-------------------------------------------------------+
1 row in set (0.00 sec)
```
https://lab.civicrm.org/dev/core/-/issues/685
PHP 7.3 compatibility
2021-07-08T23:35:38Z
JoeMurray
PHP 7.3 compatibility
PHP 7.3 was released Dec 6, 2018.
Confirm PHP 7.3 compatibity, create tasks in this issue or other related ones if they are found, then update https://docs.civicrm.org/sysadmin/en/latest/requirements/ to indicate PHP 7.3 is supported.
...
PHP 7.3 was released Dec 6, 2018.
Confirm PHP 7.3 compatibity, create tasks in this issue or other related ones if they are found, then update https://docs.civicrm.org/sysadmin/en/latest/requirements/ to indicate PHP 7.3 is supported.
There are a number of Backward Incompatible Changes in 7.3 that may affect us: http://php.net/manual/en/migration73.incompatible.php
In particular:
1. continue statements targeting switch control flow structures will now generate a warning
There don't seem to be that many places where this might be an issue:
``grep -R -n -i -A5 -B5 "continue" ./* | grep -E 'continue|switch' | more
1. Strict Interpretation of Integer String Keys on ArrayAccess
Whack-a-mole efforts may be needed.
I think if enough reports of successful use of 7.3 are found then we should go ahead and update the documentation. I will encourage dev chat channel to weigh in here.
https://lab.civicrm.org/dev/core/-/issues/686
Make "Amount Statistics" columns optional on Membership Summary report
2022-09-27T05:03:56Z
AllenShaw
Make "Amount Statistics" columns optional on Membership Summary report
Stoob suggests to me that many of his clients find these columns confusing. Seems like it would be helpful to make them optional, even if enabled by default.
Stoob suggests to me that many of his clients find these columns confusing. Seems like it would be helpful to make them optional, even if enabled by default.
AllenShaw
AllenShaw
https://lab.civicrm.org/dev/core/-/issues/688
Contacts -> New Email give Unknown Error in Smarty when Allow Mail to be sent...
2019-03-21T08:26:23Z
spalmstrom
Contacts -> New Email give Unknown Error in Smarty when Allow Mail to be sent from logged in contact's email address disabled
I raised this issue in [StackExchange](https://civicrm.stackexchange.com/questions/27901/contacts-new-email-give-unknown-error-in-smarty-when-allow-mail-to-be-sent-fr) some time ago, but didn't get a response. I was able to reproduce it...
I raised this issue in [StackExchange](https://civicrm.stackexchange.com/questions/27901/contacts-new-email-give-unknown-error-in-smarty-when-allow-mail-to-be-sent-fr) some time ago, but didn't get a response. I was able to reproduce it in one of the demo sites: [https://civicrm.demo.civihosting.com/civicrm/activity/email/add?atype=3&action=add&reset=1&context=standalone](https://civicrm.demo.civihosting.com/civicrm/activity/email/add?atype=3&action=add&reset=1&context=standalone). Basically, if you disable *Allow Mail to be sent from logged in user*, you see the error. It will probably arise from *any* disabled Boolean setting as it is generated when a request for a setting value returns FALSE. The 'offending' line is 54 in …/CRM/Core/Smarty/plugins/function.crmSetting.php. Lines 52-57 read:
```
$result = civicrm_api('setting', 'getvalue', $params);
unset($errorScope);
if ($result === FALSE) {
$smarty->trigger_error("Unknown error");
return NULL;
}
```
So, *any* setting returning FALSE will trigger the error. Replacing line 54 with
if ($result === null)
cures the issue, but what other effects does it have?
I am running CiviCRM 5.9.1 under Joomla.
5.13.0
https://lab.civicrm.org/dev/core/-/issues/692
Unable to use url search arguments in 'Advanced Search' using force=1
2023-02-25T05:03:38Z
Monish Deb
Unable to use url search arguments in 'Advanced Search' using force=1
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...
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.11
Monish Deb
Monish Deb
https://lab.civicrm.org/dev/core/-/issues/693
On contact summary page, on submitting a 'New Case' form doesn't redirect to ...
2019-02-04T22:04:19Z
Monish Deb
On contact summary page, on submitting a 'New Case' form doesn't redirect to 'Manage Case' screen
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 '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 submit
5.11
Monish Deb
Monish Deb
https://lab.civicrm.org/dev/core/-/issues/695
Custom Search results selection failure
2019-02-05T04:27:09Z
ayduns
aidan.saunders@squiffle.uk
Custom Search results selection failure
Symptom: When viewing custom search results, it is possible to select all records, but individual selections do not change the count and enable action dropdowns. This does not occur for all custom searches.
Analysis: The selections are...
Symptom: When viewing custom search results, it is possible to select all records, but individual selections do not change the count and enable action dropdowns. This does not occur for all custom searches.
Analysis: The selections are saved by `CRM_Core_PrevNextCache_Sql::markSelection()` which updates the prevnext cache. However, if the results are not already in the prevnext cache, the selections are not saved. The cache is filled by `CRM_Contact_Selector::fillupPrevNextCache()` which it does by taking the result of the custom search's `contactIDs()` method and doing a string replace to form the query used for the cache and if the string replace fails, no results are saved in the cache and therefore individual results cannot be selected.
The string replacement method is case sensitive, so if the custom search specifies `contact_a.id as contact_id` then the replacement works, but specifying `contact_a.id AS contact_id` fails.
The whole approach seems rather fragile but making the string replacement case insensitive reduces that slightly, and hopefully saves developer frustration trying to track down why an innocuous select statement case change results in UI failures.
5.10
ayduns
aidan.saunders@squiffle.uk
ayduns
aidan.saunders@squiffle.uk
https://lab.civicrm.org/dev/core/-/issues/696
Changes to copied event phone and email reflects in original event phone and ...
2019-02-19T07:07:11Z
yashodha
Changes to copied event phone and email reflects in original event phone and email
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 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 listed
5.12.0
yashodha
yashodha