Development issueshttps://lab.civicrm.org/groups/dev/-/issues2018-11-09T20:53:16Zhttps://lab.civicrm.org/dev/core/-/issues/514Premiums not saved when using PayPal_standard2018-11-09T20:53:16ZdarrickPremiums not saved when using PayPal_standardI have a contribution page setup with premiums. I am using both iAts and Paypal as payment processors. If a donor selects a premium and pays via iAts then the premium selected is saved along with the contribution. The receipt email al...I have a contribution page setup with premiums. I am using both iAts and Paypal as payment processors. If a donor selects a premium and pays via iAts then the premium selected is saved along with the contribution. The receipt email also shows the premium.
However, if the donor pays via Paypal. Which requires a redirect to Paypal and then a redirect back to the thank you page, the premium is not saved along with the contribution. It does show on both the confirm and thank you page however.https://lab.civicrm.org/dev/core/-/issues/3328Membership updates not recorded in contact log2022-04-22T16:17:17ZedvanleeuwenMembership updates not recorded in contact logI have noticed that not all changes in the membership records are registered in the contact log. See attachments.![activity](/uploads/95e4d88c1b16c40fa685032cb4b97b75/activity.png)![log](/uploads/878cd7f93d4967ae70047de240f502d7/log.png)I have noticed that not all changes in the membership records are registered in the contact log. See attachments.![activity](/uploads/95e4d88c1b16c40fa685032cb4b97b75/activity.png)![log](/uploads/878cd7f93d4967ae70047de240f502d7/log.png)https://lab.civicrm.org/dev/core/-/issues/515Empowered By Civicrm footer might overlap content: add clear:both2022-09-18T19:15:39ZphilmorbruEmpowered By Civicrm footer might overlap content: add clear:bothThe Empowered By footer at narrower screen widths might overlap content of a page with floating divs, such as Personal Campaign Page widgets.
Wrong:
![Overlapping](/uploads/cd2927f93de5a66d31a0674da4989826/Overlapping.jpeg)
Correct:
...The Empowered By footer at narrower screen widths might overlap content of a page with floating divs, such as Personal Campaign Page widgets.
Wrong:
![Overlapping](/uploads/cd2927f93de5a66d31a0674da4989826/Overlapping.jpeg)
Correct:
![Correct](/uploads/b8d6b66a32bc93352f8d6ae9c7293524/Correct.jpeg)
Easily fixed: civicrm.css, Line 670: `.crm-container #civicrm-footer.crm-public-footer {clear: both;}`https://lab.civicrm.org/dev/wordpress/-/issues/13Clean URLs2020-06-17T09:07:22ZhaystackClean URLsOverview
----------------------------------------
Rather than raise a (perhaps) premature PR on GitHub, here's a follow-up to [PR-123](https://github.com/civicrm/civicrm-wordpress/pull/123) for WordPress people to test:
https://github.c...Overview
----------------------------------------
Rather than raise a (perhaps) premature PR on GitHub, here's a follow-up to [PR-123](https://github.com/civicrm/civicrm-wordpress/pull/123) for WordPress people to test:
https://github.com/christianwach/civicrm-wordpress/tree/cleaner-urls
Here's the original [Jira ticket](https://issues.civicrm.org/jira/browse/CRM-21788). There aren't any dependencies this time, though it requires a build from CiviCRM master to work correctly - or at minimum the code from these PRs:
* https://github.com/civicrm/civicrm-core/pull/13043
* https://github.com/civicrm/civicrm-core/pull/12969
* https://github.com/civicrm/civicrm-core/pull/12968
Plus enabling Clean URLs in "civicrm.settings.php":
```php
// check for WordPress clean URLs
elseif( function_exists('get_option') && get_option('permalink_structure') != '' ) {
define('CIVICRM_CLEANURL', 1);
}
```
I'd like to see the latest code which changes the CiviCRM-WordPress plugin's init sequence out in the wild before I raise a PR, but that allows some time to test this, which will inevitably be complicated.
Before
----------------------------------------
Basepage URLs are of the form:
```
https://domain.tld/civicrm/?page=CiviCRM&q=civicrm%2Fevent%2Finfo&reset=1&id=7
```
After
----------------------------------------
Basepage URLs are of the form:
```
https://domain.tld/civicrm/event/info/?reset=1&id=7
```haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/516WSOD when importing sub-contact types2018-11-21T18:33:25ZandyburnsWSOD when importing sub-contact typesOn CiviCRM 5.6.1 when trying to import a, in my case, an organizational sub-contact type, the import fails with a WSOD after mapping fields on step 2.
Here is the error:
> [13-Nov-2018 08:09:56 America/New_York] PHP Fatal error: Uncau...On CiviCRM 5.6.1 when trying to import a, in my case, an organizational sub-contact type, the import fails with a WSOD after mapping fields on step 2.
Here is the error:
> [13-Nov-2018 08:09:56 America/New_York] PHP Fatal error: Uncaught Error: [] operator not
> supported for strings in
> /home/lporg/www/www/wp-content/plugins/civicrm/civicrm/CRM/Contact/Import/Parser.php:562
> Stack trace:
> #0
> /.../.../.../www/wp-content/plugins/civicrm/civicrm/CRM/Contact/Import/Parser/Contact.p
> hp(417): CRM_Contact_Import_Parser->getActiveFieldParams()
> #1
> /.../.../.../www/wp-content/plugins/civicrm/civicrm/CRM/Contact/Import/Parser/Contact.p
> hp(286): CRM_Contact_Import_Parser_Contact->summary(Array)
> #2 /.../.../.../www/wp-content/plugins/civicrm/civicrm/CRM/Contact/Import/Parser.php
> (199): CRM_Contact_Import_Parser_Contact->preview(Array)
> #3
> /.../.../.../www/wp-content/plugins/civicrm/civicrm/CRM/Contact/Import/Form/MapField.ph
> p(968): CRM_Contact_Import_Parser->run('civicrm_import_...', Array, 2, 4, '_id',
> '_status', '4', NULL, NULL, false, 30, 'Local_Affiliate', '11')
> #4
> /.../.../.../www/wp-content/plugins/civicrm/civicrm/CRM/Contact/Import/Form/MapField.ph
> p(668): CRM_Contact_Import_Form_MapField->submit(Array, Array)
> #5 /.../.../.../www/ in
> /.../.../.../www/wp-content/plugins/civicrm/civicrm/CRM/Contact/Import/Parser.php on
> line 562https://lab.civicrm.org/dev/core/-/issues/517Intermittent, ambiguous error "requires cookies" or is it "invalid session ke...2023-09-12T05:03:26ZbrianhayIntermittent, ambiguous error "requires cookies" or is it "invalid session keys"?Fresh, clean install of Drupal 7.61 + CiviCRM 5.7.0 on PHP 7.1
Error is intermittent (maybe every 3rd or so time) when editing contact records like adding a phone number (inline or record save) or clearing caches. Likely other actions t...Fresh, clean install of Drupal 7.61 + CiviCRM 5.7.0 on PHP 7.1
Error is intermittent (maybe every 3rd or so time) when editing contact records like adding a phone number (inline or record save) or clearing caches. Likely other actions trigger the error as well but these are the ones we've discovered so far.
HTTPS is enforced in .htaccess and permanent redirects in place to ensure one URL is used.
No javascript or network console errors. No related apache server errors logged.
The CiviCRM error message is vague and makes little sense. Cookies are enabled in the browser. And is it a cookies or invalid session key issue? It's very strange that it isn't triggered consistently, every time.
![Screen_Shot_2018-11-13_at_5.11.47_pm](/uploads/5dc5e484fba734fbcf16b1248f75cbc5/Screen_Shot_2018-11-13_at_5.11.47_pm.png)https://lab.civicrm.org/dev/core/-/issues/518Lybunt performance improvement2019-02-19T04:55:07ZeileenLybunt performance improvementA couple of years back I did some work on the performance of the Lybunt report https://issues.civicrm.org/jira/browse/CRM-17837 which succeeded in improving the query enough that it would run for prior years there is still an exponential...A couple of years back I did some work on the performance of the Lybunt report https://issues.civicrm.org/jira/browse/CRM-17837 which succeeded in improving the query enough that it would run for prior years there is still an exponential inefficiency in the query which means that 2 years later & some large number of donations later we are back to it not running.
The current query is
```
CREATE TEMPORARY TABLE civicrm_tmp_e_rptlybunt_20181114_5beb5dc8d8e46 DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci
SELECT SQL_CALC_FOUND_ROWS contact_civireport.id as cid FROM civicrm_tmp_e_rptgrp_20181114_5beb5dc8d1b4b group_temp_table INNER JOIN civicrm_contact contact_civireport
ON group_temp_table.id = contact_civireport.id INNER JOIN civicrm_contribution contribution_civireport ON contribution_civireport.contact_id = contact_civireport.id
AND contribution_civireport.is_test = 0
AND contribution_civireport.receive_date BETWEEN '20170101000000' AND '20171231235959'
LEFT JOIN civicrm_contribution cont_exclude ON cont_exclude.contact_id = contact_civireport.id
AND cont_exclude.receive_date BETWEEN '2018-01-01' AND '20181231235959' WHERE cont_exclude.id IS NULL AND 1 AND 1
GROUP BY contact_civireport.id;
```
and it takes 394 seconds
to return only a few hundred rows (the group has only 730 contacts).
Playing around I was able to reduce this time to .24 second by re-writing the query as
```
SELECT SQL_CALC_FOUND_ROWS contact_civireport.id as cid
FROM civicrm_tmp_d_dflt_3b5e17ad9138b8cc56282f75b2967e9e group_temp_table INNER JOIN civicrm_contact contact_civireport
ON group_temp_table.id = contact_civireport.id
WHERE group_temp_table.id IN
(
SELECT group_temp_table.id FROM civicrm_tmp_d_dflt_3b5e17ad9138b8cc56282f75b2967e9e group_temp_table
INNER JOIN civicrm_contribution contribution_civireport ON contribution_civireport.contact_id = group_temp_table.id
AND contribution_civireport.is_test = 0
AND contribution_civireport.receive_date BETWEEN '20170101000000' AND '20171231235959'
)
AND group_temp_table.id IN
(
SELECT group_temp_table.id FROM civicrm_tmp_d_dflt_3b5e17ad9138b8cc56282f75b2967e9e group_temp_table LEFT JOIN
civicrm_contribution cont_exclude ON cont_exclude.contact_id = group_temp_table.id
AND cont_exclude.receive_date BETWEEN '2018-01-01' AND '20181231235959'
WHERE cont_exclude.id IS NULL
)
GROUP BY contact_civireport.id;
```
I experimented on our staging site on running the query on our WHOLE data base (ie. without the group constraint) and it completed in 720 seconds - which is outrageously good really since that legitimately queries a LOT of records.
I'm going to look at how to fix up the LYBUNT report to use the above query. There are already some tests from last time I worked on performance on this report.5.9https://lab.civicrm.org/dev/core/-/issues/519Event receipts for paid events contains extraneous information2022-09-15T05:03:47ZmadhaviEvent receipts for paid events contains extraneous informationCurrently using CiviCRM 5.3.2 and drupal 7.60
Receipts for events paid via PayPal have extra information related to contribution.
**To reproduce issue:**
1. Add custom fields of your choice for Contributions
2. Create a paid event a...Currently using CiviCRM 5.3.2 and drupal 7.60
Receipts for events paid via PayPal have extra information related to contribution.
**To reproduce issue:**
1. Add custom fields of your choice for Contributions
2. Create a paid event and assign `PayPal Standard` payment processor.
3. Enable online registration for the event and set `Send Confirmation Email` to `Yes`.
4. Register a participant for the event.
5. Check the receipt received and see if you get Contribution related custom fields in the email.
Anyone is facing this issue? May be with other payment processor?https://lab.civicrm.org/dev/core/-/issues/520Permission(s) for changing order of fields (eg. in pricesets)2022-09-14T05:03:43ZwdecraenePermission(s) for changing order of fields (eg. in pricesets)You can only change the order of fields when you have the 'administer CiviCRM' permission (see CRM/Core/xml/Menu/Admin.xml):
```xml
<item>
<path>civicrm/admin/weight</path>
<page_callback>CRM_Utils_Weight::fixOrder</page_cal...You can only change the order of fields when you have the 'administer CiviCRM' permission (see CRM/Core/xml/Menu/Admin.xml):
```xml
<item>
<path>civicrm/admin/weight</path>
<page_callback>CRM_Utils_Weight::fixOrder</page_callback>
</item>
```
When you have the permission to edit all events you can create/edit pricesets. But you can't order them when you don't have the 'administer CiviCRM' permission.
Quick fix (see [civicrm-520-permissions-for-changing-fields.patch](/uploads/7019c7ba597ca5b433ac879aa7c2926c/civicrm-520-permissions-for-changing-fields.patch)):
```xml
<item>
<path>civicrm/admin/weight</path>
<page_callback>CRM_Utils_Weight::fixOrder</page_callback>
<access_arguments>administer CiviCRM;access CiviEvent</access_arguments>
</item>
```
Question: is this sufficient? Or should we add more permissions to access_arguments or should we use a callback?https://lab.civicrm.org/dev/core/-/issues/521PCP Owner notification email sending before payment2023-08-14T05:03:17Zrita_compucorpPCP Owner notification email sending before paymentHi there,
When you are the owner of a fundraising page, you are supposed to receive a notification email after a successful donation has been made to your fundraising page. However when you are using a payment processor that navigates y...Hi there,
When you are the owner of a fundraising page, you are supposed to receive a notification email after a successful donation has been made to your fundraising page. However when you are using a payment processor that navigates you out from civicrm to its own payment page (like sagepay, or paypal standard) the owner notification is sent before the payment has been made.
Steps:
- create a contribution page and enable fundraising pages to be created under it
- make the payment processor to be Sagepay or Paypal standard
- create a fundraising page
- then log out and start donating to the fundraising page
- when you click confirm button on the fundraising page, you will get navigated to the payment processor you set up for the contribution page --> this is the point when the notification email is sent to the fundraiser
Expected result: notification for the owner is sent only after a successful donation to the fundraising pagehttps://lab.civicrm.org/dev/core/-/issues/522Add case tokens to email activities2021-09-13T00:04:33ZeileenAdd case tokens to email activitieshttps://lab.civicrm.org/dev/core/-/issues/523Lybunt report - remove broken chart functionality2019-12-03T08:17:20ZeileenLybunt report - remove broken chart functionalityI'd like to propose removing the broken chart functionality from the lybunt report
There is a general level of brokenness with Charts in Civi (Luciano has a promising replacement option here https://lab.civicrm.org/partners/ixiam/report...I'd like to propose removing the broken chart functionality from the lybunt report
There is a general level of brokenness with Charts in Civi (Luciano has a promising replacement option here https://lab.civicrm.org/partners/ixiam/reportplus/blob/2.x/CRM/Reportplus/Utils/ChartJS.php#L8)
But for Lybunt it appears to be specifically & extra broken & this appears to be non-recent.
I propose that we remove the support for charts from this report. I've had a look & I can see nothing about the existing code that would make it easier to get the charts working again at some later point if we went that way (although I suspect we should be looking at something more robust that this report if we want to put that effort in)
![Screenshot_2018-11-15_13.24.44](/uploads/f655a0f7d8dde1c69375e6860863dafc/Screenshot_2018-11-15_13.24.44.png)![Screenshot_2018-11-15_13.24.48](/uploads/97a947046e4b52ed4848ac69dd9d7c91/Screenshot_2018-11-15_13.24.48.png)5.21.0seamusleeseamusleehttps://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/525Extraneous br-tags in rendered note-fields2018-11-16T00:44:05Zthomas_SYSTOPIAExtraneous br-tags in rendered note-fieldsHow to reproduce on a fresh 5.7er CiviCRM:
* Create a contact-inline-custom-group and a note-field with a TextArea- or a RichTextEditor-FieldType.
* Save this field with a multiline text on an arbitrary Contact.
You may see all linebrea...How to reproduce on a fresh 5.7er CiviCRM:
* Create a contact-inline-custom-group and a note-field with a TextArea- or a RichTextEditor-FieldType.
* Save this field with a multiline text on an arbitrary Contact.
You may see all linebreaks displayed doubly.5.9https://lab.civicrm.org/dev/core/-/issues/526Feedback cannot be translated when saving Contribution Page forms in language...2018-11-15T19:32:34ZhaystackFeedback cannot be translated when saving Contribution Page forms in languages other than EnglishWhen saving forms to configure a Contribution Page in languages other than English, the feedback given is not translated or translatable.
Example below (FWIW that's the CiviCRM Admin Utilities theme):
![Screen_Shot_2018-11-15_at_12.37....When saving forms to configure a Contribution Page in languages other than English, the feedback given is not translated or translatable.
Example below (FWIW that's the CiviCRM Admin Utilities theme):
![Screen_Shot_2018-11-15_at_12.37.55](/uploads/a7b2bf0762d271e82c595b4bdc490a16/Screen_Shot_2018-11-15_at_12.37.55.png)
This can be rectified by applying [the same logic as exists for Event Management forms](https://github.com/civicrm/civicrm-core/blob/master/CRM/Event/Form/ManageEvent.php#L376-L378).5.9https://lab.civicrm.org/dev/core/-/issues/527Non translatable fields in profile schema2021-04-22T00:08:01ZsamuelsovNon translatable fields in profile schemaThere are a few fields in profile that should be translatable :
* Public Title
* Description (not a public data but some orgs have staff with different preferred language)
* Redirect URL
* Cancel redirect URL
* Cancel Button Text
* ...There are a few fields in profile that should be translatable :
* Public Title
* Description (not a public data but some orgs have staff with different preferred language)
* Redirect URL
* Cancel redirect URL
* Cancel Button Text
* Submit Button Text
![Screenshot_2018-11-15_Profile_Settings_-_My_profile](/uploads/1cb65d527d439bb236b9e9cbe59993c8/Screenshot_2018-11-15_Profile_Settings_-_My_profile.png)samuelsovsamuelsovhttps://lab.civicrm.org/dev/core/-/issues/528Advanced Search -> Contribution Tab and Contribution Dashboard returns a fata...2018-11-17T02:37:46ZjitendraAdvanced Search -> Contribution Tab and Contribution Dashboard returns a fatal error.On Dmaster
https://dmaster.demo.civicrm.org/civicrm/contact/search/advanced?reset=1 -> Expanding the contribution div section displays a network error
![image](/uploads/1fe2c8909315b51ebded571fcb0d023d/image.png)
Similarly, Contributi...On Dmaster
https://dmaster.demo.civicrm.org/civicrm/contact/search/advanced?reset=1 -> Expanding the contribution div section displays a network error
![image](/uploads/1fe2c8909315b51ebded571fcb0d023d/image.png)
Similarly, Contribution Dashboard returns a fatal error - https://dmaster.demo.civicrm.org/civicrm/contribute?reset=15.9jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/529Editing smart group removes search criteria unless criteria tabs are opened f...2018-12-05T20:28:23ZsudomanEditing smart group removes search criteria unless criteria tabs are opened firstWhen editing the search terms in a smart group, If I click "Search" without first opening the drop down tabs that contain info about all of the search criteria, then those terms are removed from the search, returning a different number o...When editing the search terms in a smart group, If I click "Search" without first opening the drop down tabs that contain info about all of the search criteria, then those terms are removed from the search, returning a different number of contacts.
For instance, if my search terms are: `Country = United Kingdom ...AND... Contribution Date - greater than or equal to "January 2nd, 2017 12:00 AM"`, then I need to open the Address Fields and Contributions tabs before clicking "Search", otherwise, I get a much larger set of contacts.
I'm using CiviCRM version 5.3.1 on Drupal 7. Thanks! : )5.8Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/530Make a_b relationships available as case roles2019-12-02T19:31:10ZalicefruminMake a_b relationships available as case rolesCurrently one can only create case roles for CiviCRM Cases that are one direction (one only sees the options label_b_a). See screen shot below that shows the "New Case Type" Ui with the options for "add role" open (they are all label_b_a...Currently one can only create case roles for CiviCRM Cases that are one direction (one only sees the options label_b_a). See screen shot below that shows the "New Case Type" Ui with the options for "add role" open (they are all label_b_a) as one can see by checking against the Relationship Type table next to it.
![relTypesNewCaseType](/uploads/193cce5a0e6d7c395b8003e3c4593241/relTypesNewCaseType.png)
We are proposing making it so users can choose from the full list of relationships (label_a_b and label_b_a).
Rationale:
---------
1. There could be scenarios where cases should be set up to have case roles in any direction. For example.. an intergenerational case where its children taking care of parents vs a school case where its parents taking care of kids.
2. Jira issue [CRM-19754](https://issues.civicrm.org/jira/browse/CRM-19754) suggests that the options available should be label_a_b. One pr to make this change was accepted [pr 9560](https://github.com/civicrm/civicrm-core/pull/9560) a second [pr 9975](https://github.com/civicrm/civicrm-core/pull/9975) was closed due to in action and incompleteness. Making the Case Types bidirectional would solve the bugs documented in [pr 9975](https://github.com/civicrm/civicrm-core/pull/9975) without a fix up script.
Bugs this change fixes:
----------------------
1) when creating a case type, you can only select B-to-A labels
![image_1_](/uploads/11c127df30b22761b5653353534484da/image_1_.png)
then after creating a case you see the B-to-A "Parent of" label
![image_2_](/uploads/01922f80d41cd2fe8bb227d73d5e36c0/image_2_.png)
after picking the contact, the label becomes the A-to-B "Child of"
![image_4_](/uploads/a29e1194dd5af9c0b64d5945bd1ccf4f/image_4_.png)
2) When viewing a case, the Roles drop-down, only shows the labels in the B to A direction, but when one assigns the case role in the B to A direction the label displayed is in the A to B direction.
3) When editing a Case Activity in the "Send a copy" the role is correct but the label is wrong.
4) Currently, all relationships are showing the B contact, regardless of who the client is
yet they all have the B-to-A label, regardless of who the client is for example:
![Screenshot_2019-03-29_Dr_Rebekah_Cooper_-_Housing_Support_grantdetailreport](/uploads/e00afec39078c45673ab2b7f1cc0c252/Screenshot_2019-03-29_Dr_Rebekah_Cooper_-_Housing_Support_grantdetailreport.png)
In this example Rebekah is the client, and the case has her as the parent of Kathleen and the child of Carylon. In the send a copy box, she's shown as parent of Carylon and her relationship w/ Kathleen is displayed as her being parent of herself.
5) when reassigning a case role that is B-to-A (where the client is on the B side of the relationship), the list of available contacts is the contact type of the B side
since households and organizations are frequently on the B side of a relationship, this makes it difficult-to-impossible to manage a case where the client is a household or organization
![reassign](/uploads/9d71615554a0e1a15a0b6776ab9aac45/reassign.png)
Places in the Code that would need to be adjusted:
-----------------------------------------------
+ CRM/Report/Form/Case/Summary.php
+ CRM/Report/Form/Case/Detail.php
+ CRM/Case/XMLProcessor/Process.php
+ CRM/Case/XMLProcessor.php
+ CRM/Case/ManagedEntities.php
+ CRM/Case/BAO/Query.php
+ CRM/Case/BAO/Case.php
+ ang/crmCaseType.js5.16.0https://lab.civicrm.org/dev/core/-/issues/531Drop support for MySQL 5.1? Maybe more?2020-09-09T05:24:02ZJonGoldDrop support for MySQL 5.1? Maybe more?While reviewing some PRs on the sysadmin docs, it came to my attention that we're currently saying we support MySQL 5.1.3+. MySQL 5.1 has been [EOL since 2013](https://www.fromdual.com/support-for-mysql-from-oracle). 5.5 went EOL at th...While reviewing some PRs on the sysadmin docs, it came to my attention that we're currently saying we support MySQL 5.1.3+. MySQL 5.1 has been [EOL since 2013](https://www.fromdual.com/support-for-mysql-from-oracle). 5.5 went EOL at the end of 2015, with extended support ending this year.
While the impetus to drop support for MySQL isn't as strong as it is for PHP, I think we should consider dropping support before someone reports an issue on an untested configuration and points to the minimum requirements in the docs.
Whether this is just a matter of updating the docs or if we want to set up a check for `MIN_MYSQL_VERSION` and `MIN_RECOMMENDED_MYSQL_VERSION` is something we can discuss. Just updating the docs might be preferable so we don't need to navigate the MySQL/MariaDB/Percona business in code. That said, we should document whether MariaDB/Percona are supported, since we've certainly seen errors particular to one or another.