Merge pull request #16447 from samuelsov/lab#1319

dev/core#1319 Fix regression with shared household address

dev/core#1319 UI - different label for household and employer

Merge pull request #16267 from jitendrapurohit/dev-1471

dev/core#1471 - Add system status alert for deleted custom fields in …

Merge pull request #16437 from eileenmcnaughton/ev_back

Add unit test to back office form when a payment is made against a partially paid contribution

Merge pull request #16439 from eileenmcnaughton/part_odd

Respect form value for register_date on partipant form

Extend checks in test

Merge pull request #16425 from colemanw/markdown

Use markdown in php docblocks & display in APIv4 Explorer

Merge pull request #16098 from MegaphoneJon/event-23-correct

event#23 - don't count non-counted participants on Confirm Registrati…

Respect form value for register_date on partipant form

The backoffice event registration form has a register_date field. In credit card mode it
does an awful lot of handling which is mostly for legacy code reasons but the net result is to ignore it
& set it to now. However, the field defaults to now & if someone actually changed it they would expect their change to
be respected. This removes that handling & just uses the field value entered. The field is always present from my
digging

Merge pull request #16434 from eileenmcnaughton/cont_form_settings

[REF] Remove unused variable

Add unit test to back office form when a payment is made against a partially paid contribution

Merge pull request #16374 from colemanw/api4Delete

APIv4 - don't throw exception when updating/deleting 0 items

Merge pull request #16432 from colemanw/comments

Cleanup API_Exception usage

event#23 - don't count non-counted participants on Confirm Registration screen

Remove unused setting

Use markdown in php docblocks & display in APIv4 Explorer

Reformats some docblocks to use markdown, and uses the marked.js library
to display them in the APIv4 Explorer.

Merge pull request #16424 from eileenmcnaughton/cont_setting_handling

dev/core#1558 Data conversion for non-standard setting.

Merge pull request #16433 from eileenmcnaughton/fatal

dev/core#560 Replace fatal with exception

APIv4 - don't throw exception when updating 0 items

APIv4 - don't throw exception when deleting 0 items

Merge pull request #16431 from colemanw/explorerCss

APIv4 Explorer css tweaks

dev/core#1558 Data conversion for non-standard setting.

Per https://lab.civicrm.org/dev/core/issues/1558 the 'contribution_invoice_settings' 'setting'
does not follow our standard of one setting per key and this has led to all sorts of hacks in various places.

In trying to unravel this I eventually concluded we needed an interim step where the data would be
stored as the correct settings but set and get would still work on the deprecated settinng. The reason for
goinng this way is that I found more than one place where extension code is accessing these settings
and the amount of work to fix up all the places in core that access it and the settings form were too big
to deal with without a stepping stone.

With this merged the settinngs are correctly defined and a definition for the deprecated setting still exists.

Requesting the deprecated setting returns an array retrieved from the correct settings so is unchanged from calling
functions point of view. Saving the deprecated setting saves to the correct places. However, it's now also
possible to get & set the correct settings and once the core places are removed we will deprecate & remove the
deprecated setting.

Unit tests cover past & desired behaviour and the upgrade routine.

Replace fatal with exception

Merge pull request #16365 from mattwire/civicontribute_disabled_devcore547

dev/core#547 If CiviContribute is not enabled don't crash when calling ContributionPage.getoptions or Event.getoptions

Merge pull request #16392 from jaapjansma/dev_1522_tests

dev/core#1522 Handle space as thousand separator

If CiviContribute is not enabled don't crash when calling ContributionPage.getoptions or Event.getoptions

API Kernel - move params check to v3 where it's relevant

NFC - Comment & case cleanup

APIv4 Explorer css tweaks

Issue 1522: style formatting

Merge pull request #16398 from eileenmcnaughton/pref_form

dev/core#1558 [REF] Remove deprecated code from CRM_Admin_Form_Preferences

Merge pull request #15842 from totten/master-config-backend

dev/core#1387 Continue removal of "config_backend"

(dev/core#1387) ConfigSetting - Deprecation+guard for retrieve()/add()

These functions were traditionally used for accessing `config_backend`,
which was (mostly) dropped in v4.7 and became inert. However, the
functions are still referenced in a couple oddball cases.

Note that the references to `$domain->config_backend` are liable to raise
warnings if evaluated - since the field no longer exists on the DAO class.
Consequently, the extra `$hasBackend` guard should reduce warnings.

(dev/core#1387) Remove some lingering references to config_backend

(dev/core#1387) Remove config_backend from sample/dev setup

(dev/core#1387) FiveTwentyThree - Drop civicrm_domain.config_backend if it snuck in

This column was dropped in 4.7.alpha1, but it was still created on new installs, so

* Sites originating with 4.7 - 5.22 should have an empty copy of the column today
  (because it was defined in xml schema - but never used by live code).
* Sites originating with <4.7 (and subsequently upgraded) should not have the column today
  (because FourSeven.php previously dropped it).
* Sites originating with <4.7 (and not yet upgraded) should have the column with some data
  (because FourSeven.php hasn't run yet).
* It is unexpected that any site currently on 4.7-5.22 would have any data in that column.

Note: `dropColumn` has a built-in guard so it only drops the column if it
exists.

(dev/core#1387) Domain.xml - Drop config_backend

Merge pull request #15760 from colemanw/iconPicker

IconPicker widget improvements

Merge pull request #16405 from totten/master-test-codegen

Civi\Test - Allow `headless()->apply()` (etc) to execute without setup.sh

Merge pull request #16403 from totten/master-relurl

Allow most values of $civicrm_paths['XXX']['url'] to be relative

Merge pull request #16407 from totten/master-altpkgs-basic

Fix loading with alternate packages path (system-level)

Merge pull request #16406 from totten/master-menu-warn

CRM_Core_Menu - Fix warnings during local test run (dev/core#742)

Merge pull request #16409 from totten/master-altpkgs-ui

 Fix loading with alternate packages path (UI-level)

Merge pull request #16411 from colemanw/api4EntityDoc

Api4 docs improvements

Merge pull request #16423 from totten/master-setup04

composer.json - Update civicrm-setup

Merge pull request #16402 from eileenmcnaughton/part_test

[REF] Add test for line item, extract fn

Merge pull request #16422 from seamuslee001/contribute_summary_report_stats_hook

[REF] Ensure that the from is correctly modified in both the main que…

Add test for line item, extract fn

composer.json - Update civicrm-setup

Merge pull request #16421 from totten/master-config-php

composer.json - Explicitly set target PHP platform

Add in unit test of to verify the change

[REF] Ensure that the from is correctly modified in both the main query and in the statistics section of the Contribute Summary Report

composer.json - Explicitly set target PHP platform

Overview
--------

This refines the way in which `composer` resolves dependencies - so as to
prefer packages that are compatible with Civi's declared minimum requirement.

https://blog.martinhujer.cz/17-tips-for-using-composer-efficiently/#tip-%2315%3A-specify-the-production-php-version-in-%60composer.json%60

Before
------

Suppose that:

* The current minimum declared is PHP 7.0. (That happens to be the case at time of writing.)
* You locally use PHP 7.4.
* You wish to add or update a package.

`composer` may grab a version of a package that works on PHP 7.4 -- but is
not available/compatible with PHP 7.0. Then you start developing things under
the false expectation that the library will be usable -- and only discover the
problem later.

After
-----

`composer` should grab packages that are compatible with the declared PHP version,
regardless of the local PHP version.

Comment
-------

* This is orthogonal to the question of *which* PHP version should be the
  platform for CiviCRM -- whatever version that is, this dynamic can play out.
  The patch doesn't change that.
* The value will undoubtedly change over time, which has a small maintenance
  issue to keep the PHP constants in sync with the composer metadata.
  KISS solution: add a comment!

Merge pull request #16420 from civicrm/5.22

5.22 to master

Merge pull request #16417 from jmcclelland/1555b

avoid undefined offset and uninitialized key errors on upgrade - dev/core#1555

APIv4 - Add docblocks to base classes

Merge pull request #16419 from civicrm/5.22

5.22

Merge pull request #16418 from seamuslee001/5.22

Add release-notes/5.21.2.md

Add release-notes/5.21.2.md

avoid undefined offset and uninitialized key errors on upgrade

https://lab.civicrm.org/dev/core/issues/1555

Merge pull request #16415 from eileenmcnaughton/fatal

[NFC] throw exceptions, single quotes, declare exceptions, remove unused param

Merge pull request #16414 from eileenmcnaughton/acl

[REF] Remove some unused variables

Merge pull request #16412 from eileenmcnaughton/cont_settings

dev/core#1558 [REF] Remove unnecessary query, clean up silly function

Merge pull request #16408 from totten/master-altpkgs-setupsh

setup.sh - Fixes for running in basic composer file-structure

Issue 1522: missing comments

[NFC] throw exceptions, single quotes, declare exceptions, remove unused param

Remove some unused variables

phpcs correctly found these

Eileens-MacBook-Pro:civicrm eileenmcnaughton$ phpcs --standard=DrupalPractice CRM/ACL

FILE: /Users/eileenmcnaughton/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/ACL/Form/WordPress/Permissions.php
---------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
---------------------------------------------------------------------------------------------------------------------
 197 | WARNING | Unused global variable .
---------------------------------------------------------------------------------------------------------------------

FILE: /Users/eileenmcnaughton/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/ACL/Form/ACL.php
---------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
---------------------------------------------------------------------------------------------------
 97 | WARNING | Unused variable .
---------------------------------------------------------------------------------------------------

FILE: /Users/eileenmcnaughton/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/ACL/BAO/ACL.php
--------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 3 WARNINGS AFFECTING 3 LINES
--------------------------------------------------------------------------------------------------
 171 | WARNING | Unused variable .
 172 | WARNING | Unused variable .
 296 | WARNING | Unused variable .
--------------------------------------------------------------------------------------------------

[REF] spare a query

getInvoiceNumber returns NULL if the 'invoicing' setting is disabled, by checking slightly earlier
we can skip a query if it is not

Upgrade fix: Copy code to upgrade script rather than call a function.

The function will change as we fix the setting but we want the upgrade function to work off the old setting

Test fix: Use hard coded invoicePrefix

We know what it is - if it were not set right then the test would not pick it up because it is comparing
based on the assumption it is - using the string is more reliable

Api4 Explorer - enable debug by default

Api4 Explorer - Add code styles and display in tabs

Merge pull request #16410 from civicrm/5.22

5.22 to master

Merge pull request #16393 from demeritcowboy/activity-report-pager-crash

dev/core#1552 Fatal error using pager on Activity Detail Report when Include Case Activities is Yes

Merge pull request #16404 from totten/master-slashes

Make $civicrm_paths less sensitive to trailing slashes. Add tests.

CRM_Badge_Form_Layout - (Partially) Fix loading with alternate packages path

This change should work as well as before, and it's more correct.  However,
it's not a full fix making the badge-editor work in D8 - the relevant code
probably needs more of a rethink. But... this is cleaner...

js/*.js - Fix loading with alternate packages path

CRM_UF_Page_ProfileEditor - Fix loading with alternate packages path

crmResURL, crmResPath - Allow full path expressions

Before
------

In Smarty, there is no way to request values from `Civi::paths()`.

After
-----

In Smarty, you can request values from `Civi::paths()` using these notations:

```
{crmResURL expr="[civicrm.root]/foo"}
{crmResPath expr="[civicrm.root]/foo"}
```

bin/setup.sh - Skip 'composer install' on D8

GenCode - Allow execution when civicrm-packages is loaded higher up via composer

GenCode - Optionaly allow direct control over civicrm.config.php template

CRM_Utils_String - Fix loading with alternate packages path

CRM_Core_ClassLoader - Fix loading with alternate packages path

CRM_Core_IDS - Fix loading with alternate packages path

CRM_Core_Smarty - Fix loading with alternate packages path

CRM_Core_Resources - Fix loading with alternate packages path

Api4 - add more debug output

CRM_Core_Menu - Fix warnings during local test run (dev/core#742)

Before
------

In certain local OSX+D8 test environments, when running the full suite, I got a large number of warnings like this:

```
Warning: simplexml_load_file(): I/O warning : failed to load external entity "/Users/totten/bknix/build/drupal8-clean/web/vendor/civicrm/civicrm-core//CRM/Campaign/xml/Menu/Campaign.xml" in /Users/totten/bknix/build/drupal8-clean/web/vendor/civicrm/civicrm-core/CRM/Core/Menu.php on line 99
    ```

After
-----

Those warnings seem to have gone away.

The menu still seems to populate correctly.

Comments
--------

This smells a lot like dev/core#742 -- e.g.  it's the same warning and
(after adjusting for changes in line-numbering over the months) same line of
code.

E2E_Core_LocalizedDataTest - Adaptation for composer/D8/git-style deployments

Civi\Test - Allow `headless()->apply()` (etc) to execute without setup.sh

Before
------

If you have a copy of the `git` codebase and wish to run any of the headless
test suites, you *must* run `setup.sh` aka `GenCode` beforehand.

This is because certain files - `sql/civicrm.mysql` and
`sql/civicrm_data.mysql` - are used in the headless suite.  As large
auto-generated files, they are not provided in git.

After
-----

The files `sql/civicrm.mysql` and `sql/civicrm_data.mysql` are no longer
required by the test suite -- the headless tests will directly use the
`GenCode` classes to produce the needful.

Comments
--------

The general thrust of this commit is to find spots which read an SQL file, e.g.

```php
\Civi\Test::execute(file_get_contents("foobar.mysql"));
```

and instead call the generator for that file, e.g.:

```php
$schema = new \CRM_Core_CodeGen_Schema(\Civi\Test::codeGen());
$result = $schema->generateFooBar();
\Civi\Test::execute($result['foobar.mysql']);
});
```

In doing so, we incorporate a couple tricks:

* The SQL content is cached for the duration of the test-run (`Civi\Test::$statics`).
  Generating the SQL is not super expensive... but `Civi\Test::headless()->...apply()`
  may be called thousands of times, so it could add-up. Just cache it.
* Most of the `generateFooBar()` functions depend in some fashion on `ts()`. This
  commit depends on a preceding commit to make `ts()` more amenable to execution
  during early stages of the test.
    * Related discussion: https://chat.civicrm.org/civicrm/pl/ehohytqkf7bd5prg9w75dq4qqw

(REF) Civi\Test - Use de-minimis ts() while runnning installation

When running early-stage installation helpers like
`Civi\Test::headless()->...->apply()` or `Civi\Test:data()->...->populate()`
it can be hard to call `CRM_CodeGen_*` functionality - because that relies
on `ts()` which relies on other system services.

This change basically suspends/swaps some of the default `ts()` behavior
while the test system performs installation.

The change is in two sub-parts:

* Implement `asPreInstall()` (Files: `Civi/Test.php` and `CRM/Core/I18n.php`)
    * Add the helper `\Civi\Test::asPreInstall()`
    * Skip the use of "word replacements" during the pre-install phase
* Use `asPreInstall()` (Files: `Civi/Test/Data.php` and `Civi/Test/CiviEnvBuilder.php`)
    * Wrap existing code with the helper `\Civi\Test::asPreInstall(). These changes look big, but that's
      just whitespace -- inserting `asPreInstall()` changes the indentation.

This lays groundwork for another commit which will replace some references to `sql/civicrm*.mysql`
with references to `CRM_CodeGen_*`.

(REF) CRM_Core_CodeGen_Schema - Allow generating SQL without making files

Overview
--------

This is a refactoring to allow consumers of `CRM_Core_CodeGen_Schema` to
request the SQL without creating files.

Before
------

Calls to `CRM_Core_CodeGen_Schema::generateDropSql` (ad nauseum) create SQL files.

After
-----

Calls to `CRM_Core_CodeGen_Schema::generateDropSql` (ad nauseum) return SQL strings.

Comments
--------

To ensure that files are still generated consistently, you can use this procedure:

```
git checkout MY_BASE_BRANCH
./bin/setup.sh -g
cp -r sql sql.orig

git checkout MY_MODIFIED_BRANCH

rm sql/civicrm.mysql sql/civicrm_acl*mysql sql/civicrm_data*mysql sql/civicrm_drop.mysql sql/civicrm_navigation.mysql -f
./bin/setup.sh -g

colordiff -ru sql.orig sql
```

Make $civicrm_paths less sensitive to trailing slashes. Add tests.

Overview
--------

Recall that the default value of `imageUploadURL` is `[civicrm.files]/persist/contribute/`. Now, suppose you have one of these two configurations in `civicrm.settings.php`:

```php
// (1) Trailing slash configuration
$civicrm_paths['civicrm.files']['url'] = 'http://tmpd8-clean.bknix:8001/sites/default/files/civicrm/';
$civicrm_paths['civicrm.files']['path'] = '/Users/totten/bknix/build/tmpd8-clean/web/sites/default/files/civicrm/';

// (2) Trimmed slash configuration
$civicrm_paths['civicrm.files']['url'] = 'http://tmpd8-clean.bknix:8001/sites/default/files/civicrm';
$civicrm_paths['civicrm.files']['path'] = '/Users/totten/bknix/build/tmpd8-clean/web/sites/default/files/civicrm';
```

You could inspect to see if the URL is generated correctly by running these commands:

```
$ cv api setting.get return=imageUploadURL
$ cv url -c imageUploadURL
$ cv url -d "[civicrm.files]/persist/contribute/"
$ cv path -c imageUploadDir
$ cv path -d "[civicrm.files]/persist/contribute/"
```

Before
------

Under either configuration (trailing-slash or trimmed-slash), you'll find that paths are generated properly (`cv path ...` or `Civi::paths()->getPath(...)`).

For generating URLs (`cv url ...` or `Civi::paths()->getUrl(...)`), only the trailing-slash cfg works.  The trimmed-slash cfg leads to a bad URL with a missing slash.

```
[bknix-max:~/bknix/build/tmpd8prj-clean/web] cv api setting.get return=imageUploadURL
{
    "is_error": 0,
    "version": 3,
    "count": 1,
    "id": 1,
    "values": {
        "1": {
            "imageUploadURL": "[civicrm.files]/persist/contribute/"
        }
    }
}

[bknix-max:~/bknix/build/tmpd8prj-clean/web] cv url -c imageUploadURL
"http://tmpd8prj-clean.bknix:8001/sites/default/files/civicrmpersist/contribute"

[bknix-max:~/bknix/build/tmpd8prj-clean/web] cv url -d "[civicrm.files]/persist/contribute/"
"http://tmpd8prj-clean.bknix:8001/sites/default/files/civicrmpersist/contribute/"
```

This is surprising because the path expression (`[civicrm.files]/persist/contribute`) includes a slash...  but it disappears in the final computation.

After
-----

Both configurations work, for paths and for URLs.

Add E2E_Core_PathUrlTest to ensure that various path/URL lookups work

This will allow E2E matrix to send a signal about whether the default
configurations produce valid URLs.

ThemesTest - Use more realistic expected-values

1. The expected value of `$civicrmBaseUrl` should not be blank. The old value was a fiction of
   the unit-test environment. Be more realistic.
2. The expected values for extension-generated URLs should abide the same `$civicrmBaseUrl` as others.

Allow most values of $civicrm_paths['XXX']['url'] to be relative

Overview
--------

The `$civicrm_paths` variable allows a sysadmin to override various path and
URL computations.

```php
$civicrm_paths['civicrm.packages']['url'] = 'https://example.com/libraries/civicrm/packages';
```

The variable was originally tested with absolute URLs, and the subsequent
examples/docs use absolute URLs (https://docs.civicrm.org/dev/en/latest/framework/filesystem/).

These values are used to generate addresses, as in:

```php
$abs = Civi::paths()->getUrl('[civicrm.packages]/foo.js', 'absolute');
$rel = Civi::paths()->getUrl('[civicrm.packages]/foo.js', 'relative');
```

The patch allows more values in `$civicrm_paths` while ensuring that
`getUrl()` works as expected.

Before
------

The `getUrl()` requests only behave correctly if the override is an absolute URL - not if it's relative.

After
-----

The `getUrl()` requests behave correctly if the override is either an absolute URL or a relative URL.

```php
$civicrm_paths['civicrm.packages']['url'] = 'https://example.com/libraries/civicrm/packages';
$civicrm_paths['civicrm.packages']['url'] = '/libraries/civicrm/packages';
```

Comments
--------

* `toAbsoluteUrl()` needs a base to prepend. I initially used `HTTP_HOST`
  but switched to `cms.root`, but correctly inferring scheme and host and port
  and httpd prefixes would be more complex - esp for background/CLI jobs.
  Using `cms.root` as the base is simpler.
* It's tempting to allow recursive variables. But it's not actually needed for
  my purposes, and it would add complexity/maintenance. If it's really needed,
  one could update `toAbsoluteUrl()` to quickly check for variables
  (`$url[0] === '['`) and then evaluate them. But for now... I think the
  simpler format is fine.

Merge pull request #16388 from eileenmcnaughton/event_ref

[REF] Extract & share code to determine revenue recognition date.

fatal error when using pager

Api4 - Improve docblocks and their display in the Explorer

Improve code docs for Api4 Entity entity

APIv4 - Accept multiple fieldNames in Get helper fn