Development issueshttps://lab.civicrm.org/groups/dev/-/issues2019-12-02T04:47:10Zhttps://lab.civicrm.org/dev/core/-/issues/1434DB error in Mail Clickthroughs bar chart display2019-12-02T04:47:10ZxurizaemonDB error in Mail Clickthroughs bar chart displayOverview
----------------------------------------
When viewing the Mail Clickthroughs report, the table view works but the bar chart view does not.
Reproduction steps
----------------------------------------
1. Log into demo & view http...Overview
----------------------------------------
When viewing the Mail Clickthroughs report, the table view works but the bar chart view does not.
Reproduction steps
----------------------------------------
1. Log into demo & view https://dmaster.demo.civicrm.org/civicrm/report/instance/35
2. Select "Bar chart" display
3. Click View
Current behaviour
----------------------------------------
Error will read "Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred."
The SQL which fails is:
```sql
SELECT contact_civireport.id as civicrm_contact_id, contact_civireport.sort_name as civicrm_contact_sort_name, mailing_civireport.name as civicrm_mailing_mailing_name, mailing_civireport.name as civicrm_mailing_mailing_name_alias, email_civireport.email as civicrm_email_email, mailing_trackable_url_civireport.url as civicrm_mailing_trackable_url_url, COUNT(.id) as civicrm_mailing_click_count
FROM civicrm_contact contact_civireport
INNER JOIN civicrm_mailing_event_queue
ON civicrm_mailing_event_queue.contact_id = contact_civireport.id
LEFT JOIN civicrm_email email_civireport
ON civicrm_mailing_event_queue.email_id = email_civireport.id
INNER JOIN civicrm_mailing_event_trackable_url_open mailing_event_trackable_url_open_civireport
ON mailing_event_trackable_url_open_civireport.event_queue_id = civicrm_mailing_event_queue.id
INNER JOIN civicrm_mailing_trackable_url mailing_trackable_url_civireport
ON mailing_event_trackable_url_open_civireport.trackable_url_id = mailing_trackable_url_civireport.id
INNER JOIN civicrm_mailing_job
ON civicrm_mailing_event_queue.job_id = civicrm_mailing_job.id
INNER JOIN civicrm_mailing mailing_civireport
ON civicrm_mailing_job.mailing_id = mailing_civireport.id
AND civicrm_mailing_job.is_test = 0
WHERE ( 1 ) AND mailing_civireport.sms_provider_id IS NULL GROUP BY mailing_civireport.id
```
The error message is:
> You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ') as civicrm_mailing_click_count
Looks like the culprit is generating `COUNT(.id) as civicrm_mailing_click_count`
Expected behaviour
----------------------------------------
The report should show as a beautiful bar graph.
(I've never seen this bar chart, I'm reporting the issue on behalf of a community user.)
Environment information
----------------------------------------
* __CiviCRM:__ 5.19.3, verified on https://dmaster.demo.civicrm.org/
* __PHP:__ 7.2
* __CMS:__ Drupal 7
* __Database:__ 10.1.43-MariaDB-0ubuntu0.18.04.15.21.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/1405CiviCRM Option Group with a name containing spaces cannot have any options ad...2019-12-02T06:07:08Zjustinfreeman (Agileware)CiviCRM Option Group with a name containing spaces cannot have any options added, error message is shown also impacts the in-place option editorCiviCRM Option Group with a name containing spaces cannot have any options added, error message is shown also impacts the in-place option editor.
The Name field is mandatory on an Option Group and no guidance is given to the user about ...CiviCRM Option Group with a name containing spaces cannot have any options added, error message is shown also impacts the in-place option editor.
The Name field is mandatory on an Option Group and no guidance is given to the user about what value should be entered. No validation is performed on this field to prevent an invalid value from being entered.
The workaround is to **remove the spaces from the Name field value**.
Bug is shown in the screen recording below. Reproduced on CiviCRM 5.21.alpha1 - https://dmaster.demo.civicrm.org/
Agileware Ref: CIVICRM-1373
![in-place-editor-option-group](/uploads/ff54799f03f1af4926c1692548ab2d28/in-place-editor-option-group.png)
![jKq5sOxNx2](/uploads/542b18ecfe68ab3d957f00eda58ecc32/jKq5sOxNx2.gif)5.21.0justinfreeman (Agileware)justinfreeman (Agileware)https://lab.civicrm.org/dev/core/-/issues/1411Can't search for activity subjects starting with 1 - and many more caching is...2019-12-02T18:54:32ZJonGoldCan't search for activity subjects starting with 1 - and many more caching issuesOverview
----------------------------------------
Due to how the query that fills the SQL cache is built, it fails under some very common circumstances. Some of those are hidden by the fact that Civi will fall back to an uncached search...Overview
----------------------------------------
Due to how the query that fills the SQL cache is built, it fails under some very common circumstances. Some of those are hidden by the fact that Civi will fall back to an uncached search; some simply show no results.
Reproduction steps
----------------------------------------
1. Create a new activity with a subject of `12345`.
1. On **Advanced Search**, search **Activity Text** for `12345`.
1. Observe no results found.
1. Search **Activity Text** for `2345`.
1. Observe the the activity is found.
Why this happens
----------------------------------------
* The SQL created is something like `SELECT contact_a.id FROM civicrm_activity WHERE activity_subject like '%12345%'`.
* `CRM_Contact_Selector` has [this code snippet](https://github.com/civicrm/civicrm-core/blob/cf70a3eee02b1f46b23435b882d261fd400713b0/CRM/Contact/Selector.php#L1042-L1046) which replaces `SELECT contact_a.id` with `"SELECT DISTINCT %1, contact_a.id, contact_a.sort_name"`, which yields `SELECT DISTINCT %1, contact_a.id, contact_a.sort_name FROM civicrm_activity WHERE activity_subject like '%12345%'`.
* It then passes this SQL to a function that does variable substitution - but the `%1` in `%12345%` gets substituted with the cache key!
This problem manifests with any Advanced Search field that prepends a wildcard (`%`) to the form value. However, if you search for a contact named `12345` the search will still complete, because there's a fallback query in case of exceptions.
Additional Note(s)
----------------------------------------
I'm going to break my PR into two parts to make it easier to review. The first part will deal with the bug itself; I'll follow up with a cleanup PR to simplily the `fillWithSQL` signature.
The `fillWithSQL` method is only called in [one other place in the code](https://github.com/civicrm/civicrm-core/blob/1cf214fd05844767bb1b9587cca796ac47102042/CRM/Campaign/Selector/Search.php#L268-L274), in CiviCampaign. However, this query ALWAYS fails, because it puts `FROM` twice in a row. So this will always fail to populate the cache.5.21.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/530Make a_b relationships available as case roles2019-12-02T19:31:10ZalicefruminMake a_b relationships available as case rolesCurrently one can only create case roles for CiviCRM Cases that are one direction (one only sees the options label_b_a). See screen shot below that shows the "New Case Type" Ui with the options for "add role" open (they are all label_b_a...Currently one can only create case roles for CiviCRM Cases that are one direction (one only sees the options label_b_a). See screen shot below that shows the "New Case Type" Ui with the options for "add role" open (they are all label_b_a) as one can see by checking against the Relationship Type table next to it.
![relTypesNewCaseType](/uploads/193cce5a0e6d7c395b8003e3c4593241/relTypesNewCaseType.png)
We are proposing making it so users can choose from the full list of relationships (label_a_b and label_b_a).
Rationale:
---------
1. There could be scenarios where cases should be set up to have case roles in any direction. For example.. an intergenerational case where its children taking care of parents vs a school case where its parents taking care of kids.
2. Jira issue [CRM-19754](https://issues.civicrm.org/jira/browse/CRM-19754) suggests that the options available should be label_a_b. One pr to make this change was accepted [pr 9560](https://github.com/civicrm/civicrm-core/pull/9560) a second [pr 9975](https://github.com/civicrm/civicrm-core/pull/9975) was closed due to in action and incompleteness. Making the Case Types bidirectional would solve the bugs documented in [pr 9975](https://github.com/civicrm/civicrm-core/pull/9975) without a fix up script.
Bugs this change fixes:
----------------------
1) when creating a case type, you can only select B-to-A labels
![image_1_](/uploads/11c127df30b22761b5653353534484da/image_1_.png)
then after creating a case you see the B-to-A "Parent of" label
![image_2_](/uploads/01922f80d41cd2fe8bb227d73d5e36c0/image_2_.png)
after picking the contact, the label becomes the A-to-B "Child of"
![image_4_](/uploads/a29e1194dd5af9c0b64d5945bd1ccf4f/image_4_.png)
2) When viewing a case, the Roles drop-down, only shows the labels in the B to A direction, but when one assigns the case role in the B to A direction the label displayed is in the A to B direction.
3) When editing a Case Activity in the "Send a copy" the role is correct but the label is wrong.
4) Currently, all relationships are showing the B contact, regardless of who the client is
yet they all have the B-to-A label, regardless of who the client is for example:
![Screenshot_2019-03-29_Dr_Rebekah_Cooper_-_Housing_Support_grantdetailreport](/uploads/e00afec39078c45673ab2b7f1cc0c252/Screenshot_2019-03-29_Dr_Rebekah_Cooper_-_Housing_Support_grantdetailreport.png)
In this example Rebekah is the client, and the case has her as the parent of Kathleen and the child of Carylon. In the send a copy box, she's shown as parent of Carylon and her relationship w/ Kathleen is displayed as her being parent of herself.
5) when reassigning a case role that is B-to-A (where the client is on the B side of the relationship), the list of available contacts is the contact type of the B side
since households and organizations are frequently on the B side of a relationship, this makes it difficult-to-impossible to manage a case where the client is a household or organization
![reassign](/uploads/9d71615554a0e1a15a0b6776ab9aac45/reassign.png)
Places in the Code that would need to be adjusted:
-----------------------------------------------
+ CRM/Report/Form/Case/Summary.php
+ CRM/Report/Form/Case/Detail.php
+ CRM/Case/XMLProcessor/Process.php
+ CRM/Case/XMLProcessor.php
+ CRM/Case/ManagedEntities.php
+ CRM/Case/BAO/Query.php
+ CRM/Case/BAO/Case.php
+ ang/crmCaseType.js5.16.0https://lab.civicrm.org/dev/core/-/issues/389When using custom fields for smart group criteria with relative dates the gro...2019-12-03T07:22:12ZjasonobrownWhen using custom fields for smart group criteria with relative dates the group does not respect the relative date over timeIf you create a smart group using the relative (dynamic, rolling, "this week", etc...) dates for a custom field, once you save the smart group the dates are no longer relative. It creates/updates the group with static dates that match yo...If you create a smart group using the relative (dynamic, rolling, "this week", etc...) dates for a custom field, once you save the smart group the dates are no longer relative. It creates/updates the group with static dates that match your relative dates at the time you save it.
https://issues.civicrm.org/jira/browse/CRM-20499e5.8https://lab.civicrm.org/dev/core/-/issues/1166Update Country list: change Macedonia, Republic of into North Macedonia2019-12-03T08:07:43ZBetty DolfingUpdate Country list: change Macedonia, Republic of into North MacedoniaI understand ([see stackexchange question](https://civicrm.stackexchange.com/questions/31577/countries-up-to-date)) that the country list in CiviCRM is [maintained manually](https://github.com/civicrm/civicrm-core/blob/5.15.2/xml/templat...I understand ([see stackexchange question](https://civicrm.stackexchange.com/questions/31577/countries-up-to-date)) that the country list in CiviCRM is [maintained manually](https://github.com/civicrm/civicrm-core/blob/5.15.2/xml/templates/civicrm_country.tpl#L172).
In the iso 3166-1 list, Macedonia, Republic of is now called: **North Macedonia**
Can this be changed in the country list in CiviCRM?5.21.0seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/523Lybunt report - remove broken chart functionality2019-12-03T08:17:20ZeileenLybunt report - remove broken chart functionalityI'd like to propose removing the broken chart functionality from the lybunt report
There is a general level of brokenness with Charts in Civi (Luciano has a promising replacement option here https://lab.civicrm.org/partners/ixiam/report...I'd like to propose removing the broken chart functionality from the lybunt report
There is a general level of brokenness with Charts in Civi (Luciano has a promising replacement option here https://lab.civicrm.org/partners/ixiam/reportplus/blob/2.x/CRM/Reportplus/Utils/ChartJS.php#L8)
But for Lybunt it appears to be specifically & extra broken & this appears to be non-recent.
I propose that we remove the support for charts from this report. I've had a look & I can see nothing about the existing code that would make it easier to get the charts working again at some later point if we went that way (although I suspect we should be looking at something more robust that this report if we want to put that effort in)
![Screenshot_2018-11-15_13.24.44](/uploads/f655a0f7d8dde1c69375e6860863dafc/Screenshot_2018-11-15_13.24.44.png)![Screenshot_2018-11-15_13.24.48](/uploads/97a947046e4b52ed4848ac69dd9d7c91/Screenshot_2018-11-15_13.24.48.png)5.21.0seamusleeseamusleehttps://lab.civicrm.org/dev/financial/-/issues/96Unreleased regression - fatal when recording part-payment against a pending c...2019-12-04T05:45:51ZeileenUnreleased regression - fatal when recording part-payment against a pending contribution (conditions apply)Our just-merged fix on line item allocation hits an issue when there are no financial items as it turns out.
Per https://github.com/civicrm/civicrm-dev-docs/issues/712 for historical (and perhaps unwise) reasons there are circumstances ...Our just-merged fix on line item allocation hits an issue when there are no financial items as it turns out.
Per https://github.com/civicrm/civicrm-dev-docs/issues/712 for historical (and perhaps unwise) reasons there are circumstances where line items are created with no financial items. We need to handle that in the payment.create function. I hope to look tomorrow
FYI @kcristianohttps://lab.civicrm.org/dev/core/-/issues/1435Membership and Event Related Contributions - shows all contributions2019-12-05T03:06:22Zaydunsaidan.saunders@squiffle.ukMembership and Event Related Contributions - shows all contributionsOverview
----------------------------------------
When viewing a membership or participant record, the related contributions show *all* contributions, not those related to the membership.
Reproduction steps
-----------------------------...Overview
----------------------------------------
When viewing a membership or participant record, the related contributions show *all* contributions, not those related to the membership.
Reproduction steps
----------------------------------------
1. Go to a contact's Memberships tab. (Or Events tab)
1. Click View on the Membership (Or Event)
Current behaviour
----------------------------------------
Observe that the 'Related Contributions' shows all contributions, not just those related to the membership/event.
Expected behaviour
----------------------------------------
Related Contributions should only show those related to the membership.
Comments
----------------------------------------
This used to work correctly - eg in 5.18.4
The membership view uses CRM_Contribute_Form_Search and passes a `contactId` and `memberId`. The handling of forced searches and the use of `$this->_formValues` in CRM_Contribute_Form_Search and CRM_Core_Form_Search has changed with the result that `memberId` is not passed into the query.
In https://github.com/civicrm/civicrm-core/blob/5.18/CRM/Contribute/Form/Search.php#L108 forced searches are performed after `$this->_formValues['contribution_membership_id']` is set at https://github.com/civicrm/civicrm-core/blob/5.18/CRM/Contribute/Form/Search.php#L101
The forced search is now carried out in `parent::preProcess()`. Retrieving `memberId` from the URL needs to happen somewhere before the query. Note that with the changes to setFormValues(), getFormValues() just assigning to `$this->_formValues['contribution_membership_id']` is not the right approach. The question (probably for @eileen) is what the right approach is now.
The issue applies to `participantId` and events.5.19.4https://lab.civicrm.org/dev/core/-/issues/1426Manager/Creator Information not being returned for case related contacts when...2019-12-05T04:47:50Ztunbola@compucorp.co.ukManager/Creator Information not being returned for case related contacts when fetching Case DetailsOverview
----------------------------------------
When Fetching a case details e.g by calling the Case.get API, related contacts are returned with extra information returned for
creators and managers (see: https://github.com/civicrm/civ...Overview
----------------------------------------
When Fetching a case details e.g by calling the Case.get API, related contacts are returned with extra information returned for
creators and managers (see: https://github.com/civicrm/civicrm-core/blob/master/CRM/Case/BAO/Case.php#L1198)
e.g
```php
{
"contacts": [
{
"contact_id": "2",
"display_name": "Tetss ssss",
"sort_name": "ssss, Tetss",
"relationship_type_id": "11",
"role": "Case Coordinator is",
"email": "admin@example.com",
"phone": "",
"manager": "1" //Manager details added here. Part of extra information for case related contacts
}
]
}
```
## Issue
When saving sase soles for a case type, It is the reverse relationship type that gets saved for the case type. e.g if the case role label`_b_a` is displayed as the option label relationship type when
adding a case role to a case type, when this gets saved, it is actually the name`_a_b` that get saved in the database for that relationship type
![Housing_Support__CiviCase_2019-11-27_18-02-55](/uploads/5997bf68db91a67c4c655898bf63d751/Housing_Support__CiviCase_2019-11-27_18-02-55.png)
Please see the code that generates the relationship type options used for this screen here: https://github.com/civicrm/civicrm-core/blob/master/ang/crmCaseType.js#L335-L338
Not sure why the order is reversed as this seems [intentional](https://github.com/civicrm/civicrm-core/blob/master/ang/crmCaseType.js#L328). However this has some **implications:**
When calling the Case.get API, it returns related contacts along with the API results. It should also add the details or more info about the role (creator, manager) for applicable contacts also, so that for contacts that has a manager role, the `manager => 1` is returned along with the contact information, this helps identify the manager quickly. https://github.com/civicrm/civicrm-core/blob/master/api/v3/Case.php#L626
However this line here (https://github.com/civicrm/civicrm-core/blob/master/CRM/Case/BAO/Case.php#L1199) returns a NULL even when there is a valid case
manager for the case and as such the extra information is not added. The reason is that the `$CaseRoles` array here(https://github.com/civicrm/civicrm-core/blob/master/CRM/Case/BAO/Case.php#L1138) fetches the case roles stored in the case type definition which is fine but the results of the query returns the role name that does not match what is stored for the case role.
Reproduction steps
----------------------------------------
For example for the default relationship type that ships with civicrm
Name AB = Case Coordinator is
Label AB = Case Coordinator is
Name BA = Case Coordinator
Label BA = Case Coordinator
If I add this relationship type as a case role and as manager i.e as `Case Coordinator is` (Name AB) for a case type, it is the (Case Coordinator) that gets saved in the definition column in case_type table. If I then assign a contact as the (Case Coordinator is) for a contact (client) then create a new case with this contact as the case client.
Current behaviour
----------------------------------------
When I try to get the Case Details for this case, when this query is ran https://github.com/civicrm/civicrm-core/blob/master/CRM/Case/BAO/Case.php#L1142-L1176, it returns the `Case Coordinator is` as the role name for the related contact which is fine but this line
https://github.com/civicrm/civicrm-core/blob/master/CRM/Case/BAO/Case.php#L1199 returns NULL because what is saved in the case definition is the reverse relationship name i.e (`Case Coordinator`) hence, the extra details is not added for the contact.
```php
{
"contacts": [
{
"contact_id": "2",
"display_name": "Tetss ssss",
"sort_name": "ssss, Tetss",
"relationship_type_id": "11",
"role": "Case Coordinator is",
"email": "admin@example.com",
"phone": "",
}
]
}
```
In previous versions of Civicrm e.g `5.15`, the relationship type options were not swapped and this functionality worked fine, see https://github.com/civicrm/civicrm-core/blob/5.15/ang/crmCaseType.js#L266-L295
Expected behaviour
----------------------------------------
When I try to get the Case Details for this case, the extra details such as `manager => 1` should be added for the Contact who is the Case Coordinator for the Client.
```php
{
"contacts": [
{
"contact_id": "2",
"display_name": "Tetss ssss",
"sort_name": "ssss, Tetss",
"relationship_type_id": "11",
"role": "Case Coordinator is",
"email": "admin@example.com",
"phone": "",
"manager": "1" //Manager details added here
}
]
}
```5.21.0https://lab.civicrm.org/dev/core/-/issues/1429CiviEvent - can't add event payment if the user already has previous paid events2019-12-05T06:50:32ZRoseLaniganCiviEvent - can't add event payment if the user already has previous paid eventsI have managed to replicate on the demo site:
* Added Brent Adams to one event (Rainforest Soccer) but with no payment
* Edited the event registration to add a payment, and I can see the 'Record payment' checkbox properly and I record a...I have managed to replicate on the demo site:
* Added Brent Adams to one event (Rainforest Soccer) but with no payment
* Edited the event registration to add a payment, and I can see the 'Record payment' checkbox properly and I record a payment - fine
* Added Brent Adams to a second event (Fall Fundraiser Dinner) but with no payment
* Tried to edit this registration and add a payment but there is no 'Record Payment' checkbox this time, and at the bottom of the registration page, it has incorrectly listed the payment for the first event and no ability to record the payment for this event.5.19.4eileeneileenhttps://lab.civicrm.org/dev/core/-/issues/1454Upgrade: Upgrade to 5.20.0 freeze on2019-12-06T20:29:51ZmarcineqUpgrade: Upgrade to 5.20.0 freeze onOverview
----------------------------------------
When i start my CiviCRM upgrade, upgrader freeze on task: [Executed: Change direction of autoassignees in case type xml].
I have CiviCase component configured with custom case type, wit...Overview
----------------------------------------
When i start my CiviCRM upgrade, upgrader freeze on task: [Executed: Change direction of autoassignees in case type xml].
I have CiviCase component configured with custom case type, with custom roles autoassign to case creator.
After refresh updater page - updater not run.
In Drupal log can i see this issue after notice about executed job.
`Error: Class 'CRM_Documents_Entity_DocumentRepository' not found w documents_civicrm_pre() (linia 172 z /path/to/crm/sites/default/files/civicrm/ext/org.civicoop.documents/documents.php).`
I tried turn off Document extension and restore database from backup. After this i see this error in log:
Error: Class 'CRM_CiviMobileAPI_PushNotification_Utils_NotificationFactory' not found w civimobileapi_civicrm_pre() (linia 342 z /path/to/civicrm/sites/default/files/civicrm/ext/com.agiliway.civimobileapi/civimobileapi.php).
In CiviCRM log i don't have anything of this errors.
Reproduction steps
----------------------------------------
1. Try to upgrade CiviCRM from 5.19.3 to 5.20.0 with enable CiviCase
Current behaviour
----------------------------------------
![image](/uploads/79b14274de224db4f551476d4588c453/image.png)
Expected behaviour
----------------------------------------
Upgrade is finished.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__ _Chrome 78.0.3904.108_
* __CiviCRM:__ _5.19.2 to 5.20.0_
* __PHP:__ _7.2__
* __CMS:__ _Drupal 7.67_
* __Database:__ _10.3.20-MariaDB_
* __Web Server:__ _Apache 2.4_
Comments
----------------------------------------
My extensions:
![image](/uploads/2101f41e3155a0098890bbe323e40752/image.png)https://lab.civicrm.org/dev/core/-/issues/14475.21-RC upgrade fails if there are similar-named Option Groups2019-12-07T18:07:08Zbgm5.21-RC upgrade fails if there are similar-named Option GroupsOn civicrm.org we ran into a fatal error due to:
```
CRM_Upgrade_Incremental_php_FiveTwentyOne::fixOptionGroupName()
```
Error message:
```
UPDATE civicrm_option_group SET name = 'numeric_rating' WHERE ( civicrm_option_group.id =...On civicrm.org we ran into a fatal error due to:
```
CRM_Upgrade_Incremental_php_FiveTwentyOne::fixOptionGroupName()
```
Error message:
```
UPDATE civicrm_option_group SET name = 'numeric_rating' WHERE ( civicrm_option_group.id = 357 )
[nativecode=1062 ** Duplicate entry 'numeric_rating' for key 'UI_name']
```
Pre-upgrade data:
```
> select * from civicrm_option_group where name like '%numeric%';
+-----+-------------------------------+----------------+----------------------------+-------------+-----------+-----------+-----------+
| id | name | title | description | is_reserved | is_active | is_locked | data_type |
+-----+-------------------------------+----------------+----------------------------+-------------+-----------+-----------+-----------+
| 357 | Numeric Rating | Numeric Rating | numeric rating from 1 to 5 | 1 | 1 | 0 | Integer |
| 358 | numeric_rating | Numeric Rating | NULL | 1 | 1 | 0 | Integer |
| 359 | numeric_rating_20171003141125 | Numeric rating | NULL | 0 | 1 | 0 | String |
+-----+-------------------------------+----------------+----------------------------+-------------+-----------+-----------+-----------+
```
To make matters worse, the id=357 group does not have an option values. I have no idea where it's used. (and exists from before enabling detailed-log, 2019-02)
Nonetheless, I feel like this should require a pre-upgrade check?
cc @seamuslee5.21.0https://lab.civicrm.org/dev/core/-/issues/1455Contribution tab sort by Type column not working with db error2019-12-08T21:33:03ZStoobContribution tab sort by Type column not working with db errorWhen clicking Type to sort by Financial Type in the Contributions tab, a Network Error occurs. "Database Error Code: Column 'financial_type_id' in order clause is ambiguous, 1052"
**The full error is attached.**[type-error.txt](/upload...When clicking Type to sort by Financial Type in the Contributions tab, a Network Error occurs. "Database Error Code: Column 'financial_type_id' in order clause is ambiguous, 1052"
**The full error is attached.**[type-error.txt](/uploads/a3e2347b0dfa04c24fa7c68783a892aa/type-error.txt)
![type](/uploads/683755c044a7cb017d3bcc09b20ad355/type.png) <--- this button
The error began after the update from 5.13 to 5.19, and version currently in use is 5.19.4.5.20.0https://lab.civicrm.org/dev/core/-/issues/1422Event Participants actions (Print Name Badges, Export...) ignores search crit...2019-12-09T01:47:09ZalainbEvent Participants actions (Print Name Badges, Export...) ignores search criteriaOverview
----------------------------------------
After a participant search from an event, the actions ignore the search criteria.
Reproduction steps
----------------------------------------
In the CiviCRM demo environment:
1. Click on...Overview
----------------------------------------
After a participant search from an event, the actions ignore the search criteria.
Reproduction steps
----------------------------------------
In the CiviCRM demo environment:
1. Click on **Events -> Manage Events**.
1. For e.g. the Rain-forest Cup Youth Soccer Tournament, click on the right-hand side, click on **Participants -> Registered, Attended, Pending...**.
1. Got 8 participants.
1. Click on **All 8 records -> Actions -> Name Badges Print**
1. The next screen shows **Number of selected participants: 18** instead of **8**.
Similar problem if you select the export action: the confirmation screen shows 8, but the actual export contains 18 lines.
Comments
----------------------------------------
I noticed that the function setDefaults() was removed from the file CRM/Event/Form/Search.php
between these changes:
* still there: https://lab.civicrm.org/dev/core/blob/8a6fde27c69f5e6e51fa91060fa67124d9ca9e18/CRM/Event/Form/Search.php
* removed: https://lab.civicrm.org/dev/core/blob/6fbf3a31a162dd5bdaff0db876360bc4e0f09a49/CRM/Event/Form/Search.php
when I add the function setDefaults() again in CRM/Event/Form/Search.php, the problem seems to be solved.
Can anyone confirm this?5.19.4https://lab.civicrm.org/dev/core/-/issues/14495.20 Upgrade fails when CiviCase is enabled and you have an extension that ca...2019-12-09T20:42:09Zseamuslee5.20 Upgrade fails when CiviCase is enabled and you have an extension that calls hook_civicrm_pre/post and the hook function uses a class within the extensionOverview
----------------------------------------
5.20 Upgrade fails if you use an extension e.g. mailchimp extension and you have CiviCase enabled and you have a case type created that will be affected by the upgrade
Reproduction steps...Overview
----------------------------------------
5.20 Upgrade fails if you use an extension e.g. mailchimp extension and you have CiviCase enabled and you have a case type created that will be affected by the upgrade
Reproduction steps
----------------------------------------
1. Create a case type with the roles of Benefit Specilalist, Spouse of, and Case Coordinator
1. Install mailchimp extension latest version
1. Try running the upgrade in the UI
1. Upgrade stops after the CiviCase label step and doesn't progress and see a PHP error about missing class.
Expected behaviour
----------------------------------------
Upgrade works
Environment information
----------------------------------------
* __CiviCRM:__ _5.20.0_
* __PHP:__ _7.2__
* __CMS:__ _Drupal 7.30_5.20.0seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/1443hook_civicrm_post() implementation results in DB Error: already exists for cu...2019-12-10T06:44:32Zjensschuppehook_civicrm_post() implementation results in DB Error: already exists for custom field valuesOverview
----------------------------------------
When an implementation of `hook_civicrm_post()` creates custom field values for a newly created entity (e.g. a contribution), saving the entity results in
> DB Error: already exists
wit...Overview
----------------------------------------
When an implementation of `hook_civicrm_post()` creates custom field values for a newly created entity (e.g. a contribution), saving the entity results in
> DB Error: already exists
with details
> Duplicate entry '123' for key 'unique_entity_id', 1062
with 123 being the entity ID.
Reproduction steps
----------------------------------------
1. Install an extension with an implementation of `hook_civicrm_post()` that creates a custom value for a newly created entity
e.g.:
```php
/**
* Implements hook_civicrm_post().
*/
function test_civicrm_post( $op, $objectName, $objectId, &$objectRef ) {
if ($op=='create' && $objectName=='Contribution') {
civicrm_api3('CustomValue', 'create', array(
'entity_id' => $objectId,
'custom_123' => 'foobar',
));
}
}
```
1. Try to create an entity of that type (UI or API)
1. Notice the error
Environment information
----------------------------------------
CiviCRM >= 5.16.0
Technical background
----------------------------------------
Commit 46fe0a66dc6bfc0fb63bfc0344ea6ff70ca40c8c [added a condition](https://lab.civicrm.org/dev/core/commit/46fe0a66dc6bfc0fb63bfc0344ea6ff70ca40c8c#7c141e5308ec9ecf64d1bff21cb3af527d47cb22_260_264) for the `ON DUPLICATE KEY UPDATE` clause to only be added when the `$parentOperation` is not `'create'`. However, `hook_civicrm_post()` is being invoked before the transaction that creates the entity is committed and without any `$parentOperation`. Thus, the hook implementation is the first to create a record in the respective custom group table. When the entity creation transaction is about to be committed, there already is a record and the `INSERT` clause without `ON DUPLICATE KEY UPDATE` fails with _DB Error: already exists_.
Proposed solution
----------------------------------------
The condition for not adding the `ON DUPLICATE KEY UPDATE` is of course there for a reason. So maybe removing it is not the best solution. My feeling is that `hook_civicrm_post()` should be invoked later, which might not be that easy, since adding custom field values may not apply to all entity types.
Handing down the `$parentOperation` into the hook will not work, since anything can happen in there and the API (as in the example code above) will not respect it anyway.
Comments
----------------------------------------
Maybe there should be an extension in the testing framework that adds this scenario as a test case, so that changes to code that's invoking hooks can be more sensitive in respect to common or known use cases.5.21.0https://lab.civicrm.org/dev/core/-/issues/1468Advanced search fails to properly search for contribution source2019-12-11T19:17:56ZRichAdvanced search fails to properly search for contribution sourceOverview
----------------------------------------
Try searching for a contribution source from the Advanced search - bet you don't get any results.
Reproduction steps
----------------------------------------
1. Create a contact; add ...Overview
----------------------------------------
Try searching for a contribution source from the Advanced search - bet you don't get any results.
Reproduction steps
----------------------------------------
1. Create a contact; add a contribution with a source `findme`
1. Do an advanced search, specifying a contribution with a source `findme`
1. no results - expected to find your contact.
Current behaviour
----------------------------------------
No results.
Reason: the SQL generation generates SQL like this: `civicrm_contribution.source IN ("%findme%")`
i.e. it's added `%` wildcards as if for a `LIKE` operator, but then it's used `IN`!
Expected behaviour
----------------------------------------
It should generate SQL like this: `civicrm_contribution.source LIKE ("%findme%")` and return the result.
Environment information
----------------------------------------
* __CiviCRM:__ _Master_ and _5.20.0_5.22.0RichRichhttps://lab.civicrm.org/dev/core/-/issues/1425CIVI-SA-2019-21 may lead to regressions when following typehints on CRM_Core_...2019-12-11T19:47:08ZjensschuppeCIVI-SA-2019-21 may lead to regressions when following typehints on CRM_Core_BAO_Setting::setItem()The last security upgrade 5.19.3 introduced a replacement for `unserialize()` which does not allow PHP objects anymore.
This led to serious problems in some of our extensions that make use of `CRM_Core_BAO_Setting::setItem()` for storin...The last security upgrade 5.19.3 introduced a replacement for `unserialize()` which does not allow PHP objects anymore.
This led to serious problems in some of our extensions that make use of `CRM_Core_BAO_Setting::setItem()` for storing extension settings. Since this method explicitly expects settings values to be of type `object`, those settings can not be retrieved from the database anymore.
All those extensions need an upgrader that converts objects in settings records to arrays. Unfortunately, some of those extensions, whenever the current settings are being fetched and there are no defaults, stores those defaults to the database (alongside existing settings, which are now not fetched anymore), which resulted in data loss.
Of course, that's the responsibility of the extension, but `CRM_Core_BAO_Setting::setItem()`'s typehinting is now wrong and should be reworked.5.22.0https://lab.civicrm.org/dev/core/-/issues/1463Record Payment form Errors.2019-12-12T04:25:34ZjitendraRecord Payment form Errors.Overview
----------------------------------------
1. Record Payment form does not load.
2. Record payment fails when Amount Owed is a decimal point number. Eg 264.65
Reproduction steps
----------------------------------------
1. Registe...Overview
----------------------------------------
1. Record Payment form does not load.
2. Record payment fails when Amount Owed is a decimal point number. Eg 264.65
Reproduction steps
----------------------------------------
1. Register a contact for an event with Fee Amount = $264.65.
1. Keep the status as Partially Paid and pay only part of the above amount. Eg 100. Amount owed = $164.65.
1. Save.
1. Click "Record Payment" and try to pay the remaining amount. The form does not load which seem to be a regression from https://github.com/civicrm/civicrm-core/pull/15465
![image](/uploads/0c301633b5e7d8926657e52e737ddec4/image.png)
1. Select payment method and click save.
![image](/uploads/c50f706ae3c26ad42586950d0a505c21/image.png)
Expected behaviour
----------------------------------------
Form should load fine and accept the decimal amount as it is equal to the remaining amount that needs to be paid.5.20.2jitendrajitendra