Development issueshttps://lab.civicrm.org/groups/dev/-/issues2019-12-12T04:25:34Zhttps://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.2jitendrajitendrahttps://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/1452Recurring contributions label on contribution pages is unstylable text, leadi...2021-05-03T11:44:27ZlarsssandergreenRecurring contributions label on contribution pages is unstylable text, leading to problems with themesOn a contribution page with recurring contributions enabled, the label for the recurring selection shows up as:
`<label for="is_recur">I want to contribute this amount</label>
every month
...On a contribution page with recurring contributions enabled, the label for the recurring selection shows up as:
`<label for="is_recur">I want to contribute this amount</label>
every month
`
(including some odd spacing around between the label and the word every). If you allow more than one option (e.g. weeks and months), only the word every is outside the label tags.
Because of this, any theme that changes the styling of the labels ends up looking very bad, as the words "every month" will be in a different font, size, etc. and there can also be some weird spacing. It seems like the fix would be to apply additional label tags around the words.
This is fixable on individual sites by applying styles to the divs that contain this label, but that's obviously not a great solution.
Confirmed on latest demo.5.38.0https://lab.civicrm.org/dev/core/-/issues/1451Incorrect boolean comparisons in ang/crmCaseType/list.html for is_active and ...2020-02-17T16:18:46ZDaveDIncorrect boolean comparisons in ang/crmCaseType/list.html for is_active and is_reservedIn the case type listing, the various actions available are determined by combinations of is_active and is_reserved. However in javascript:
```
var x = "0";
if (x) {console.log('true'); } else {console.log('false');}
x = "1";
if (x) {co...In the case type listing, the various actions available are determined by combinations of is_active and is_reserved. However in javascript:
```
var x = "0";
if (x) {console.log('true'); } else {console.log('false');}
x = "1";
if (x) {console.log('true'); } else {console.log('false');}
```
will output true for both. Similarly for `!x` it will output false for both.
This comes up a couple ways:
1. The stock case types can't be deleted. (It's probably always been assumed this was on purpose for a reason, that they are "special". I can't think why this would be true - there's nothing in core that references them except they get loaded automatically when you first enable civicase.)
1. And to disable the stock types there's no dropdown option you have to go in and edit the "enabled" field.
1. After you disable a case type (stock or not), the dropdown action still says "Disable".
I'm thinking it's always been like this.5.24.0https://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/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/1444Activities not visible if they have a campaign_id & contact does not have 'ad...2020-01-23T21:20:51ZeileenActivities not visible if they have a campaign_id & contact does not have 'administer CiviCampaign'The activity tab in Civi adds the filter campaign_id = NULL where the contact does not have the 'Administer CiviCRM' permission.
This seems wrong...The activity tab in Civi adds the filter campaign_id = NULL where the contact does not have the 'Administer CiviCRM' permission.
This seems wrong...5.21.0https://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/1438when importing contributions, can't match contact on phone number2020-02-17T15:27:10Zjamiewhen importing contributions, can't match contact on phone numberOverview
----------------------------------------
When importing contributions, you can't match an existing contact using a phone number, even when the default unsupervised rule specified the phone field. It is because the dedupe rule ca...Overview
----------------------------------------
When importing contributions, you can't match an existing contact using a phone number, even when the default unsupervised rule specified the phone field. It is because the dedupe rule calls the phone field "phone_numeric" yet the contact list of importable fields lists the field as "phone" - so no match is every made.
Reproduction steps
----------------------------------------
1. Click on **Contacts -> Find and Merge Duplicate Contacts**.
1. Click **Add rule for Individuals**.
1. Rule Name: Phone, Used: Unsupervised, Select field Phone and enter weight: 1, Threshhold: 1 and **Save**
1. Click **Contributions -> Import Contributions**
1. Upload any CSV file, choose defaults
1. Click Next
1. See that Phone is not listed in fields to import
Current behaviour
----------------------------------------
When the field mapper screen appears and you have an supervised dedupe rule with a phone field, you get a missing index error, a phantom "match to contact" option in the field list, and the phone field is not listed.
![phone-import-error](/uploads/26b39da7bed124937c3666d4fb275a03/phone-import-error.png)
Expected behaviour
----------------------------------------
The phone field should be listed (with "match to contact").
Environment information
----------------------------------------5.24.0https://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/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/1433CRM_Case_XMLProcessor::allActivityTypes() doesn't do caching right2020-06-16T11:13:35ZDaveDCRM_Case_XMLProcessor::allActivityTypes() doesn't do caching rightThis isn't recent. The function looks like this:
```php
public static function &allActivityTypes($indexName = TRUE, $all = FALSE) {
if (self::$activityTypes === NULL) {
self::$activityTypes = CRM_Case_PseudoConstant::caseActiv...This isn't recent. The function looks like this:
```php
public static function &allActivityTypes($indexName = TRUE, $all = FALSE) {
if (self::$activityTypes === NULL) {
self::$activityTypes = CRM_Case_PseudoConstant::caseActivityType($indexName, $all);
}
return self::$activityTypes;
}
```
So it works fine the first time in any given page run, but then if you call it again with different parameters it just returns the thing it cached last time regardless of the parameters. It isn't used very often and so I guess it doesn't come up in a typical page run, but it was driving me a bit nuts while trying to write a unit test and not getting what I was expecting.
PR coming, just debating whether it's worth trying to eliminate completely since it isn't used in that many places, i.e. deprecate it and replace everywhere it's used in core with CRM_Case_PseudoConstant::caseActivityType which does its own caching anyway.5.28.0https://lab.civicrm.org/dev/core/-/issues/1430Contribution ID token not working with 'contribution type' scheduled reminders2021-09-13T05:23:27Zellen_compucorpContribution ID token not working with 'contribution type' scheduled remindersThe Contribution ID token does not appear to be working when used with with 'contribution type' scheduled reminders, however it does seem to still work when used in sending an email from 'find contributions'.
----------------------------...The Contribution ID token does not appear to be working when used with with 'contribution type' scheduled reminders, however it does seem to still work when used in sending an email from 'find contributions'.
----------------------------------------
Reproduction steps
----------------------------------------
1. Go to /civicrm/admin/scheduleReminders?reset=1
1. Create a new scheduled reminder with type 'contribution type', a financial type selected, and the contribution status 'completed'
1. Set scheduled reminder to be sent 0 hours after received date
1. Give the email a subject, and in the email body, insert the token 'contribution ID'
1. Save the scheduled reminder
1. Create a new contribution on any contact record (using the same financial type used previously, and with status 'completed).
1. Execute the 'send scheduled reminders' scheduled job
Current behaviour
----------------------------------------
Scheduled reminder email is sent, but contribution ID has not been generated
Expected behaviour
----------------------------------------
Contribution ID should have been generated and should be include in the received email
Environment information
----------------------------------------
* __CiviCRM:__ 5.19.2
* __PHP:__ _7.2
* __CMS:__ Drupal
Comments
----------------------------------------
As mentioned above, the token does seem to work correctly when used in an email sent via the 'search contributions' action menu5.43.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/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/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/1424Export doesn't work in Excel with diacritic chars2020-07-12T03:19:04ZeileenExport doesn't work in Excel with diacritic charsPROPOSAL - prepend the BOM for UTF8 "\xEF\xBB\xBF" so csv's exported from excel
Discussion (note this is the same writeup on the PR - creating a gitlab too as I suspect there might be discussion).
There is a long-standing issue ...PROPOSAL - prepend the BOM for UTF8 "\xEF\xBB\xBF" so csv's exported from excel
Discussion (note this is the same writeup on the PR - creating a gitlab too as I suspect there might be discussion).
There is a long-standing issue whereby files exported from CiviCRM with diacritic characters - eg.
ę are mangled when opened in MS Excel.
The underlying issue is that the characters are UTF-8 encoded & MS Excel by default does not assume UTF8.
In order to do so it needs a BOM - Byte Order Marker - which is a few hex characters at the start of
the csv.
The BOM indicator is 'not recommended' .... unless you want your csv to work with
MS Excel. Since MS Excel is a major use case for csvs I think it's pretty clear that all
things being equal we want to support it... I note that there are extensions to export to excel
natively but I don't think that replaces this. The number one reason to want to export
a csv is to work with it in a spreadsheeting programme & unless we can't safely make it
work in core we shouldn't require an extension for that.
There are various recommendations over time but it seems things have improved in the MS
Excel world and what works on Windows now appears to work on Mac too - at least on a recent version.
This link https://donatstudios.com/CSV-An-Encoding-Nightmare is a pretty good discussion.
While the above link and others say that you need a different BOM for MAC than Windows my
testing shows that the one recommended for Windows works fine on Mac Excel (while you would need
to convert to UTF 16 to follow the Mac recommendation. (https://csv.thephpleague.com/9.0/interoperability/encoding/)
Other links
https://stackoverflow.com/questions/35294443/does-excel-for-mac-2016-properly-import-unicode-in-csv-files
https://stackoverflow.com/questions/2223882/whats-the-difference-between-utf-8-and-utf-8-without-bom/2223926#2223926
Notably this summary :
" When should you encode with a BOM?
If you're unable to record the metadata in any other way (through a charset tag or file system meta), and the programs being used like BOMs, you should encode with a BOM. This is especially true on Windows where anything without a BOM is generally assumed to be using a legacy code page. The BOM tells programs like Office that, yes, the text in this file is Unicode; here's the encoding used.
When it comes down to it, the only files I ever really have problems with are CSV. Depending on the program, it either must, or must not have a BOM. For example, if you're using Excel 2007+ on Windows, it must be encoded with a BOM if you want to open it smoothly and not have to resort to importing the data."
So the argument for a BOM is - if you want it to be compatible with MS Excel use a BOM. This seems to apply.
The risk is that perhaps there is some variant of csv viewing programme that can't cope - the risk of this is rather mitigited by
1) the fact that MS Excel adds the BOM to the start of any files it saves as UTF-8 encoded csv so any programme that expects to open MS Excel generated
csvs would need to be able to cope with it. In addition it is a standard, if not required, file indicator so it feels like the programmes
that were legacy in 2016 writeups might be of no concern now.
2) There really is no programatic way to export these csvs so the risk that this is being parsed by code is close to zero
There are 2 other things we could do to mitigate
1) test on more platforms - I've tested with MS Excel for Mac (Office 365 v 16.31) and Libre Office and MS Numbers
& MS word, cot editor & notes
2) We could add a setting. I'm generally a bit loath on settings as they are a bit of a maintenance nightmare.
However, perhaps it would be a setting like 'export csvs in legacy format & there could be a link
to the gitlab to explain your use-case if you feel the need to set it. If no-one does then we could later remove.
Final note - csv tables are created with the CRM_Core_Report_Excel (spot the irony) from 3 places
- the main export, the export for custom fields & a third place which I believe to be unreachable. This is one path
only but I can look at centralising for the custom fields export path.5.22.0https://lab.civicrm.org/dev/financial/-/issues/109Invoice does not assign/display the contact's country2020-03-01T20:27:10ZbgmInvoice does not assign/display the contact's countryTo reproduce:
* Enable Taxes and Invoicing
* Edit the "Contribution Invoice Receipt" message template to include `{$country}` (other related contact tokens are called `{$street_address}`, `{$email}`, etc.
* Go to a contact, create a con...To reproduce:
* Enable Taxes and Invoicing
* Edit the "Contribution Invoice Receipt" message template to include `{$country}` (other related contact tokens are called `{$street_address}`, `{$email}`, etc.
* Go to a contact, create a contribution, and from "view contribution", click "print PDF invoice" to view an invoice.
The country will be empty.5.24.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/1420Quicksearch with phone filter doesn't work with non-numeric character2020-01-10T07:23:49ZMonish DebQuicksearch with phone filter doesn't work with non-numeric characterSteps to replicate:
1. Say a contact A has a phone number : 876-123-234
2. Go to quicksearch bar and select 'Phone' filter
3. Type '876-123' in the search field.
Bug: It doesn't return contact A, because the code doesn't trim non-numeri...Steps to replicate:
1. Say a contact A has a phone number : 876-123-234
2. Go to quicksearch bar and select 'Phone' filter
3. Type '876-123' in the search field.
Bug: It doesn't return contact A, because the code doesn't trim non-numeric character for the phone_numeric filter which expects only numeric digits.5.21.0Monish DebMonish Deb