Merge pull request #15248 from MegaphoneJon/reporting-19

reporting#19 - Performance improvements on report display/export

Merge pull request #15758 from yashodha/contributors

add contributor name

Merge pull request #15595 from eileenmcnaughton/dedupe3

dev/core#1339 Dedupe screen check to carry across any data where the other contact has none by default.

add contributor name

Merge pull request #15755 from seamuslee001/copywrite_date_update

[NFC] Update copyright date for 2020

Merge pull request #15739 from eileenmcnaughton/dompdf

Update dompdf (0.8.0=>0.8.3) & dependencies

[NFC] Style Fix Prepare Event

(NFC) Style fixups

Update copyright date for 2020

Set version to 5.21.alpha1

Set version to 5.20.beta1

Merge pull request #15754 from seamuslee001/master

5.19

Merge in 5.19

Set version to 5.19.0

Merge pull request #15752 from agh1/5.19.0-releasenotes-final

5.19.0 release notes: added late changes

Update 5.19.0.md

Merge pull request #15751 from magnolia61/workflow_template_contribution_terms

changed wording to Total Fee & Total Paid

5.19.0 release notes: added late changes

Merge pull request #15748 from eileenmcnaughton/line_item_belt_braces

Provide precautionary handling for theoretical error scenario.

changed wording to Total Fee & Total Paid

Provide precautionary handling for theoretical error scenario.

While testing payments I hit a bug where I tried to add a payment to a contribution with no financial items.

I never managed to replicate it again or determine how the payment came to be in that state but
it's been playing in my mind that people could get fatal errors if the financial_items don't exist
and dealing with those as regression reports will very tough. So my plan is
- for 5.20 add this extra routine to create it if it does not exist
- use this mechanism + more digging to figure out how legit an issue it is https://github.com/civicrm/civicrm-core/pull/15706
- in future releases 'get noisy' about having to create them if they don't exist
- eventually remove this routine

Merge pull request #15740 from eileenmcnaughton/partial

dev/financial#40 Fix for non-allocation of payment to fully reversed checkboxes option

Merge pull request #15745 from seamuslee001/master

Update template upgrade list as per PR #15742

Merge pull request #15750 from eileenmcnaughton/except

[NFC] Cleanup on exceptions

Merge pull request #15744 from yashodha/participant_edit

(dev/core#1065) Participant in Edit mode needs to be shown consistently

Merge pull request #15749 from seamuslee001/Additional_Fixes_to_workflow_templates

Additional fixes to workflow templates

Update template upgrade list as per PR #15742

Cleanup on exceptions

Fixes a low level function to throw a CRM_Core_Exception & tidies up functions
above to specify that. Fixes casing on a function call, removes a fatal
for status bounce

Fix Smarty Syntax in payment_or_refund_notification_text template and update unit tests to match the change in langauge in the templates

Merge pull request #15746 from civicrm/5.19

5.19

Merge pull request #15741 from totten/5.19-volinst

(dev/core#1093) Fix regression during extension activation

Merge pull request #15743 from eileenmcnaughton/validate_test

Fix test to be more valid

Additional changes to workflow message templates

(dev/core#1065) Participant in Edit mode needs to be shown consistently

Fix test to be more valid

I've added a check to run after tests & before tearDown to ensure that all payments have the
right entity_financial_trxn records.

This required fixing one ttest to be valid. It's not possible to create a contribution using the
back office for with status set to Partially Paid (it's not an option in the drop down, so
the test should create as Pending & then add a payment to get to partially paid

(dev/core#1093) Fix permission error when activating extension

Overview
--------

This fixes a recent/unreleased regression from #15726 in which the D7 demo build fails.

Before
------

When running `civibuild reinstall ...` on a `drupal-demo` site, it fails at this step:

```
+++ drush -y cvapi extension.install key=org.civicrm.volunteer debug=1
Authorization failed                                                                                                                                                   [error]
Array
(
    [error_code] => unauthorized
    [entity] => Extension
    [action] => install
    [trace] => #0 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(166): Civi\API\Kernel->authorize(Object(Civi\Api4\Provider\ActionObjectProvider), Object(Civi\Api4\Generic\DAOSaveAction))
1 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/Api4/Generic/AbstractAction.php(235): Civi\API\Kernel->runRequest(Object(Civi\Api4\Generic\DAOSaveAction))
2 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Utils/Migrate/Import.php(374): Civi\Api4\Generic\AbstractAction->execute()
3 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Utils/Migrate/Import.php(82): CRM_Utils_Migrate_Import->customFields(Object(SimpleXMLElement), Array)
4 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/tools/extensions/civivolunteer/CRM/Volunteer/Upgrader.php(836): CRM_Utils_Migrate_Import->runXmlElement(Object(SimpleXMLElement))
5 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/tools/extensions/civivolunteer/CRM/Volunteer/Upgrader.php(48): CRM_Volunteer_Upgrader->executeCustomDataTemplateFile('volunteer-custo...')
6 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/tools/extensions/civivolunteer/CRM/Volunteer/Upgrader/Base.php(306): CRM_Volunteer_Upgrader->install()
7 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/tools/extensions/civivolunteer/volunteer.civix.php(131): CRM_Volunteer_Upgrader_Base->onInstall()
8 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/tools/extensions/civivolunteer/volunteer.php(204): _volunteer_civix_civicrm_install()
9 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Extension/Manager/Module.php(76): volunteer_civicrm_install()
10 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Extension/Manager/Module.php(48): CRM_Extension_Manager_Module->callHook(Object(CRM_Extension_Info), 'install')
11 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Extension/Manager.php(264): CRM_Extension_Manager_Module->onPreInstall(Object(CRM_Extension_Info))
12 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/api/v3/Extension.php(58): CRM_Extension_Manager->install(Array)
13 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Provider/MagicFunctionProvider.php(101): civicrm_api3_extension_install(Array)
14 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(168): Civi\API\Provider\MagicFunctionProvider->invoke(Array)
15 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(99): Civi\API\Kernel->runRequest(Array)
16 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/api/api.php(23): Civi\API\Kernel->runSafe('extension', 'install', Array, NULL)
17 /Users/myuser/bknix/build/dmaster/web/sites/all/modules/civicrm/drupal/drush/civicrm.drush.inc(1557): civicrm_api('extension', 'install', Array)
18 phar:///Users/myuser/bknix/civicrm-buildkit/extern/drush8.phar/includes/command.inc(422): drush_civicrm_api('extension.insta...', 'key=org.civicrm...', 'debug=1')
19 phar:///Users/myuser/bknix/civicrm-buildkit/extern/drush8.phar/includes/command.inc(231): _drush_invoke_hooks(Array, Array)
20 phar:///Users/myuser/bknix/civicrm-buildkit/extern/drush8.phar/includes/command.inc(199): drush_command('extension.insta...', 'key=org.civicrm...', 'debug=1')
21 phar:///Users/myuser/bknix/civicrm-buildkit/extern/drush8.phar/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array)
22 phar:///Users/myuser/bknix/civicrm-buildkit/extern/drush8.phar/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
23 phar:///Users/myuser/bknix/civicrm-buildkit/extern/drush8.phar/includes/startup.inc(465): drush_main()
24 phar:///Users/myuser/bknix/civicrm-buildkit/extern/drush8.phar/includes/startup.inc(369): drush_run_main(false, '/', 'Phar detected. ...')
25 phar:///Users/myuser/bknix/civicrm-buildkit/extern/drush8.phar/drush(114): drush_startup(Array)
26 /Users/myuser/bknix/civicrm-buildkit/extern/drush8.phar(10): require('phar:///Users/t...')
27 {main}
    [is_error] => 1
    [error_message] => Authorization failed
)
```

After
-----

It works again.

Merge pull request #15738 from agileware/CIVICRM-1354

Fix the relationship direction in testSingleMembershipForTwoRelationships

Fix for non-allocation of payment to fully reversed checkboxes option

This addresses an issue partially identified in https://lab.civicrm.org/dev/financial/issues/98 whereby
civicrm_entity_financial_trxn records for the civicrm_financial_item table are not created when
refunding against line items with a quantity of zero  - ie where there were selected checkboxes & they
were reversed.

The reason this check was there relates to former logic - now we have a calculated allocation
we don't need this check.

I want to do a test but need to do a bit of work to get it set up & I think this should hit 5.20
as it relates to an issue identified by Kevin in reviewing patches merged to that version

Merge pull request #15731 from eileenmcnaughton/rel_clean

dev/core#1361 Fix bug where 2 memberships created for same relationship

Update dompdf & dependencies

DomPDF issues warnings on php 7.3
The latest version boasts 'Improved compatibility with PHP 7.3'
https://github.com/dompdf/dompdf/releases/tag/v0.8.3

To get there I needed to do
composer   update dompdf/dompdf phenx/php-svg-lib sabberworm/php-css-parser

& also got https://github.com/sabberworm/PHP-CSS-Parser/releases
onto the version that supports php 7+ - no obvious issues in the release notes  and

https://github.com/PhenX/php-svg-lib/releases
- moving us from Bruised Bumblebee to Fanatical Furet

Once againt nothing alarming & improved php 7+ support

Merge pull request #15556 from demeritcowboy/convert-label-to-name-2

Upgrade script for dev/core#1046

CIVICRM-1354 fix test

Merge pull request #15735 from jitendrapurohit/dev-1367

dev/core#1367 - Incorrect line items recorded with contribution repea…

dev/core#1361 Fix bug where 2 memberships created for same relationship

Fixes a bug (likely recent regression) identified by @agileware-pengyi where duplicate inherited relationships for the same membership were being created

I've been pretty much sweating blood trying to understand the code, & have now resorted to adding a class to
generate a saner data set

Merge pull request #15733 from seamuslee001/payment_process_api4_schema

Schema changes for PaymentProcessor and PaymentProcessorType to suppo…

Merge pull request #15737 from eileenmcnaughton/php73

Php 7.3 fix - don't mis-use continue

Merge pull request #15705 from eileenmcnaughton/refund_fix

Fix Payment.create with a negative value to create the correct financial items

Merge pull request #15736 from demeritcowboy/remove-old-code

(NFC) Remove windows-specific debugging code from 11 years ago

Fix Payment.create with a negative value to create the correct financial items

The job of a refund in this function turns out to be exactly the same as the a payment. I originally thought the
from & to accounts would be reversed but in fact because we are recording a negative amount that is not the case.
We need the from-to accounts to be the same. The only difference turns out to be the status
of the financialTrxn (Completed vs Refunded it seems).

Without this change the refund code is calling the recordFinancialAccounts function but after stepping
through it I'm sure the only thing that function is doing for it is creating the
FinancialTrxn. It *should* be creating the EntityFinancialItem too but it is not
and the best place for that to be done is in the payment class not in a spaghetti function.

Note that after this we need some robust testing & probably a follow up
patch on the handling of tax items - which is unlikely to be correct since it wasn't in the past
AFAIK and is unchanged.....

However, this fixes an important bug & should be merged as soon as it is confirmed non-regressive
to allow the next one to be investigated

m

Bring recordRefundPayment back into the main function.

It's adding confusion and it turns out it's broken so let's fix properly

Update all payment tests to ensure entity financial items created

Alsothwe had tests for this it turns out they were only checking that they were correct IF created. This
ensures they also exist & is a sanity check to run at the end of tests. The two failing tests are
really failing :-(

Fix double loop on lineItems

Historically the code followed 2 loops - one for the (very rare) situation when an array of
'line_item' was passed in - in fact this array is an array of arrays where each array represents
the id of a line item and the amount to allocate.

The other loop is the main loop that allocates according to a calculation.

This fixes it so that the allocation is correctly merged in if passed in in
getPayableLineItems and from that point we only need one loop.

This simplification is tested via the testCreatePaymentLineItems
which I cleaned up and made more robust. I was able to step through it and identify how
it was working

Merge pull request #15684 from eileenmcnaughton/legacy_extract

Remove recordPayment function.

Php 7.3 fix - don't mis-use continue

Also fix some casing

Merge pull request #15640 from eileenmcnaughton/pp_pay

Fix Payment.create bug whereby payment_processor_id is not being used for the to_account_id

remove debugging code

dev/core#1367 - Incorrect line items recorded with contribution repeattransaction api

Merge pull request #15732 from totten/master-tplaner-when

composer.{json,lock} - Make the "tplaner/when" exception for old PHP reproducible

Schema changes for PaymentProcessor and PaymentProcessorType to support apiv4 entities

Merge pull request #15730 from seamuslee001/new_xkerman_package

Add in xkerman/restricted-unserialize package

composer.{json,lock} - Make the "tplaner/when" exception for old PHP reproducible

Overview
--------

The library `tplaner/when` has an inaccurate dependency on php71 and
requires special work to deploy on php70.

Before
------

The `composer.lock` file was manually edited to make it runnable on php70.
However, if you `rm composer.lock && composer install`, then it fails.

After
-----

The `composer.json` and `composer.lock` are more repeatable.  If you run
`rm composer.lock && composer install`, then it works.

Comments
--------

This adds a fairly ugly section.  However, the good news is that it should
be more transparent - which should make it easier to understand/remove
later.

As a general rule, we don't want to have `civicrm-core.git` depend on
packages/versions that aren't published.  This is a somewhat unusual
edge-case - this package/version is published via `packagist.org`.  If you
run without this on php71+, then you still get a valid/equivalent package.
All that we've done is to enable running on `php70` (when `civicrm-core` is
a root project).

Add in xkerman/restricted-unserialize package

Merge pull request #15728 from eileenmcnaughton/rel_clean

[REF] minor code simplification

[REF] minor code simplification

Switches a call to an old function to an api function & removes post filtering.

Currently the code calls an old function which gets all membership ids & then filters on
statuses. This switches to an api call & passes statuses in as a filter

Strong test cover in testSingleMembershipForTwoRelationships which tests these lines in a variety of ways

Merge pull request #15707 from eileenmcnaughton/setter

dev/financial#82 revert added setters

Merge pull request #15710 from seamuslee001/custom_field_convert

dev/core#561 Add in routine to convert custom date fields in smart groups to datep…

Merge pull request #14349 from mattwire/case_links_refactor_3

Convert case activity links to 'actionLinks'

Re-apply useful cleanups from reverted commits

Revert "dev/financial#77 ++ Make contribution_id mandatory for PaymentProcessor.pay, pass incoieID"

This reverts commit 783b62a7dfe3c94bd69bcb182732b240e53911be.

Revert places where setters are used to set things

These are all new in 5.20 & if we are going to change we should reverse & re-do before cutting 5.20

Revert "Add getters & setters for contributionID on CRM_Core_Payment."

This reverts commit c28ad54a7194e30033ffed1ad727586546e80db3.

Revert "Add a bunch of additional getters & setters"

This reverts commit c5884dfddb30e40e06af9ef0f2dc940ad6ae55bd.

Merge pull request #15694 from eileenmcnaughton/custom

Get rid of jcalendar range in custom data

Merge pull request #15729 from civicrm/5.19

5.19 to master

Merge pull request #15726 from MiyaNoctem/dev-core-1093-fix-installation-of-custom-fields-with-option-values

dev/core#1093: Fix Installation of Custom Fields with Option Values From XML

Add in a unit test of the custom field date range conversion

Add in routine to convert custom date fields in smart groups to datepicker format

Remove 'recode handling

Add in template file for laying out datepicker in custom fields and extract js into own template for sharing

Get rid of jcalendar range in custom data

Merge pull request #15727 from civicrm/5.19

5.19

Merge pull request #15719 from eileenmcnaughton/custom_query_fix_join

Fix Custom field date query builder to work with 'raw' high & low params

Merge pull request #15724 from MiyaNoctem/dev-core-1360-fix-programatic-installation-of-extensions-v519

dev/core#1360: Fix Programatic Installation Of Multiple Extensions on v5.19

dev/core#1093: Fix Installation of Custom Fields with Option Values From XML

Merge pull request #15722 from eileenmcnaughton/rel_test

[REF] minor tidy ups on very nasty function

dev/core#1360: Fix Programatic Installation Of Multiple Extensions

Merge pull request #15723 from eileenmcnaughton/rel_clean

Eliminate silly parameter

Further join tests & fixes

Turns out the carefully constructed join was being whomped - but only sometimes

Fix Custom field date query builder to work with 'raw' high & low params

Once we convert to datePicker we will be passing in parameters like custom_3_high, custom_3_low & custom_3_relative.

Currently we pass in custom_3_to & custom_3_from and custom_3_relative. This adds support for the new high & low
withoutt touching support for previously working or switching the field across (as yet). This paves the way for
the datepicker conversion. After a lot of brain pain I concluded the fundamental problem was the whereTables
from the CustomQuery were being merged in but actually then lost when where() is called.

Move all thte code that relates to joining tables/constructing From to one place.

This could definitely be cleaned up more - but the goal of this step is just to move all the code that
constructs the from code into one place, so it can be called more sensibly.

Tested in the newly written testAddressCustomFields

Switch to cached retrieval function

Add date check to test

Remove a few lines of unnecessary code
It used to be necessary to ISO format code before DAO->save. However, along the line wee fixed it lower
down & no longer need this smattered all over the code. Test proves it's OK

Eliminate silly parameter

 is only ever passed into this function once. In that instance
it is then populated off owner_membership_id & then wrangled in the calling function
back to a separatte arry before being unset. The moves it back to the calling function &
simplifieds

Good test cover exists in testCreateMembership

Merge pull request #15721 from eileenmcnaughton/odd_return

Remove early return on joinTable

Merge pull request #15720 from eileenmcnaughton/test_clean

Test improvements

Remove early return on joinTable

I looked up the reason for the early return here and it was that the UI for adding other tables
in was too complex. In other words the removed lines should never be true.

However, I don't think it's the place of the query object to enforce not attempting a query the
UI struggles with. Removing this will save a later person having to figure that out

Convert customQueryTest to test the BAO_Contact_Query

While I understand the theory of unit tests is to test low level chunks of code that relates in many
ways to WELL-DESIGNED chunks. In the case of the query object it is more important to
ensure the results experienced by the user are correct - this converts the existing test
to a more end-to-end test on the CRM_Contact_BAO_Query object acting correctly.

[NFC] Test cleam up

Merge pull request #15718 from eileenmcnaughton/custom_query_fix

[REF] Remove early return on joinTable

Merge pull request #15714 from eileenmcnaughton/custom_sane_save

[REF] remove  as a return Param of getHierContactDetails