Update civicrm_generated mysql file following changes to custom mysql file

Merge pull request #12671 from eileenmcnaughton/ex55

Fix + Add test for exporting location types with changed names

Merge pull request #12674 from totten/5.5-upgr-tpl-msg

Upgrader - When updating message templates, identify them by name

Merge pull request #12670 from totten/5.5-perm-msg

Refine upgrade message for `save Report Criteria`

Fix + Add test for exporting location types with changed names

Merge pull request #12673 from eileenmcnaughton/atest

Test fix for intermittant error

Upgrader - When updating message templates, identify them by name

Also: Fix a layout issue caused by a typo in the `<li>` tag.

Loosedn activityTest on country order.

The order is no considered significant, be open minded

(NFC) Upgrade - Improve example of an upgrade message for a new permission

@bgm pointed out that the permission name should be translated as well.
This left me wondering...  why do we bother with parameterizing the string
with a `%1` if it's all going to be translated anyway?

There is a plausible reason.  It's not super-critical, but it's plausible --
the permission name is used in more contexts (like the permission mgmt
screen in D7/WP *as well as* the upgrade screen).  This arrangement ensures
that the name appears the same in *all those contexts*, even in various
edge-cases of the translation lifecycle (e.g.  where the permission-names
have been translated but the upgrade-messages have not).  Again...  it's not
a big deal, but it is a slightly better default.

Upgrade messages - When going through 5.4.*, the permission name should be legible

Upgrade messages - When going through 5.4.*, only display permission message once

Merge pull request #12634 from seamuslee001/dev_core_273

dev/core/#273 Fix issue where sending an SMS with the To Field in the…

dev/core/#273 Fix issue where sending an SMS with the To Field in the provider params set did not work and fix handling of do_not_sms

Add test of error message

Merge pull request #12646 from eileenmcnaughton/option_group_cache

Fix option group caching issue.

Fix option group caching issue.

Per https://lab.civicrm.org/dev/core/issues/304 in some cases the api
cache has already been built so adding a new option_group
is not picked up causing a crash

Merge pull request #12640 from xurizaemon/GL316-cache_key_no_whitespace

(dev/core#316) Fix crash on Memcache systems when session key involves whitespace

dev/core#316 - Update long string cache key test results

This is replaces 95b65673b6259be3a02ed6510e7562939d35b6c8.  The intent is to
have a delimiter every ten chars so that it's easy to read/confirm the
length of the string.

The delimiter was space, but this became a longer encoded char (`-20`)
and threw off the numbers. Switching to dash just gives a different encoded char.
To get the counts right, it needs ot be a pass-through char... like underscore.

(NFC) CRM_Utils_Cache::create - Update docblock for 'name' param

Issue #316: Update long string cache key test results

Issue #316: Ensure Container caches have safe prefixes

Issue #316: Expand cache key test coverage with emoji

Issue #316: Update tests for whitespace escaping

Avoid calling Cache::cleanKey() twice in quick succession

Since this method is performance related and called frequently,
no need to recalculate results from preg_replace_callback() with
the same inputs.

Issue #316: Exclude spaces from cache keys for Memcache compatibility

- https://lab.civicrm.org/dev/core/issues/316
- https://github.com/memcached/memcached/blob/master/doc/protocol.txt

Merge pull request #12616 from eileenmcnaughton/report_date

Test fix, update activity report adds a this.month filter by default, accomodate

Test fix, update activity report adds a this.month fiter by default so make dates movable.

I also put time at the end of the day to avoid bounciness on status being overdue

5.4.0.md - Tweak cache notes

5.4.0 release notes (#12605)

* 5.4.0 release notes: raw from script

* 5.4.0 release notes: added boilerplate

* 5.4.0 release notes: finished documenting changes

* 5.4.0 release notes: updated contributors

Set version to 5.5.beta1

Merge pull request #12607 from colemanw/caseDetails

dev/core#289 - Fix links on case dashboard

Merge pull request #12610 from mattwire/recurtab_sort_desc

dev/core/issues/277 Sort recurring contributions by newest first

Merge pull request #12606 from JMAConsulting/custom-value-update

Customvalue ID is ignored

Sort recurring contributions by newest first

Merge pull request #12558 from totten/master-prevnext-misc

(dev/core#217) PrevNext - Allow swapping getPositions (etal) for contact-search

Merge pull request #12587 from eileenmcnaughton/header_test

Export - add tests out header output, move phone_type_id to metadata

Merge pull request #12585 from eileenmcnaughton/param_passing

Stdise references to BAO_Query->_fields [nfc]

Fix activity edit link

dev/core#289 - Fix caseId url param

Merge pull request #12553 from pradpnayak/77

dev/core/issues/277, Fixed count to include only live recurring contr…

Merge pull request #12602 from colemanw/checkIfFieldExists

NFC - Deprecate duplicate function

Merge pull request #12604 from tschuettler/296-custom-value-return-field

api - CustomValue::get - add handling for comma separated return fields

Customvalue ID is ignored

Explode return values if it is not already an array.

Add unit tests for CustomValueGet return fields

Stop passing relationQuery object now it is not required

Stdise references to BAO_Query->_fields [nfc]

Merge pull request #12596 from eileenmcnaughton/export_ref

[NFC] Export - don't pass arrays as reference when they are not changed

Merge pull request #12591 from eileenmcnaughton/membership_type

Towards using EntityForm.tpl for Membership type & enabling custom data

Merge pull request #12600 from tschuettler/293-geocoding

Skip check for format method when there is no valid geocoding provider

Stricter validation for checkIfFieldExists

NFC - Deprecate duplicate function

Skip check for format method when there is no valid geocoding provider

Export - don't pass arrays as reference when they are not changed

Move definition of phone_type_id to the xml.

This has the side effect of making it such that it only gets 16 char rather than 255. I thnk this is 'ok' here but there is a separate issue open to increase the varchar for all fields on export

Add tests for header output

Merge pull request #12535 from eileenmcnaughton/export_participant_test

Export Add unit test + minor refactor covering specifiable payment output fields for participant export.

Merge pull request #12592 from civicrm/5.4

5.4 to master

Merge pull request #12590 from totten/5.4-flushcache

(dev/core#284) System::flushCache - Reproduce legacy cache behavior. Improve test performance.

Remove some fields from the form to rely on EntityTrait

Convert 'name' & 'description' to use the entity Fields format.

Note that doing a partial conversion in the template is just a stepping stone to using the
EntityField template, when lots of fields need conversion / review it allows us to break it up

Simplify converstion of fields, convert 2 more

Define entity data for membership type form

Merge pull request #12589 from seamuslee001/password_size

dev/core#291 Allow for field size to be set for password fields

Overview
----------------------------------------

`CRM_Utils_System::flushCache()` calls `CRM_Utils_Cache::singleton()->flush()`.
In `5.3`, this triggered a cascading effect; in development of `5.4.alpha`,
some of the cascades were overzealous and we revised to get tighter control
over cascading.

With an aim to being conservative and reproducing old behavior, I previously
patched `5.4.alpha` to add several extra flushes and simulate the old cascades.
However, it wasn't really as conservative as hoped -- because the "old
behavior" depended on the environment.  This patch brings us closer the "old
behavior".

See also: https://lab.civicrm.org/dev/core/issues/284

Before (Behavior in version <=`5.3`)
----------------------------------------

On systems with memory-backed caches, `flushCache()` had an aggressive
cascading side-effect where several named caches (`settings`, etc) were also
flushed.

On systems with a default configuration (SQL+ArrayCache), `flushCache()` had a
very limited cascading effect -- it *only cleared the in-process ArrayCache*.
The bulk of the cache content was preserved in SQL.

Before (Behavior in version ~= `5.4.alpha`)
----------------------------------------

To simulate the cascading effect, `flushCache()` explicitly flushes a
half-dozen individual caches.  (These half-dozen are chosen to match the old
cascade list and exclude some new things which would problematic.)

On systems with memory-backed caches, this reproduces the aggressive cascading
effect.

On systems with a default configuration (SQL+ArrayCache), this amplifies the
flushing -- because it also destroys the underlying SQL caches.

This has the side-effect of significantly degrading performance of the test
suite.

After (Behavior with patch)
----------------------------------------

`CRM_Utils_System::flushCache` calls `CRM_Utils_Cache::singleton()->flush()`.

To simulate the cascading effect, `flushCache()` explicitly flushes a
half-dozen individual caches...  *but only on memory-backed* systems.

On systems with memory-backed caches, this reproduces the aggressive cascading
effect.

On systems with a default configuration (SQL+ArrayCache), this is closer to the
old behavior.  The bulk of the cache remains available in SQL.

Based on local spot-checking, this restores performance of the test suite.

Comments
----------------------------------------

Deep down, I don't really believe the cascading effect is a good thing.  At
some point, I'd rather just remove these bits.  But in absence of a crystal
ball to predict the side-effects of that, I think it's good to find a better
approximation of the old behavior.

Merge pull request #12588 from mattwire/5.4_backportcasefixes

Backport "Fix regression on case export" to 5.4

dev/core#291 Allow for field size to be set for password fields

Fix regression on case export from recent export fix

https://github.com/civicrm/civicrm-core/commit/3b4adc92793dccfa446cf66f0740edb543f110d7 changed the way componentmode is defined

It now seems inconsistent

Non functional changes towards shared functions in Core_Form_Task

Merge pull request #12578 from JKingsnorth/patch-10

(NFC) Update readme to link to GitLab instead of JIRA

Merge pull request #12577 from eileenmcnaughton/export_sql_columns

Export clean up sql columns

Merge pull request #12530 from colemanw/plainObject

crmRouteBinder - Don't convert arrays to objects

Merge pull request #12573 from pradpnayak/ThrowExceptionOnGetValue

Added code to throw exception on getvalue api call

Extract getMungedFieldName

Extract getSqlColumnDefinition off to processor class.

Note that I wrote test coverage that was pretty extensive on the output of this function earlier

 Update readme to link to GitLab instead of JIRA

crmRouteBinder - Don't convert arrays to objects

Merge pull request #12388 from pradpnayak/optionValuePaymentMethod-b

dev/financial/issues/24, Moved code from form layer to BAO and used api instead of BAO function

Merge pull request #12416 from pradpnayak/232

dev/core/issues/232, Some smart groups and some searches not returning any contacts

Added code to throw exception on getvalue api call

Moved code from form layer to BAO and used api instead of BAO function

updated explode function in custom search

dev/core/issues/232, fixed how contact sub type is using separator

Merge pull request #12556 from totten/master-prevnext-selection

(dev/core#217) PrevNext - Migrate selection methods

added unit test to search contact based on contact sub type

Merge pull request #12571 from civicrm/5.4

Add 5.3.2 release notes (#12570)

Add 5.3.2 release notes (#12570)

[reviewed, pending rebase] CRM-20703 - Event Contribution Created When No Payment Option Provided (#12367)

* CRM-20703 - Event Contribution Created When No Payment Option Provided

* throw form rule when amount block is active

Merge pull request #12569 from civicrm/5.4

5.4

Merge pull request #12568 from kcristiano/5.4

dev/279 - When Merging two contacts flip, prev, next not working

Merge pull request #12563 from eileenmcnaughton/enotice54

dev/core#276 enotice fix

dev/279 - When Merging two contacts flip, prev, next not working

Affects Joomla and WordPress

Signed-off-by: Kevin Cristiano <kcristiano@tadpole.cc>

dev/core#276 enotice fix

Merge pull request #12185 from eileenmcnaughton/entity_form_url_defaults

Entity form : Establish methodology to allow default values to be passed in on the url

Merge pull request #12561 from eileenmcnaughton/mailing

CRM-21768_NOFOLLOW_links_in_public_online_view_of_mailings

Merge pull request #12560 from scardinius/core-278

dev/core#278 Fix DB syntax error when try to search deleted cases

CRM-21768_NOFOLLOW_links_in_public_online_view_of_mailings

dev/core#278 Fix DB syntax error when try to search deleted cases

(dev/core#217) PrevNext - Allow swapping `getCount()` for purposes of contact-search

The `getCount()` function is used by both contact-search and dedupe-merge use-cases.

* Contact-search
    * `CRM/Contact/Selector.php:            $countRow = CRM_Core_BAO_PrevNextCache::getCount($cacheKey, NULL, "entity_table = 'civicrm_contact'");`
* Dedupe-merge
    * `CRM/Contact/Page/AJAX.php:           $iTotal   = CRM_Core_BAO_PrevNextCache::getCount($cacheKeyString, $join, $whereClause, '=', $queryParams);`
    * `CRM/Contact/Page/DedupeMerge.php:    $total    = CRM_Core_BAO_PrevNextCache::getCount($cacheKeyString, NULL, ($onlyProcessSelected ? "pn.is_selected = 1" : NULL));`

Our aim in developing `CRM_Core_PrevNextCache_Interface` is to allow contact-search to swap a MySQL
backend with a Redis backend -- and dedupe-merge should continue as-is (whether or not Redis is
available).  This basically means:

* Contact-search switches to using `Civi::service('prevnext')->getCount()`
* Dedupe-merge continues using `CRM_Core_BAO_PrevNextCache::getCount()`

Note that the `Interface::getCount()` is simpler than the BAO's variant. This is good because:

* Contact-search doesn't need as many parameters.
* Dedupe-merge still needs all the parameters.
* Adding all parameters would make it hard to implement on other backends. (This is esp true of SQL-style options `$join` and `$where`.)

(dev/core#217) PrevNext - Allow swapping `deleteItem()` for purposes of contact-search

The `deleteItem()` function is used by both contact-search and dedupe-merge use-cases. We can classify
several of these just based on the files:

* Contact-search use-cases. (These should be updated to use the interface.)
    * `CRM/Campaign/Selector/Search.php:     CRM_Core_BAO_PrevNextCache::deleteItem(NULL, $cacheKey, 'civicrm_contact');`
    * `CRM/Contact/Form/Search.php:          CRM_Core_BAO_PrevNextCache::deleteItem(NULL, $cacheKey);`
    * `CRM/Contact/Selector.php:             CRM_Core_BAO_PrevNextCache::deleteItem(NULL, $cacheKey, 'civicrm_contact');`
* Dedupe-merge use-cases. (These should contiue using the BAO.)
    * `CRM/Contact/Form/DedupeRules.php:     CRM_Core_BAO_PrevNextCache::deleteItem(NULL, $cacheKey);`
    * `CRM/Contact/Page/DedupeFind.php:      CRM_Core_BAO_PrevNextCache::deleteItem(NULL, CRM_Dedupe_Merger::getMergeCacheKeyString($rgid, $gid, $criteria))`
    * `CRM/Dedupe/Merger.php:                CRM_Core_BAO_PrevNextCache::deleteItem(NULL, "{$cacheKeyString}_stats");`

Additionally, there are two oddballs which are harder to categorize.

* `CRM_Contact_BAO_Contact_Utils::clearContactCaches($isEmptyPrevNextTable = FALSE)` deletes *all*
  prev-next cache-records (`CRM_Core_BAO_PrevNextCache::deleteItem();`).  It only does so in one
  scenario (as part of `CRM/Contact/Import/Form/Preview.php`), which has this explanatory comment:
  "Clear all caches, forcing any searches to recheck the ACLs or group membership as the import may
  have changed it."
* `CRM_Contact_BAO_Contact::deleteContact(...)` deletes any prev-next cache-records which
  reference a specific contact (`CRM_Core_BAO_PrevNextCache::deleteItem($id)`).
  I suppose this provides a low-grade form of referential integrity.

Part of me thinks those should be re-considered (e.g.  to use a hook/event -- and reduce the
coupling between `Contact` and `PrevNext` subsystems).  However, for purposes of dev/core#217, it
seems OK to send `deleteItem(...)` to both BAO (SQL-only) and service (SQL-or-memory) variants.

(dev/core#217) PrevNext - Allow swapping `getPositions()` for purposes of contact-search

The `getPositions()` function is used by both contact-search and dedupe-merge use-cases.

```
CRM/Contact/Form/Merge.php:      $pos = CRM_Core_BAO_PrevNextCache::getPositions($cacheKey, $this->_cid, $this->_oid, $this->_mergeId, $join, $where, $flip);
CRM/Contact/Form/Merge.php:      $pos = CRM_Core_BAO_PrevNextCache::getPositions($cacheKey, NULL, NULL, $this->_mergeId, $join, $where);
CRM/Contact/Page/View.php:       $pos = CRM_Core_BAO_PrevNextCache::getPositions("civicrm search $qfKey", $this->_contactId, $this->_contactId);
```

Our aim in developing `CRM_Core_PrevNextCache_Interface` is to allow contact-search to swap a MySQL
backend with a Redis backend -- and dedupe-merge should continue as-is (whether or not Redis is
available).  This basically means:

* Contact-search switches to using `Civi::service('prevnext')->getPositions()`
* Dedupe-merge continues using `CRM_Core_BAO_PrevNextCache::getPositions()`

Note that the `Interface::getPositions()` is simpler than the BAO's variant. This is good because:

* Contact-search doesn't need as many parameters.
* Dedupe-merge still needs all the parameters.
* Adding all parameters would make it hard to implement on other backends. (This is esp true of SQL-style options `$join` and `$where`.)

(dev/core#217) PrevNext - Make getSelectedContacts() more portable

This function is used one time -- when you run a search, select some
contacts, and perform a task (like "Delete contacts"), the
`CRM/Contact/Form/Task.php` displays a table with the names of the selected
contacts.

This patch makes the logic portable -- so that it can work regardless of
whether selections are stored in MySQL or Redis.

Before
------

* The contacts are selected `FROM civicrm_prevnext_cache WHERE cacheKey LIKE {$key}% AND cacheKey NOT LIKE {$key}_alphabet%`.
* The contact names come from `civicrm_prevnext_cache.data`, which has been
  pre-filled with either `civicrm_contact.sort_name` (for most contact
  searches) or `civicrm_contact.display_name` (for campaign respondent
  searches).

After
-----

* The selections are chosen with `FROM civicrm_prevnext_cache WHERE cacheKey LIKE {$key}%`.
* The contact names are loaded directly from `civicrm_contact.sort_name`.

Comments
--------

* The use of wildcards with `cacheKey` seems like a code-smell suggest a
  somewhat deeper problem in how `cacheKey` is understood.  However, for our
  purposes, it shouldn't matter.
* The before and after queries are very similar in how they use
  `cacheKey`...  and slightly different.  (Ugh.) Is the new one better or
  worse?  Well, look at how `CRM_Contact_Form_Task` uses `getSelection()`
  (for finding contact IDs, which feed into the task logic) and
  `getSelectedContacts()` (for finding contact names, which are displayed to
  user).  If the subtle difference in `cacheKey` filtering matters, then our
  UX is buggy because we're showing the user one contact-list (based on old
  `getSelectedContacts()`) and we're executing on a different contact-list
  (based on the old `getSelection()`).
* Is the old technique for getting names (querying
  `civicrm_prevnext_cache.data`) better than the new technique (querying
  civicrm_contact.sort_name)?  I haven't benchmarked, but I'm skepitcal.
  Both techniques transfer the full `O(n)` list from mysql to php.
  In typical usage, the size of `n` is limited by what an admin is
  willing to click through in the UI (which is probably a few hundred
  IDs). The contact tables is indexed by ID. Maybe... if you manually
  check several thousand records, it might make a small difference. But
  if you're clicking that many, then other things are also getting more
  expensive (like the actual task). In this case, it feels like an
  unnecessary optimization.