CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-09-19T05:03:39Zhttps://lab.civicrm.org/dev/core/-/issues/565Make subject field of Note, inline editable in contact summary page2022-09-19T05:03:39ZMonish DebMake subject field of Note, inline editable in contact summary pageThis is a minor style change, which adds the ability of the user to edit note field in contact summary page editable.This is a minor style change, which adds the ability of the user to edit note field in contact summary page editable.Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/558Improve code quality2022-09-18T05:03:38ZeileenImprove code qualityThis is an intended parent issue for ongoing code cleanup initiatives - the specific ones will be linked from here.This is an intended parent issue for ongoing code cleanup initiatives - the specific ones will be linked from here.https://lab.civicrm.org/dev/core/-/issues/373Custom field set behaving incorrectly in Contributions2022-09-16T05:03:38ZAndy ClarkCustom field set behaving incorrectly in ContributionsA custom field set that is flagged to appear only for 'Donations' correctly appears when a contribution is made. However if a field in that set isn't completed or is in error, an error message is correctly shown but the custom field set ...A custom field set that is flagged to appear only for 'Donations' correctly appears when a contribution is made. However if a field in that set isn't completed or is in error, an error message is correctly shown but the custom field set disappears and is replaced by 'Additional Details' which is opened up. To enter the custom field set you have to start again with the contribution. This only happens when the custom field set is **not ** set to 'Any'. The problem found in 5.4.1, and can be reproduced on the demo sites which today are at 5.6 alpha1. Problem is also present in 5.1.2 but not sure about 5.2 or 5.3.https://lab.civicrm.org/dev/core/-/issues/524Lybunt incorrect / misleading rowCount information2022-09-14T05:03:42ZeileenLybunt incorrect / misleading rowCount informationThe Lybunt report declares a misleading number of rows because it includes the rollup row in the count.
So for example there are 9 matching contacts but we see the confusing message Rows Listed 9, Rows found 10. The 10th Row is a calcu...The Lybunt report declares a misleading number of rows because it includes the rollup row in the count.
So for example there are 9 matching contacts but we see the confusing message Rows Listed 9, Rows found 10. The 10th Row is a calculation of the total rows.
![Screenshot_2018-11-15_14.20.45](/uploads/5933de1016a4fb8b9b1e4447206b07a7/Screenshot_2018-11-15_14.20.45.png)
When there is just one screen we can remove a row that is meant to help - but doesn't & the 'Total Rows' line goes away.
However, when there are multiple pages we have both the pager & the totals to deal with. If we remove the row from the totals count but not the pager it creates a confusing mismatch. If we remove from both the last row may become unreachable.
On the Lybunt report a maximum of one level of group by is in play. However, where reports support multiple levels of group by it's unknowable how many rows are rollup rows.
This might all be an argument against the use of Rollup - but not going there at this stage I think my best proposal is to add text to indicate the possible presence of calc rows in the Total Rows
![Screenshot_2018-11-15_14.11.37](/uploads/cd4c266eb5c49570815b130a809f26ec/Screenshot_2018-11-15_14.11.37.png)https://lab.civicrm.org/dev/core/-/issues/107After creating a new case, the assignee for each activity must be selected ma...2022-09-13T05:03:46ZreneolivoAfter creating a new case, the assignee for each activity must be selected manually### Issue
After you create a new case multiples activities are created with it, but the assignee must be manually chosen for each one of them which takes considerable time since this must be done by editing each activity one at a time.
...### Issue
After you create a new case multiples activities are created with it, but the assignee must be manually chosen for each one of them which takes considerable time since this must be done by editing each activity one at a time.
![default-assignee-issue](/uploads/987455f62441d6f77bc1892b930b4a90/default-assignee-issue.png)
There are references for the roles and relationships that are interesting for the particular case, but those are there for reference, the assignee still must be selected manually.
### Solution
Allow administrators to define rules for selecting a default assignee for each one of the activities. The rules would be based on the following options:
* By relationship to case client (ex: parent, manager, or spouse of case client).
* User creating the case.
* Specific contact.
* No default assignee.
When creating a new case each case activity should be created and assigned based on these rules. The case manager could then modify the assignees as usual.
----
Core PR:
https://github.com/civicrm/civicrm-core/pull/11998https://lab.civicrm.org/dev/core/-/issues/510unserialize(): Error, When duplicating site, database caused by userFramework...2022-09-12T05:03:51ZMouathunserialize(): Error, When duplicating site, database caused by userFrameworkResourceURLBug error
`PHP Notice: unserialize(): Error at offset 60 of 66 bytes in /home/*****/******/wp-content/plugins/civicrm/civicrm/Civi/Core/SettingsBag.php on line 153`
Steps to reproduce the bug:
1. Have a stable production site running...Bug error
`PHP Notice: unserialize(): Error at offset 60 of 66 bytes in /home/*****/******/wp-content/plugins/civicrm/civicrm/Civi/Core/SettingsBag.php on line 153`
Steps to reproduce the bug:
1. Have a stable production site running CiviCRM 5.6.1 under WordPress 4.9.8 with url: https://*****.com
1. A defined variable for `userFrameworkResourceURL` in `wp-content/uploads/civicrm/civicrm.settings.php` and in the database under table `civicrm_setting` name: `userFrameworkResourceURL`
3. Create a duplicate/staging site (including new duplicated database) with a subdomain/url dev.*****.com and update `civicrm.settings.php` vars including `userFrameworkResourceURL`
1. Run upgrade database. everything is fine
1. On any page load
Receive error `unserialize(): Error at offset 60 of 66 bytes`
Workaround:
1. Delete the "value" from `userFrameworkResourceURL` in the database.
```SELECT * FROM `civicrm_setting` WHERE `name` = 'userFrameworkResourceURL' ```
1. Go to `Settings - Resource URLs` and hit save
1. Proper serialized value gets written in the database
Note: if `userFrameworkResourceURL` is defined in `civicrm.settings.php` (which is the default at least in WordPress install)
Saving through the web-end doesn't overwrite the database hence the "workaround"https://lab.civicrm.org/dev/core/-/issues/290If locationType name/label are different, for non-billing locations, the cont...2022-09-10T05:03:24ZbgmIf locationType name/label are different, for non-billing locations, the contribution form will not pre-populate known fieldsHow to reproduce:
* Login on https://dmaster.demo.civicrm.org
* Go to the contact record of the demo user, and enter a "Home" address
* https://dmaster.demo.civicrm.org/civicrm/contact/view?reset=1&cid=203
* Configure this contrib for...How to reproduce:
* Login on https://dmaster.demo.civicrm.org
* Go to the contact record of the demo user, and enter a "Home" address
* https://dmaster.demo.civicrm.org/civicrm/contact/view?reset=1&cid=203
* Configure this contrib form, in Profiles, select the "Name and Address" profile (it includes the 'Home' address):
* https://dmaster.demo.civicrm.org/civicrm/admin/contribute/custom?reset=1&action=update&id=1
* Witness how it will correctly pre-populate the Home address on the contrib form:
* https://dmaster.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=1
![Capture_d_écran_de_2018-07-27_17-50-57](/uploads/aa17899d9a177a0f4b1e482d2308d8fc/Capture_d_écran_de_2018-07-27_17-50-57.png)
That works because the name = label. Let's change the label of the Location Type:
* Change the Location Type label of "Home" to "Home2"
* https://dmaster.demo.civicrm.org/civicrm/admin/locationType?reset=1
* Go back to the contribution form and witness how it does not show the address anymore :-)
![civi-location-types](/uploads/8faf552cccd52706f6c782f72fd60ae8/civi-location-types.png)
![Capture_d_écran_de_2018-07-27_17-52-23](/uploads/97e1f638b9a92c80c06aa63526a58140/Capture_d_écran_de_2018-07-27_17-52-23.png)
:tada: :grimacing:https://lab.civicrm.org/dev/core/-/issues/280Deleting membership types do not remove price field values from online member...2022-09-09T05:03:27ZyashodhaDeleting membership types do not remove price field values from online membership formsSteps to replicate:
------------------
1. Create a price field with options(select/checkbox/radio).
2. Choose an option related to a membership type.
3. Delete the membership type and it sets NULL membership type for the price option wi...Steps to replicate:
------------------
1. Create a price field with options(select/checkbox/radio).
2. Choose an option related to a membership type.
3. Delete the membership type and it sets NULL membership type for the price option without any indications.
Desired behavior:
-----------------
**Delete membership**
I would like to get some input about the behavior-
1. When admin tries to delete a membership type, check for any related price fields and if yes, throw a form rule implying them to delete the price field first.
2. Or just show warning message with list of membership type used in price field and allow anyway.
**Disabled Membership Type**
I would like to get some input about the behavior-
1. Show warning Message on disable action and if yes, skip building price field option related to disabled membership type.
2. User can dismiss warning message but can't continue with disablement of membership typeyashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/453Creating New Individual via quick add block fails if after adding you try to ...2022-09-04T05:03:41ZhfarooqCreating New Individual via quick add block fails if after adding you try to add a phone numberDrupal 7.59
CiviCRM 5.3.1
I was able to replicate on https://dmaster.demo.civicrm.org/ demo site. When contact is created through add individual contact block and at least one of the custom field is required, on the full individual crea...Drupal 7.59
CiviCRM 5.3.1
I was able to replicate on https://dmaster.demo.civicrm.org/ demo site. When contact is created through add individual contact block and at least one of the custom field is required, on the full individual create form if phone field is populated and form is submitted, it gives error saying "One Phone should be marked as primary".
There is already a JIRA issue created for this bug but no resolution yet.
Jira issue: https://issues.civicrm.org/jira/browse/CRM-5207
Thanks!https://lab.civicrm.org/dev/core/-/issues/2650Use consistent token syntax for pseudoconstants2022-09-01T07:55:13ZeileenUse consistent token syntax for pseudoconstantsAt some point we want to have consolidated token code. One thing that is missing at the moment is agreement as to what tokens we are working towards. (this came out of discussion fixing for php8 in https://github.com/civicrm/civicrm-core...At some point we want to have consolidated token code. One thing that is missing at the moment is agreement as to what tokens we are working towards. (this came out of discussion fixing for php8 in https://github.com/civicrm/civicrm-core/pull/20591) I want to constrain this issue to the very narrow question of syntax for pseudoconstants & unique names in tokens.
If we look at [the test](https://github.com/civicrm/civicrm-core/blob/275686a34ca7bf5e9c4d6653cd8cca5cf15e36cf/tests/phpunit/CRM/Contribute/Form/Task/PDFLetterCommonTest.php#L264) we can see the current tokens supported by the existing code. A somewhat different set is supported by the [TokenProcessor class for contributions](https://github.com/civicrm/civicrm-core/blob/c2a33d9c890f81bf2287351f0a830ef58b1dc98c/CRM/Contribute/Tokens.php#L26)
So we can see that in one place you would pass
{contribution.contribution_status_id} to get 'Pending'
and in the other it would be {contribution.status}
We are also 'promoting' (by presenting in the UI selector) {contribution.contribution_source} over {contribution.source} in how we present tokens, even though in this case I think both work.
I would propose that our preferred tokens adhere to apiv4 style conventions as much as possible. Preferring means that we work towards the following (on an ad hoc basis).
1) the tokens that are selectable in the UI on the form return the preferred variants
2) we support the preferred variants in tested code on both token methods
3) we run db update scripts to replace the less preferred with the preferred in the msg_template and action_schedule tables as we feel safe doing so
4) we deprecate less preferred variants by adding deprecation notices to places where they are used, when we feel safe doing so.
Proposed conventions
1) deprecate unique name prefixing - ie prefer {contribution.source} over {contribution.contribution_source}
2) actual field name returns the value of that field - ie {contribution.contribution_status_id} would return a number rather than a string
3) we use apiv4 style tokens for labels - ie {contribution.contribution_status_id:label}
(out of scope for this issue = apiv4 style custom field names or custom fields in general, returning calculated values for eg. contribution.check_number)
If we go with the above the specific action I will add to my (long) todo list is to engage with fixing contribution_status_id to make it consistent between the 2 classes and the selector - ie
1) Replace the 'advertised' token from
``` 'contribution.contribution_status_id:label' => 'Contribution Status'```
'contribution.contribution_status_id:label' => 'Contribution Status'
2) add tested support for ```'contribution.contribution_status_id:label'``` to both classes
3) fix any core message templates to use 'contribution.contribution_status_id:label'
4) fix the upgrade script to str_replace 'contribution.contribution_status_id' in the message template table (only)
The other fields in this space that are currently inconsistent are
- financial_type_id, campaign, payment instrument id, cancel_date, source
@colemanw @totten @seamuslee @mattwire5.43.0https://lab.civicrm.org/dev/core/-/issues/320Current Employer only allows you to filter by static groups, not all groups2022-08-30T15:42:55ZjamieCurrent Employer only allows you to filter by static groups, not all groupsI suspect this is just old code that has not been updated to use the _groupFilter property.I suspect this is just old code that has not been updated to use the _groupFilter property.https://lab.civicrm.org/dev/core/-/issues/303Print/Merge Document to HTML uses PHPWord to process the HTML - is this meant...2022-08-28T05:03:34ZAndrew WestPrint/Merge Document to HTML uses PHPWord to process the HTML - is this meant to happen?In 'Print/Merge Document' you can select to output to HTML. In practice, this processes the HTML via PHPWord. This seems to mangle it quite badly: div tags get converted into text (it literally says 'div'), styling gets removed, etc. I'm...In 'Print/Merge Document' you can select to output to HTML. In practice, this processes the HTML via PHPWord. This seems to mangle it quite badly: div tags get converted into text (it literally says 'div'), styling gets removed, etc. I'm not sure whether this is deliberate or not, but there's an easy alternative that seems to work well.
The conversion starts in CRM_Contact_Form_Task_PDFLetterCommon. If we want to export anything other than a PDF it's sent to CRM_Utils_PDF_Document::html2doc(), which uses PHPWord. But I'm wondering if it makes more sense to actually use the PDF route for HTML - this goes via CRM_Utils_PDF_Utils::html2pdf().
html2PDF works by generating HTML pages for the PDF processor. So it produces an elegant HTML document by itself anyway. It does some basic processing like removing header tags, applying the appropriate margins, and applying print.css. But other than that the HTML is untouched. It's very easy just to output the HTML before the final step of converting to PDF.
I have this working here, and I can make it into an extension easily enough (though it'd need to override core files). But as the HTML output functionality doesn't really seem to work like I'd expect, I thought I'd flag it here. I can put the changes into a PR if that'd help.https://lab.civicrm.org/dev/core/-/issues/215Contact Dashboard Personal Campaign Pages section repeats Campaign rows for e...2022-08-18T05:03:48ZAllenShawContact Dashboard Personal Campaign Pages section repeats Campaign rows for each user-created PCPLooks to me like a regression of [CRM-11340](https://issues.civicrm.org/jira/browse/CRM-11340).
**PR Raised https://github.com/civicrm/civicrm-core/pull/12369**
To reproduce on dmaster.demo.civicrm.org:
1. Ensure exixstence of at leas...Looks to me like a regression of [CRM-11340](https://issues.civicrm.org/jira/browse/CRM-11340).
**PR Raised https://github.com/civicrm/civicrm-core/pull/12369**
To reproduce on dmaster.demo.civicrm.org:
1. Ensure exixstence of at least 2 1 contriubution page with Personal Campaign Pages enabled; this recipe is easier if you remove the admin approval requirement, but that's not relevant to the issue.
2. As anonymous user, visit the URL to create your own PCP page for this campaign and complete the process.
3. Repeat step 2 to create a second PCP page for this campaign.
4. As admin, visit http://dmaster.demo.civicrm.org/civicrm/admin/pcp?reset=1&action=browse and observe there are at least two PCP pages for this campaign. Also ensure neither of these two pages is owned by the account you're currently logged in with.
5. Visit the user dashboard at http://dmaster.demo.civicrm.org/civicrm/user?reset=1, and observe this campaign is listed twice under "create a Personal Campaign Page", ass in attached screenshot:
![dmaster](/uploads/45adace7953442815335acdff567dbf6/dmaster.png)
Preliminary testing shows the following patch fixes the issue, but unsure of possible side effects:
```
diff --git a/CRM/PCP/BAO/PCP.php b/CRM/PCP/BAO/PCP.php
index b21a3a2..65ef434 100644
--- a/CRM/PCP/BAO/PCP.php
+++ b/CRM/PCP/BAO/PCP.php
@@ -184,7 +184,7 @@ FROM civicrm_pcp_block block
LEFT JOIN civicrm_pcp pcp ON pcp.pcp_block_id = block.id
WHERE block.is_active = 1
{$clause}
-GROUP BY block.id, pcp.id
+GROUP BY block.id
ORDER BY target_entity_type, target_entity_id
";
$pcpBlockDao = CRM_Core_DAO::executeQuery($query);
```Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/1858User account form action not passing along contact id correctly possibly lead...2022-08-17T13:52:08ZseamusleeUser account form action not passing along contact id correctly possibly leading to duplicate contactsOverview
----------------------------------------
When submitting the back office user account creation user contact action the contact id of the user you are creating the account for is not properly passed along and can depending on you...Overview
----------------------------------------
When submitting the back office user account creation user contact action the contact id of the user you are creating the account for is not properly passed along and can depending on your unsupervised dedupe rule create duplicate contact record
Reproduction steps
----------------------------------------
1. Click on Contacts -> Find and Merge Duplicate Contacts and edit the Unsupervised Individual rule to change it from just email to use first and last name as well
1. Navigate to an individual's record that doesn't have a CMS user account
1. Select Actions -> Create User Record
1. Possibly / likely receive a fatal error due to duplicate record in civicrm_uf_match, find that a duplicate contact has been created
Current behaviour
----------------------------------------
Duplicate contact is created when the CMS record is created
Expected behaviour
----------------------------------------
No Duplicate contact is created and the CMS account is properly connected to the contact you are creating the user account for
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __CiviCRM:__ _5.26.0_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.1__
* __CMS:__ _Drupal 8_5.29.0https://lab.civicrm.org/dev/core/-/issues/195Add Contribution Counts to Sub-tabs2022-08-17T05:03:37ZCamilo RodríguezAdd Contribution Counts to Sub-tabs## Overview
It would be helpful to be able to see on each sub-tab a count of Contributions / Recurring Contributions, keeping the UX consistent with how the rest of tabs work on Contact's Detail View.
## How it Works Currently
1. Go to ...## Overview
It would be helpful to be able to see on each sub-tab a count of Contributions / Recurring Contributions, keeping the UX consistent with how the rest of tabs work on Contact's Detail View.
## How it Works Currently
1. Go to a Contact's detail view.
2. The **Contributions** tab shows also the count of contributions associated to the contact.
3. Clicking on the tab displays two sub-tabs, one for Contributions, the second one for Recurring Contributions.
4. Sub-tabs don't show number of contributions on each.
## How it Should Work
1. Go to a Contact's detail view.
2. The **Contributions** tab shows also the count of contributions associated to the contact.
3. Clicking on the tab displays two sub-tabs, one for Contributions, the second one for Recurring Contributions.
4. Sub-tabs show number of contributions on each. Count done for **Recurring Contributions** is done on active recurring contributions.https://lab.civicrm.org/dev/core/-/issues/214Suppress inappropriate error when trying to schedule mailing for today2022-08-17T05:03:36ZJoeMurraySuppress inappropriate error when trying to schedule mailing for todayWhen trying to schedule a mailing, there are two fields: one for date and one for time. If you select today for date a popup error immediately says that 'Error
The scheduled date and time is in the past'. It would be better if this was d...When trying to schedule a mailing, there are two fields: one for date and one for time. If you select today for date a popup error immediately says that 'Error
The scheduled date and time is in the past'. It would be better if this was delayed somewhat, though there are many possibilities. User ends up thinking Civi doesn't know correct date.
How about if validation changed so that if date==today and time is null, then set time=now()+1 minute?Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/168If scheduled jobs are run individually nothing is logged to civicrm job log2022-08-15T05:03:21ZlolcodeIf scheduled jobs are run individually nothing is logged to civicrm job logWhen running scheduled jobs individually to have greater control over the timing or parameters of those jobs then nothing is logged to the JobLog at least for certain jobs like process_mailing. This leaves the user to implement something...When running scheduled jobs individually to have greater control over the timing or parameters of those jobs then nothing is logged to the JobLog at least for certain jobs like process_mailing. This leaves the user to implement something else for logging.
I don't agree with this approach because it will push organisations to use custom solutions but it should at least be a documented limitation.
https://docs.civicrm.org/user/en/latest/initial-set-up/scheduled-jobs/#specific-jobshttps://lab.civicrm.org/dev/core/-/issues/3802Symfony 6 can't find the EventDispatcher when adding hooks that are defined i...2022-08-15T02:11:04ZDaveDSymfony 6 can't find the EventDispatcher when adding hooks that are defined in getSubscribedEventsThey did this, and also a little higher up you can see they removed the constructor: https://github.com/symfony/event-dispatcher/commit/0bc2e0d8ba8a6eb353a42d19890f57a3dee410a5#diff-f3f413e17bbd20e345b3721f9c4556ed5e319d133c32bf7492dffd5...They did this, and also a little higher up you can see they removed the constructor: https://github.com/symfony/event-dispatcher/commit/0bc2e0d8ba8a6eb353a42d19890f57a3dee410a5#diff-f3f413e17bbd20e345b3721f9c4556ed5e319d133c32bf7492dffd55a024d0efR57
So what happens is this https://github.com/civicrm/civicrm-core/blob/da21dc84950b013a03d3fe5e72e12e7d652cce7f/Civi/Core/Container.php#L93 is expecting it to be called `dispatcher`, but this https://github.com/symfony/event-dispatcher/commit/0bc2e0d8ba8a6eb353a42d19890f57a3dee410a5#diff-f3f413e17bbd20e345b3721f9c4556ed5e319d133c32bf7492dffd55a024d0efR57 is expecting it to be called `event_dispatcher`, so that returns early and never calls `$container->findTaggedServiceIds('kernel.event_listener'`, so doesn't pick up any of the getSubscribedEvents hooks, e.g. civi.token.eval and others.
The naive fix of calling `$container->setAlias('event_dispatcher', 'dispatcher')` doesn't seem to be enough and causes a crash later which I haven't tracked down yet.5.54.0https://lab.civicrm.org/dev/core/-/issues/2910Remove the CiviCRM Connections functionality (Task 1 of 2) - Remove the menu ...2022-08-09T14:44:38Zjustinfreeman (Agileware)Remove the CiviCRM Connections functionality (Task 1 of 2) - Remove the menu item**CiviCRM Connections** is available under the System Settings menu. From what I can tell this feature is an artefact that is no longer being used. Happy to be educated on the subject if this is not the case.
Cannot find any references ...**CiviCRM Connections** is available under the System Settings menu. From what I can tell this feature is an artefact that is no longer being used. Happy to be educated on the subject if this is not the case.
Cannot find any references to it in the documentation:
- https://docs.civicrm.org/user/en/latest/
- https://docs.civicrm.org/sysadmin/en/latest/
Googling doesn't reveal anything relevant either.
So can we remove this code from the system?
![Screenshot_20211013_091315](/uploads/724bb11ee0a345f31be5b369b22af959/Screenshot_20211013_091315.png)
Agileware Ref: CIVIBLD-2865.44.0https://lab.civicrm.org/dev/core/-/issues/3774Can't submit backend credit card contribution unless you have at least one pa...2022-08-04T21:07:47ZJonGoldCan't submit backend credit card contribution unless you have at least one payment processor that supports a future start dateIf you don't have a payment processor that supports a future start date, you can't submit a credit card contribution.
### Steps to replicate
* On a buildkit site, add a PayPal Pro payment processor. The creds don't have to be valid.
* S...If you don't have a payment processor that supports a future start date, you can't submit a credit card contribution.
### Steps to replicate
* On a buildkit site, add a PayPal Pro payment processor. The creds don't have to be valid.
* Submit a backend credit card contribution with PayPal Pro. Should go through (or tell you invalid credentials).
* Delete the default processor of type "Dummy Payment Processor".
* Submit another backend credit card contribution with PayPal Pro.
### Expected Result
Absence of a dummy test processor shouldn't affect the ability to submit a credit card processor.
### Actual result
```
Please correct the following errors in the form fields below:
Date Received is a required field.
```
### Why
In `CRM_Contribution_Form_AbstractEditPayment::assignProcessors()` is this line:
```
$this->assign('processorSupportsFutureStartDate', CRM_Financial_BAO_PaymentProcessor::hasPaymentProcessorSupporting(['FutureRecurStartDate']));
```
This will return `TRUE` if *any* payment processor supports a future start date. Which in turn causes the `receive_date` to appear on `templates/CRM/Contribute/Form/Contribution.tpl`.
Without the `receive_date` on the form, even hidden, you can't submit the form.
The workaround is to create a dummy processor on your site. I have to run, but tomorrow I'll try to put together a PR that fixes this at the template level.
Is this a regression? I mean, technically yes, but it's two years old. And tricky to catch because the test suite creates the dummy processor in `setUp()`. To catch this we might have to move that out of `setUp()` and into its own helper function.5.52.0JonGoldJonGold