CIVI-28 Added permissions for Drupal page

CIVI-28 Added permission check for admin financial type

CIVI-28 Added permission check for Contribution page

CIVI-28 Added permission cehck for offline contribution form

CIVI-28 Added permissions for Drupal permission pages

Merge remote-tracking branch 'upstream/4.6' into 4.6-master-2015-09-21-15-52-41

Conflicts:
CRM/Contribute/BAO/ContributionPage.php
CRM/Core/Resources.php

Merge pull request #6712 from jitendrapurohit/CRM-17146-tests

Test to check CRM-17146 - include trxn_date in completetransaction API

Merge pull request #6776 from totten/master-setting-redux

CRM-16373 - $config - Separate runtime and boot services

Fix api_v3_ContactTest.testContactGetBy*Username

Construct runtime+extensions+container through boot services

Convert $config->userSystem to boot service

CRM-16373 - Bootstrap subsystems in more predictable order

Several subsystems were initialized on-demand. This had a weird side-effect
where the container would start initializing and call another service, which
would then (indirectly) try to initialize another container. The two container
instances would not be the same.

This revision enforces a more carefully considered sequence of events (which
will be documented in the wiki page, "Bootstrap Reference").

CRM_Core_Error - Don't display HTML crash when running tests

CRM-16373 - MagicMerge - Improve comments/readability.

Merge pull request #6774 from totten/master-fs25

composer.json - Use symfony/filesystem circa 2.5

composer.json - Use symfony/filesystem circa 2.5

The rest of the Symfony components are targetting ~2.5, but some reason
we're autoselecting `symfony/filesystem` ~2.7.  That produces errors on
`test-debian6-1`.

Merge pull request #6773 from civicrm/eileenmcnaughton-patch-1

CRM-16555 add code-comments

CRM-16555 add code-comments

The patch added for CRM-16555 should not have been needed as the intention was that the function to getValidProcessors handling for mode would have worked. Adding some comments to indicate this for next time someone looks at it.

Merge pull request #6771 from seamuslee001/CRM-17231-Master

CRM-17231 Allow for Multipart Report to be included in the Email Processor

Merge pull request #6769 from monishdeb/CRM-17191

CRM-17246 fix - Contact name showing in Contribution summary report

PHPCS fixes

Further tweeks following testing

PHPCS fixes

CRM-17231 Allow for Multipart Report to be included in the Email Processor

Merge pull request #6755 from agileware/master-crm-17055

CRM-17055: Confirmation email on unpaid events produces syntax error …

Merge pull request #6770 from monishdeb/CRM16920

CRM-16920 - When coding a report template, can specify a default 'fro…

CRM-16920 - When coding a report template, can specify a default 'from' and 'to' for date ranges, but not for integer ranges

https://issues.civicrm.org/jira/browse/CRM-16920

format fix

CRM-17246 fix - Contact name showing in Contribution summary report

https://issues.civicrm.org/jira/browse/CRM-17246

Merge pull request #6768 from totten/master-composer-lock

composer.lock - update

composer.lock - update

Previous merges left composer.lock with incorrect hash

Merge pull request #6766 from monishdeb/CRM-17191

Crm 17191

Merge pull request #6764 from davecivicrm/CRM-15378

CRM-15378 - Add max participants and count to price option browse page.

notice and format fixes

CRM-17191 - removing redundant if clause.

CRM-17191 - ensure Participant list report works with custom Grouping

Previously, we got a trace back if a user defined a group by clause.
I've removed what appears to be crufty code that tries to add the
group by fields to an ORDER BY statement - which conflicts with the
existing ORDER BY statement and seems unnecessary. Also, if the user
wants to group by another field, we should not group by the participant
id.

Merge pull request #6756 from agileware/4.6-crm-17055

CRM-17055: Confirmation email on unpaid events produces syntax error …

Merge pull request #6757 from yashodha/CRM-17227

CRM-17227: Error thrown while saving profile in Contribution page

Merge pull request #6765 from totten/master-cdl

CRM-14232, CRM-16373 - Fix saving of contact_default_language

CRM-14232, CRM-16373 - Fix saving of contact_default_language

Merge pull request #6542 from totten/master-setting-helper

CRM-16373 - $config based on settings (no config_backend). Use Civi:: helper.

Merge pull request #6761 from eileenmcnaughton/CRM-17233

CRM-17233 payment block showing in edit mode on contribution page

CRM-15378 - Add max participants and count to price option browse page.

----------------------------------------
* CRM-15378: Include Max Participants and Participant Count columns when viewing price field options
  https://issues.civicrm.org/jira/browse/CRM-15378

civicrm_generated.mysql - regen

CRM-16373 - Path, URL Admin - Explain variables

SettingsManager::getSystemDefaults() - Return defaults even for critical boot settings

This fixes some issues in tests involving enableComponents.

Upshot: The UI for setting URLs/directories now displays the default values properly.

CRM_Core_BAO_Setting - Don't prefill settings

It's no longer necessary to prefill settings because defaults are loaded in
real(ish) time.

Removing this because it depends on ConfigSetting functions which I'd
like to also remove.

CRM_Admin_Form_Preferences - Fix loading of settings

CRM-16373 - Migrate config_backend to civicrm_setting

There are two steps at which we convert config_backend:

 * In loading the upgrade environment, we may need access to old settings.
   So SettingsBag supports reading config_backend for the active domain.
 * As a specific upgrade step (for 4.7.alpha1), we migrate all values
   for all domains (unless there's already a setting).

CRM_Core_Config - Expose userFrameworkVersion, replyTo, versionCheck, initialized

The first three were migrated to settings; although core no longer accesses them on $config,
we may need to migrate them, and it doesn't hurt to provide them for backward-compatibility.

Initialized was a just a bug.

CRM-14707 - CRM_Utils_Hook::runHooks - Cache function names

CRM-14707 - CRM_Core_BAO_Cache::setItem - Don't fire hooks

Memcache for extension, setting, and string caches

CRM_Core_Config - Simplify. Current cache commands are pointless.

MagicMerge - Changes to properties should not be persistent across requests

Remove CRM_Core_Config_Defaults

MagicMerge - Per-request cache of path/url properties

Civi::paths() - Decouple settings from paths. Allow path vars.

There has been a policy underwhich paths and URLs are assumed to be relative
to different points (urls => webroot; paths => sites/*/files/civicrm).  For
some settings, this is fairly confusing.  The policy had been encoded in
`SettingsBag::getPath` and `SettingsBag::getUrl`.  It's particularly
confusing because (sometimes) the default value of a specific property isn't
really aligned with the policy.

This revision attempts to cleanup in two ways:

 1. It removes policy from `SettingsBag` and puts it in `Civi\Core\Paths`.
 2. It makes the policy less important by allowing variables in the paths.
   * `[civicrm.files]/upload` might evaluate to `/var/www/sites/default/files/civicrm/upload`
   * `[cms.root]/myuploads` might evaluate to `/var/www/myuploads`

The revision also updates MagicMerge to store various path and URL policies
in `getPropertyMap()` rather than adhoc callbacks.

CRM-16373 - rm CRM_Core_Config_Variables

civicrm_navigation.tpl - Move defaults into settings/*.php

For a large number of settings, defaults are declared twice -- once in
`xml/templates/civicrm_navigation.tpl` and once in `settings/*.php`.  In
many cases, these are identical/redundant, but there are a couple where the
defaults diverged.

I believe the `civicrm_navigation.tpl` values have generally taken precedent
on new installations, so this commit revises `settings/*.php` to fix any
discrepancies.

SettingsBag::setDb() - Merge in CRM_Core_BAO_Setting::_setItem and ::dao()

CRM_Core_BAO_Setting - Remove redundant static cache

Before CRM-16373, the setting cache was stored in a static property of the
BAO.  This data is now loaded into objects -- which are stored in the
container.

This is essentially the same for a typical request, and (for unit-testing)
it provides simpler cleanup between tests.

CRM-16373 - SettingsManager - useMandatory() to apply post-boot changes

Note: The global `$civicrm_setting` is meant to provide sysadmins with a way
to override settings in `civicrm.settings.php`, but it has traditionally
been possible for extensions to manipulate `$civicrm_setting` in a hook.  If
you do this, please call `useMandatory()` to tell SettingsManager to re-scan
`$civicrm_setting`.

SettingsBag - Add getDefault(), getMandatory(). Cleanup comments.

settings/ - Add comment about critical/bootstrap settings.

CRM-16373 - Simplify UpdateConfigBackend and doSiteMove()

doSiteMove() has been performing a search-and-replace against data
structures which haven't exist since at least 4.0; it seems quite unlikely
that this works.  Anecdotally, the workflow around this either incomplete or
buggy/broken.  Simplifying this is simply a reflection of the reality that
it doesn't do what it was written to do.

Instead, doSiteMove() now resets to a standard baseline/default.

CRM_Utils_PDF_Utils::pdflib - Remove unused function with quaint data defaults

api_v3_SettingTest - Fix up

CRM_Core_Config - Bind to the settings of the active domain at the moment of setup.

I'm not sure this is actually a good behavior, but it's the old behavior,
and there's a unit-test which checks for it.

Core.settings.php - doNotAttachPDFReceipt - Match previous defaults

config->countryLimit - Don't directly modify array

When using magic method for countryLimit, it's difficult to directly modify
the array.  It's easier to replace the array as a whole.

Settings - Remove special cases for `prefetch` and `config_only`

Remove invalid $config->defaultSymbol

Even in v4.5, this field appears to have been undefined, but it probably
behaved correctly anyway because the undefined value was passed into a
function which didn't need it.

Cleanup `config_only` settings (maxFileSize, doNotAttachPDFReceipt, resCacheCode)

Move BAO_Setting::getSettingSpecification => SettingsMetdata::getMetadata

When this function is in the BAO, it requires that the DAO exist. In a new
installation running GenCode, this can create dependency loop (where
generating code requires ts(), and using ts() requires settings, and using
settings requires that you already have the generated code).

CRM_Core_I18n - Use CRM_Core_Config less

CRM_Utils_Cache::create - Use factory function

Low-level tools like GenCode may run without access to a database. When we
try to use caching in central code, the cache-accesses are prone to
crashing. The problem -- in this environment, we shouldn't even try to use
databse for caching.

`CRM_Utils_Cache::create()` will attempt to create the best cache it can,
depending on what services are available.

CRM_Core_I18n::crm_translate_raw - Don't lookup $config->lcMessages for every string

Accessing `$config` is now be a little slower, and this function accounted
for about half of all calls.

GenCode - More complete env

CRM_Utils_System - Cleanup useFrameworkRelativeBase

CRM-16373 - CRM_Core_Config - Use `Runtime` and `MagicMerge`

Civi\Core\SettingsManager - Don't try to read settings if there's no DB

CRM-16373 - Civi\Core\SettingsManager - Load defaults *after* core bootstrap.

CRM_Extension_System - Make it a little easier to skim.

CRM-16373 - CRM_Core_Config_Variables should be strictly about data

The distribution of variables and functions between `CRM_Core_Config` and
`CRM_Core_Config_Variables` seems pretty random.  In anticipation of
swapping out `CRM_Core_Config_Variables`, make a few changes:

 * Move various functions from `CRM_Core_Config_Variables` to BAOs (`provinceLimit, `countryLimit`, `defaultContactCountry`, `defaultContactCountryName`, `defaultCurrencySymbol`)
 * Put deprecated stubs in `CRM_Core_Config`
 * Move most variables from `CRM_Core_Config` to `CRM_Core_Config_Variables`.

CRM_Core_Config - Fix bugs in path/dir settings

CRM-16373 - Search Settings - Fix dupes (eg contact_reference_options/autocompleteContactReference)

Note:
 * The `autocompleteContactReference` and `autocompleteContactSearch` settings don't seem to be really stored as such.
 * The form includes various hacks which effectively saves these fields in `contact_reference_options` and `contact_autocomplete_options`.
 * At runtime, the application logic checks for `contact_reference_options` and `contact_autocomplete_options`.
 * This situation predates the declarations of `autocompleteContactReference` and `autocompleteContactSearch` in `Search.setting.php`. It seems likely
   that these settings have never been useful.

The fields still have some hacks, but they should be a bit easier to read/trace/grep.

CRM-16373 - Localization - Rearrange load/save logic

 * Declare missing setting `languageLimit`
 * Allow saving admin form -- even when using makeMultilingual, makeSinglelingual, addLanguage, and/or languageLimit
 * Move onChange logic for `lcMessages` from `ConfigSetting::add()` to `onChangeLcMessages()`
 * Move locale init from `ConfigSetting::retrieve()` to `applyLocale()`

CRM-16373 - CRM_Admin_Form_Setting - Generate error instead of saving config fields

CRM-16373 - CRM_Admin_Form_Setting_Search - Don't save through ConfigSetting::add()

CRM-16373 - CRM_Admin_Form_Setting_Date - Don't save through ConfigSetting::add()

CRM-16373 - CRM_Admin_Form_Setting_Misc - Don't save through ConfigSetting::add()

CRM-16373 - Migrate Map/Geocode settings

CRM-16373 - Localization - Save through settings instead of domain

ConfigSetting::fixParams - Remove legacy handling for countryLimit, provinceLimit, defaultContactCountry

This appears to be migration logic for handling a change in the format of
select config fields.  The migration logic appears to originate before v3.0.
Since we're only supporting upgrades from v4.0+, there's no point in keeping
it.

CRM_Core_BAO_ConfigSetting::formatParams - Remove silly function

This function is basically just array_merge().

In theory, there's a side-effect where NULL values in `$values` are unset,
but neither use-case seems to make any use of `$values` afterward, and that
smells like an accidental side-effect anyway.

CRM-16373 - Mailer settings - Remove reliance on CRM_Core_BAO_ConfigSetting::create

CRM-16373, CRM-14349 - Config - Disintermediate localeCustomStrings

localeCustomStrings has a pretty w.e.i.r.d. lifecycle (involving table `civicrm_word_replacements`
and column `civicrm_domain.locale_cusotm_Strings`).  This commit does not unweird it, but the
weirdness no longer involves special-case logic on `CRM_Core_Config*` -- all the weirdness is
concentrated in `CRM_Core_BAO_WordReplacements` and `CRM_Admin_Form_WordReplacements`.

CRM-16373 - Simplify loading of enableComponents

CRM_Core_BAO_Setting::dao() - Don't filter on group, but do save a blank group.