CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2019-08-21T16:48:10Zhttps://lab.civicrm.org/dev/core/-/issues/1061Bad popup on update recurring screen2019-08-21T16:48:10ZeileenBad popup on update recurring screenWe are seeing a popup when checksum users attempt to update a recurring contribution.
![Screenshot_2019-06-12_at_18.50.39](/uploads/85512b40438dcd0e198fddc51dd64c00/Screenshot_2019-06-12_at_18.50.39.png)
This appears to date back to M...We are seeing a popup when checksum users attempt to update a recurring contribution.
![Screenshot_2019-06-12_at_18.50.39](/uploads/85512b40438dcd0e198fddc51dd64c00/Screenshot_2019-06-12_at_18.50.39.png)
This appears to date back to March 2018 when custom data was added to this form (by @mattwire ) - which means we don't need to target the rc & I'm inclined to focus on 'the right fix' on master.
Fundamentally we have a backoffice form that is being exposed for front end users. I have personally proposed doing similar to the 'Add Payment' form recently so it probably bares a little thought. In this case the custom data is not accessible to checksum accessors of the page & superficially the problem is not that it is not available but that it is noisily not available.
I feel like at a conceptual level we probably want to either
1) say front end forms are front end forms and back end forms are back end forms and never the twain shall meet or
2) set the front end form flag whenever a both-use-form is accessed with a checksum
In terms of the custom data I feel the safest option is just to say 'don't expose custom data on both-use forms to users without Access CiviCRM'. If people want to this might not be the right form approach for them - they can actually probably intervene by hook but the risk of exposing inappropriate custom data fields seems real.
This probably also impacts on theming & provides an obvious way not to present un-themed versions of these pages (@seamuslee @totten )5.17.0https://lab.civicrm.org/dev/core/-/issues/1226Smart groups: Relative date filters saved incorrectly2019-09-03T06:50:14ZPradeep Nayakpradpnayak@gmail.comSmart groups: Relative date filters saved incorrectly(*Original title: "Regression: Smart group with Change log criteria is not saved."*)
If you create a smart group which uses a relative date filter (e.g. "Last 60 days" or "This calendar current year"), the relative date filter is not sa...(*Original title: "Regression: Smart group with Change log criteria is not saved."*)
If you create a smart group which uses a relative date filter (e.g. "Last 60 days" or "This calendar current year"), the relative date filter is not saved correctly.
This issue entails two aspects:
1. (*Code update in 5.16.4*) Fix the code so that smart groups are properly saved
2. (*Data cleanup; case-by-case*) Identify any smart-groups which were created or edited in the past month (5.16.x). Determine if they should be updated to use a relative date filter.
The following fields are believed to affected:
* `log_date_relative`
* `pledge_payment_date_relative`
* `pledge_start_date_relative`
* `pledge_end_date_relative`
* `pledge_create_date_relative`
* `member_join_date_relative`
* `member_start_date_relative`
* `member_end_date_relative`
* `birth_date_relative`
* `deceased_date_relative`
* `mailing_date_relative`
* `relation_date_relative`
* `relation_start_date_relative`
* `relation_end_date_relative`
* `relation_action_date_relative`
* `contribution_recur_start_date_relative`
* `contribution_recur_next_sched_contribution_date_relative`
* `contribution_recur_cancel_date_relative`
* `contribution_recur_end_date_relative`
* `contribution_recur_create_date_relative`
* `contribution_recur_modified_date_relative`
* `contribution_recur_failure_retry_date_relative`5.17.0Pradeep Nayakpradpnayak@gmail.comPradeep Nayakpradpnayak@gmail.comhttps://lab.civicrm.org/dev/core/-/issues/1171unreleased regression2019-08-08T01:27:17Zeileenunreleased regressionnew enotices on importing with an import mapping (not to be confused with the pre-existing ones)
https://github.com/civicrm/civicrm-core/pull/14978new enotices on importing with an import mapping (not to be confused with the pre-existing ones)
https://github.com/civicrm/civicrm-core/pull/149785.17.0https://lab.civicrm.org/dev/core/-/issues/1170Fix getLoginURL() for Backdrop2019-08-08T03:16:12ZherbdoolFix getLoginURL() for BackdropBecause of https://github.com/backdrop/backdrop-issues/issues/260, any anonymous visits to `/user` will redirect to `/user/login`. Currently `CRM_Utils_System_Backdrop::getLoginURL()` creates a link to `/user?destination...` and this URL...Because of https://github.com/backdrop/backdrop-issues/issues/260, any anonymous visits to `/user` will redirect to `/user/login`. Currently `CRM_Utils_System_Backdrop::getLoginURL()` creates a link to `/user?destination...` and this URL will automatically try to redirect. And because of Backdrop/Drupal allowing the `?destination` parameter to override other redirects, it will automatically go to that destination instead of staying at `/user` or even `/user/login`
There's probably an easy fix by just changing getLoginURL to point to `/user/login` and no immediate redirect will happen.5.17.0https://lab.civicrm.org/dev/core/-/issues/1135Participants having multiple roles affects maximum event registration count2019-08-05T19:47:12ZDon WijesooriyaParticipants having multiple roles affects maximum event registration countIf you add multiple participant roles for a participant entry, it affects the event full count.
### Steps to reproduce
1. On dmaster, create a new event
2. Enable online registration and set "Max Number of Participants" to 1
3. Go to l...If you add multiple participant roles for a participant entry, it affects the event full count.
### Steps to reproduce
1. On dmaster, create a new event
2. Enable online registration and set "Max Number of Participants" to 1
3. Go to live event registration page. You should be able to register
4. Now add a new registration to a different contact from backend.
5. Once again go to live event registration page. Now it should show the event full message.
6. Go back to the other contact's events. Edit the event participant entry and add another role such as "Host".
7. Now go to the event registration page and you will be able to register for the maxed out event
### Issue
After inspecting `CRM_Event_BAO_Participant::eventFull()` the following line assumes there will only be one value in the field
````php
$where[] = " participant.role_id IN ( '" . implode("', '", $escapedRoles) . "' ) ";
````
Therefore when you have multiple values it won't work properly.
### Solution
I used regular expression code that's used in `CRM_Event_BAO_Query::whereClauseSingle()` under `case 'participant_role_id'`. This is a simple workaround I could think of. Haven't tested in all other scenarios.
````php
$regexp = "([[:cntrl:]]|^)" . implode('([[:cntrl:]]|$)|([[:cntrl:]]|^)', $escapedRoles) . "([[:cntrl:]]|$)";
$where[] = " participant.role_id REGEXP '{$regexp}'";
````5.17.0https://lab.civicrm.org/dev/core/-/issues/1118Case summary report filters incorrectly for case type2019-07-21T23:07:54ZDeepak SrivastavaCase summary report filters incorrectly for case typeCase summary report uses REGEXP filtering for case type:
`WHERE case_civireport.case_type_id REGEXP '[[:cntrl:]]*5[[:cntrl:]]*' `
Which results in records where case type id consists of 5 (for this example).
![image](/uploads/485a42f6d...Case summary report uses REGEXP filtering for case type:
`WHERE case_civireport.case_type_id REGEXP '[[:cntrl:]]*5[[:cntrl:]]*' `
Which results in records where case type id consists of 5 (for this example).
![image](/uploads/485a42f6d595079ce990816695e1b4a6/image.png)
The clause looks old and appears to be based on assumption that case could be based on multiple case types. Case type however is an integer column and could use where() clause of CRM/Report/Form.php.
The problem also been raised on stack exchange - https://civicrm.stackexchange.com/questions/30573/case-type-filter-bug-in-case-summary-report-multiple-case-types-reported.
A PR would follow.5.17.0https://lab.civicrm.org/dev/core/-/issues/1109Contact Reference fields are not updated when merging contacts2019-08-08T03:27:12ZPatrick Figelpfigel@greenpeace.orgContact Reference fields are not updated when merging contactsWhen contacts are merged, any Contact Reference custom fields pointing to the contact that was deleted will not be updated to point to the remaining contact.
This is not a recent regression. It used to work in 4.6, but was broken at som...When contacts are merged, any Contact Reference custom fields pointing to the contact that was deleted will not be updated to point to the remaining contact.
This is not a recent regression. It used to work in 4.6, but was broken at some point after that. (Confirmed as broken in 5.7, 5.13 and master.)5.17.0https://lab.civicrm.org/dev/core/-/issues/961Contribution page including 2 email fields does not respect dedupe rule.2019-08-02T01:27:13ZjitendraContribution page including 2 email fields does not respect dedupe rule.Unsupervised rule fails if we have 2 email fields to match on with latter set as empty. To replicate -
- Add a profile with first name, last name, billing email and work email.
- Create a contact with first name = "Test", Last name = "D...Unsupervised rule fails if we have 2 email fields to match on with latter set as empty. To replicate -
- Add a profile with first name, last name, billing email and work email.
- Create a contact with first name = "Test", Last name = "Dedupe" and email = "test@example.com"
- Add the profile to a contribution page.
- Submit the contribution page anonymously and enter First name = Test, Last name = "Dedupe" and billing email = "test@example.com". Keep work email as empty.
- Complete the payment.
![image](/uploads/43e2533c1a6f37dc9251b380755ca0f9/image.png)
- The payment should be recorded against the existing contact based on dedupe matching.
- As we do not have any value filled for second email field, dedupe fails and a new contact is created with same details.5.17.0jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/949Export table field size is inadequate for State/Province data values2019-08-06T20:35:08ZorigamiusaExport table field size is inadequate for State/Province data valuesExporting a custom data field of type State/Province crashes with a db error "Data too long for column" if the State/Province has a long name (example: no crash with "Massachusetts", but crash with "District of Columbia"). The temporary ...Exporting a custom data field of type State/Province crashes with a db error "Data too long for column" if the State/Province has a long name (example: no crash with "Massachusetts", but crash with "District of Columbia"). The temporary table is created with a column size of varchar(16), presumably because the State/Province key is stored as a LONG; but the exported quantity is the value, which could be of arbitrary length (and certainly includes examples longer than 16 characters in normal usage).
This appears to be a similar issue to https://lab.civicrm.org/dev/core/issues/181 and https://lab.civicrm.org/dev/core/issues/877.5.17.0https://lab.civicrm.org/dev/core/-/issues/578Fatal db error in Activity Summary report for some Sorting fields (with ONLY_...2019-07-09T20:07:12ZdavejFatal db error in Activity Summary report for some Sorting fields (with ONLY_FULL_GROUP_BY)A fatal db error occurs in Activity Summary report for some Sorting fields. This occurs only with ONLY_FULL_GROUP_BY set in sql_mode.
Steps to replicate:
1. From the standard pre-defined Contact Reports, go to Activity Summary.
2. Le...A fatal db error occurs in Activity Summary report for some Sorting fields. This occurs only with ONLY_FULL_GROUP_BY set in sql_mode.
Steps to replicate:
1. From the standard pre-defined Contact Reports, go to Activity Summary.
2. Leave Columns as default, with Contact Name not checked.
3. Leave Grouping as default (Activity Type + Activity Status).
4. In Sorting, select Contact Name.
5. Click "Refresh results".
Expected result:
Report runs.
Actual result:
```
DB Error: unknown error
Database Error Code: Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'dmasterciv_t1nir.contact_civireport.sort_name' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by, 1055
[debug_info] => INSERT INTO civicrm_activity_temp_a10856f163bac9e54ba4f5f5538d1cbf (civicrm_activity_duration_total)
SELECT SUM(activity_civireport.duration) as civicrm_activity_duration_total
FROM civicrm_activity activity_civireport
LEFT JOIN civicrm_activity_contact target_activity
ON activity_civireport.id = target_activity.activity_id AND
target_activity.record_type_id = 3
LEFT JOIN civicrm_contact contact_civireport
ON target_activity.contact_id = contact_civireport.id
WHERE
activity_civireport.is_test = 0 AND
activity_civireport.is_deleted = 0 AND
activity_civireport.is_current_revision = 1 GROUP BY activity_civireport.activity_type_id, activity_civireport.status_id ORDER BY contact_civireport.sort_name ASC LIMIT 0, 50 [nativecode=1055 ** Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'dmasterciv_t1nir.contact_civireport.sort_name' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by]
```
The error also happens for various other combinations of Columns, Grouping & Sorting.
Occurs in current dmaster with MySQL 5.7.23, when ONLY_FULL_GROUP_BY set in sql_mode.5.17.0https://lab.civicrm.org/dev/core/-/issues/577Fatal db error in Activity Summary report when Sorting uses Section Header (w...2019-07-07T05:16:06ZdavejFatal db error in Activity Summary report when Sorting uses Section Header (without ONLY_FULL_GROUP_BY)A fatal db error occurs in Activity Summary report when sorting by a field that has not been selected in Columns, if Section Header is checked. This occurs with or without ONLY_FULL_GROUP_BY.
Steps to replicate:
1. From the standard p...A fatal db error occurs in Activity Summary report when sorting by a field that has not been selected in Columns, if Section Header is checked. This occurs with or without ONLY_FULL_GROUP_BY.
Steps to replicate:
1. From the standard pre-defined Contact Reports, go to Activity Summary.
2. Leave Columns as default, with Contact Name not checked.
3. Leave Grouping as default (Activity Type + Activity Status).
4. In Sorting, select Contact Name and check "Section Header / Group By".
5. Click "Refresh results".
Expected result:
Report runs.
Actual result:
```
DB Error: value count on row
Database Error Code: Column count doesn't match value count at row 1, 1136
[debug_info] => INSERT INTO civicrm_activity_temp_319632dc20cdeda8063b99ed6caaec62 ( civicrm_contact_id,civicrm_activity_activity_type_id,civicrm_activity_status_id,civicrm_activity_duration,civicrm_activity_id_count )
SELECT contact_civireport.id as civicrm_contact_id, activity_civireport.activity_type_id as civicrm_activity_activity_type_id, activity_civireport.status_id as civicrm_activity_status_id, activity_civireport.duration as civicrm_activity_duration, COUNT(DISTINCT(activity_civireport.id)) as civicrm_activity_id_count , contact_civireport.sort_name as civicrm_contact_sort_name
FROM civicrm_activity activity_civireport
LEFT JOIN civicrm_activity_contact target_activity
ON activity_civireport.id = target_activity.activity_id AND
target_activity.record_type_id = 3
LEFT JOIN civicrm_activity_contact assignment_activity
ON activity_civireport.id = assignment_activity.activity_id AND
assignment_activity.record_type_id = 1
LEFT JOIN civicrm_activity_contact source_activity
ON activity_civireport.id = source_activity.activity_id AND
source_activity.record_type_id = 2
LEFT JOIN civicrm_contact contact_civireport
ON target_activity.contact_id = contact_civireport.id
LEFT JOIN civicrm_contact civicrm_contact_assignee
ON assignment_activity.contact_id = civicrm_contact_assignee.id
LEFT JOIN civicrm_contact civicrm_contact_source
ON source_activity.contact_id = civicrm_contact_source.id
LEFT JOIN civicrm_option_value
ON ( activity_civireport.activity_type_id = civicrm_option_value.value )
LEFT JOIN civicrm_option_group
ON civicrm_option_group.id = civicrm_option_value.option_group_id
LEFT JOIN civicrm_case_activity
ON civicrm_case_activity.activity_id = activity_civireport.id
LEFT JOIN civicrm_case
ON civicrm_case_activity.case_id = civicrm_case.id
LEFT JOIN civicrm_case_contact
ON civicrm_case_contact.case_id = civicrm_case.id WHERE civicrm_option_group.name = "activity_type" AND
activity_civireport.is_test = 0 AND
activity_civireport.is_deleted = 0 AND
activity_civireport.is_current_revision = 1 GROUP BY activity_civireport.activity_type_id, activity_civireport.status_id ORDER BY contact_civireport.sort_name ASC LIMIT 0, 50 [nativecode=1136 ** Column count doesn't match value count at row 1]
```
Occurs in Civi 5.5.1 with MariaDB 10.1.34 or 10.1.37; also in current dmaster with MySQL 5.7.23 .
Note that dev/core/issues/428 reported an error in similar circumstances for the Activity Detail report but the error details are different and the error occurs at a different stage: here in INSERT INTO civicrm_activity_temp_XXX, there in a SELECT query.5.17.0https://lab.civicrm.org/dev/core/-/issues/439Contact Reference Field Cutoff on Export2019-08-04T18:55:16ZhershelContact Reference Field Cutoff on ExportOn a brand new Drupal 7 / CiviCRM 5.6.0 install I created a custom field group for Grants and added one Contact Reference field and then created 2 grants. When I search for grants and export and try to export that Contact Reference field...On a brand new Drupal 7 / CiviCRM 5.6.0 install I created a custom field group for Grants and added one Contact Reference field and then created 2 grants. When I search for grants and export and try to export that Contact Reference field, the name of the Contact is limited to 16 characters.
Further testing indicates that the name of a Contact Reference field on a Contact record also is limited to 16 characters when exported.
First reported here: https://civicrm.stackexchange.com/questions/26835/grant-export-custom-field-cutoff5.17.0