Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-10-09T05:03:32Zhttps://lab.civicrm.org/dev/core/-/issues/796Updating priceset when selected option is full2022-10-09T05:03:32ZwdecraeneUpdating priceset when selected option is fullYou want to edit as an admin the priceset of an participant, the option the participant selected is full.
![Schermafbeelding_2019-03-12_om_21.21.42](/uploads/4e6f018316f4f102805ad121f83f46d7/Schermafbeelding_2019-03-12_om_21.21.42.png)
...You want to edit as an admin the priceset of an participant, the option the participant selected is full.
![Schermafbeelding_2019-03-12_om_21.21.42](/uploads/4e6f018316f4f102805ad121f83f46d7/Schermafbeelding_2019-03-12_om_21.21.42.png)
You change the value to another option and save it.
![Schermafbeelding_2019-03-12_om_21.24.34](/uploads/cab5f64141209839934a3f517be84095/Schermafbeelding_2019-03-12_om_21.24.34.png)
After saving, the option did not change.
But, when you change the radio after the selected one it does save it.
Reason: behind the option which is selected and full, there is a hidden option field which is selected. When you select the option before this radio and post the form, the browser only post the last one (a radio field can only have one selected value). That is also the reason why the value is changed when you select the radio after the original one.
Solution ? No hidden/disabled options for admins? Should admins be able to override the max possibilities per participant?https://lab.civicrm.org/dev/core/-/issues/797KAM appearing on front-end under WordPress2019-03-13T12:54:12ZhaystackKAM appearing on front-end under WordPress@colemanw The KAM menu is appearing on the front-end when it shouldn't. See this form on the base page when logged in:
https://wpmaster.demo.civicrm.org/contribution-page/
Probably just a question of checking `$config->userFrameworkFro...@colemanw The KAM menu is appearing on the front-end when it shouldn't. See this form on the base page when logged in:
https://wpmaster.demo.civicrm.org/contribution-page/
Probably just a question of checking `$config->userFrameworkFrontend`https://lab.civicrm.org/dev/core/-/issues/798Prefix/suffix select2 renders oddly on public-facing pages2019-03-14T21:07:10ZJonGoldPrefix/suffix select2 renders oddly on public-facing pagesPrefix and suffix fields in contribution/event profiles render incorrectly on public-facing pages. See screenshot:
![Selection_823](/uploads/5d05559371fa6c062b2dad8ecd8c2901/Selection_823.png)
There are a couple of ways to fix, I'll do...Prefix and suffix fields in contribution/event profiles render incorrectly on public-facing pages. See screenshot:
![Selection_823](/uploads/5d05559371fa6c062b2dad8ecd8c2901/Selection_823.png)
There are a couple of ways to fix, I'll do whatever folks like best.
One is to fix `civicrm.css` here:
```css
.crm-container.crm-public .select2-container .select2-choice {
padding: 5px 5px 5px 8px;
height: auto;
}
```
Changing `height: auto` to `height: 26px` matches the backend `select2.css`. Other select2 widgets are unaffected because they have placeholder text. I could also add placeholder text to the default rendering of this widget, but I think the CSS fix makes more sense.
I'll submit a PR to continue this discussion.5.13.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/799While upgrading from CiviCRM 4.6 to 5.10.x , old smartgroups stopped refreshi...2020-07-13T02:47:16ZVangelisPWhile upgrading from CiviCRM 4.6 to 5.10.x , old smartgroups stopped refreshing contactsSteps to reproduce:
1) Save a smartgroup that was using eg. a customfield value on a CiviCRM 4.6.x environment
2) Migrate to the latest CiviCRM
3) Change a contact so that the change can reflect to that smartgroup
4) Do a simple search ...Steps to reproduce:
1) Save a smartgroup that was using eg. a customfield value on a CiviCRM 4.6.x environment
2) Migrate to the latest CiviCRM
3) Change a contact so that the change can reflect to that smartgroup
4) Do a simple search using this smartgroup. Contact should not appear. `drush cvapi job.group_rebuild` doesn't fix the issue.
Resolution:
We traced this down to the fact that old form values and in general saved search settings were not being converted to new form values during the upgrade process.
There are 2 possible solutions on this:
1) Open the smartgroup criteria, do a search and `update smartgroup`. This is efficient if there are not many smartgroups in the installation.
2) Include a fix during the upgrade process that will call in essence those lines:
```php
// Read the existing form values
$formValues = CRM_Contact_BAO_SavedSearch::getFormValues($SavedSearchId);
// Update saved search record.
$savedSearch = new CRM_Contact_BAO_SavedSearch();
$savedSearch->id = $SavedSearchId;
$savedSearch->form_values = serialize(CRM_Contact_BAO_Query::convertFormValues($formValues));
$savedSearch->save();
```
In our case, we followed this path:
1) We've made a custom API call to do a search for all smartgroups and then apply the above fix on each one of these.
2) Then we issued a `TRUNCATE TABLE civicrm_group_contact_cache`.
3) Lastly, we issued a `drush cvapi job.group_rebuild` to force a smartgroup rebuild.
It seems that it's fixing our issue.
Do you believe that the upgrader needs a patch to resolve this situation?https://lab.civicrm.org/dev/core/-/issues/800Allow operator as a parameter for Advanced Filter in auto-complete Contact Re...2022-10-10T05:03:25ZyashodhaAllow operator as a parameter for Advanced Filter in auto-complete Contact Reference fieldCurrently you can specify Advanced filters for auto-complete Contact Reference fields
> EXAMPLE: To list Students in group 3: "action=get&group=3&contact_sub_type=Student"
But if I want to search all contacts with `contact_sub_type ...Currently you can specify Advanced filters for auto-complete Contact Reference fields
> EXAMPLE: To list Students in group 3: "action=get&group=3&contact_sub_type=Student"
But if I want to search all contacts with `contact_sub_type != 'Student'`
I propose that we pass operator something like` contact_sub_type_op = 'neq'`
which would do the same. This is consistent with what we are doing in reports as well.https://lab.civicrm.org/dev/core/-/issues/801Thank You letters have an invalid 'from' when sending from the contact's emai...2019-03-25T21:48:33ZbgmThank You letters have an invalid 'from' when sending from the contact's email addressTo reproduce:
* Record a contribution for a contact
* Find Contributions, select the contribution, Send Thank You Letters
* Select the option to send emails
* Use the default from of the contact, which should be the email on their conta...To reproduce:
* Record a contribution for a contact
* Find Contributions, select the contribution, Send Thank You Letters
* Select the option to send emails
* Use the default from of the contact, which should be the email on their contact record.
When sending the emails, CiviCRM will throw an error that there is no 'from' in the email, which sounds like this SE question: https://civicrm.stackexchange.com/questions/21780/civicontribute-thank-you-letter-not-emailed-using-cividesk-sparkpost/24948
Inspecting the form html reveal's this:
![Capture_d_écran_de_2019-03-14_12-45-04](/uploads/04998410f1c204cb52310c0dbb6da0fc/Capture_d_écran_de_2019-03-14_12-45-04.png)
It seems very familiar to issue #3575.12.0https://lab.civicrm.org/dev/core/-/issues/802Unsubscribe message doesn't display consistently2022-10-10T05:03:26ZRoseLaniganUnsubscribe message doesn't display consistentlyWhen an individual unsubscribes from a mailing group, they get a standard message confirmation message that says they have been unsubscribed (see image 001). However, the message specified in the Headers, Footers and Automated Messages l...When an individual unsubscribes from a mailing group, they get a standard message confirmation message that says they have been unsubscribed (see image 001). However, the message specified in the Headers, Footers and Automated Messages list includes a link to resubscribe (image 002) that doesn't appear.
![image001](/uploads/737d703e38b8ec9a63b0baa549715a30/image001.jpg)
![image002](/uploads/457215465165297186362e2938ab07f8/image002.jpg)https://lab.civicrm.org/dev/core/-/issues/803Upgrade and vendor HMTLPurifier2019-04-11T00:26:06ZmfbUpgrade and vendor HMTLPurifierHTMLPurifier version 4.3.0 can be found at https://github.com/civicrm/civicrm-packages/blob/master/IDS/vendors/htmlpurifier but current version, with PHP 7.2 compatibility, is 4.10.0
Ideally we could move it to composer.json for core.HTMLPurifier version 4.3.0 can be found at https://github.com/civicrm/civicrm-packages/blob/master/IDS/vendors/htmlpurifier but current version, with PHP 7.2 compatibility, is 4.10.0
Ideally we could move it to composer.json for core.https://lab.civicrm.org/dev/core/-/issues/804Address indiscrepancy in participant count in summary report - due to presenc...2023-04-26T05:03:22ZeileenAddress indiscrepancy in participant count in summary report - due to presence of currency in $0 participant recordsOpened this to track
https://github.com/civicrm/civicrm-core/pull/13037Opened this to track
https://github.com/civicrm/civicrm-core/pull/13037https://lab.civicrm.org/dev/core/-/issues/806DB Error:: Already exists during renewing membership automatically2019-04-03T16:58:22ZPradeep Nayakpradpnayak@gmail.comDB Error:: Already exists during renewing membership automaticallyI have a cron job that runs smart debit sync every day for recurring contribution and its failing with DB Error: already exists
After looking it carefully in details found that it fails when the original contribution of recurring has ta...I have a cron job that runs smart debit sync every day for recurring contribution and its failing with DB Error: already exists
After looking it carefully in details found that it fails when the original contribution of recurring has tax_amount set.
Mar 18 10:53:06 [info] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => -5
[message] => DB Error: already exists
[mode] => 16
[debug_info] => INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , price_field_id , label , qty , unit_price , line_total , price_field_value_id , financial_type_id , tax_amount ) VALUES ('civicrm_contribution' , 20069 , 20069 , 1 , 'Contribution Amount' , 1 , 30.00 , 30.00 , 1 , 33 , 6 ) [nativecode=1062 ** Duplicate entry 'civicrm_contribution-20069-20069-1-1' for key 'UI_line_item_value']
[type] => DB_Error
[user_info] => INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , price_field_id , label , qty , unit_price , line_total , price_field_value_id , financial_type_id , tax_amount ) VALUES ('civicrm_contribution' , 20069 , 20069 , 1 , 'Contribution Amount' , 1 , 30.00 , 30.00 , 1 , 33 , 6 ) [nativecode=1062 ** Duplicate entry 'civicrm_contribution-20069-20069-1-1' for key 'UI_line_item_value']
[to_string] => [db_error: message="DB Error: already exists" code=-5 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , price_field_id , label , qty , unit_price , line_total , price_field_value_id , financial_type_id , tax_amount ) VALUES ('civicrm_contribution' , 20069 , 20069 , 1 , 'Contribution Amount' , 1 , 30.00 , 30.00 , 1 , 33 , 6 ) [nativecode=1062 ** Duplicate entry 'civicrm_contribution-20069-20069-1-1' for key 'UI_line_item_value']"]
)https://lab.civicrm.org/dev/core/-/issues/807Error in participant counts on events with waitlists2022-10-11T05:03:32ZCharlie DunlaveyError in participant counts on events with waitlistsThere seems to be a participant calculation error at a specific stage in the workflow for events using waitlists, which is making the waitlist feature unuseable.
When a place becomes available on an event with a waitlist, the reminder e...There seems to be a participant calculation error at a specific stage in the workflow for events using waitlists, which is making the waitlist feature unuseable.
When a place becomes available on an event with a waitlist, the reminder email is being sent correctly to the person at the top of the waitlist, but when this user clicks on the registration link in the email, they see the 'Oops, it looks like there are no spaces' message.
At the confirmation page stage, it looks like Civi is counting all participants as opposed to just those with counted set to true. Are you able to take a look?
Thank you,
Charliehttps://lab.civicrm.org/dev/core/-/issues/808support reCaptcha v32020-11-24T22:45:22ZJoeMurraysupport reCaptcha v3There's a new reCaptcha that does not show I am not a robot, but does require evaluation of a score returned. Would be good to support it before current v2 goes away (this is Google, days before Google+ is disappearing ;) ).
See https:/...There's a new reCaptcha that does not show I am not a robot, but does require evaluation of a score returned. Would be good to support it before current v2 goes away (this is Google, days before Google+ is disappearing ;) ).
See https://developers.google.com/recaptcha/docs/versionshttps://lab.civicrm.org/dev/core/-/issues/809Bug with CiviCRM 5.10.3 Remote Profiles HTML Form Snippet Form Action URL2022-10-24T05:03:34ZjohngehrigBug with CiviCRM 5.10.3 Remote Profiles HTML Form Snippet Form Action URLVersion: CiviCRM 5.10.3
Type: Bug
With the update to CiviCRM 5.10.3, I noticed the form action URL in the HTML Form Snippet generated for Remote Profile submissions has changed, breaking the form submission functionality for anonymous ...Version: CiviCRM 5.10.3
Type: Bug
With the update to CiviCRM 5.10.3, I noticed the form action URL in the HTML Form Snippet generated for Remote Profile submissions has changed, breaking the form submission functionality for anonymous users with all newly generated HTML Form Snippets.
This is the first time I have noticed this bug, which was definitely introduced sometime after version CiviCRM 5.7.2, the last time I generated an HTML Form Snippet that was used with a Remote Profile.
Previously, the HTML Form Snippet generated code with a form action URL that posted to the "create profile" URL, allowing form submissions from anonymous users:
`<form action="https://wpmaster.demo.civicrm.org/civicrm/?page=CiviCRM&q=civicrm%2Fprofile%2Fcreate" method="post" name="Edit" id="Edit" class="CRM_Profile_Form_Edit" >`
After the update, the code generated by the HTML Form Snippet includes a form action URL that posts to the default "admin group":
`<form action="https://wpmaster.demo.civicrm.org/civicrm/?page=CiviCRM&q=civicrm%2Fadmin%2Fuf%2Fgroup" method="post" name="Edit" id="Edit" class="CRM_Profile_Form_Edit" >`
With the above form action URL, anonymous users see the following error when the user clicks the "Submit" button:
> You do not have permission to access this content.
Manually changing the code in the HTML Form Snippet to use a form action URL with the previous "create profile" version restores the functionality.
This bug is specifically related to the generate HTML Form Snippet code as Profiles work properly for anonymous users when inserted using the "Add CiviCRM Public Pages" button within WordPress, which inserts the code that includes the correct "create profile" form action URL.
I tested both WordPress and Drupal 7 demo sites and was able to replicate the bug with ONLY the WordPress demo site:
https://wpmaster.demo.civicrm.org/
https://dmaster.demo.civicrm.org/
----
Steps to Reproduce Bug with WordPress CiviCRM 5.10.3+:
Login
CiviCRM > Administer > System Settings > Misc (Undelete, PDFs, Limits, Logging, Captcha, etc.)
For the "Accept profile submissions from external sites" option, select "Yes" and then click "Save"
Administer > Custom Data and Screens > Profiles
For any Profile, generate the code by clicking: more > HTML Form Snippet
The code generated by the updated version includes a "post" action URL to the "admin group"https://lab.civicrm.org/dev/core/-/issues/810Non-primary details exported in primary-only exports, when the setting 'Searc...2023-04-05T05:03:18ZAndrew WestNon-primary details exported in primary-only exports, when the setting 'Search Primary Details Only' is set to 'no'If you run an export with 'Export PRIMARY fields', but you have the setting 'Search Primary Details Only' set to 'No', the primary filter is not applied and you simply get the first available row in the table. This also happens when you ...If you run an export with 'Export PRIMARY fields', but you have the setting 'Search Primary Details Only' set to 'No', the primary filter is not applied and you simply get the first available row in the table. This also happens when you select the 'Primary' option when exporting individual fields.
This definitely applies to postal addresses. I haven't tested emails but I think it'll happen there too.
It happens because of this line in CRM_Contact_BAO_Query:
https://github.com/civicrm/civicrm-core/blob/a2540ad336faf7fb0218055a485c1a702200293f/CRM/Contact/BAO/Query.php#L446
which defaults to using the value from the setting. If this is set to no, the result SQL clause doesn't include 'is_primary = 1'.
CRM_Export_BAO_ExportProcessor creates the Query object here:
https://github.com/civicrm/civicrm-core/blob/a2540ad336faf7fb0218055a485c1a702200293f/CRM/Export/BAO/ExportProcessor.php#L509
but doesn't pass through a value for 'primaryLocationOnly' to override the default setting.
I can presumably adapt the above to pass through primaryLocationOnly when users have selected the 'Export PRIMARY fields' option - that *seems* simple enough. I haven't had a chance to dig into how it works when the export specifies individual fields, though - that seems like it'd be more complicated.
To replicate on demo site:
1. Create a new tmp group
2. Find a contact with an existing primary address
3. Add a new address for them, and set it to primary
4. Add this contact to the tmp group
4. Turn off the setting 'Search Primary Details Only'
5. Search for all members of the tmp group, and export them using 'Export PRIMARY fields only'
6. The contact's address in the CSV will be the original address, which is non-primaryhttps://lab.civicrm.org/dev/core/-/issues/811Autocomplete select list disabled options2019-03-19T23:27:09ZPradeep Nayakpradpnayak@gmail.comAutocomplete select list disabled optionsCustom field with type Autocomplete-select lists disabled options.
![Autocomplete-select](/uploads/4255d3183f1e8baf55aee8e4201b95cc/Autocomplete-select.gif)Custom field with type Autocomplete-select lists disabled options.
![Autocomplete-select](/uploads/4255d3183f1e8baf55aee8e4201b95cc/Autocomplete-select.gif)5.13.0https://lab.civicrm.org/dev/core/-/issues/812Contribution row displayed even if contact has 0 contributions.2019-03-22T12:47:10ZjitendraContribution row displayed even if contact has 0 contributions.For a contact who has no contribution, an empty row is displayed on the contact summary page.
Screenshot from dmaster -
![image](/uploads/dac551024d803fc3c59464f397aa79d0/image.png)
If any of the link is clicked on the row, it results...For a contact who has no contribution, an empty row is displayed on the contact summary page.
Screenshot from dmaster -
![image](/uploads/dac551024d803fc3c59464f397aa79d0/image.png)
If any of the link is clicked on the row, it results into an error -
![image](/uploads/54f210db421782c0c987ece4dea9d16f/image.png)
This was working in the latest rc version. Seems to have broken after https://github.com/civicrm/civicrm-core/pull/13720 .5.13.0jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/814[unreleased regression] Menubar light on Drupal, dark on WP2019-03-22T02:27:59ZAndie Hunt[unreleased regression] Menubar light on Drupal, dark on WPThe new KAM menubar has appeared light grey everywhere I've seen it before. However, it is showing up dark in the RC as of right now (last commit `96a2a2b`).
I think it's a problem that we're changing the color of the menu all of a sud...The new KAM menubar has appeared light grey everywhere I've seen it before. However, it is showing up dark in the RC as of right now (last commit `96a2a2b`).
I think it's a problem that we're changing the color of the menu all of a sudden (think of how many instructions say "go in the black menu to Administer"), so I like the darker one. However, it seems that the color specified in crm-menubar.css isn't taking effect in WP, so that's the "broken" one.
Also, more than one person has indicated that the color is the same as their browser, camouflaging the menu so that they thought it wasn't there.
So, this issue really has two parts:
1. We need to be sure the CSS takes effect
2. We should make the color something closer to the old black menu (which was `#1b1b1b`, to be specific)
## Screenshots
Wordpress:
![Screenshot_from_2019-03-20_12-22-06](/uploads/7029af2395f97de2aafd26508bbd1ecd/Screenshot_from_2019-03-20_12-22-06.png)
Drupal:
![Screenshot_from_2019-03-20_12-22-35](/uploads/6613d8b9ca1637582a204102b6dcea30/Screenshot_from_2019-03-20_12-22-35.png)https://lab.civicrm.org/dev/core/-/issues/815Define activity types which appear in the contact quick actions list via a se...2022-10-13T05:03:27ZJamie Novick - CompucoDefine activity types which appear in the contact quick actions list via a setting on the activity type screen**How it works currently:**
All activity types that have Component set as Contacts and Cases will appear in the Contact actions drop down.
**How it should work:**
Users should be able to be specify that an activity type will not be sh...**How it works currently:**
All activity types that have Component set as Contacts and Cases will appear in the Contact actions drop down.
**How it should work:**
Users should be able to be specify that an activity type will not be shown in the contact action drop down, even if they have set the Component to be Contacts and Cases.https://lab.civicrm.org/dev/core/-/issues/816Contribution Details Report double amount when Credit Card Type Column is sho...2022-10-13T05:03:26ZScottyPspulver@ibafriends.orgContribution Details Report double amount when Credit Card Type Column is shown and Contribution was changedWhen running a Contribution Details report it seems to double the amount of the contribution when you enable the Credit Card Type column and have changed the Contribution amount. See in the attached screenshot from Sandbox. But I can rep...When running a Contribution Details report it seems to double the amount of the contribution when you enable the Credit Card Type column and have changed the Contribution amount. See in the attached screenshot from Sandbox. But I can replicated in 5.11 and 5.10.3 with Drupal 7.65 on Apache with PHP 5.6.39 and 5.5.62 MySQL.
To replicate:
1) Enter Contribution with Total amount for $5 then save
2) Edit Contribution with Total amount to $10 then save
3) Run Contribution Details with Credit Card Type column (screenshot with ($20) and without $10)
Hopefully I'm not missing something and this is actually a bug. Thanks!
![WithCreditCardType](/uploads/0181982614aa26c60e5da0fa43b33fac/WithCreditCardType.png)
![WithoutCreditCardType](/uploads/bc2bd115149d90b9c10eb119b03fe59f/WithoutCreditCardType.png)
![Contribution](/uploads/020b93143fc4d5ff5360bd839990c1fa/Contribution.png)https://lab.civicrm.org/dev/core/-/issues/817META - improve code quality2024-02-29T20:06:14ZeileenMETA - improve code qualityI'm writing this as a place to group together various efforts to improve our code quality - this means we can link towards other issues that reflect where we are going code-wise.
In general from a product maintenance point of view the ...I'm writing this as a place to group together various efforts to improve our code quality - this means we can link towards other issues that reflect where we are going code-wise.
In general from a product maintenance point of view the goals we have are
1) ongoing improvement in code stability through
- adding test coverage,
- fixing things 'the right way' rather than hack-fixes
- addressing buggy coding
- improving code commenting
- addressing underlying logic problems
- cleaning up known bad patterns
- extracting smaller functions out of larger functions
- improving code readability
- not adding new functionality (fields, logic etc and even bug fixes) to dirty code (either cleaning it up first or leaving well enough alone).
Note that is IS harder to get changes accepted into parts of the code which are nasty - this is a feature not a bug. It's also harder to get changes reviewed & accepted into areas with poor test coverage. As I write this prs to alter sending out invoices and code impacting on imports are notably stagnating. This reflects an unwillingness to touch those code areas unless unit tests are being added as they have almost no coverage. (of course we also want tests on more tested code areas...)
2) ongoing improvement in performance through
- removing bad joins & bad queries
- php improvements
3) ensuring secure code practices are used
4) adapting the code to new versions of mysql & php as they become relevant
6) laying the ground work for LeXIM through
- moving logic out of the form layer and into the BAO, api xml or other metadata where appropriate
- improving api interaction with the code (making more stuff api-accessible & making it more logical & consistent)
- adding hooks, regions etc, although not into dirty code as that locks in suboptimal fixes.
- improving hook consistency
There are other goals for CiviCRM as a product - in the Leap By Extension / funded projects part of the LeXIM picture which are outside the scope of the concerns of product maintenance. It should be noted that the there is limited capacity to review PRs submitted to core so fit with these will affect how high a priority product mtce reviewers give to PRs. Of course other things play into the prioritisation like whether the submitter has been actively reviewing other PRs.
I'm going to start adding / linking issues that relate to cleaning up known bad patterns here
**Related issues**
~~Remove ->free calls https://lab.civicrm.org/dev/core/issues/562~~
~~Performance - done, remove use of mysql LOWER~~
Switch core forms to Entity Forms https://lab.civicrm.org/dev/core/issues/818 - also https://lab.civicrm.org/dev/core/issues/115
~~Get rid of jcalendar https://lab.civicrm.org/dev/core/issues/561~~
Use TempTable class for all temp tables - https://lab.civicrm.org/dev/core/issues/183
Consolidate settings & preference forms onto being metadata driven https://lab.civicrm.org/dev/core/issues/495
Consolidate recurring forms https://lab.civicrm.org/dev/core/issues/846
Use guzzle to get http requests https://lab.civicrm.org/dev/core/issues/849 (for testability)
Get rid of nullArray usage https://lab.civicrm.org/dev/core/issues/1047
Remove non-std contribution_invoice_settings https://lab.civicrm.org/dev/core/issues/1558