CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-01-04T18:01:59Zhttps://lab.civicrm.org/dev/core/-/issues/1528End of life plans for php 7.0 & deprecate php 7.12023-01-04T18:01:59ZeileenEnd of life plans for php 7.0 & deprecate php 7.1Php 7.1 is unsupported as of the start of last month. We have been saying we will remove php 7.0 support for a while - we should announce end of support for php 7.0 and start to message people to get off php 7.1. This went OK for php 5.6...Php 7.1 is unsupported as of the start of last month. We have been saying we will remove php 7.0 support for a while - we should announce end of support for php 7.0 and start to message people to get off php 7.1. This went OK for php 5.6 (which actually still reports more installs that 7.0 oddly).
I propose we
1) publish a blog saying that the March release of 5.23 will be the last release supporting php 7.0
2) offer support for 7.0 in 5.21 for the duration of that being the ESR (as we did for 5.6)
3) plan to discontinue support for 7.1 in the months after the next ESR is released (e.g Sep 2020) - with longer support for it in the ESR
4) add in app notifications for people to get off 7.1
- Our recommended version should be php 7.3 which works well.
- We are seeing increasing issues with composer packages dropping support for php 7.0 & 7.1. I think this is mostly because of phpunit issues, which have also been hitting us.
- In practice my guess is that CI aside the code will work fine on php 7.0 but it just won't be supported.5.34.0https://lab.civicrm.org/dev/core/-/issues/1524[regression] Searches based on created/modified date don't like certain relat...2020-01-14T06:16:51ZJonGold[regression] Searches based on created/modified date don't like certain relative filtersOverview
----------------------------------------
Any relative date filter on Advanced Search that doesn't calculate both a "From" and "To" date (e.g. "To end of yesterday") result in a "No Such Field" error.
Reproduction steps
--------...Overview
----------------------------------------
Any relative date filter on Advanced Search that doesn't calculate both a "From" and "To" date (e.g. "To end of yesterday") result in a "No Such Field" error.
Reproduction steps
----------------------------------------
1. Go to **Advanced Search**, open **Change Log**.
1. For *Created Date*, set a relative date filter that doesn't calculate both begin and end date (e.g. "To end of yesterday"). Press **Search**.
1. Get an error `[nativecode=1054 ** Unknown column 'civicrm_contact.created_date' in 'where clause']"]`.
Current behaviour
----------------------------------------
Incorrect SQL query is constructed.
Expected behaviour
----------------------------------------
No error.5.22.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/1522, as decimal separator, and [space] as thousand separators leads to api errors2020-03-17T22:27:15Zjaapjansma, as decimal separator, and [space] as thousand separators leads to api errors**Steps to reproduce**
1. At Administer --> Localisation --> Languages, Currencies and Location: set , as a decimal separator
2. At Administer --> Localisation --> Languages, Currencies and Location: Set space as thousand separator (So ...**Steps to reproduce**
1. At Administer --> Localisation --> Languages, Currencies and Location: set , as a decimal separator
2. At Administer --> Localisation --> Languages, Currencies and Location: Set space as thousand separator (So that 1234.56 is displayed as 1 234,56)
3. Go to api 3 explorer (Support --> Developers --> Api explorer v3)
4. Create a contribution with total_amount = 250.00 (keep the dot and the two zero's).
**Expected result**
Contribution created with a total amount of € 250,00
**Actual result**
Api error: `total_amount is not a valid amount: 250.00`
**Caused by**
This is caused by the statement in _https://github.com/civicrm/civicrm-core/blob/master/CRM/Utils/Rule.php#L603_
This statement expects at least . in either decimal separator or thousand separator.
```php
if ($config->monetaryDecimalPoint &&
$config->monetaryDecimalPoint != '.' &&
// CRM-7122 also check for Thousands Separator in config settings
$config->monetaryThousandSeparator != '.' &&
substr_count($value, '.')
) {
return FALSE;
}
```
**Analyses**
Below an analyses of the _contribution.create_ api with different localization settings and inputs.
| Currency | Decimal sep. | Thousand sep. | Contribution.create total_amount | Raw Value | Display as | 5.13 | 5.20 |
|----------|--------------|---------------|----------------------------------|------------|------------------|----------|----------|
| $ | . | , | 1,234,567.89 | 1234567.89 | $ 1,234,567.89 | OK | OK |
| $ | . | , | 1234567.89 | 1234567.89 | $ 1,234,567.89 | OK | OK |
| $ | . | [space] | 1 234 567.89 | 1234567.89 | $ 1 234 567.89 | OK | OK |
| $ | . | [space] | 1234567.89 | 1234567.89 | $ 1 234 567.89 | **Fail** | **Fail** |
| € | . | , | 1,234,567.89 | 1234567.89 | € 1,234,567.89 | OK | OK |
| € | . | , | 1234567.89 | 1234567.89 | € 1,234,567.89 | OK | OK |
| € | , | . | 1.234.567,89 | 1234567.89 | € 1.234.567,89 | OK | OK |
| € | , | . | 1234567.89 | 1234567.89 | € 1.234.567,89 | OK | OK |
| € | , | [space] | 1 234 567,89 | 1234567.89 | € 1 234 567,89 | OK | OK |
| € | , | [space] | 1234567.89 | 1234567.89 | € 1 234 567,89 | **Fail** | **Fail** |
| NOK | . | , | 1,234,567.89 | 1234567.89 | NOK 1,234,567.89 | OK | OK |
| NOK | . | , | 1234567.89 | 1234567.89 | NOK 1,234,567.89 | OK | OK |
| NOK | , | . | 1.234.567,89 | 1234567.89 | NOK 1.234.567,89 | OK | OK |
| NOK | , | . | 1234567.89 | 1234567.89 | NOK 1.234.567,89 | OK | OK |
| NOK | , | [space] | 1 234 567,89 | 1234567.89 | NOK 1 234 567,89 | OK | OK |
| NOK | , | [space] | 1234567.89 | 1234567.89 | NOK 1 234 567,89 | **Fail** | **Fail** |
**See also**
This bug is introduced by https://issues.civicrm.org/jira/browse/CRM-7122
**Question before fixing this**
What exactly is this if statement checking for? 5.23.0https://lab.civicrm.org/dev/core/-/issues/1519Auto renew text appears at top of membership edit form2020-01-10T21:07:09ZwmortadaAuto renew text appears at top of membership edit formOverview
----------------------------------------
A line of text appears at the top of the membership edit form when editing an auto-renewing membership:
> For auto-renewing memberships the emails are sent when each payment is received...Overview
----------------------------------------
A line of text appears at the top of the membership edit form when editing an auto-renewing membership:
> For auto-renewing memberships the emails are sent when each payment is received
This text should appear lower down next to the 'Send Confirmation and Receipt?' text box. It appears that the HTML is incorrectly nested which is why the browser places this text out of the normal flow.
Reproduction steps
----------------------------------------
1. View a contact with an auto-renewing membership.
1. Click on the membership tab.
1. Click to edit that membership.
Current behaviour
----------------------------------------
See the line of text at the top of this form:
![Before](/uploads/334c4d296f4c14a6964c75acf9c27397/Before.png)
Expected behaviour
----------------------------------------
This text should appear lower down next to the 'Send Confirmation and Receipt?' text box.
![After](/uploads/c80686a359e718331993c7362d30c9ad/After.png)
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:__ _Firefox 71.0/Chrome 79.0.3945.88_
* __CiviCRM:__ _4.7-Master_
* __PHP:__ _7.2.23_
* __CMS:__ _Drupal 7.68_
* __Database:__ _N/A_
* __Web Server:__ _N/A_
Comments
----------------------------------------
This text was introduced in a PR from @eileen on 2 Dec 2015: https://github.com/civicrm/civicrm-core/pull/7335/files
Here is the related issue in JIRA: https://issues.civicrm.org/jira/browse/CRM-176355.23.0https://lab.civicrm.org/dev/core/-/issues/1517Permission error on event info page for anonymous users2020-02-14T12:03:41ZjitendraPermission error on event info page for anonymous usersGiving anonymous "access CiviEvent" in addition to "view event info" cause them to get "API permission check failed for Event/get call; insufficient permission: require access CiviCRM".
To replicate -
- Grant `access CiviEvent`, `view ...Giving anonymous "access CiviEvent" in addition to "view event info" cause them to get "API permission check failed for Event/get call; insufficient permission: require access CiviCRM".
To replicate -
- Grant `access CiviEvent`, `view event info`, `register for events` to anonymous.
- Navigate to the info page of any event.
![image](/uploads/3a7114e07ec47065b83a00e1a8488cb2/image.png)
- The registration page works fine.
Related SE - https://civicrm.stackexchange.com/questions/19038/api-permission-check-failed-civievents-fails-after-update-to-4-7-19-and-4-7-20/25326#253265.24.0https://lab.civicrm.org/dev/core/-/issues/1512Address ID field should be exportable2020-01-10T23:28:27ZJonGoldAddress ID field should be exportableOverview
----------------------------------------
Address ID is currently not set as exportable.
Example use-case
----------------------------------------
The use case for exporting is to ship address data to a third party for cleanup (...Overview
----------------------------------------
Address ID is currently not set as exportable.
Example use-case
----------------------------------------
The use case for exporting is to ship address data to a third party for cleanup (vendors who will return addresses with more accurate postal codes, changes of address, etc.). It's necessary to export an address ID to allow a reimport on the same address.
Current behaviour
----------------------------------------
Address ID not exportable.
Proposed behaviour
----------------------------------------
Address ID exportable.5.23.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/1511Expose "is_show_location" to control display of event locations2020-02-27T19:57:26Zaydunsaidan.saunders@squiffle.ukExpose "is_show_location" to control display of event locationsOverview
----------------------------------------
The Event DAO has a boolean field 'is_show_location' that determines whether the event location is shown or not. This field is available via the API and existing code suggests it was int...Overview
----------------------------------------
The Event DAO has a boolean field 'is_show_location' that determines whether the event location is shown or not. This field is available via the API and existing code suggests it was intended to be available to event administrators, but it is not currently shown.
Current behaviour
----------------------------------------
This field allows event locations to be configured, but not shown to users. The field already exists and is referenced in multiple places but is not configurable via the GUI.
CRM_Event_Form_ManageEvent_Location::buildQuickForm() adds the field to the form but it is not included in the template - see https://github.com/civicrm/civicrm-core/blob/master/CRM/Event/Form/ManageEvent/Location.php#L184
Proposed behaviour
----------------------------------------
Add the field to the template templates/CRM/Event/Form/ManageEvent/Location.tpl
Comments
----------------------------------------
This improves consistency between API & GUI.
Original motivation for this was that some events on a client site do not have this field set but there is no way to see or correct this for administrators.
PR
-----
https://github.com/civicrm/civicrm-core/pull/162305.23.0aydunsaidan.saunders@squiffle.ukaydunsaidan.saunders@squiffle.ukhttps://lab.civicrm.org/dev/core/-/issues/1508E_NOTICE when viewing any contribution2020-01-09T01:25:25ZDaveDE_NOTICE when viewing any contributionIt's easier to see if you turn off popups under display settings, but you can also see it in drupal watchdog.
`Notice: Undefined variable: status in CRM_Contribute_Form_ContributionView->preProcess() (line 213 of blah/CRM/Contribute/For...It's easier to see if you turn off popups under display settings, but you can also see it in drupal watchdog.
`Notice: Undefined variable: status in CRM_Contribute_Form_ContributionView->preProcess() (line 213 of blah/CRM/Contribute/Form/ContributionView.php).`
On master.5.22.0https://lab.civicrm.org/dev/core/-/issues/1507Recent items list has blank entry and E_NOTICE's when viewing an Email activi...2020-01-14T17:09:56ZDaveDRecent items list has blank entry and E_NOTICE's when viewing an Email activity from activities tabTo reproduce just go to someone's activity tab who has an activity of type Email and click to view it. Then refresh the page or go somewhere else and notice that the recent items list has a blank entry.
Can reproduce on dmaster.demo.
T...To reproduce just go to someone's activity tab who has an activity of type Email and click to view it. Then refresh the page or go somewhere else and notice that the recent items list has a blank entry.
Can reproduce on dmaster.demo.
The url that gets generated for activities of type Email in the activities tab is `civicrm/activity/view`, which seems lightly used throughout civi. This corresponds to CRM_Activity_Form_ActivityView. What's happening is that in preProcess it's calling CRM_Activity_BAO_Activity::retrieve(), and then later on it's expecting the retrieved values to contain `source_contact_id`, but it doesn't.
It seems likely that it used to contain it and something changed, but I'm not sure when and since this particular view url is rarely used it doesn't come up much. Also, when using popups which is the default you don't see the E_notices in the UI unless you open in new tab.
```
Notice: Undefined index: source_contact_id in CRM_Activity_Form_ActivityView->preProcess() (line 98 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Activity/Form/ActivityView.php).
Notice: Undefined property: CRM_Activity_Form_ActivityView::$_values in CRM_Activity_Form_ActivityView->preProcess() (line 99 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Activity/Form/ActivityView.php).
Notice: Undefined index: source_contact_id in CRM_Activity_Form_ActivityView->preProcess() (line 103 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Activity/Form/ActivityView.php).
```
I can do a PR but I wonder if at one time there were efforts to eliminate the use of this particular url and that this form is maybe-not-officially-but-kinda-deprecated-except-maybe-for-emails ??5.23.0https://lab.civicrm.org/dev/core/-/issues/1506Editing a group description inline causes the recent items list to display bl...2020-01-05T23:27:09ZDaveDEditing a group description inline causes the recent items list to display blank instead of the group title1. Go to Contacts - manage groups.
2. Click in a description column cell to edit a description inline. It doesn't matter if it's already filled in or not.
3. Type something and save.
4. Refresh the page or go to another page.
5. In the r...1. Go to Contacts - manage groups.
2. Click in a description column cell to edit a description inline. It doesn't matter if it's already filled in or not.
3. Type something and save.
4. Refresh the page or go to another page.
5. In the recent items list in the sidebar the entry for the group will be blank. The group itself is fine, just the entry in the recent items list.
It works fine when editing a group via the settings action link on the row. It doesn't matter if the item is already in the recent items list or not - it always displays blank after inline edit.
Can reproduce on dmaster.demo
More details TBD.
Here is a ridiculously large screenshot:
![screenshot](/uploads/4d8cc3060166a2bdf88959ea21f991ab/screenshot.gif)5.23.0DaveDDaveDhttps://lab.civicrm.org/dev/core/-/issues/1502Make Deja Vu Sans the default font for mailing labels2020-10-15T20:14:26ZDaveDMake Deja Vu Sans the default font for mailing labelsAs per https://civicrm.stackexchange.com/questions/34182/make-mailing-labels-not-working-for-bosnia-language and similar pdf issues elsewhere, the default font of Helvetica doesn't work for unicode characters and you just get a `?` in th...As per https://civicrm.stackexchange.com/questions/34182/make-mailing-labels-not-working-for-bosnia-language and similar pdf issues elsewhere, the default font of Helvetica doesn't work for unicode characters and you just get a `?` in the output. It's configurable at Administer - Communications - Label Formats but why not make the default font one that supports unicode.
One downside is that the pdfs will be larger because Helvetica is a core pdf font and deja vu needs to be embedded in every file, but at least for mailing labels once the file is printed you usually discard the pdf. So right now I'm just talking about mailing labels and the default font setting on that admin page.
Any other reasons not to?5.23.0https://lab.civicrm.org/dev/core/-/issues/1499Case Resource shows contact names that are not accessible to logged in user2020-01-07T02:19:16ZjitendraCase Resource shows contact names that are not accessible to logged in userTo replicate -
1. Add contact A, B and C to case resource group.
2. Create a case for User1 and make sure that user1 is able to access only contact A (add appropriate ACL or relationships, etc).
3. Log in as User1 and navigate to Manage...To replicate -
1. Add contact A, B and C to case resource group.
2. Create a case for User1 and make sure that user1 is able to access only contact A (add appropriate ACL or relationships, etc).
3. Log in as User1 and navigate to Manage case screen -> open "Other relationship" panel.
4. Notice that "Case Resources" section displays all the 3 contacts A, B and C in the list instead of showing only A to the user.
![image](/uploads/aba0a7f01efc49fbf83ef237bbd8335c/image.png)
IMO - this group contacts should only be shown to users having access to view them?5.23.0jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/1498Upgrade fails when civicrm_managed table contains a row including entity_type...2020-04-12T03:13:45ZgharrisUpgrade fails when civicrm_managed table contains a row including entity_type='PaymentProcessorType';Overview
----------------------------------------
See https://civicrm.stackexchange.com/questions/34152/upgrade-fails-with-civicrm-api3-exception-api-error-could-not-delete-payment/34153#34153
Reproduction steps
------------------------...Overview
----------------------------------------
See https://civicrm.stackexchange.com/questions/34152/upgrade-fails-with-civicrm-api3-exception-api-error-could-not-delete-payment/34153#34153
Reproduction steps
----------------------------------------
Unverified, but expected that adding the iATS payment processor extension, and then later removing that processor or disabling the extension, results in the database entry.
Error message and error log output.
Deletion Error
There is a Payment Processor associated with selected Payment Processor type, hence it can not be deleted.
CiviCRM_API3_Exception: "API error: Could not delete payment processor type"
#0 /dir/wp/wp-content/plugins/civicrm/civicrm/CRM/Upgrade/Incremental/php/FiveTwenty.php(370): civicrm_api3("CaseType", "create", (Array:9))
#1 /dir/wp/wp-content/plugins/civicrm/civicrm/CRM/Upgrade/Incremental/php/FiveTwenty.php(289): CRM_Upgrade_Incremental_php_FiveTwenty::_processCaseTypeLabelName(FALSE, "7")
#2 /dir/wp/wp-content/plugins/civicrm/civicrm/CRM/Upgrade/Incremental/php/FiveTwenty.php(265): CRM_Upgrade_Incremental_php_FiveTwenty::_changeCaseTypeLabelToName(FALSE)
#3 /dir/wp/wp-content/plugins/civicrm/civicrm/CRM/Queue/Task.php(88): CRM_Upgrade_Incremental_php_FiveTwenty::changeCaseTypeLabelToName(Object(CRM_Queue_TaskContext))
#4 /dir/wp/wp-content/plugins/civicrm/civicrm/CRM/Queue/Runner.php(217): CRM_Queue_Task->run(Object(CRM_Queue_TaskContext))
#5 /dir/wp/wp-content/plugins/civicrm/civicrm/CRM/Queue/Page/AJAX.php(52): CRM_Queue_Runner->runNext(TRUE)
#6 /dir/wp/wp-content/plugins/civicrm/civicrm/CRM/Queue/ErrorPolicy.php(106): CRM_Queue_Page_AJAX::{closure}()
#7 /dir/wp/wp-content/plugins/civicrm/civicrm/CRM/Queue/Page/AJAX.php(54): CRM_Queue_ErrorPolicy->call(Object(Closure))
#8 /dir/wp/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(250): CRM_Queue_Page_AJAX::runNext()
#9 /dir/wp/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:13))
#10 /dir/wp/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:5))
#11 /dir/wp/wp-content/plugins/civicrm/civicrm.php(1465): CRM_Core_Invoke::invoke((Array:5))
#12 /dir/wp/wp-includes/class-wp-hook.php(288): CiviCRM_For_WordPress->invoke("")
#13 /dir/wp/wp-includes/class-wp-hook.php(312): WP_Hook->apply_filters("", (Array:1))
#14 /dir/wp/wp-includes/plugin.php(478): WP_Hook->do_action((Array:1))
#15 /dir/wp/wp-admin/admin.php(254): do_action("toplevel_page_CiviCRM")
#16 {main}
Current behaviour
----------------------------------------
Upgrade stops as seen in SE example.
Expected behaviour
----------------------------------------
Upgrade goes smoothly.
Environment information
----------------------------------------
A former version of the iATS Payment Processor extension seems to be the common theme.5.23.0https://lab.civicrm.org/dev/core/-/issues/1496Support PHP 7.4 EPIC2021-03-26T09:47:11ZJoeMurraySupport PHP 7.4 EPICPHP 7.4 was released November 28, 2019.
This is an epic for tasks associated with upgrading core to be compatible with PHP 7.4, based on https://www.php.net/manual/en/migration74.incompatible.php and https://www.php.net/manual/en/migra...PHP 7.4 was released November 28, 2019.
This is an epic for tasks associated with upgrading core to be compatible with PHP 7.4, based on https://www.php.net/manual/en/migration74.incompatible.php and https://www.php.net/manual/en/migration74.deprecated.php. I have reviewed potential issues and mention below those that I think we need to work on, or may need to work on.
Here are five subissues that could use some love. Note that I was merely creating issues based on the Release Notes and there may be no more to do than checking nothing is wrong.
1. https://lab.civicrm.org/dev/core/issues/1491
1. https://lab.civicrm.org/dev/core/issues/1492
1. https://lab.civicrm.org/dev/core/issues/1493
1. https://lab.civicrm.org/dev/core/issues/1494
1. https://lab.civicrm.org/dev/core/issues/1495
I think we need to do whack-a-mole when testing against PHP 7.4 on:
1. \<?php tag at end of file
1. Array-style access of non-arrays: Trying to use values of type null, bool, int, float or resource as an array (such as $null["key"]) will now generate a notice.
1. htmlentities() function: htmlentities() will now raise a notice (instead of a strict standards warning) if it is used with an encoding for which only basic entity substitution is supported, in which case it is equivalent to htmlspecialchars().
1. Tokenizer: token_get_all() will now emit a T_BAD_CHARACTER token for unexpected characters instead of leaving behind holes in the token stream.
```
$ grep -R token_get_all ./*
./CRM/Core/CodeGen/Util/ArraySyntaxConverter.php: $tokens = token_get_all($code);
```
1. Nested ternary operations must explicitly use parentheses to dictate the order of the operations. Previously, when used without parentheses, the left-associativity would not result in the expected behaviour in most cases. My grep-foo wasn't good enough to find nested uses of ternary operations.
1. Convert any use of array_key_exists() on objects to either isset() or property_exists() to deal with deprecation of array_key_exists function.
1. Passing parameters to implode() in reverse order is deprecated, use implode($glue, $parts) instead of implode($parts, $glue).5.37.0https://lab.civicrm.org/dev/core/-/issues/1494replace deprecated money_format() fn to support PHP 7.42022-05-10T22:47:22ZJoeMurrayreplace deprecated money_format() fn to support PHP 7.4https://www.php.net/manual/en/migration74.deprecated.php indicates that money_format() is deprecated and should be replaced with NumberFormatter functionality. CiviCRM uses it in a couple of places in one file and in some documentation:
...https://www.php.net/manual/en/migration74.deprecated.php indicates that money_format() is deprecated and should be replaced with NumberFormatter functionality. CiviCRM uses it in a couple of places in one file and in some documentation:
```
$ grep -R money_format ./*
./CRM/Utils/Money.php: // money_format() exists only in certain PHP install (CRM-650)
./CRM/Utils/Money.php: if (is_numeric($amount) and function_exists('money_format')) {
./CRM/Utils/Money.php: $amount = money_format($valueFormat, $amount);
./CRM/Utils/Money.php: // money_format() exists only in certain PHP install (CRM-650)
./CRM/Utils/Money.php: if (is_numeric($amount) && function_exists('money_format')) {
./CRM/Utils/Money.php: $amount = money_format($valueFormat, $amount);
./templates/CRM/Admin/Form/Setting/Localization.hlp:{capture assign="money_format_help"}
./templates/CRM/Admin/Form/Setting/Localization.hlp: {ts 1='href="http://php.net/manual/en/function.money-format.php"'}For a full list of options see the php <a %1>money_format documentation</a>.{/ts}
./templates/CRM/Admin/Form/Setting/Localization.hlp: {$money_format_help}
./templates/CRM/Admin/Form/Setting/Localization.hlp: {$money_format_help}
```5.37.0https://lab.civicrm.org/dev/core/-/issues/1490Syntax error in Membership html receipt2019-12-20T11:47:10ZbgmSyntax error in Membership html receiptTo reproduce:
* Setup a membership form, basic settings, with a test gateway so that billing fields are enabled
* Enable email confirmation receipts
Result:
![civicrm-html-receipt](/uploads/107aadfced33fb28cb1dc22badc7c4dd/civicrm-htm...To reproduce:
* Setup a membership form, basic settings, with a test gateway so that billing fields are enabled
* Enable email confirmation receipts
Result:
![civicrm-html-receipt](/uploads/107aadfced33fb28cb1dc22badc7c4dd/civicrm-html-receipt.jpg)5.21.0bgmbgmhttps://lab.civicrm.org/dev/core/-/issues/1485Membership "join_date" is ignored on import2020-01-01T12:27:23ZjptillmanMembership "join_date" is ignored on importOverview
----------------------------------------
When importing memberships ("Create" context) on the latest Civi release (5.20.2), if a "Member Since" value is mapped and imported, it will be ignored and the current date will be used.
...Overview
----------------------------------------
When importing memberships ("Create" context) on the latest Civi release (5.20.2), if a "Member Since" value is mapped and imported, it will be ignored and the current date will be used.
Reproduction steps
----------------------------------------
1. Click **Memberships->Import Memberships**
1. Import any membership data CSV file with a Member Since column and map that to the import
1. After import, note that the current date was used on all created membership records
Current behaviour
----------------------------------------
Memberships are always imported with Member Since as current date, regardless of provided Member Since value in mapped import
Expected behaviour
----------------------------------------
Memberships are created with the mapped Member Since date
Comments
----------------------------------------
Looking into the code, I noticed that ` \CRM\MemberImport\Parser\Membership.php ` has been modified extensively to map `membership_start_date` and `membership_end_date` to `start_date` and `end_date` values in the final formatted parameter set. However, `membership_join_date` is left alone and unformatted and a default-value `join_date` is created instead. This resulting structure appears to be fed into the Membership::create() method.
A modification of that code file which adjusts `membership_join_date` in the same way as the other values results in a correctly imported Member Since value. I have NOT tested this modification with the Membership import in an update context, however.5.21.0https://lab.civicrm.org/dev/core/-/issues/1482Remove code to create a subscription history entry when a contact is created2019-12-22T22:53:31ZeileenRemove code to create a subscription history entry when a contact is createdI feel like these lines are part of an idea in the early days of Civi that faded out & we should remove them
```
// make a civicrm_subscription_history entry only on contact create (CRM-777)
if (empty($params['contact_id'])) {
...I feel like these lines are part of an idea in the early days of Civi that faded out & we should remove them
```
// make a civicrm_subscription_history entry only on contact create (CRM-777)
if (empty($params['contact_id'])) {
$subscriptionParams = [
'contact_id' => $contact->id,
'status' => 'Added',
'method' => 'Admin',
];
CRM_Contact_BAO_SubscriptionHistory::create($subscriptionParams);
}
```
The referenced JIRA is https://issues.civicrm.org/jira/browse/CRM-777
(I only noticed them because they failed due to a deadlock - https://lab.civicrm.org/dev/core/issues/1481)5.22.0https://lab.civicrm.org/dev/core/-/issues/1480Ubuntu 19.10 MySQL 8 and 'grouping' keyword in OptionGroup.php2020-01-02T00:07:08Zthoni56Ubuntu 19.10 MySQL 8 and 'grouping' keyword in OptionGroup.phpCiviCRM 5.19.3
Joomla 3.9.11
Ubuntu 19.10
Updating Ubuntu from 19.04 to 19.10 will pull in MySQL v8. It is a known issue (https://lab.civicrm.org/dev/core/issues/392) that `grouping` now became a reserved word which caused some problems...CiviCRM 5.19.3
Joomla 3.9.11
Ubuntu 19.10
Updating Ubuntu from 19.04 to 19.10 will pull in MySQL v8. It is a known issue (https://lab.civicrm.org/dev/core/issues/392) that `grouping` now became a reserved word which caused some problems.
I found an instance of this in `OptionGroup.php`. On line 124 (https://lab.civicrm.org/dev/core/blob/master/CRM/Core/OptionGroup.php#L124) :
SELECT v.{$labelColumnName} as {$labelColumnName} ,v.{$keyColumnName} as value, v.grouping as grouping
This caused our whole site to `DB Error syntax error` since the first page is an event listing.
I did not have the time to figure out if there actually was some further use of that identifier, since the full query is built in run-time. Seems like an easy fix anyway.
Just single-quoting the grouping-word on that line brought it back for us. And a quick test seems to indicate that the site works ok.
I'm volunteering to staying on MySQL 8 for now to flesh out any further issues. Worst case, I'll downgrade MySQL.5.22.0seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/1477Trying to edit the settings for a reserved option group gives a network error...2019-12-14T03:32:47ZDaveDTrying to edit the settings for a reserved option group gives a network error can't connect to serverIt seems to be from https://github.com/civicrm/civicrm-core/pull/15937 where the `name` textbox was removed from the form but then it tries to "freeze" it later if it's reserved.
PR coming.It seems to be from https://github.com/civicrm/civicrm-core/pull/15937 where the `name` textbox was removed from the form but then it tries to "freeze" it later if it's reserved.
PR coming.5.21.0