Issue template - Small tweak

Issue template - Rename "general-bug-or-issue" to "problem"

Because... fewer words

Issue template - Move error-msg block from "Reproduction steps" to "Current behavior"

Issue template - No screenshot for expected behavior

The "Expected Behavior" is specifically what the system does *not* do, so...
it might be hard to give a screenshot of that...

Issue template - For triple `, use multiline

Issue template - Update "Environment"; combine type+version fields

We want "versions" for everything. Making separate lines for the version just makes it bit
harder to write (you have to remove more things) and to read (you have to skim more lines).

Changes:

* Combine "CMS/CMS Version"
* Combine "Database/Database Version"
* For "Web Server", also include version.
* Add "PHP"

Update general-bug-or-issue.md

Update and rename general.md to general-bug-or-issue.md

Update general.md

Create a GitLab general issue template

I had a call with Craig this morning to discuss how to raise issues etc on GitLab for new contributors - it was useful but it made me realise that we can help out people opening issues with one or more sensible templates for issues to guide people on what information to include in their issue.

So here's a general issue template based on the PR template and this issue of @jaapjansma's https://lab.civicrm.org/dev/core/issues/1345

Merge pull request #15660 from totten/master-no-persistent

Remove unused, hidden subsystem for "persistent DB tpl strings"

Upgrader - Drop table "civicrm_persistent" (unless it has data)

sql/civicrm_generated.mysql - Update

DB Tpl Strings - Remove table "civicrm_persistent"

DB Tpl Strings - Remove unused form 'civicrm/admin/tplstrings'

If you grep for this (in v3.2, v5.20, and universe), you will find that the
only usages are self-referential or pro-forma:

- There is / never been a navigation item pointing to the page.
- There is no codepath which *consumes* data produced here.

DB Tpl Strings - Remove unused Smarty function crmDBTpl

I've searched `universe` and haven't found any references to this.  This
appears to be the only code-path which consumes information from
`civicrm_persistent`.

I also went back to spot-check a few SVN branches of CiviCRM (v3.2, v3.3).
It appears that this was added in v3.2 *but never used or documented*.

CRM_Upgrade_Incremental_Base - Add helper dropTableIfEmpty()

CRM_Core_DAO - Add helper checkTableHasData()

Merge pull request #15653 from eileenmcnaughton/billin_name

dev/core#1344 Simplify email template logic on displaying card inform…

Merge pull request #15659 from civicrm/5.19

5.19

Merge pull request #15657 from demeritcowboy/pledge-search-backport

dev/core#1348 - pledge search not working backport of 15656

Merge pull request #15658 from MikeyMJCO/patch-1

Delete mkdocs.yml

Merge pull request #15655 from demeritcowboy/activity-search-form-values

dev/core#1348 - backport of PR 15654

Merge pull request #15652 from eileenmcnaughton/schema

Add uniquenames for mailing_name, mailing_job_status

Delete mkdocs.yml

We may as well remove the old mkdocs.yml file as it's not used.

pledge search not working

activity search not working at all

dev/core#1344 Simplify email template logic on displaying card information

Same deal as https://github.com/civicrm/civicrm-core/pull/15646

Add uniquenames for mailing_name, mailing_job_status

This is in support of https://github.com/civicrm/civicrm-core/pull/15369

Where the names in the search do not match the 'real names' we have 2 techniques

1) where adding a unique name to the schema gives a match we do that - here that is
the case for mailing_name
2) otherwise we ensure the schema has a unique name if appropriate &
rename the field in the upgrade scriptt

In this case when we look at CRM_Mailing_BAO_Query we don't see mailing_name
as present (only mailing_id which should be an entity reference field). However it
is used in the confusingly-not-related Mailing search so lets rename this
one at the same time.

Merge pull request #15646 from eileenmcnaughton/add_pay

dev/core#1344 Simplify email template logic on displaying billing detail

Merge pull request #15626 from demeritcowboy/case-pdf-merge-order

dev/core#893 - fix misfiled case print/merge pdfs (alternate to PR 15609/15364)

Merge pull request #14763 from eileenmcnaughton/payment_3

dev/financial#34 Fix line allocation in Payment.create

Merge pull request #15648 from seamuslee001/relationship_date_cleanup_fixes

Cleanup following smart group conversions and fix the old name of the…

Cleanup following smart group conversions and fix the old name of the relationship date relative fields for conversion and add a unit test

Merge pull request #15647 from demeritcowboy/regen-upper-lower

Allow regen.sh to work with either upper/lower case for CMS name to match elsewhere

Merge pull request #15637 from eileenmcnaughton/relationdates

Convert relationship start & end dates to datepicker

work with either upper/lower to match elsewhere

Convert relationship_start_date & relationship_end_date to datepicker

This seems to work OK - look forwards to seeing you kick the tyres on it & see if you find any issues

Merge pull request #15635 from eileenmcnaughton/contact_date

dev/core#561 Convert birth_date & deceased_date to datepicker

Convert birth_date & deceased_date to datepicker

Merge pull request #15636 from eileenmcnaughton/relationship_date

Add unique name for relationship start & end dates

dev/core#1344 Simplify email template logic on displaying billing detail

Per https://lab.civicrm.org/dev/core/issues/1344 we currently use complex & fragile logic whereas we can simply display
what we have gathered. Since email templates are already being upgraded this release it feels like a good
opportunity to clean these up too.

This just includes one template - but I'll rip through the rest if this gets merged & people agree

Merge pull request #15643 from omarabuhussein/fixing-optionvalues-xml-processing

Fixing a fatal error when installing extensions with Option Values defined in XML

Merge pull request #15630 from eileenmcnaughton/pay_fail

Fix cancel payment action to reverse financial items related to cancelled payment

Merge pull request #15644 from civicrm/5.19

5.19 to master

Merge pull request #15642 from MiyaNoctem/dev-core-1093-backport-fix-to-v5.19-rc

dev/core#1093: Bckport Fix to v.5.19 to Add Custom Fields to Logging Tables

Fixing a fatal error when installing extensions with Option Values
defined in XML

If an Extension has an option value defined in an XML file and the
option value belongs to an option group that is already defined in Civi
But in the XML (e.g activity_type option group) then installing the
extension will result in a fatal error with the following message :

"A fatal error was triggered: One of parameters (value: ) is not of the type Integer"

The error happen because CiviCRM fails to find the option group in the
XML file so it look for it in the database, but the code that look for
it pass the option group name as a SimpleXML object (since SimpleXML
does not return scalar values and rather objects of Type SimpleXML) and
because of that the code won't be able to find the value which will
result in executing a query that expect an integer but rather a NULL
pass to it which result in the fatal error.

I fixed it by casting the option group name inside the SimpleXML object
to string.

dev/core#1093: Add Custom Fields to Logging Tables

BulkSave method was adding fields to custom group table, but not to custom
group logging table. If these tables were updated on installation, before all
the schema is synced bewtween main and logging tables, fatal errors would be
thrown, as triggers tried to insert info into log tables missing required
fields.

Fixed by building log table after all fields are added to main table, and
before rebuilding triggers.

Merge pull request #15639 from eileenmcnaughton/pay

dev/financial#77 ++ Make contribution_id mandatory for PaymentProcessor.pay, pass invoiceID

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

Replaces https://github.com/civicrm/civicrm-core/pull/15477 & also resolves https://lab.civicrm.org/dev/financial/issues/77

by requiring contribution_id for PaymentProcessor.pay as a way to ensure that it is only called after the order is created
per our preferred flow (people could still get past this but it feels like they would at least know they werre
hacking our process & take responsibility for any issues if it breaks or we suddenly start enforcing that
it is a valid contribution.

This also sets some of the recommended variables. Note that I had to use a few more lines to ensure we were always setting
contactID, contributionRecurID to an integer. I do think this stricter approach is better but it wound up
more verbose

Merge pull request #15375 from ixiam/dev_issue#1282

dev/core#1282 Takes care of customfields of type multiselect that were not being rendered

Merge pull request #15541 from ixiam/dev_issue#1324

Adds missing join on the customtable of address customfields while exposed as profile

Add unique name for relationship start & end dates

Preliminary to fixing for datepicker

Merge pull request #15634 from eileenmcnaughton/mailing_date

Improve metadata support for table civicrm_mailing_job in search

Merge pull request #15633 from seamuslee001/dev_core_561_mailing

dev/core#561 Convert mailing date search field to using datepicker

Merge pull request #15631 from eileenmcnaughton/fix_it

[REF] Further deconstruction of updateFinancialAccounts

Pass dbFieldName to dbFieldName parameter

Improve metadata support for table civicrm_mailing_job in search

This makes the civicrm_mailing_job_start_date field available as
metadata and cleans up the code specifying how
civicrm_mailing_job gets joined in.

It turns out the code design has a pretty sensible methodology for ensuring that required
tables are added but unaware of this the tables
got configured all over the place in the where clause
functions.

dev/core#561 Convert mailing date search field to using datepicker

Some more cleanup and also open tab if specified in the URL

Merge pull request #15629 from eileenmcnaughton/mailing_form

Change parent class on mailing_form

Merge pull request #15627 from eileenmcnaughton/nfc

[NFC] reformat BAO_Case file

Further deconstruction of updateFinancialAccounts

updateFinancialAccounts is only called from one place with the context of 'changedStatus'. When called this
way the function updateFinancialAccountsOnContributionStatusChange is called & that 'tells'
the calling function whether to call the rest of this function.

Since this handling is specific to one place from which the function is called we can move that logic
back to the place that calls it & further simplify the updateFinancialAccounts function
which has been a bit of a haven of chaos

Fix cancel payment action to reverse financial items related to cancelled payment

The unit test to test & ensure this was failing to pick up that the records were not being created because it iterated
through the created rows & checked they were right but there was no check to ensure the rows were created :-(

This still leaves a gap I think for refunds not tied to a specific payment but that can be a later step

Merge pull request #15601 from eileenmcnaughton/items

[REF] simplify definition of isARefund

Merge pull request #15628 from eileenmcnaughton/mailing

[NFC] Add date information to MailingJob Schema

Add call to getSearchFieldMetadata

Change parent class on mailing_form

[REF] simplify definition of isARefund

Add date information to MailingJob Schema

Merge pull request #15625 from seamuslee001/e2e_cache_debugging

[NFC] Add in debugging to try and resolve E2E Cache intermitant test …

[NFC] reformat BAO_Case file

Exceptions

Update ArrayDecoratorTest.php

fix misfiled pdf merges

Merge pull request #15613 from eileenmcnaughton/lines_extract

[REF] extract chunk of code that creates the financial items for a given line.

Extract code to calculate how much of a line item has been paid

dev/financial#34 Fix line allocation in Payment.create

Cast result of getContributionBalance to float to match comment block.

Without this it is possible for it to return 'null' which is not useful / in keeping. I did a bit of an audit &
did not find places where this would cause an === comparison to fail

[NFC] Add in debugging to try and resolve E2E Cache intermitant test failures

Merge pull request #15620 from eileenmcnaughton/order

Fix test setup Function to use order api

Merge pull request #15623 from seamuslee001/type_check_exceptions

dev/core#560 [REF] Throw exceptions for invalid type errors when aborting

Merge pull request #15621 from eileenmcnaughton/float

Cast result of getContributionBalance to float to match comment block.

Fix test setup Function to use order api

After ongoing issues resolving https://github.com/civicrm/civicrm-core/pull/14763 I have concluded the underlying
issue on the failing tests is the test setup. Specifically the use of 'partial_amount_to_pay' does not
create the correct underlying entities - it 'sort of' creates a payment without linking it to
the financial items.

These parameters are part of our first attempt at partial payments. I am removing them from the test here but
will deprecate later from other places in the code

[REF] Throw execptions for invalid type erorrs when aborting

Merge pull request #15622 from eileenmcnaughton/deprecate_bad

Change test to use preferred methods, fix revealed money bug

Change test to use preferred methods, fix revealed money bug

In switching this test over I found that Payment.create does not handle cleaning money - which it should to bring it
into line with Contribution.create api

Cast result of getContributionBalance to float to match comment block.

Without this it is possible for it to return 'null' which is not useful / in keeping. I did a bit of an audit &
did not find places where this would cause an === comparison to fail

Merge pull request #15619 from seamuslee001/fix_force_case_form_date

Ensure that using case_start_date_high and case_start_date_low etc in…

Merge pull request #15513 from magnolia61/Display_name_in_some_workflow_templates

dev/core#1320 Include displayname in subjects to prevent grouping in email clients

Ensure that using case_start_date_high and case_start_date_low etc in url variables works in force=1 mode

Merge pull request #15618 from eileenmcnaughton/case_from_to

Case datepicker field conversion - Follow up cleanup

Include Displayname in some workflow templates

Merge pull request #15614 from seamuslee001/convert_case_date_jcalendar

dev/core#561 Convert Case date fields on search forms from jcalendar …

Merge pull request #15616 from eileenmcnaughton/qill

Minimal fix for new enotice on case.subject

dev/core#561 Convert Case date fields on search forms from jcalendar to datepicker

Swap to using buildDateRangeQuery function

Fix notice error and generically handle cases where we have specified to use the LIKE operator for strings

Merge pull request #15580 from jaapjansma/dev_1205

Issue 1205: allow custom fields of type file for entities

Merge pull request #15615 from colemanw/explorerFix

Api4 explorer: Fix variable leaking to global scope

Minimal fix for new enotice on case.subject

The new enotice is caused by treating it as a LIKE string rather than a strict match (which is generally
a good thing)

Follow up cleanup

Api4 explorer: Fix variable leaking to global scope

Merge pull request #15370 from JMAConsulting/core-692-2

Core/dev#692 : Support search arguments to Case Search form