Development issueshttps://lab.civicrm.org/groups/dev/-/issues2019-12-16T19:27:10Zhttps://lab.civicrm.org/dev/core/-/issues/1472Thousands-separator corrupts price field values (comma)2019-12-16T19:27:10ZAllenShawThousands-separator corrupts price field values (comma)This issue appears with price field values of 1000 and above. It is reproducible as follows on dmaster:
I start by visiting Administer CiviCRM > Localization > Languages, Currency, Locations, and ensure the following settings:
* Thousa...This issue appears with price field values of 1000 and above. It is reproducible as follows on dmaster:
I start by visiting Administer CiviCRM > Localization > Languages, Currency, Locations, and ensure the following settings:
* Thousands Separator: ,
* Decimal Delimiter: .
Then I take these steps:
1. Create a price field with an amount of 1200.00, and click Save
1. In the list of price fields, observe that the amount is correct: "1,200.00".
1. Edit that price field, and in the Edit form, the amount is displayed with decimal and thousands-separators, as "1,200.00"
1. Remove the comma and click Save.
1. In the list of price fields, observe that the amount is correct: "1,200.00".
1. Again edit that price field, and in the Edit form, the amount is again displayed with decimal and thousands-separators, as "1,200.00"
1. Change nothing in this form and merely press Save.
1. In the list of price fields, observe that the amount is now "1.00".
My guess is that the comma is being treated as a decimal, even though the localization settings specify that it is the thousands-separator.
Perhaps we could just do without thousands-separators in editable price fields, and sidestep the issue of processing them; but then someone would enter them manually and be surprised at the result. So omitting them is probably not enough.5.22.0https://lab.civicrm.org/dev/core/-/issues/1471Smart groups with deleted/disabled custom fields throw fatal error on its usage.2023-03-30T05:03:42ZjitendraSmart groups with deleted/disabled custom fields throw fatal error on its usage.To replicate -
- Create a smart group with custom date as one of the filter.
- Disable the custom field after the smart group creation.
- The update smart group count `/civicrm/group?reset=1&update_smart_groups=1` functionality returns ...To replicate -
- Create a smart group with custom date as one of the filter.
- Disable the custom field after the smart group creation.
- The update smart group count `/civicrm/group?reset=1&update_smart_groups=1` functionality returns a DB error.
![image](/uploads/5482a85c55b162c84d2e5cfc7c1857b5/image.png)
- Usage of this group in mailings does not calculate the recipient -
![image](/uploads/ede5567e4cd0b68db9c9a1ae80fef133/image.png)
**Possible Solutions**
- Fix the code to ignore the disabled custom field criteria while fetching the formvalues for the smart group.
This calculates the count and retrieves all the contacts correctly but is not following the exact filter condition setup by the user while creating this group.
- Produce a warning on the custom field delete page that this field is being used by a smart group. And avoid deletion?
- System Status warning with an indication that there are some smart groups configured on your site that uses disabled custom fields as a filter.
- Probably 1 and 3 both?
ping @petednz @eileenjitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/1470Activity type listing shows name instead label2019-12-12T17:59:26ZPradeep Nayakpradpnayak@gmail.comActivity type listing shows name instead labelActivity type listing shows name instead label on case type setting. See attached image to replicate the problem
![BeforeFix](/uploads/2a68345b9b5103e5aa58460b9337a32f/BeforeFix.gif)Activity type listing shows name instead label on case type setting. See attached image to replicate the problem
![BeforeFix](/uploads/2a68345b9b5103e5aa58460b9337a32f/BeforeFix.gif)5.22.0Pradeep Nayakpradpnayak@gmail.comPradeep Nayakpradpnayak@gmail.comhttps://lab.civicrm.org/dev/core/-/issues/1469Confirm from email always not valid when updating "online registration" of an...2021-08-17T21:35:47ZhansrosselConfirm from email always not valid when updating "online registration" of an event after updating to 5.20.2Overview
----------------------------------------
After updating from 5.19 to 5.20.2 the "online registration" tab of an event cannot be updated because the "Confirm From Email" is always invalid.
Reproduction steps
--------------------...Overview
----------------------------------------
After updating from 5.19 to 5.20.2 the "online registration" tab of an event cannot be updated because the "Confirm From Email" is always invalid.
Reproduction steps
----------------------------------------
1. Save the "online registration" form of an existing event https://www.example.com/en/civicrm/event/manage/registration?reset=1&action=update&id=xxx
with a valid "Confirm from email"
2. Got an error "Confirm From Email", "Email is not valid"
Full error in the logs:
/civicrm/event/manage/registration?action=update&id=xx&component=event&qfKey=xx&snippet=json
Notice: Use of undefined constant INTL_IDNA_VARIANT_UTS46 - assumed 'INTL_IDNA_VARIANT_UTS46' in HTML_QuickForm_Rule_Email->validate() (line 58 of /sites/all/modules/civicrm/packages/HTML/QuickForm/Rule/Email.php)
Warning: idn_to_ascii() expects parameter 3 to be integer, string given in HTML_QuickForm_Rule_Email->validate() (line 58 of /sites/all/modules/civicrm/packages/HTML/QuickForm/Rule/Email.php).
Environment information
----------------------------------------
Using php 7.1 with php-intl5.21.0https://lab.civicrm.org/dev/financial/-/issues/111Thank-you letter incorrect contribution currency2020-10-09T01:04:37ZkleehkThank-you letter incorrect contribution currencySteps to replicate:
* Enter a contribution with a currency that is not the default.
* Using any method that supports contribution tokens (Thank-you letter print or email, CiviRules, etc.) use one of the following tokens: `{contribution.t...Steps to replicate:
* Enter a contribution with a currency that is not the default.
* Using any method that supports contribution tokens (Thank-you letter print or email, CiviRules, etc.) use one of the following tokens: `{contribution.total_amount} {contribution.fee_amount} {contribution.net_amount}`.
**Expected result**
The token displays the amount formatted to the currency of the contribution.
**Actual result**
The token displays the amount formatted to the default currency.
[Original message follows].
~~~~
My setup: CiviCRM 5.20.0 on Drupal 7.
I entered contributions in different currencies. In Find Contributions, check some entries. At Actions select Thank-you letter print or email.
I put tokens Contributions:
{contribution.currency} {contribution.total_amount} {contribution.fee_amount} {contribution.net_amount}
and it gives me lines like these:
CNY HK$ 1,299.90 HK$ 0.00 HK$ 1,299.90
GBP HK$ 500.00 HK$ 0.00 HK$ 500.00
where CNY and GBP are the currencies of those contributions and HK$ is the symbol of the default currency.
It seems the amounts variables just took the system default, rather than contributions' currencies.
Thank you.
Original post at https://civicrm.stackexchange.com/questions/34031/thank-you-letter-incorrect-contribution-currency5.32.0JonGoldJonGoldhttps://lab.civicrm.org/dev/drupal/-/issues/98CiviCRM session instance not working when Masquerading in Drupal 72021-09-01T21:02:42ZMichael McAndrewCiviCRM session instance not working when Masquerading in Drupal 7Have just upgraded to D7-5.20.1 and noticed that CRM_Core_Session::singleton() does not work when masquerading.
Setting a breakpoint in a Drupal page while masquerading and running `Civi::log()->debug(var_export(CRM_Core_Session::single...Have just upgraded to D7-5.20.1 and noticed that CRM_Core_Session::singleton() does not work when masquerading.
Setting a breakpoint in a Drupal page while masquerading and running `Civi::log()->debug(var_export(CRM_Core_Session::singleton(),true))`
Results in the following in the log:
```
Dec 11 13:08:57 [debug] CRM_Core_Session::__set_state(array(
'_key' => 'CiviCRM',
'_session' =>
array (
'masquerading' => '76',
),
))
```5.23.0https://lab.civicrm.org/dev/core/-/issues/1468Advanced search fails to properly search for contribution source2019-12-11T19:17:56ZRichAdvanced search fails to properly search for contribution sourceOverview
----------------------------------------
Try searching for a contribution source from the Advanced search - bet you don't get any results.
Reproduction steps
----------------------------------------
1. Create a contact; add ...Overview
----------------------------------------
Try searching for a contribution source from the Advanced search - bet you don't get any results.
Reproduction steps
----------------------------------------
1. Create a contact; add a contribution with a source `findme`
1. Do an advanced search, specifying a contribution with a source `findme`
1. no results - expected to find your contact.
Current behaviour
----------------------------------------
No results.
Reason: the SQL generation generates SQL like this: `civicrm_contribution.source IN ("%findme%")`
i.e. it's added `%` wildcards as if for a `LIKE` operator, but then it's used `IN`!
Expected behaviour
----------------------------------------
It should generate SQL like this: `civicrm_contribution.source LIKE ("%findme%")` and return the result.
Environment information
----------------------------------------
* __CiviCRM:__ _Master_ and _5.20.0_5.22.0RichRichhttps://lab.civicrm.org/dev/core/-/issues/1467Multiple participant registration sends only p1 amount to the processor.2019-12-12T04:30:04ZjitendraMultiple participant registration sends only p1 amount to the processor.To replicate -
- Create an event with multiple participant.
- Register atleast 2 participants to the event.
- Correct fees shown on the confirmation page -
![image](/uploads/354b1d233f2cb91a3f0d7f168a2e123f/image.png)
- When the page ...To replicate -
- Create an event with multiple participant.
- Register atleast 2 participants to the event.
- Correct fees shown on the confirmation page -
![image](/uploads/354b1d233f2cb91a3f0d7f168a2e123f/image.png)
- When the page is submitted, the processor site only shows the last participant amount.
![image](/uploads/5681cac2aa44409d15d39da3cef5c1a3/image.png)
It seems to be a problem with the processors that do a checkout to their site for payment.5.20.2jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/1466System Status "Read more about this warning" points to non existent docs2020-02-20T20:30:05ZPaul-TahoeSystem Status "Read more about this warning" points to non existent docsThere are several places where there is a link to docs. These links still point to http://wiki.civicrm.org/confluence... instead of https://docs.civicrm.org/sysadmin/en/latest/setup/security...
I think the following:
The CiviCRM debug...There are several places where there is a link to docs. These links still point to http://wiki.civicrm.org/confluence... instead of https://docs.civicrm.org/sysadmin/en/latest/setup/security...
I think the following:
The CiviCRM debug log should not be downloadable Should point to
https://docs.civicrm.org/sysadmin/en/latest/setup/security/#the-log-file-should-not-be-accessible
Files in the data directory (.../sites/default/files/civicrm/upload/) should not be downloadable. Should point to
https://docs.civicrm.org/sysadmin/en/latest/setup/security/#uploads-should-not-be-accessible
Directory ... should not be browseable via the web. Should point to
https://docs.civicrm.org/sysadmin/en/latest/setup/security/#directories-should-not-be-browsable
I think the code is in civicrm/CRM/Utils/Check/Component/Security.php5.24.0https://lab.civicrm.org/dev/core/-/issues/1465CiviCRM truncate multiple option fields to 255 characters2023-06-13T05:03:14ZcalbasiCiviCRM truncate multiple option fields to 255 charactersOverview
----------------------------------------
CiviCRM truncate multiple option fields to 255 characters
Reproduction steps
----------------------------------------
1. Create a multioption field with lots of text option choices
2. Sa...Overview
----------------------------------------
CiviCRM truncate multiple option fields to 255 characters
Reproduction steps
----------------------------------------
1. Create a multioption field with lots of text option choices
2. Save a contact selecting several options that sum more than 255 char.
3. Export it
Current behaviour
----------------------------------------
Your exported field gets truncated at 255 characters
Expected behaviour
----------------------------------------
All the info should be exported.
Environment information
----------------------------------------
* CiviCRM: 5.15
* PHP: 5.x
* CMS: Drupal 7.x
* Database: MariaDB
* Web Server: Apache 2.x
* OS: Debian 9.x
Comments
----------------------------------------
I think it could be related with this:
* https://issues.civicrm.org/jira/browse/CRM-15048
* https://github.com/civicrm/civicrm-core/pull/3790
In this case, @colemanw fix the bug using the lenght of the field set in CiviCRM. But what about multiple choices?https://lab.civicrm.org/dev/core/-/issues/1463Record Payment form Errors.2019-12-12T04:25:34ZjitendraRecord Payment form Errors.Overview
----------------------------------------
1. Record Payment form does not load.
2. Record payment fails when Amount Owed is a decimal point number. Eg 264.65
Reproduction steps
----------------------------------------
1. Registe...Overview
----------------------------------------
1. Record Payment form does not load.
2. Record payment fails when Amount Owed is a decimal point number. Eg 264.65
Reproduction steps
----------------------------------------
1. Register a contact for an event with Fee Amount = $264.65.
1. Keep the status as Partially Paid and pay only part of the above amount. Eg 100. Amount owed = $164.65.
1. Save.
1. Click "Record Payment" and try to pay the remaining amount. The form does not load which seem to be a regression from https://github.com/civicrm/civicrm-core/pull/15465
![image](/uploads/0c301633b5e7d8926657e52e737ddec4/image.png)
1. Select payment method and click save.
![image](/uploads/c50f706ae3c26ad42586950d0a505c21/image.png)
Expected behaviour
----------------------------------------
Form should load fine and accept the decimal amount as it is equal to the remaining amount that needs to be paid.5.20.2jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/1462Deletion of managed dashboard entities causes DB constraint violations at man...2020-09-17T22:58:06ZFrancis (Agileware)Deletion of managed dashboard entities causes DB constraint violations at managed entity / cache rebuild.Overview
--------
After deleting a dashboard (which can be done accidentally), attempting an operation that causes the managed entities to be evaluated causes a DB constraint error.
> Sorry, due to an error, we are unable to fulfill yo...Overview
--------
After deleting a dashboard (which can be done accidentally), attempting an operation that causes the managed entities to be evaluated causes a DB constraint error.
> Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred.
API error: DB Constraint Violation - domain_id should possibly be marked as mandatory for Dashboard,create API. If so, please raise a bug report.
Reproduction steps
------------------
1. Install an extension that created managed dashboard entities, such as [Civisualize](https://civicrm.org/extensions/civisualize-missing-data-visualization-extension)
2. Go to the CiviCRM dashboard as an admin, and select "Configure my Dashboard"
3. Delete any of the managed dashboards, so that they are no longer available for selection, and press Done
4. Attempt an operation that triggers the managed entities to be checked, e.g. installing another extension (I think this actually happens every cache rebuild, so `cv flush` on the command line should be sufficient).
Current behaviour
-----------------
A fatal error is thrown by the database, due to a foreign key constraint violation:
```
nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails (`izjlsytg_civicrm`.`civicrm_dashboard_contact`, CONSTRAINT `FK_civicrm_dashboard_contact_dashboard_id` FOREIGN KEY (`dashboard_id`) REFERENCES `civicrm_dashboard` (`id`) ON DELETE CASCADE)
```
Expected behaviour
------------------
Entities are re-evaluated without issue and operation succeeds.
Agileware ref CIVICRM-1394https://lab.civicrm.org/dev/core/-/issues/1461Donor can modify existing fields of honoree2023-01-19T05:03:38ZBobSDonor can modify existing fields of honoreeOverview
----------------------------------------
Values specified in the honoree fields of a contribution update existing values of the honoree contact record.
Reproduction steps
----------------------------------------
1. Ensure that...Overview
----------------------------------------
Values specified in the honoree fields of a contribution update existing values of the honoree contact record.
Reproduction steps
----------------------------------------
1. Ensure that the unsupervised dedupe rule requires first name and email to match.
1. Create an honoree contact: Joe Honoree, joe@honoree.com.
1. Create a contribution page with the Honoree section enabled. Use the default honoree profile consisting of first name, last name, email.
1. Make a contribution, specifying for the honoree joE WrongName, joe@honoree.com.
Current behaviour
----------------------------------------
The honoree contact has been changed to joE WrongName.
in addition to the last name in the honoree's contact record being changed completely, the capitalization of the first name has also been changed.
Expected behaviour
----------------------------------------
Existing fields in the honoree's contact record should not be changeable by a third party (donor). It would be best to create a new contact which can later be manually deduped, rather than to allow a third party to overwrite existing information.
Environment information
----------------------------------------
* __CiviCRM:__ _5.20.0_
* __PHP:__ _7.2.25_
* __CMS:__ _Drupal 7.30_
* __Database:__ _MariaDB 10.0_https://lab.civicrm.org/dev/core/-/issues/1460How best to handle Event Dispatchers during upgrade2023-03-08T05:03:30ZseamusleeHow best to handle Event Dispatchers during upgradeAs shown by #1449 and in PRs https://github.com/civicrm/civicrm-core/pull/13551 and https://github.com/civicrm/civicrm-core/pull/16034 there have been shown issues with dispatching most hooks when in upgrade mode, this ticket is to discu...As shown by #1449 and in PRs https://github.com/civicrm/civicrm-core/pull/13551 and https://github.com/civicrm/civicrm-core/pull/16034 there have been shown issues with dispatching most hooks when in upgrade mode, this ticket is to discuss the best ways forward and if we need to move the whitelisting or similar to the dispatcher or elsewhere ping @eileen @tottenhttps://lab.civicrm.org/dev/core/-/issues/1458Searches with force=1&sort_name don't support spaces in the sort_name parameter2023-01-18T05:03:45ZDaveDSearches with force=1&sort_name don't support spaces in the sort_name parameterFor example if I want to return all contacts with first name `Jar Jar` but not `Jar Joe` I can't search for `sort_name=Jar%20Jar` or `sort_name=Jar+Jar`. It just ignores the parameter completely and returns all contacts.
I don't have a ...For example if I want to return all contacts with first name `Jar Jar` but not `Jar Joe` I can't search for `sort_name=Jar%20Jar` or `sort_name=Jar+Jar`. It just ignores the parameter completely and returns all contacts.
I don't have a stake in this, and not sure how important it is to anyone, just noting it as it has come up in testing of the force=1 searches.https://lab.civicrm.org/dev/core/-/issues/1457Sort Custom Fields by Custom Field Group in Search Builder2023-01-18T05:03:44Zmagnolia61Sort Custom Fields by Custom Field Group in Search BuilderOverview
----------------------------------------
The list of custom fields is not sorted in the search builder when *not* selecting a contact subtype.
This makes creating a selection when you have quite a few custom fields very labor i...Overview
----------------------------------------
The list of custom fields is not sorted in the search builder when *not* selecting a contact subtype.
This makes creating a selection when you have quite a few custom fields very labor intensive and cumbersome.
Example use-case
----------------------------------------
See screenshots below.
Current behaviour
----------------------------------------
When choosing a contact type the list of Custom Fields is not sorted
![Screenshot_from_2019-12-07_20-27-47](/uploads/ea28ab71b8e23f8d96e97d893059b3f6/Screenshot_from_2019-12-07_20-27-47.png)
After seleting a contact subtype the list is alfabetically sorted by Custom Group / Custom Field
![Screenshot_from_2019-12-07_20-27-52](/uploads/cd2a434a4ff42ddaa2f8552b4ec569a1/Screenshot_from_2019-12-07_20-27-52.png)
Proposed behaviour
----------------------------------------
The list of custom fields is also sorted by Custom Group / Custom Field for when no contact subtype is selected.
Comments
----------------------------------------
Probably this is a very small change. Sorting an array or different query. I just don't know in which haystack to look for this needle :-)https://lab.civicrm.org/dev/core/-/issues/1456Major search limitations and inconsistency2020-01-15T11:43:46Zmagnolia61Major search limitations and inconsistencyOverview
----------------------------------------
I have been using CiviCRM for some 7 years nowm more as a implementer and casual small and simple pr creator.
Something we have run into since using CiviCRM is the inconsistency in using...Overview
----------------------------------------
I have been using CiviCRM for some 7 years nowm more as a implementer and casual small and simple pr creator.
Something we have run into since using CiviCRM is the inconsistency in using the search functions to create smart groups.
We have found workarounds but these are mostly resource expensive.
Example use-case
----------------------------------------
**Advanced Search (AS)**
+ intuitive interface
- Is not able to do advanced logic like '= NULL'
**Search Builder (SB)**
+ great overall flexibility
- Is not able to use relative date filters
Current behavior
----------------------------------------
For creating some of the smart groups we need, we now usually create 3 smartgroups.
1. smartgroup AS with participant info with relative date filter
2. smartgroup SB with some value = (NOT) NULL
3. An include/exclude search group to combine the two
This is very resource intensive but the only workaround we know of today
Proposed behavior
----------------------------------------
enable the following search logic Advanced Search:<br>- IS NULL / IS NOT NULL for select and date fields<br>
enable the following search logic for Search Builder:<br>- relative date filters for date fields
Comments
----------------------------------------
I will try to come up with some more comprehensive examples which I think will enhance both functionality and performance of CiviCRM.
Related issues, pr's and stackexchange topics:
----------------------------------------
Proposal to add is empty / is not empty to AS date field filters https://lab.civicrm.org/dev/core/issues/1211<br>
Api4 Search Builder Vision by Eileen: https://lab.civicrm.org/dev/core/issues/1106 https://lab.civicrm.org/dev/core/-/issues/1455Contribution tab sort by Type column not working with db error2019-12-08T21:33:03ZStoobContribution tab sort by Type column not working with db errorWhen clicking Type to sort by Financial Type in the Contributions tab, a Network Error occurs. "Database Error Code: Column 'financial_type_id' in order clause is ambiguous, 1052"
**The full error is attached.**[type-error.txt](/upload...When clicking Type to sort by Financial Type in the Contributions tab, a Network Error occurs. "Database Error Code: Column 'financial_type_id' in order clause is ambiguous, 1052"
**The full error is attached.**[type-error.txt](/uploads/a3e2347b0dfa04c24fa7c68783a892aa/type-error.txt)
![type](/uploads/683755c044a7cb017d3bcc09b20ad355/type.png) <--- this button
The error began after the update from 5.13 to 5.19, and version currently in use is 5.19.4.5.20.0https://lab.civicrm.org/dev/core/-/issues/1454Upgrade: Upgrade to 5.20.0 freeze on2019-12-06T20:29:51ZmarcineqUpgrade: Upgrade to 5.20.0 freeze onOverview
----------------------------------------
When i start my CiviCRM upgrade, upgrader freeze on task: [Executed: Change direction of autoassignees in case type xml].
I have CiviCase component configured with custom case type, wit...Overview
----------------------------------------
When i start my CiviCRM upgrade, upgrader freeze on task: [Executed: Change direction of autoassignees in case type xml].
I have CiviCase component configured with custom case type, with custom roles autoassign to case creator.
After refresh updater page - updater not run.
In Drupal log can i see this issue after notice about executed job.
`Error: Class 'CRM_Documents_Entity_DocumentRepository' not found w documents_civicrm_pre() (linia 172 z /path/to/crm/sites/default/files/civicrm/ext/org.civicoop.documents/documents.php).`
I tried turn off Document extension and restore database from backup. After this i see this error in log:
Error: Class 'CRM_CiviMobileAPI_PushNotification_Utils_NotificationFactory' not found w civimobileapi_civicrm_pre() (linia 342 z /path/to/civicrm/sites/default/files/civicrm/ext/com.agiliway.civimobileapi/civimobileapi.php).
In CiviCRM log i don't have anything of this errors.
Reproduction steps
----------------------------------------
1. Try to upgrade CiviCRM from 5.19.3 to 5.20.0 with enable CiviCase
Current behaviour
----------------------------------------
![image](/uploads/79b14274de224db4f551476d4588c453/image.png)
Expected behaviour
----------------------------------------
Upgrade is finished.
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. -->
* __Browser:__ _Chrome 78.0.3904.108_
* __CiviCRM:__ _5.19.2 to 5.20.0_
* __PHP:__ _7.2__
* __CMS:__ _Drupal 7.67_
* __Database:__ _10.3.20-MariaDB_
* __Web Server:__ _Apache 2.4_
Comments
----------------------------------------
My extensions:
![image](/uploads/2101f41e3155a0098890bbe323e40752/image.png)https://lab.civicrm.org/dev/core/-/issues/1453DB Error from CRM_Contact_BAO_Contact::triggerInfo when enabling/disabling ex...2023-01-17T05:03:31ZcolemanwDB Error from CRM_Contact_BAO_Contact::triggerInfo when enabling/disabling extensionsI just switched to a new localhost with a bleeding-edge LAMPP stack:
- PHP 7.3.11
- MariaDB 10.4.8
- Apache 2.4.41
I was able to setup buildkit and install a site, but when enabling/disabling an extension I get: `DB Error: unknown erro...I just switched to a new localhost with a bleeding-edge LAMPP stack:
- PHP 7.3.11
- MariaDB 10.4.8
- Apache 2.4.41
I was able to setup buildkit and install a site, but when enabling/disabling an extension I get: `DB Error: unknown error` bubbling up from `Civi\Core\SqlTriggers->rebuild()`. The offending query is `"DROP FUNCTION IF EXISTS civicrm_strip_non_numeric"` called by `CRM_Contact_BAO_Contact::triggerInfo`.
"Unknown error" isn't much to go on so I'm posting this to see if anyone has encountered this as well. If my ~~theory~~ hunch is right then it's due to my newer-than-recommended MariaDB version.
So far I've tried removing the `DROP FUNCTION` query and having it just do the subsequent `CREATE FUNCTION` (I appended `IF EXISTS`) but that too crashes with "unknown error".