GitLab

Note: `enableComponents` is heavily used, but `enableComponentIDs` is only
used once.  Generally, it's much easier to write tests based on names
(`enableComponents`) than IDs (`enableComponentIDs`).

Conflicts:
	composer.json

CRM_Core_BAO_Setting::getItem() - Fix calls which use deprecated parameters. Fix dedupe_email_default conflict.

For `dedupe_email_default`, the default values in `getItem()` and in
`settings/` disagree.  The default in `settings/` seems better IMHO.

This was a weird one:

 * The admin form rendered HTML element "checksumTimeout" but saved setting "checksum_timeout", which required workarounds.
 * The runtime code read the setting as "checksum_timeout".
 * The metadata defined setting "checksumTimeout". `prefetch` is enabled, but there's no `config_key` or `legacy_key`.

I believe this means that the runtime and admin form worked (because they
agreed that the name was "checksum_timeout"), but the Setting API would not
work (because it used "checksumTimeout").

This revision standardizes on "checksum_timeout" on the theory that
"checksum_timeout" was the actual value used at runtime. This means:

 * If you had configured the form and had it working correctly, it should
   still work correctly.
 * If you had a script to set "checksumTimeout" via API, then it wasn't
   working before, and it's still not working now.

CRM-17223 - fix for cvv2 failure.

CRM-17205 -- Fix for broken Free event registration

CRM-14232 add setting for default contact language.

CRM-16555 - Fix double-processors on backend credit card event form

If a contact is created & the preferred_language is not set this
setting can be used to manipulate the default.

Tests!

Conflicts:
	settings/Localization.setting.php

CRM-14232 adjust options for default contact language

To reflect bgm suggestions  - add current language & remove long-list of countries

CRM-14232 contact default language setting: don't use null as it has special handling

----------------------------------------
* CRM-17223: PayJunction CVV Transactions Fail
  https://issues.civicrm.org/jira/browse/CRM-17223

CRM-17075 convert membership_type_id field to entity_reference field in search

CRM-17169 - Inconsistent Soft Credit Reporting

Running the fetch_activities cli task stops with a fatal error when t…

Conflicts:
	CRM/Admin/Form/Setting/Localization.php
	CRM/Event/BAO/Query.php
	CRM/Export/BAO/Export.php
	CRM/Financial/Page/AJAX.php
	templates/CRM/Event/Form/Registration/Register.tpl
	tests/phpunit/CRM/Contribute/BAO/ContributionTest.php
	tests/phpunit/api/v3/ContactTest.php
	tests/phpunit/api/v3/SyntaxConformanceTest.php

comment fixes

Comments formatting

CRM-16941 test failure fix

CRM-17207 - Use mailto link on contact summary when outbound email is…

CRM-16584 Remove line causing fatal error

----------------------------------------
* CRM-16941: Search Form and api.Get fixes for Contact
  https://issues.civicrm.org/jira/browse/CRM-16941

This commit also adds generic handling for changing select fields to
entity reference fields with tests to ensure previous smart group
behaviour is respected by handling within the convertFormValues function.

This reverts advanced search domain filtering to ?4.4? 4.5? behaviour which does not assume only that domain's memberships should be searched on.

It make be that domain filtering + allowing an override makes most sense. I did think the pseudoconstant & getoptions use the same
mechanism, but it seems they don't. Really they should both allow the same behaviour & override

Until such time as a hook allows overriding of the domain assumptions we should not limit this by domain in advanced search
(which leverages the getoptions via use of an entity reference field

comment fixes