Development issueshttps://lab.civicrm.org/groups/dev/-/issues2018-08-15T20:00:54Zhttps://lab.civicrm.org/dev/core/-/issues/331Export contributions - missing Field Mapping dropdown2018-08-15T20:00:54ZhfarooqExport contributions - missing Field Mapping dropdownCivicrm: 5 (tested on 5.31, 5.40)
Drupal: 7.59
I was able to reproduce on CIVICRM DEMO site: https://demo.circle-interactive.co.uk
Steps to reproduce:
1. Find contributions
2. Select a few of them
3. Select action 'Export contributions...Civicrm: 5 (tested on 5.31, 5.40)
Drupal: 7.59
I was able to reproduce on CIVICRM DEMO site: https://demo.circle-interactive.co.uk
Steps to reproduce:
1. Find contributions
2. Select a few of them
3. Select action 'Export contributions'
4. Select option 'Select fields for export'
A dropdown should display to let use select fields for mapping but in civicrm version 5 that div id '#map' do not have any content.https://lab.civicrm.org/dev/core/-/issues/328Reports: don't add query to developer tab if we are downloading the data2018-08-15T20:11:09ZjamieReports: don't add query to developer tab if we are downloading the dataWhen running a report, if you choose an output format of pdf, print or csv (others?) the developer tab is not displayed, so adding queries to this tab is wasted CPU cycles.
It would not be such a big deal except I discovered that in som...When running a report, if you choose an output format of pdf, print or csv (others?) the developer tab is not displayed, so adding queries to this tab is wasted CPU cycles.
It would not be such a big deal except I discovered that in some cases, it can cause CiviCRM to hang for a very long time. For example, if you run CRM_Report_Form_Contribute_Detail with more than 1,000 records and try to download as a CSV file, it will hang for more time than I have patience for.
The cause comes from https://github.com/civicrm/civicrm-core/pull/11898 (ping @eileen) - in which a few extra sql statements are helpfully added to the developers tab - but they are sql statements that are execute for each row in the results.
The addition of the sql statements to the developers tab is not a big deal under normal operations (since most reports limit to just 50 rows per page), however, when downloading via csv then all the rows are returned, so addToDeveloperTab gets called once for each row and that seems to gum up the works.
We could arguably remove any call to addToDevelopersTab that would operate on each row, but I think if we just add something like this to the addToDevelopersTab function it would be more flexible:
```
$ignored_output_modes = array('pdf', 'csv', 'print');
if (in_array($this->_outputMode, $ignored_output_modes)) {
return;
}
```
What do others think?5.6https://lab.civicrm.org/dev/core/-/issues/333testTargetAddressFields() in 5.5 fails half the time2018-08-16T05:58:55ZtottentestTargetAddressFields() in 5.5 fails half the timeThe test `CRM_Report_Form_ActivityTest::testTargetAddressFields()` was added in 5.5. 5.5 is the current RC, and test is failing frequently -- about half the time. ([Recent build history](https://test.civicrm.org/job/CiviCRM-Core-Matrix/C...The test `CRM_Report_Form_ActivityTest::testTargetAddressFields()` was added in 5.5. 5.5 is the current RC, and test is failing frequently -- about half the time. ([Recent build history](https://test.civicrm.org/job/CiviCRM-Core-Matrix/CIVIVER=5.5,label=ubuntu1204/))
I think the problem traces to [this line](https://github.com/civicrm/civicrm-core/pull/11660/files#diff-9b126bfd3563d59749fc7aac722e04ceR155). Evidently, the ordering must be non-deterministic -- i.e. both `India;United States` and `United States;India` come up in practice.
I don't know if that variation is acceptable or not. If it is acceptable, then the simplest change would be to make the assertion a logical `OR` (e.g. assert that `$rows[0]['civicrm_address_country_id']` is either `India;United States` or `United States;India`). If the variation is significant... then I guess that would require something else...?
@monish.deb, can you figure out a patch for 5.5?5.5.0https://lab.civicrm.org/dev/release/-/issues/15.x - Update version-numbering pattern2018-08-17T00:17:24Zcolemanw5.x - Update version-numbering pattern## Tasks
* [x] `civicrm.org` - Update extension validation to accept 4.7 as synonym for 5.x
* [x] `civicrm.org` - Update extension validation to allow forward compatibility within 5.x series
* [x] *Upgrader* and `set-version` - Allow on...## Tasks
* [x] `civicrm.org` - Update extension validation to accept 4.7 as synonym for 5.x
* [x] `civicrm.org` - Update extension validation to allow forward compatibility within 5.x series
* [x] *Upgrader* and `set-version` - Allow one to easily increment middle digit
* [ ] [doc](https://lab.civicrm.org/development-team/Release-Management/tree/master/doc) - Update RM docs
* [x] `5.x-rc.md`
* [x] `5.x-final.md`
* [x] `5.x-patch.md`
* [x] `test.civicrm.org` - Assess/update CI:
* [x] `civi-test-run`
* [x] `civibuild upgrade-test`
* [x] https://test.civicrm.org/job/CiviCRM-Core-Matrix/
* [x] https://test.civicrm.org/job/CiviCRM-Ext-Matrix/
* [x] https://test.civicrm.org/job/CiviCRM-WebTest-Matrix/
* [x] https://test.civicrm.org/job/CiviCRM-Core-PR/
* [x] https://test.civicrm.org/job/CiviCRM-Backdrop-PR/
* [x] https://test.civicrm.org/job/CiviCRM-Drupal-PR/
* [x] https://test.civicrm.org/job/CiviCRM-Packages-PR/
* [x] https://test.civicrm.org/job/CiviCRM-Publish/
* [x] https://test.civicrm.org/job/CiviCRM-Publish-Watch-Core/
* [x] http://download.civicrm.org/latest - Display multiple autobuilds/pre-releases simultaneously
* [x] `civicrm-core` - Trial run, using installer/upgrader/distmaker/test-suite on v5.0
* [x] `civicrm-core` - Update various copyright headers from "4.7" to "5.x".
* [ ] `civicrm-drupal` - SPECME: The *.info files are set to 4.7 and twiddled on release. For git-based deployments, should we do anything to maintain these?
* [ ] `civicrm-wordpress` - SPECME: The `civicrm.php` file is set to 4.7 and twiddled on release. For git-based deployments, should we do anything to maintain these?
* [ ] *Extension author outreach* - Grep universe for READMEs/docs. Send mail-blast with suggested updates.
* [ ] `civicrm-core` - The file `js/crm.angular.js` has a function with a "remove me" notice
* [x] `docs-publisher` - https://lab.civicrm.org/documentation/docs-publisher/merge_requests/87
* [x] `civicrm-sysadmin-guide` - https://github.com/civicrm/civicrm-sysadmin-guide/pull/75
## FAQ
__Q: Would it be better to say `v4.8.0` vs `v5.0.0` vs `v5.1803.0` vs `v18.3.0` vs `v33.0.0`?__
They're all basically the same. All of these options will give *someone* the heebeegeebees -- because we've been doing 4.7.x for two years, and anything that looks different will look different, and different is scary.
The fundamental message should be this:
* The change in number is superficial.
* The substantive editorial/QA regime for `v5.{$Y}.0` is (initially) the same as the previous `v4.7.{$Z}`.
* The new numbering makes it to easier to administer minor patch updates, enabling us to consider more fine-tuned maintenance regimes.
There are bikesheddy reasons to favor one or another.
__Q: But I think there should be substantive change!__
Grand! Please head over to #2 to weigh-in on proposals or add new ones! (Or, if you want to focus-in on the [main review criteria](https://docs.civicrm.org/dev/en/latest/standards/review/), feel free to open a pull-request in [civicrm-dev-docs](https://github.com/civicrm/civicrm-dev-docs).)
__Q: Does this mean you're going to start making more, bigger, scarier changes more often?__
No. This is strictly a superficial realignment of the numbers. In fact, the general tenor of editorial policy has been toward tightening rather than loosening standards.
https://lab.civicrm.org/dev/core/-/issues/316Use cache keys which are compatible with supported backends (CiviCRM 5.4 vs M...2018-08-17T00:40:54ZxurizaemonUse cache keys which are compatible with supported backends (CiviCRM 5.4 vs Memcache)[Reported by @haystack in ~dev channel](https://chat.civicrm.org/civicrm/pl/yo7drhis3pgg3cemfzuctd6ixr), suggested that it's a result of #174 changes.
After upgrading to CiviCRM 5.4 when using Memcache:
> Memcached::get(/CiviCRM Sessio...[Reported by @haystack in ~dev channel](https://chat.civicrm.org/civicrm/pl/yo7drhis3pgg3cemfzuctd6ixr), suggested that it's a result of #174 changes.
After upgrading to CiviCRM 5.4 when using Memcache:
> Memcached::get(/CiviCRM Session//_CRM_Activity_Form_ActivityFilter_851ce9ce57b6137a76ba5239cc2b6a6d_3667_container) failed: A BAD KEY WAS PROVIDED/CHARACTERS OUT OF RANGE
> Memcached set (/CiviCRM Session//_CRM_Event_Form_Search_023fbd690622b4991938e06757805c3e_6468_container) failed
[memcached/doc/protocol.txt](https://github.com/memcached/memcached/blob/master/doc/protocol.txt) has,
> the key must not include control characters or whitespace.
[Also noted on Stack Exchange](https://stackoverflow.com/questions/5826768/can-memcached-keys-contain-spaces).https://lab.civicrm.org/dev/core/-/issues/273"Recipient phone number is invalid or recipient does not want to receive SMS"...2018-08-18T21:44:11Zjyothi"Recipient phone number is invalid or recipient does not want to receive SMS" error and Contacts with DoNotSms preference failing to filter out during Mass Sms in 5.x"Recipient phone number is invalid or recipient does not want to receive SMS" error occurs during individual SMS. https://civicrm.stackexchange.com/questions/25478/clickatell-sms-recipient-phone-number-is-invalid-or-recipient-does-not-wa..."Recipient phone number is invalid or recipient does not want to receive SMS" error occurs during individual SMS. https://civicrm.stackexchange.com/questions/25478/clickatell-sms-recipient-phone-number-is-invalid-or-recipient-does-not-want-to.
Contacts marked as 'donotsms' is not filtered out during mass SMS.5.5.0https://lab.civicrm.org/dev/core/-/issues/341"Contributions made in Year X and not Year Y" custom search ignores date field2018-08-19T22:11:13Zlcdweb"Contributions made in Year X and not Year Y" custom search ignores date fieldThe "Contributions made in Year X and not Year Y" custom search ignores date field parameters.The "Contributions made in Year X and not Year Y" custom search ignores date field parameters.5.6lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/322Contribution page, completing this form on behalf of someone else: JavaScript...2018-08-19T22:47:31ZdavejContribution page, completing this form on behalf of someone else: JavaScript error for checkbox fieldOn a contribution page, when "completing this form on behalf of someone else", a JavaScript syntax error occurs when the page includes a profile with a checkbox field and the contact has this field checked.
Steps to replicate:
1. Creat...On a contribution page, when "completing this form on behalf of someone else", a JavaScript syntax error occurs when the page includes a profile with a checkbox field and the contact has this field checked.
Steps to replicate:
1. Create a custom field, Test Checkbox: Alphanumeric, CheckBox with 1 option:
label "I agree", value 1.
2. Create a profile including this field.
3. Include this profile on a contribution page.
4. Edit Contact A and check the "I agree" checkbox.
5. On the contribution page, click "Not demo test, or want to do this for a different person?"
6. Choose Contact A.
Expected result:
Form populates with Contact A's data.
Actual result:
JavaScript error: "Syntax error, unrecognized expression: [name=custom_13[1]]".
Form does not populate with Contact A's data.
I have a fix for this, will create a PR & link to this issue.5.6https://lab.civicrm.org/dev/core/-/issues/226use decimal point from config to fix european numbers format2018-08-19T22:52:39Zsuniluse decimal point from config to fix european numbers formatFormat Amount using hardcoded decimal point, which is not fit for european format.Format Amount using hardcoded decimal point, which is not fit for european format.5.6https://lab.civicrm.org/dev/core/-/issues/202Empty row under currency drop down2018-08-20T15:21:29ZPradeep Nayakpradpnayak@gmail.comEmpty row under currency drop downThis is something i noticed on drupal7, CiviCRM 5.2.1 fresh install where i don't have default currency set under(Settings - Localization). The currency field on New Contribution and elsewhere shows an empty option as attached in screens...This is something i noticed on drupal7, CiviCRM 5.2.1 fresh install where i don't have default currency set under(Settings - Localization). The currency field on New Contribution and elsewhere shows an empty option as attached in screenshot
![Before](/uploads/672ac199ab60d3763a20d1c5968616b9/Before.png)
PR at https://github.com/civicrm/civicrm-core/pull/123565.4.0https://lab.civicrm.org/dev/joomla/-/issues/2Joomla cron.php/cli.php fail on Windows server2018-08-21T05:41:13ZAndrew ThompsonJoomla cron.php/cli.php fail on Windows serverThis issue was raised on StackExchange by another user:
https://civicrm.stackexchange.com/questions/24867/compatibility-problem-with-joomla-3-8-7-and-civicrm-5-0-1-that-affects-cron
With CiviCRM running on Joomla on Windows, cron jobs f...This issue was raised on StackExchange by another user:
https://civicrm.stackexchange.com/questions/24867/compatibility-problem-with-joomla-3-8-7-and-civicrm-5-0-1-that-affects-cron
With CiviCRM running on Joomla on Windows, cron jobs fail.
```
require(C:\Apache24\htdocs\joomla\administrator\components\com_civicrm\civicrm\administrator\includes\defines.php): failed to open stream: No such file or directory in C:\Apache24\htdocs\joomla\administrator\components\com_civicrm\civicrm\CRM\Utils\System\Joomla.php on line 559
```
It is caused by this line in ```CRM\Utils\System\Joomla.php```:
```
$joomlaPath = explode('/administrator', $civicrm_root);
```
The forward slash is not matched on Windows systems, which results in an incorrect path to Joomla. The solution is to replace it with DIRECTORY_SEPARATOR.
PR: https://github.com/civicrm/civicrm-core/pull/126925.6https://lab.civicrm.org/dev/core/-/issues/304Upgrade from 4.7.27 to 5.4.0 failed on activity_default_assignee (also 5.3.2 ...2018-08-22T13:29:57ZdavejUpgrade from 4.7.27 to 5.4.0 failed on activity_default_assignee (also 5.3.2 failed on Monmouthshire)Trying to upgrade a test site from 4.7.27 using drush cvupdb. D7, PHP 5.6.36, MySQL 5.5.60 . Cleared templates_c/en_* before upgrading.
4.7.27 to 5.4.0 fails with:
```
CiviCRM_API3_Exception: "'activity_default_assignee' is not a valid ...Trying to upgrade a test site from 4.7.27 using drush cvupdb. D7, PHP 5.6.36, MySQL 5.5.60 . Cleared templates_c/en_* before upgrading.
4.7.27 to 5.4.0 fails with:
```
CiviCRM_API3_Exception: "'activity_default_assignee' is not a valid option for field option_group_id"
#0 .../sites/all/modules/civicrm/CRM/Core/BAO/OptionValue.php(560): civicrm_api3("OptionValue", "get", (Array:4))
#1 .../sites/all/modules/civicrm/CRM/Upgrade/Incremental/php/FiveFour.php(108): CRM_Core_BAO_OptionValue::ensureOptionValueExists((Array:5))
#2 [internal function](): CRM_Upgrade_Incremental_php_FiveFour::addActivityDefaultAssigneeOptions(Object(CRM_Queue_TaskContext))
#3 .../sites/all/modules/civicrm/CRM/Queue/Task.php(88): call_user_func_array((Array:2), (Array:1))
1:31 PM
```
version in civicrm_domain at this point is 5.4.alpha1.upgrade . I re-tried, dropping db & restoring from pre-upgrade dump, same result.
Also a less serious issue, as presumed due to someone manually adding Monmouthshire to db in the past...
4.7.27 to 5.3.2 fails with:
```
PEAR_Exception: "DB Error: already exists"
* ERROR TYPE: DB_Error
* ERROR CODE: -5
* ERROR MESSAGE: DB Error: already exists
* ERROR MODE: 16
* ERROR USERINFO: INSERT INTO civicrm_state_province (country_id, abbreviation, name)
VALUES (@UKCountryId, 'MON', 'Monmouthshire') [nativecode=1062 ** Duplicate entry 'Monmouthshire-1226' for key 'UI_name_country_id']
* ERROR DEBUGINFO: INSERT INTO civicrm_state_province (country_id, abbreviation, name)
VALUES (@UKCountryId, 'MON', 'Monmouthshire') [nativecode=1062 ** Duplicate entry 'Monmouthshire-1226' for key 'UI_name_country_id']
#0 [internal function](): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#1 .../sites/all/modules/civicrm/packages/PEAR.php(921): call_user_func((Array:2), Object(DB_Error))
#2 .../sites/all/modules/civicrm/packages/DB.php(985): PEAR_Error->__construct("DB Error: already exists", -5, 16, (Array:2), "INSERT INTO civicrm_state_province (country_id, abbreviation, name)\nVALUES (...")
```
version in civicrm_domain is 5.3.0.upgrade at this point.
I suspect Monmouthshire had previously been added manually. Resolved by manually removing it, setting the existing address records using it to state_province_id NULL, then to the new id.
Then tried 5.3.2 to 5.4.0 and it worked.https://lab.civicrm.org/dev/core/-/issues/361Mistake in Case api spec description2018-08-25T21:02:02ZkainukMistake in Case api spec descriptionThe description for the `tag_id` parameter should be
"Find cases with specified tags."
instead of
"Find activities with specified tags."
![civiIssue](/uploads/ad4d069b1fbea34dda1917ab65d8646b/civiIssue.png)The description for the `tag_id` parameter should be
"Find cases with specified tags."
instead of
"Find activities with specified tags."
![civiIssue](/uploads/ad4d069b1fbea34dda1917ab65d8646b/civiIssue.png)https://lab.civicrm.org/dev/core/-/issues/278DB syntax error when try to search deleted cases2018-08-26T21:58:57ZscardiniusDB syntax error when try to search deleted casesOverview
----------------------------------------
Fix DB syntax error when try to search deleted cases.
Before
----------------------------------------
* open Cases > Find Cases
* select Deleted Cases checkbox
* click Search button
* re...Overview
----------------------------------------
Fix DB syntax error when try to search deleted cases.
Before
----------------------------------------
* open Cases > Find Cases
* select Deleted Cases checkbox
* click Search button
* result: DB Error: syntax error
[case-search-deleted](/uploads/9123a9941405b60f36c1ecf6a9a47021/case-search-deleted.png)
After
----------------------------------------
Searching for deleted and non-deleted cases works fine.
Technical Details
----------------------------------------
There was invalid argument in getCaseActivityQuery() method - for $limit argument was used $cases['case_deleted']
```php
-- invalid
$query = self::getCaseActivityQuery($type, $userID, $condition, $cases['case_deleted']);
-- fixed
$query = self::getCaseActivityQuery($type, $userID, $condition);
```https://lab.civicrm.org/dev/core/-/issues/363Getting “DB Error: syntax error” When searching for Deleted cases2018-08-26T21:58:57ZPradeep Nayakpradpnayak@gmail.comGetting “DB Error: syntax error” When searching for Deleted caseshttps://civicrm.stackexchange.com/questions/26269/getting-db-error-syntax-error-when-searching-for-deleted-cases
Works fine on 4.6.x
Regression : https://github.com/civicrm/civicrm-core/pull/7592
Fixed PR : https://civicrm.stackexchange.com/questions/26269/getting-db-error-syntax-error-when-searching-for-deleted-cases
Works fine on 4.6.x
Regression : https://github.com/civicrm/civicrm-core/pull/7592
Fixed PR : https://lab.civicrm.org/dev/core/-/issues/319Advanced search export: when location types' display names are different from...2018-08-27T01:41:01ZnoahAdvanced search export: when location types' display names are different from their machine names, empty columns are exportedEDITED to be more accurate following further investigation into the symptoms.
This is a regression in the last couple versions of Civi (I see it on 5.3.1 and 5.4.0, as well as 5.5-rc and master).
**Summary:** When exporting from advanc...EDITED to be more accurate following further investigation into the symptoms.
This is a regression in the last couple versions of Civi (I see it on 5.3.1 and 5.4.0, as well as 5.5-rc and master).
**Summary:** When exporting from advanced search, if you select email/phone/address fields to export _where the location type's display name is different from its machine name_, the headers for those columns will be included in the export, but the cells in those columns will be blank.
**To reproduce:**
1. Create a location type called "Field Office" with machine name "FieldOffice" or "FO"
1. Create a contact with a "Field Office" email.
1. Find that contact using advanced search and select the "export" task.
1. Select "Individual - Email - Field Office" as a field to export.
1. In the resulting CSV, there's a blank cell where the email address should be.
**Notes:** I also notice:
* the columns in the export are not in the same order as on the export column selection screen.
* exporting from Search Builder has a similar-but-different problem: if two location types are selected for export, only one of the columns will successfully be exported.
I see that quite a bit of work has gone into the Export code in recent releases and I suspect this regression happened as a result.
I'm interested in creating tests for this but I'd need someone to hold my hand through the process, as I have no recent experience doing that.5.5.0https://lab.civicrm.org/dev/core/-/issues/295Default 'from' mail address is not the default one showing in 'send email'2018-08-27T11:18:09ZjitendraDefault 'from' mail address is not the default one showing in 'send email'SE Post - https://civicrm.stackexchange.com/questions/25562/why-does-the-default-from-email-address-not-show-as-the-first-option-when-usin
If I add a second email address to the list of "from" emails at /civicrm/admin/options/from_email...SE Post - https://civicrm.stackexchange.com/questions/25562/why-does-the-default-from-email-address-not-show-as-the-first-option-when-usin
If I add a second email address to the list of "from" emails at /civicrm/admin/options/from_email_address?reset=1 and set it to default, i expect it to be selected as the first option when using "Send an Email' but it continues to be the second in the list.
If i change the Order of the From emails so my default is first, it continues to show as the second when using "Send an Email' (though perhaps a clear of caches would fix it, but fundamentally something seems wrong here.jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/297permission "access my cases and activities" is broken by CRM-214612018-08-28T01:29:10ZDaveDpermission "access my cases and activities" is broken by CRM-21461See https://civicrm.stackexchange.com/questions/25950/problem-with-civicase. CRM_Case_BAO_Case::getCases() used to return a list keyed on case_id. Now it returns a sequentially keyed list. I'm not sure if anything new is depending on the...See https://civicrm.stackexchange.com/questions/25950/problem-with-civicase. CRM_Case_BAO_Case::getCases() used to return a list keyed on case_id. Now it returns a sequentially keyed list. I'm not sure if anything new is depending on the new keys, but since that seems unlikely, replacing "$key" with "$case['case_id']" around line 680 and later instances would fix this?https://lab.civicrm.org/dev/translation/-/issues/14InnoDB Advanced Logging cannot be enabled on multi-lingual2018-08-28T09:41:10ZbgmInnoDB Advanced Logging cannot be enabled on multi-lingualHow to reproduce:
* Install/configure a multi-lingual CiviCRM site with 2 languages
* Enable the [innodbtriggers](https://github.com/mlutfy/nz.co.fuzion.innodbtriggers) extension
* Run: `System.updatelogtables` to update the log tables....How to reproduce:
* Install/configure a multi-lingual CiviCRM site with 2 languages
* Enable the [innodbtriggers](https://github.com/mlutfy/nz.co.fuzion.innodbtriggers) extension
* Run: `System.updatelogtables` to update the log tables.
Result: fatal error, as encountered here: https://github.com/eileenmcnaughton/nz.co.fuzion.innodbtriggers/issues/1
Related, but not a duplicate: dev/translation#85.6bgmbgmhttps://lab.civicrm.org/dev/core/-/issues/349Scheduled reminders list default sort does not work2018-08-28T11:11:10Zmagnolia61Scheduled reminders list default sort does not workThe Scheduled Reminder list default sort does not work because of a small typo.
This PR corrects that.The Scheduled Reminder list default sort does not work because of a small typo.
This PR corrects that.5.6