Fix mistake in comment

Merge pull request #16621 from totten/master-setup-autoload

dev/core#1615 - Fix for recently migrated civicrm-setup

Merge pull request #16622 from seamuslee001/test_dev_core_1386

dev/core#1386 Add in unit test for #15834

dev/core#1386 Add in unit test for #15834

dev/core#1615 - Fix for recently migrated civicrm-setup

Overview
--------

Fix a recent (intra-alpha) regression from https://github.com/civicrm/civicrm-core/pull/16618

The search for `civicrm-setup` goes slightly awry because the migrated copy of civicrm-setup uses
the core's classloader rather than its own classloader.

Steps to Reproduce
------------------

* Create a site with WP and Civi(master).
* Ensure Civi is uninstalled. (ex: `cv core:uninstall -f`)
* In `wp-content/plugins/civicrm/civicrm`, touch the file `.use-civicrm-setup`.
  (*This is supposed to activate the new UI.*)
* Go to the WP admin console. In the left navbar, choose "CiviCRM Installer".

Before
------

It fails to load the new UI -- the search finds `.use-civicrm-setup` but does not
find `civicrm-setup-autoload.php`. It falls back to the old UI.

After
-----

It opens the new UI.

Merge pull request #16618 from totten/master-setup

dev/core#1615 - Import civicrm-setup

Merge pull request #16619 from demeritcowboy/remove-noop-translations

dev/translation#37 - Remove hardcoded translations from 13 years ago that no longer do anything

remove hardcoded translations that don't actually do anything anyway

(NFC) Update civicrm-setup to current civilint

(dev/core#1615) Load local copy of 'civicrm-setup' instead of downloading package

(dev/core#1615) Import civicrm-setup code

Note: This does not import the docs. Those should go to the dev guide.

Merge pull request #16616 from totten/master-scn

Move sequentialcreditnotes under `ext/` folder

Move sequentialcreditnotes under `ext/` folder

Maybe this is a bit of bikeshedding, but..

* `civicrm/ext/` is used for similar content in a few other cases (eg when adding `iatspayment` to the tarball; eg for
   the `drupal-case` and `wp-case` build-types).
* `civicrm/ext/` looks analgous to `sites/default/files/civicrm/ext`, which has similar content.
* Among the list of folders under `civicrm/`, `ext/` looks more consistent.  There are only two
  folders with capital letters (`CRM/` `Civi/`) and only two folders with multiple
  words (`bower_components/` `release-notes/`)... and 18 other folders which are
  lowercase+single-word (`ang/` `api/` `bin/` `css/` `distmaker/`
  `extern/` `i/` `install/` `js/` `l10n/` `packages/` `settings/` `sql/`
  `templates/` `tests/` `tools/` `vendor/` `xml/`).
* The file-hierarchy is additive (combining elements of the OS/host FHS, of the CMS, and of intra-extension content)
  and makes for a long total.

Merge pull request #16613 from seamuslee001/nfc_custom_field_array

[NFC] Convert Custom Field BAO file to use short array syntax

[NFC] Convert Custom Field BAO file to use short array syntax

Merge pull request #15834 from francescbassas/patch-16

dev/core#1386 Allow advanced search for contributions without a soft credit related

Merge pull request #16608 from civicrm/5.23

5.23

Merge pull request #16607 from totten/5.23-pathurltest

Update recently-added PathUrlTest to be more representative

Update recently-added PathUrlTest to be more representative

Before
------

The test generates the URL for an example page (`civicrm/mailing/subscribe`)
by calling `url()`. It does not explicitly set the `url(...$frontend...)` option,
so it defaults to `FALSE`.

By contrast, the other places which make URLs for `civicrm/mailing/subscribe`
(eg `CRM/Mailing/BAO/Mailing.php` and `CRM/Utils/Token.php`) do set `$frontend` to `TRUE`.

After
-----

The test behaves the same way as other code.

Merge pull request #16545 from eileenmcnaughton/part_pend

[REF] Extract function to getTransactionInfo

Merge pull request #16606 from ejegg/API4Regex-5.23

Fix two more php-finding regexes

Fix two more php-finding regexes

Before: Civi code living under a path containing the characters php
(such as ~/src/php/civicrm) will fail to load the API4 explorer with
a message like the following:
    ReflectionException: "Class \Civi\Api4\src does not exist"

After: API4 explorer loads no matter what the enclosing path

Very similar to PR #16377

Merge pull request #16605 from seamuslee001/master

[REF] Update civicrm_generated following merge of #16362

Merge pull request #16604 from civicrm/5.23

5.23

[REF] Update civicrm_generated following merge of #16362

Merge pull request #16602 from mattwire/apiv3paymentspec

Add description to params for api3 Payment.get

Add description to params for api3 Payment.get

Merge pull request #16600 from mattwire/casesettingstpl

Remove hardcoded settings from form and use SettingForm.tpl for Case settings

Merge pull request #16362 from eileenmcnaughton/pp_disable

Do not enable core payment processor types that we believe likely don't work on new installs

Remove hardcoded settings from form and use SettingForm.tpl for Case settings

Merge pull request #16599 from seamuslee001/dev_translation_36

dev/translation#36 Ensure that we are only passing integers to the ng…

Merge pull request #16562 from eileenmcnaughton/notice

Move determination of year & month to formatCreditCardDetails

dev/translation#36 Ensure that we are only passing integers to the ngettext function for plurals

Merge pull request #16596 from civicrm/5.23

5.23

Merge pull request #16594 from alifrumin/rn-5.23

First pass at release notes for 5.23

First pass at release notes for 5.23

Merge pull request #16529 from mattwire/altermailing_templatetype

Pass template_type through to alterMailing hook

dev/core#1386 Allow advanced search for contributions without a soft credit related

Merge pull request #16085 from seamuslee001/dev_core_1466

[NFC] dev/core#1466 Update Documentation URLS to be the correct links…

Merge pull request #15940 from seamuslee001/dev_financial_105

dev/financial#105 Add CSS class onto the radio button payment processor options

Merge pull request #15316 from mepps/order-campaign-dashboard

Secondarily order campaign dashboard by id

Merge pull request #15884 from kainuk/issue-lab-1365

Related / Inherited Memberships: Custom fields not filled with data

Merge pull request #16359 from jensschuppe/dev_core_1547

dev/core#1547 Add DT_RowClass CSS classes to nested group markup

Merge pull request #16005 from magnolia61/Contribution_Invoice_Privacy

dev/core#1436 Do not CC or BCC Contribution invoice

Merge pull request #16580 from civicrm/5.23

5.23

Merge pull request #16588 from eileenmcnaughton/523partnotice

Fix enotice regression (unreleased)

Merge pull request #16589 from colemanw/copyValues

Cleanup copyValues DAO function

Cleanup copyValues DAO function

The $serializeArrays parameter was transitional and is now always enabled.
Passing $params by reference was unnecessary and has been removed.
Renamed a few variables for readability.

Merge pull request #16585 from eileenmcnaughton/dep_it

Add deprecation notice

Merge pull request #16581 from eileenmcnaughton/nfc

[NFC] Test cleanup.

Fix enotice regressionn

This was merged to 5.23 but I made a booboo in it
https://github.com/civicrm/civicrm-core/commit/a3aed42a453009733e8feb2c56fde5750b37cd14

I think the params are actually not used so it's just the notice it causes but this fixes

Merge pull request #16587 from seamuslee001/5.23

Add release-notes/5.22.1.md

Merge pull request #16575 from colemanw/savedSearch

Make savedSearch bao sane

Merge pull request #16583 from totten/5.23-gencode-no-l10n

xml/GenCode.php - Fix execution in default locale (without l10n data)

Add release-notes/5.22.1.md

Add deprecation notice

I've been trying to figure out when this line would be hit but I just can't find a way to trigger
it - removing it would help a lot with this code but let's deprecate for a bit.

Further test fix

Merge pull request #16582 from eileenmcnaughton/ids

(NFC) Remove `$Id$` from header

Make savedSearch bao sane

xml/GenCode.php - Fix execution in default locale (without l10n data)

Overview
--------

This fixes a recent regression in which `xml/GenCode.php` fails to execute in certain configurations.

Initial report: https://github.com/civicrm/civicrm-buildkit/issues/503

Before
------

* If the folder `l10n` exists in its traditional location, and if you run `./bin/setup.sh -g`, then it
  correctly executes.
* If the folder `l10n` does not exist in its traditional locacation, and if you run `./bin/setup.sh -g`,
  then it fails with an error like this:
  ```
  + php -d mysql.default_host=127.0.0.1:3306 -d mysql.default_user=dmasterciv_abcde -d mysql.default_password=abcd1234 GenCode.php schema/Schema.xml '' Drupal

  civicrm_domain.version := 5.23.alpha1

  Parsing schema description schema/Schema.xml
  Extracting database information
  Extracting table information
  PHP Fatal error:  Uncaught RuntimeException: Invalid configuration: the [cms.root] path must be an absolute URL in /home/me/.../Civi/Core/Paths.php:174
  Stack trace:
  #0 /home/me/.../Civi/Core/Paths.php(151): Civi\Core\Paths->toAbsoluteUrl('/', 'cms.root')
  #1 /home/me/.../Civi/Core/Paths.php(176): Civi\Core\Paths->getVariable('cms.root', 'url')
  #2 /home/me/.../Civi/Core/Paths.php(151): Civi\Core\Paths->toAbsoluteUrl('/', 'civicrm.root')
  #3 /home/me/.../Civi/Core/Paths.php(224): Civi\Core\Paths->getVariable('civicrm.root', 'path')
  #4 /home/me/.../Civi/Core/Paths.php(84): Civi\Core\Paths->getPath('l10n')
  #5 [internal function]: Civi\Core\Paths->Civi\Core\{closure}()
  #6 /home/jo in /home/me/.../Civi/Core/Paths.php on line 174
  ```

After
-----

You can run `./bin/setup.sh -g` with or without the `l10n` folder.

Comments
--------

There's an argument to be made that this shouldn't be necessary: when running
`GenCode`, it should only create PHP files, and none of the output should depend
on the CMS URL - because that's liable to change when you deploy the PHP code.
If someone did try to generate URL at such an early stage, it's arguably good to
generate an error.  In point of fact, `GenCode` is not actually using the CMS
URL.

The oddity stems from the contract of `CRM_Utils_System_*` (specifically,
`getCiviSourceStorage()` and `getDefaultFileStorage()`) which do double-duty
providing both path and URL.  To avoid duplicate work, `Civi\Core\Paths` uses
the same grain of information - it tracks the pairs of path+URL.

A more aggressive fix might be to split `getCiviSourceStorage()` and
`getDefaultFileStorage()` so that it's possible to get the path and URL
separately; then revise `Civi\Core\Paths` to take advantage of the finer-grained
contract.  However, splitting those things would be a more invasive patch,
and we're currently in RC.

[NFC] Test cleanup.

Cleaned up this test - re-used code etc

Merge pull request #16531 from eileenmcnaughton/cn_

dev/financial#84 Move sequential credit notes from 'deeply  embeded functions to separate structure

Merge pull request #16528 from mattwire/removeoldflexmailer

Remove old defines for flexmailer that haven't been required since CiviCRM 5.x

Remove  from header

I was a bit surprised to see the old drupal svn  value pop back up - did if come from this header.txt file

Merge pull request #16578 from seamuslee001/dev_core_1602

dev/core#1602 Fix join date filtering in search builder by standardis…

dev/core#1602 Fix join date filtering in search builder by standardising date field handling in Membership Query BAO

Merge pull request #16563 from eileenmcnaughton/selfsvc

[NFC] Minor code cleanup

Merge pull request #16577 from civicrm/5.23

5.23 to master

Merge pull request #16558 from eileenmcnaughton/523dupe

dev/core#1597 & dev/core#1595 fix regression when deduping on custom fields

CRM-21541 CRM.moneyFormat can't handle values with zero or one decimals (#16445)

* CRM.formatMoney() handles zero or one decimals

* CRM.formatMoney() handles zero or one decimals

* CRM.formatMoney() handles zero or one decimals

* CRM.formatMoney() handles zero or one decimals

* CRM.formatMoney() handles zero or one decimals

* CRM.formatMoney() handles zero or one decimals

* CRM.formatMoney() handles zero or one decimals

* missing semicolon

* comment

* comment

* comment

* comment

Merge pull request #16564 from eileenmcnaughton/test

dev/financial#102 Extend test to check status

dev/core#1597 & dev/core#1595 fix regression when deduping on custom fields

Merge pull request #16571 from wmortada/over-ride

(NFC) Fix typo - no hyphen in 'override'

Merge pull request #16095 from seamuslee001/dev_core_1450

dev/core#1450 Try reducing the size of the temporary table so it only…

Merge pull request #16574 from civicrm/5.23

5.23

Merge pull request #16567 from eileenmcnaughton/parti_form

Fix theoretical regression

Merge pull request #16572 from civicrm/5.23

5.23

Fix typo - no hyphen in 'override'

Merge pull request #16506 from mattwire/invoicedue_countrefunded

Count refunds when calculating amount due for an invoice

Merge pull request #16009 from jmcclelland/import-match-phone

dev/core#1438 Enable matching on contact phone when importing contributions

Merge pull request #16035 from demeritcowboy/ang-crmcasetype-list-boolean

dev/core#1451 Incorrect dropdown action choices on case type listing screen

Merge pull request #16565 from eileenmcnaughton/contview

dev/financial#118 Move source & receive date to the top on contribution view page

Merge pull request #16568 from JGaunt/patch-4

Update 5.23.0.md

Merge pull request #16491 from mfb/undefined-index

Resolve notices if first donation amount and date columns were disabled

Merge pull request #16455 from MegaphoneJon/core-1568

core#1568: Show recipientListing to non-admins

Update 5.23.0.md

Added organisation name :)

Merge pull request #14928 from lcdservices/dev-core-1158

dev/core#1158 mailing labels: explicitly set primary flag

Merge pull request #15856 from agileware/CIVICRM-1368

dev/financial#104 Use rounding and integers to compare monetary values…

Fix theoretical regression

This PR https://github.com/civicrm/civicrm-core/pull/16363/commits/44237a295dc5eab4f6110fb0556b1af742364f6e
(merged to 5.23) calls self::::getDefaultRoleID() in a way that was always flawed but definitely woudl
not work now. I think it is never reached but better to put this fix into 5.23 & maybe reemove the line in master
later since it assumes participant_status_id is optional - which is not true of the backoffice form

dev/financial#118 Move source & receive date to the top on contribution view page

Per https://lab.civicrm.org/dev/financial/issues/118 this doesn't seem to be controversial - although there is a desire
to take it further & once this is merged I'll look at that

dev/financial#102 Extend test to check status

It turns out the code is working fine (fixed in the meantime?) and I just needed to extend the checks
a bit, did some tangental cleanup

[NFC] Minor code cleanup

Declare exceptions, use single quotes & strict comparison, do not declare unused params

Move determination of year & month to formatCreditCardDetails

Per https://github.com/civicrm/civicrm-core/pull/16514 it makes sense as a better place for these

Merge pull request #16557 from eileenmcnaughton/find

[NFC] Preliminary cleanup

Merge pull request #16498 from seamuslee001/net_smtp_upgrade

Upgrade Net_SMTP Package and remove now unneded patches and mov…

Update patch URL and remove patch content as per standard now

[REF] Upgrade Net_SMTP Package and remove now unneded patches and move to using composer patches rather than patching in a script file

[NFC] Preliminary cleanup

Declare exceptions, params, don't declare unused variables

Merge pull request #16552 from eileenmcnaughton/part_form

[REF] Fix static call to non-static function.

dev/financial#84 Move sequential credit notes from 'deeply  embedeed in BAO functions' to usin a listener structure

https://lab.civicrm.org/dev/financial/issues/84

We have a significant problem in our code base that it is hard to cleanup our key processes and make them usable and
Form-builder ready because of all the features deeply interwoven into them. It will be important that our
Order->add payment flow works and can be utilsed by the form builder. The expectation is that adding a payment
will update all the appropriate entities. We've been working pretty hard on this for a couple of years now (I think the time
taken to clean up code is sadly greater than the time it takes to add it :-() and the Payment.create part is getting
pretty solid now.

However, we are consistently hampered by code that has been 'enmeshed' into deep BAO code. In the case of the credit note
creation something that can easily be implemented as a pre hook and kept entirely out of the  Contribution.create function
is not only embedded in there but also in updateFinancialAccountsOnContributionStatusChange - which is one of the functions
we are some dozens of hours into adding tests & 'sorting out'. We need to find a way to

1) Declutter key functions where possible and
2) Model good ways of implementing things by hook (& work through limitations in this approach) as part of cleaning
up core and pushing towards a LeXIM approach.

I originally agreed with the CiviDiet approach that we should try to move the myriad of things that are 'add ons' that someone
thought was necessary & useful to others (or less charitably  they thought that if they got it into core someone else would have
to maintain it for them) moved out of core into extensions and eventually the maintenance of them moved out of the core team too.

However, it's clear from the  discussion on moving credit notes out of core that this is too hard for the forseeable future. We can try to avoid more features being added to core but most features in core are used by at least one organization & the politics of
moving things out are too hard. On the bright side we let a lot less new features into core these days - not none - the membership status override date springs to mind and the ongoing adding of fields & filters to reports - but less.

This leaves us with the question of whether we can still achieve the goal of making add-on features less of a developer burden.
In addition to ensuring code is tested we can do this by getting it out of the 'deep functions' into a listener structure.
I was able to covert the  'spaghetti-like-tendrils' in the credit note code to a simple 'pre' hook.

So it felt like we needed to create something new. Something like .. an extension .. but not visible on the extensions screen
and in core. Something like ... an extension in a folder in the core codebase that is suppressed from the extensions UI....

So this adds it as an extension to core in a new location & ensures GUI users cannot see it. I don't know exactly where we
draw the line around packaging things this way - Partial payments is clearly part of the core architecture, but there might be
a world in which we move something like event cart to be a more distinct bundle. As we move to form builder forms we are going to
want forms being replaced to be able to be 'quarantined' for future amputation.... I would be looking to move financial type acls and
invoicing to this structure - mostly because they are the biggest 'offenders' in terms of having code all over the place causing
problems with  other code initiatives & we've struggled to come up with a way to deal with that other than putting touching that
code in the 'too hard basket'. But even things like PCPs & Premiums would be more maintainable if they were discrete & overcoming
the challenges involved in that would solve a lot of extensibility issues.

Note this approach permits an  incremental cleanup-up-to-separation  process. For example we could create an  extension for  a
feature and move some code to it and later move some other code. For example we  could move the invoicingPostProcessHook
to a  shell invoicing extension and at some later point  address other  parts of the  invoicing code (check LineItem::getLineItems
for the chunk of  code  that has been blocking  other  cleanup - moving  this to a listener would help a lot

Note this PR does not address the significant performance issues associated with the creditnotes code on larger sites, only the impact
it has on our code maintainability. If we can agree a way to start to address how to split out or code into listeners in an agreed structure then I can look at that as a follow up.