CiviCRM Core issues
https://lab.civicrm.org/dev/core/-/issues
2021-08-08T14:42:02Z
https://lab.civicrm.org/dev/core/-/issues/707
Not all search fields are respected on batch transaction listing search form
2021-08-08T14:42:02Z
Pradeep Nayak
pradpnayak@gmail.com
Not all search fields are respected on batch transaction listing search form
The Financial batch transaction listing search uses Find contribution form however but is limited to only few sets of filter in code
```
$searchFields = array(
'sort_name',
'financial_type_id',
'contribution_page_id',
...
The Financial batch transaction listing search uses Find contribution form however but is limited to only few sets of filter in code
```
$searchFields = array(
'sort_name',
'financial_type_id',
'contribution_page_id',
'contribution_payment_instrument_id',
'contribution_trxn_id',
'contribution_source',
'contribution_currency_type',
'contribution_pay_later',
'contribution_recurring',
'contribution_test',
'contribution_thankyou_date_is_not_null',
'contribution_receipt_date_is_not_null',
'contribution_pcp_made_through_id',
'contribution_pcp_display_in_roll',
'contribution_date_relative',
'contribution_amount_low',
'contribution_amount_high',
'contribution_in_honor_of',
'contact_tags',
'group',
'contribution_date_relative',
'contribution_date_high',
'contribution_date_low',
'contribution_check_number',
'contribution_status_id',
'financial_trxn_card_type_id',
'financial_trxn_pan_truncation',
);
```
[PR#13556](https://github.com/civicrm/civicrm-core/pull/13556) holds refactoring of how this transaction are searched to use core function to generate query for contribution with any filters.
5.40.1
https://lab.civicrm.org/dev/core/-/issues/705
Disabling Alphabetical Pager is not respected for events and contribution pages.
2019-05-07T20:27:12Z
yashodha
Disabling 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.0
yashodha
yashodha
https://lab.civicrm.org/dev/core/-/issues/703
Event Registration Confirmation Email missing Custom Location Type Field Data
2024-02-27T05:03:25Z
joegl
Event Registration Confirmation Email missing Custom Location Type Field Data
**Environment**
CiviCRM 5.9.1 with Drupal 7. Have enabled the following permissions for all drupal users: access all custom data, profile create, register for events, view event info, view event participants. We have a custom "Location T...
**Environment**
CiviCRM 5.9.1 with Drupal 7. Have enabled the following permissions for all drupal users: access all custom data, profile create, register for events, view event info, view event participants. We have a custom "Location Type" called "EditedInfo" and a custom profile called "Registration Information" -- the EditedInfo Location Type is set as the default, if it makes a difference. The profile has the default "Your Registration Information" First and Last name fields (Individual - Primary), and the rest of the fields (Email, Phone, Address, etc.,) are of Type "Contact - EditedInfo".
**Problem**
When a user/contact registers for an event everything works flawlessly -- the values for the "EditedInfo" are copied correctly to their fields on the Contact record, the registration occurs and a confirmation email is sent. However, the email has blanks where the values for all the "EditedInfo" information should be. The labels are there, so the template is recognizing the fields, but the values are empty.
**Troubleshooting**
I assumed it was a permissions issue, but I could not get it solved by toggling various permissions on/off. I am not sure what else to look for at this point. I have also switched these "EditedInfo" fields to regular "Primary" fields, and they are successfully included in the email. However, this is undesirable from the CiviCRM administrators perspective and they'd like to use the "EditedInfo" Location Type fields.
Thanks!
https://lab.civicrm.org/dev/core/-/issues/700
Advanced Search: The reason of failed search result is not displayed, when a ...
2019-05-09T21:46:30Z
Pradeep Nayak
pradpnayak@gmail.com
Advanced Search: The reason of failed search result is not displayed, when a contact with the matching Contact ID was not found
Steps:
* Click "View contact record"
* Click "Search" -> "Advanced Search"
* Enter e.g. '123' (non-existent) to "Basic Criteria" -> "Contact ID"
* Click "Search"
* Take a look at the result report (No matches found for)
**Actual resul...
Steps:
* Click "View contact record"
* Click "Search" -> "Advanced Search"
* Enter e.g. '123' (non-existent) to "Basic Criteria" -> "Contact ID"
* Click "Search"
* Take a look at the result report (No matches found for)
**Actual result:** The reason of failed search result is not displayed, when a contact with the matching Contact ID was not found.
**Expected result:** The reason of failed search result is displayed
![_thumb_10644](/uploads/32278dbc3e7345b4df3570b0cfb6a0e3/_thumb_10644.png)
PR:https://github.com/civicrm/civicrm-core/pull/13549
https://lab.civicrm.org/dev/core/-/issues/697
Reconcile delegated queries for DAO and DynamicFKAuthorization
2022-09-29T05:03:22Z
totten
Reconcile delegated queries for DAO and DynamicFKAuthorization
There are two facilities which are generally designed to check permissions on related entities:
* In the API layer, `DynamicFKAuthorization`
* In the DAO layer, `getSelectWhereClause()` / `addSelectWhereClause()`
These originate in som...
There are two facilities which are generally designed to check permissions on related entities:
* In the API layer, `DynamicFKAuthorization`
* In the DAO layer, `getSelectWhereClause()` / `addSelectWhereClause()`
These originate in somewhat different use-cases, but they generally both need to (a) look at some arbitrary table/entity reference and (b) filter to determine access. There are also some differences (e.g. single-record vs multi-record/batched; read-permission vs write-permission).
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
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/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/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/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/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/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/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/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/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/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/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/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/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/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.