CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-06-06T05:03:18Zhttps://lab.civicrm.org/dev/core/-/issues/1214Suggest to add a system status check that checks if trigger/view definer is t...2023-06-06T05:03:18ZDaveDSuggest to add a system status check that checks if trigger/view definer is the same db user as in civicrm_settings.phpIt comes up semi-regularly for people who are moving sites around or setting up staging/live where the trigger/view definer is the db user on the other site, and so errors happen. A system status check could point this out and point you ...It comes up semi-regularly for people who are moving sites around or setting up staging/live where the trigger/view definer is the db user on the other site, and so errors happen. A system status check could point this out and point you to the link to rebuild triggers. I don't think it should do it automatically because there might be a legit reason you purposely made them different, although that does seem unlikely for a civi site.
I can add this to my rainy-day todo list. It's just not going to be at the top.https://lab.civicrm.org/dev/core/-/issues/1156Do not delete associated contributions when membership is deleted2022-11-29T05:03:30ZStoobDo not delete associated contributions when membership is deletedBack in 2011 https://issues.civicrm.org/jira/browse/CRM-7188 it appears it was the intent to change the behavior of membership deletion to NOT delete associated contributions. This warning message was instituted as a work around but the...Back in 2011 https://issues.civicrm.org/jira/browse/CRM-7188 it appears it was the intent to change the behavior of membership deletion to NOT delete associated contributions. This warning message was instituted as a work around but the behavior change was apparently never implemented. I'd like to get some discussion and/or traction on finally implementing this change. Having discussed with @eileen @andrewhunt @JoeMurray @KarinG and BoT, I haven't found yet an opinion or a use case where the current behavior is desirable, but I don't want to assume that the community is unanimous in this reagard.
Input from others is welcome, I'm asking @colemanw @cividesk and any others who have run into this behavior for their thoughts and/or historical memory.
![delete-member](/uploads/2528146de59e3210bf7015eb726d036e/delete-member.jpg)https://lab.civicrm.org/dev/core/-/issues/1111Move upload_max_filesize warning to system check2022-11-20T21:49:18ZAndie HuntMove upload_max_filesize warning to system checkCurrently the `CRM_Utils_Number::formatUnitSize()` function [does a check](https://github.com/civicrm/civicrm-core/blob/358a1864ba3c5a3fc3ff65f03b3db045ea2199a8/CRM/Utils/Number.php#L107-L118) for whether the `upload_max_filesize` in PHP...Currently the `CRM_Utils_Number::formatUnitSize()` function [does a check](https://github.com/civicrm/civicrm-core/blob/358a1864ba3c5a3fc3ff65f03b3db045ea2199a8/CRM/Utils/Number.php#L107-L118) for whether the `upload_max_filesize` in PHP is smaller than the maximum upload size in your site settings.
1. The message calls the php.ini setting "upload_max_size", which will lead people astray.
2. This really should be a system check that you see well before you are about to upload something.
There's a similar check in there if `post_max_size` is smaller than `upload_max_filesize`. This should also move to the system check.https://lab.civicrm.org/dev/core/-/issues/723File custom fields cause a fatal error when trying to merge2019-05-30T21:47:13ZtommyboboFile custom fields cause a fatal error when trying to mergeIf you are trying to merge a contact with a custom field that is a file, if the contact that will be deleted is passing a file to the remain contact, the merge will fail, generate a fatal error, and lose all the custom data in the set in...If you are trying to merge a contact with a custom field that is a file, if the contact that will be deleted is passing a file to the remain contact, the merge will fail, generate a fatal error, and lose all the custom data in the set including the file.
To recreate:
1. Create a contact custom field that accepts a file.
2. Add files to one or two contact records.
3. Merge a contact with a file into another contact
4. Fatal Error occurs. All files are no longer attached to the custom fields. The contact to be deleted loses all the custom fields. While the remaining contact looses only the file.
If the contact that is to remain has no image the error message is
> **No record found for given file ID - 0 and entity ID - 203**
The Entity ID is the Contact ID of the remaining contact
> Feb 13 16:13:23 [info] $backTrace = #0 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(381): CRM_Core_Error::backtrace("backTrace", TRUE)
> #1 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/File.php(234): CRM_Core_Error::fatal("No record found for given file ID - 0 and entity ID - 203")
> #2 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Dedupe/Merger.php(1723): CRM_Core_BAO_File::deleteFileReferences(NULL, "203", 9)
> #3 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Contact/Form/Merge.php(289): CRM_Dedupe_Merger::moveAllBelongings("203", "204", (Array:11))
> #4 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php(489): CRM_Contact_Form_Merge->postProcess()
> #5 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/StateMachine.php(160): CRM_Core_Form->mainProcess()
> #6 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Next.php(61): CRM_Core_StateMachine->perform(Object(CRM_Contact_Form_Merge), "next", "Next")
> #7 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Next->perform(Object(CRM_Contact_Form_Merge), "next")
> #8 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contact_Form_Merge), "next")
> #9 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Controller.php(351): HTML_QuickForm_Page->handle("next")
> #10 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Utils/Wrapper.php(113): CRM_Core_Controller->run()
> #11 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(282): CRM_Utils_Wrapper->run("CRM_Contact_Form_Merge", "Merge Contact", (Array:0))
> #12 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:13))
> #13 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:3))
> #14 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm.php(1240): CRM_Core_Invoke::invoke((Array:3))
> #15 /srv/www/demo19/public_html/wp-includes/class-wp-hook.php(298): CiviCRM_For_WordPress->invoke("")
> #16 /srv/www/demo19/public_html/wp-includes/class-wp-hook.php(323): WP_Hook->apply_filters("", (Array:1))
> #17 /srv/www/demo19/public_html/wp-includes/plugin.php(453): WP_Hook->do_action((Array:1))
> #18 /srv/www/demo19/public_html/wp-admin/admin.php(222): do_action("toplevel_page_CiviCRM")
> #19 {main}
If the remaining contact has a file that will be overwritten.
>** DB Error: syntax error**
> [code] => -2
> [message] => DB Error: syntax error
> [mode] => 16
> [debug_info] => UPDATE civicrm_value_test_info_4 SET image_9 = WHERE entity_id = 203 [nativecode=1064 ** You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'WHERE entity_id = 203' at line 1]
> [type] => DB_Error
> [user_info] => UPDATE civicrm_value_test_info_4 SET image_9 = WHERE entity_id = 203 [nativecode=1064 ** You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'WHERE entity_id = 203' at line 1]
> [to_string] => [db_error: message="DB Error: syntax error" code=-2 mode=callback callback=CRM_Core_Error::handle prefix="" info="UPDATE civicrm_value_test_info_4 SET image_9 = WHERE entity_id = 203 [nativecode=1064 ** You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'WHERE entity_id = 203' at line 1]"]
> )
> #1 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/packages/PEAR.php(921): CRM_Core_Error::handle(Object(DB_Error))
> #2 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/packages/DB.php(985): PEAR_Error->__construct("DB Error: syntax error", -2, 16, (Array:2), "UPDATE civicrm_value_test_info_4 SET image_9 = WHERE entity_id = 203 [native...")
> #3 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/packages/PEAR.php(575): DB_Error->__construct(-2, 16, (Array:2), "UPDATE civicrm_value_test_info_4 SET image_9 = WHERE entity_id = 203 [native...")
> #4 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/packages/PEAR.php(223): PEAR->_raiseError(Object(DB_mysqli), NULL, -2, 16, (Array:2), "UPDATE civicrm_value_test_info_4 SET image_9 = WHERE entity_id = 203 [native...", "DB_Error", TRUE)
> #5 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/packages/DB/common.php(1907): PEAR->__call("raiseError", (Array:7))
> #6 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/packages/DB/mysqli.php(933): DB_common->raiseError(-2, NULL, NULL, "UPDATE civicrm_value_test_info_4 SET image_9 = WHERE entity_id = 203 [native...", "1064 ** You have an error in your SQL syntax; check the manual that correspon...")
> #7 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/packages/DB/mysqli.php(403): DB_mysqli->mysqliRaiseError()
> #8 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/packages/DB/common.php(1216): DB_mysqli->simpleQuery("UPDATE civicrm_value_test_info_4 SET image_9 = WHERE entity_id = 203")
> #9 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/packages/DB/DataObject.php(2415): DB_common->query("UPDATE civicrm_value_test_info_4 SET image_9 = WHERE entity_id = 203")
> #10 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/packages/DB/DataObject.php(1607): DB_DataObject->_query("UPDATE civicrm_value_test_info_4 SET image_9 = WHERE entity_id = 203")
> #11 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php(438): DB_DataObject->query("UPDATE civicrm_value_test_info_4 SET image_9 = WHERE entity_id = 203")
> #12 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php(1413): CRM_Core_DAO->query("UPDATE civicrm_value_test_info_4 SET image_9 = WHERE entity_id = 203", TRUE)
> #13 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Dedupe/Merger.php(1736): CRM_Core_DAO::executeQuery("UPDATE civicrm_value_test_info_4 SET image_9 = WHERE entity_id = 203")
> #14 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Contact/Form/Merge.php(289): CRM_Dedupe_Merger::moveAllBelongings("203", "204", (Array:10))
> #15 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php(489): CRM_Contact_Form_Merge->postProcess()
> #16 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/StateMachine.php(160): CRM_Core_Form->mainProcess()
> #17 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Next.php(61): CRM_Core_StateMachine->perform(Object(CRM_Contact_Form_Merge), "next", "Next")
> #18 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Next->perform(Object(CRM_Contact_Form_Merge), "next")
> #19 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contact_Form_Merge), "next")
> #20 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Controller.php(351): HTML_QuickForm_Page->handle("next")
> #21 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Utils/Wrapper.php(113): CRM_Core_Controller->run()
> #22 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(282): CRM_Utils_Wrapper->run("CRM_Contact_Form_Merge", "Merge Contact", (Array:0))
> #23 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:13))
> #24 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:3))
> #25 /srv/www/demo19/public_html/wp-content/plugins/civicrm/civicrm.php(1240): CRM_Core_Invoke::invoke((Array:3))
> #26 /srv/www/demo19/public_html/wp-includes/class-wp-hook.php(298): CiviCRM_For_WordPress->invoke("")
> #27 /srv/www/demo19/public_html/wp-includes/class-wp-hook.php(323): WP_Hook->apply_filters("", (Array:1))
> #28 /srv/www/demo19/public_html/wp-includes/plugin.php(453): WP_Hook->do_action((Array:1))
> #29 /srv/www/demo19/public_html/wp-admin/admin.php(222): do_action("toplevel_page_CiviCRM")5.15.0https://lab.civicrm.org/dev/core/-/issues/711Google+ references should be removed as it phases out2023-01-10T18:40:34ZphilmorbruGoogle+ references should be removed as it phases outNot a big deal, but as Google phases out Google+, visible references to it should be removed, especially from non-configurable features such as the "Tell a Friend" block for events.Not a big deal, but as Google phases out Google+, visible references to it should be removed, especially from non-configurable features such as the "Tell a Friend" block for events.5.23.0https://lab.civicrm.org/dev/core/-/issues/645Use site email domain in place of bounce email domain for automated messages2023-09-23T05:03:26ZnishantBUse site email domain in place of bounce email domain for automated messagesHello there!!
We encountered a scenario where we can whitelist only one email domain to send emails. We want to use email domain (eg: bouncedomain.com) for bounce processing and a different one (sitedomain.com) for rest of the emails wh...Hello there!!
We encountered a scenario where we can whitelist only one email domain to send emails. We want to use email domain (eg: bouncedomain.com) for bounce processing and a different one (sitedomain.com) for rest of the emails which works fine except that do-not-reply emails use the email domain set for bounce processing (bouncedomain.com) because of which AWS SES prevent those emails to be sent.
**Current behaviour:**
1. Regular emails: example@sitedomain.com
2. Bounce emails: bounce@bouncedomain.com
3. Do-not-reply emails: do-not-reply@bouncedomain.com
**Expected behaviour:**
1. Regular emails: example@sitedomain.com
2. Bounce emails: bounce@bouncedomain.com
3. Do-not-reply emails: do-not-reply@sitedomain.com
Is there already a configuration to set that or would it be a good idea to add a field where we can set the email domain for do-not-reply emails ?
Thanks!https://lab.civicrm.org/dev/core/-/issues/539Create a hook for custom relative date filters (CRM-16195)2024-03-25T15:18:49ZJonGoldCreate a hook for custom relative date filters (CRM-16195)To summarize: From the time relative date filters debuted in 4.2(?) until 4.7, each release added a number of relative date filters that one person needed and the rest of the world didn't. To prevent this happening forever, we moved rel...To summarize: From the time relative date filters debuted in 4.2(?) until 4.7, each release added a number of relative date filters that one person needed and the rest of the world didn't. To prevent this happening forever, we moved relative dates into an OptionGroup, and intended to give the ability to create new ones.
I worked on this last year but some cleanup PRs got stalled. They're all merged now so I'm submitting this.
While @eileen did work recently to support relative dates like "32 months in the past", it's still not possible to do relative dates like, "from 6 months ago to the end of this year", or "from Thanksgiving to Christmas". A former client of mine had reports that went from October to September, but this was NOT their fiscal year.
A simple hook facilitates the creation of custom relative date filters. I'll submit tests, but you can see an extension that uses it here: https://github.com/MegaphoneJon/com.megaphonetech.relativedatetest5.9JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/285Scheduled Reminders for Membership not being sent2019-07-12T03:35:58ZMickCScheduled Reminders for Membership not being sentMembership reminders are not being sent - 2 probable causes found:
1. civicrm_action_log records for the same reminder 1 year ago
2. Status Override is checked
When either of the above conditions exist, the reminder is not sent.
Whe...Membership reminders are not being sent - 2 probable causes found:
1. civicrm_action_log records for the same reminder 1 year ago
2. Status Override is checked
When either of the above conditions exist, the reminder is not sent.
When neither of the above conditions exist, the reminder is sent.
When corrective action is taken to remove past civicrm_action_log records and remove any override, the reminder is sent.
Environment:
* CiviCRM 4.7.29
* Extension 'Transactional Email' is installed5.17.0https://lab.civicrm.org/dev/core/-/issues/20Can't place a contribution widget on a Contribution Page2023-11-23T07:47:01ZJonGoldCan't place a contribution widget on a Contribution PageWhen you attempt to place a contribution widget on its own contribution page in the "Inroductory Message" section, you get the error:
`Illegal characters in input (potential scripting attack)`
I confirmed this is a regression by replica...When you attempt to place a contribution widget on its own contribution page in the "Inroductory Message" section, you get the error:
`Illegal characters in input (potential scripting attack)`
I confirmed this is a regression by replicating the problem on the Drupal demo site (4.7) and confirming it didn't exist ion the Joomla site (4.6). I'm pretty sure it didn't happen earlier in the 4.7 cycle either.https://lab.civicrm.org/dev/core/-/issues/5061New structure for getFields array in `.entityType.php`2024-03-25T20:55:29ZcolemanwNew structure for getFields array in `.entityType.php`Currently getFields reads from a `schema/xml` file with some wonky formatting. The plan in #4999 is to migrate those `.xml` files to `.entityType.php` files. So now we have a clean slate to decide how those files should be formatted.
No...Currently getFields reads from a `schema/xml` file with some wonky formatting. The plan in #4999 is to migrate those `.xml` files to `.entityType.php` files. So now we have a clean slate to decide how those files should be formatted.
Note: This will not affect the output of `DAO::fields()` or `APIv(3|4).getFields`, as we'll add a compatibility layer and tests to ensure those remain unchanged. But since we're replacing the underlying source of the data with something new, we get to clean that up.
Here are all the current keys in the schema/xml files, and what we plan to do with it in the new file. Many of the proposed changes would improve consistency with APIv4.getFields.
| Old key from `xml` | What to do | New key in `php` | Notes |
| ------ | ------ | ------ | ------ |
| `<name>` | ⚠️ index by | | Use name as array key, omit from array values |
| `<title>` | ✅ keep | `title` | |
| `<required>` | ✅ keep | `required` | |
| `<add>` | ✅ keep | `add` | |
| `<pseudoconstant>` | ✅ keep | `pseudoconstant` | snake_case all values in array |
| `<default>` | ✅ keep | `default` | |
| `<contactType>` | ✅ keep | `contact_type` | |
| `<deprecated>` | ✅ keep | `deprecated` | |
| `<readonly>` | ✅ keep | `readonly` | |
| `<serialize>` | ✅ keep | `serialize` | |
| `<localizable>` | ✅ keep | `localizable` | |
| `<usage>` | ✅ keep | `usage` | |
| `<component>` | ✅ keep | `component` | Ok, but it smells bad to have columns belonging to one component in another component's table :nose: (fixme for another day) |
| `<localize_context>` | ✅ keep | `localize_context` | Obscure property only used by 3 fields, but it's easier to keep it. |
| `<type>` | ⚠️ rename | `sql_type` | |
| `<crmType>` | ⚠️ rename | `data_type` | Historically this was inferred by `<type>` but a few fields explicitly declare `<crmType>` |
| `<uniqueName>` | ⚠️ deprecate | `unique_name` | We can't get rid of it yet but we can discourage it & stop indexing by it at every layer except `DAO::fields()` |
| `<uniqueTitle>` | ⚠️ deprecate | `unique_title` | Are title & attributes[label] not enough? |
| `<comment>` | ⚠️ rename | `description` | |
| `<html>` | ⚠️ rename/reorganize | `attributes` | `type` gets moved out (see `<html><type>` below), while `length` gets moved in as `maxlength` |
| `<html><type>` | ⚠️ move/rename | `input_type` | |
| `<length>` | ⚠️ rename | `attributes[maxlength]` | That seems better. |
| `<import>` | ⚠️ move | `usage[import]` | |
| `<export>` | ⚠️ move | `usage[export]` | |
| `<foreignKey>` | ⚠️ move+reformat | `entity_reference` | This tag is outside of `<fields>` in the xml but doesn't need to be. Let's move it into the getFields array. |
| `<dynamicForeignKey>` | ⚠️ move+reformat | `entity_reference` | Conceptually the same as above so can share the same name. |
| `<permission>` | ⚠️ reformat | `permission` | Convert `<or>` tags to nested array format used by `CRM_Core_Permisison::check()`. |
| `<drop>` | ❌ remove | | `<drop>` designates a field has been dropped, but in that case let's just [remove it](https://github.com/civicrm/civicrm-core/pull/18244) from the array as nothing else was being done with it. |
| `<rule>` | ❌ remove | | Unused as of [PR#29611](https://github.com/civicrm/civicrm-core/pull/29611). |
| `<headerPattern>` | ❌ remove | | Unused as of [PR#29612](https://github.com/civicrm/civicrm-core/pull/29612). |
| `<dataPattern>` | ❌ remove | | Appears to be unused in `universe`. |
| `<fulltext/>` | ❌ remove | | Apparently unused. Ignored by GenCode when writing DAOs. |https://lab.civicrm.org/dev/core/-/issues/5060Automated reminder to people that didn't subcribe to groups they applied subs...2024-03-14T22:45:20Znikola.mladenovicAutomated reminder to people that didn't subcribe to groups they applied subscription forOverview
----------------------------------------
Subscribing for newsletter usually ends up as a one way street, if they want to have subscribers and be under wing of GDPR. If the user doesn't confirm their subscription, they would eith...Overview
----------------------------------------
Subscribing for newsletter usually ends up as a one way street, if they want to have subscribers and be under wing of GDPR. If the user doesn't confirm their subscription, they would either have to find original email or resubscribe if they cant find it, but usually users just forget they did subscribe.
Recommended improvement was discussed on Mattermost to check if such feature existed in civicrm and few users did raise concern and that they would like to have this feature request:
[Mattermost chat](https://chat.civicrm.org/civicrm/pl/bg6x9u7qmf8fdkwn8tz4o9ft1r )
Current behaviour
----------------------------------------
Subscribing to newsletter only sends email as user applies for newsletter
Proposed behaviour
----------------------------------------
Scheduled job for example, which would check if there are any users which are pending for some groups, check the date they applied and then send another nudge for user to join in. This feature should be limited to only once per fresh request for all pending users. Proposal for after how much this automated schedueld job would contact users should be a week, 2 weeks, month, 2 months, 3 months.
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/4941Number field input validation does not respect decimal separator setting (eve...2024-02-12T17:14:12ZDetlev SieberNumber field input validation does not respect decimal separator setting (event custom field)## Overview
This is a variant of https://lab.civicrm.org/dev/core/-/issues/4154, regarding custom fields for events of type _This iPlease describe your problem or bug in detail._
_If you have already posted on __https://civicrm.stackex...## Overview
This is a variant of https://lab.civicrm.org/dev/core/-/issues/4154, regarding custom fields for events of type _This iPlease describe your problem or bug in detail._
_If you have already posted on __https://civicrm.stackexchange.com__ or __https://chat.civicrm.org__, please include the link to that conversation._
## Reproduction steps
1. Under Administer \> Localization \> Languages, Currency, Locations, set "Thousands Separator" to "." (dot) and "Decimal Delimiter" to "," (comma).
2. Create a custom field extending Events. Data type: Number.
3. Edit an existing event (or: add a new event). In the number field, enter a number that includes a comma, such as "1,5".
4. Press Save: nothing happens
5. Reload page: Error message appears "**Error One of parameters (value: 1,5) is not of the type Float**"
## Current behaviour
Validation fails with the error message "**Error One of parameters (value: 1,5) is not of the type Float**"
## Expected behaviour
Validation should not fail for decimal numbers with decimal separator ","
## Environment information
* **CiviCRM:** 5.69.3
* **PHP:** 7,4, 8.1
* **CMS:** Drupal, WordPress
## Comments
This bug was fixed for some fields with #4154 (https://github.com/civicrm/civicrm-core/pull/28369)
Also, I believe this is some kind of regression, because in a system of one of my clients, this did work \~15 months ago. However, tbh I have no clear idea when it broke. (and still, it cannot completely excluded that the existing data was entered with decimal separator ".")5.71.0https://lab.civicrm.org/dev/core/-/issues/4915Sending an invoice per email goes to primary address, not to billing2024-02-09T23:08:39ZMariaVSending an invoice per email goes to primary address, not to billingI have found this post on StackExchange:
https://civicrm.stackexchange.com/questions/9094/sending-an-invoice-per-email-goes-to-primary-address-not-to-billing
I tested on CiviCRM 5.68.1 and it seems that CiviCRM still only sends the invo...I have found this post on StackExchange:
https://civicrm.stackexchange.com/questions/9094/sending-an-invoice-per-email-goes-to-primary-address-not-to-billing
I tested on CiviCRM 5.68.1 and it seems that CiviCRM still only sends the invoice to the primary address.
What do you think about a setting 'send invoice email to Billing if it exists, otherwise send it to Primary'?
The setting could be optional so that nothing changes for users who want to keep it as it is.
Or is there any knowing extension already that I could not find?
Thanks in advance!https://lab.civicrm.org/dev/core/-/issues/4812Drop php 7.3 in 5.70 after the 5.69 ESR release2023-12-13T17:32:03ZeileenDrop php 7.3 in 5.70 after the 5.69 ESR releaseIt has been a year since we dropped php 7.2 so we are staying a similar amount behind the php support schedule
https://lab.civicrm.org/dev/core/-/issues/3991It has been a year since we dropped php 7.2 so we are staying a similar amount behind the php support schedule
https://lab.civicrm.org/dev/core/-/issues/3991https://lab.civicrm.org/dev/core/-/issues/4725Proposal: Don't include "I am contributing on behalf of an organization" on c...2023-11-23T07:51:08ZlarsssandergreenProposal: Don't include "I am contributing on behalf of an organization" on contribution pages when the current contact is an organizationIf an organization receives a personalized link to a contribution page, the user may not realize they are already using the form as an organization (especially because the billing details will show their first and last name if they used ...If an organization receives a personalized link to a contribution page, the user may not realize they are already using the form as an organization (especially because the billing details will show their first and last name if they used them in the past). If they then select "I am contributing on behalf of an organization", they will get a error: `Payment Processor Error message :Invalid Relationship .`
This is because we are attempting to create a new organization with an employer of relationship to the current contact, which fails when the current contact is an organization as this is not allowed.
I think the simplest and most logical way to fix this is simply to not include the on behalf of option on the contribution page if the current contact is an organization and instead show the organization profile by default. If the user wants to contribute on behalf of the current contact organization, then this is fine. If they are contributing on behalf of a different organization or as an individual, they should click the not you link.https://lab.civicrm.org/dev/core/-/issues/4641CiviMail - Add support for List-Unsubscribe=One-Click2024-02-21T10:44:20ZtottenCiviMail - Add support for List-Unsubscribe=One-ClickOverview
----------------------------------------
There was a [recent announcement](https://blog.google/products/gmail/gmail-security-authentication-spam-protection/) that Gmail would begin [requiring `List-Unsubscribe=One-Click`](https...Overview
----------------------------------------
There was a [recent announcement](https://blog.google/products/gmail/gmail-security-authentication-spam-protection/) that Gmail would begin [requiring `List-Unsubscribe=One-Click`](https://support.google.com/mail/answer/81126) from mailing lists circa Feb 2024. The relevant protocols are described by:
* https://datatracker.ietf.org/doc/html/rfc2369
* https://datatracker.ietf.org/doc/html/rfc8058
Example use-case
----------------------------------------
1. Create a "New Mailing"
2. Send it
3. As a recipient, view the headers of the message
4. Check the content of `List-Unsubscribe` and `List-Unsubscribe-Post`
Current behavior
----------------------------------------
CiviMail generates one header:
```
List-Unsubscribe: <mailto:u.1.1.rrpjscmw7whtdg4e@example.org>
```
Proposed behavior
----------------------------------------
CiviMail generates two headers:
```
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.org/civicrm/mailing/oneclick?jid=1&qid=1&h=rrpjscmw7whtdg4e>
```5.70.0https://lab.civicrm.org/dev/core/-/issues/4639New approaches to ACL caching (and smart groups?)2024-02-16T16:22:42ZJonGoldNew approaches to ACL caching (and smart groups?)A lot of work has gone into improving the efficiency and frequency of ACL calculation. Let's attack the performance of writing the results to db?
I have a site where contacts change frequently, and ACLed users need to wait for 100,000 ...A lot of work has gone into improving the efficiency and frequency of ACL calculation. Let's attack the performance of writing the results to db?
I have a site where contacts change frequently, and ACLed users need to wait for 100,000 records to be written each time. Disabling opportunistic flushes only partly mitigates the issue.
Here are some ideas:
* Could we move ACL/smart group caching into `\Civi::cache`? Then we could use Redis etc.
* Instead of truncating and writing all contacts - what if we only `INSERT` and `DELETE` changes from the existing cache?
* When a contact's edited, could we just calculate cache for that contact? For any ACL based on a static group, this should be trivial. Even with smart groups/custom code - are there scenarios where we'd ever need to calculate ACLs for anyone but the changed contact and all their related contacts?https://lab.civicrm.org/dev/core/-/issues/4627Proposal: Membership type label2023-10-01T19:23:57Zmattwiremjw@mjwconsult.co.ukProposal: Membership type labelThe membership type table only has "name" and you cannot specify a separate label/title for display. This makes it problematic for portability/import/export as well as translation.
Proposal: Add new field "label" to MembershipType which...The membership type table only has "name" and you cannot specify a separate label/title for display. This makes it problematic for portability/import/export as well as translation.
Proposal: Add new field "label" to MembershipType which is used for display instead of the name.https://lab.civicrm.org/dev/core/-/issues/4614Search Displays: Let booleans be displayed as "instant-save" checkboxes2023-09-26T12:18:30ZnoahSearch Displays: Let booleans be displayed as "instant-save" checkboxesIn SearchKit, turning on "inline edit" for a boolean field results in a UI that involves three clicks to toggle the field value:
1. click the field to enter edit mode
2. click "Yes" or "No"
3. click the submit button
A much smoother UI...In SearchKit, turning on "inline edit" for a boolean field results in a UI that involves three clicks to toggle the field value:
1. click the field to enter edit mode
2. click "Yes" or "No"
3. click the submit button
A much smoother UI (one click instead of three) would be a single checkbox that saves immediately when toggled.https://lab.civicrm.org/dev/core/-/issues/4576Proposal: Unique Identifier/Field references for input fields in Form Builder2023-09-14T13:23:58Zsimon.hermannProposal: Unique Identifier/Field references for input fields in Form Builder## Overview
We propose to add a way to reference fields via an unique identifier in order to use the field value elsewhere on the field, e.g. the success page proposed in issue #4569 or on another page of a multi-page form.
Proposed use...## Overview
We propose to add a way to reference fields via an unique identifier in order to use the field value elsewhere on the field, e.g. the success page proposed in issue #4569 or on another page of a multi-page form.
Proposed uses of this feature are:
* setting the value of another field
* setting input fields in a form processor
The field reference should be automatically generated when creating a new field but be editable, if needed.
## Use case
Donation form:
* set default value for account holder based on field values “first name”, “last name”
* show chosen amount of donation on the next page
* use “first name” and “last name” as well as “donation amount” for success page to confirm donation and say thank you
## Current behavior
Not implemented
## Proposed behavior
Every field has an auto-generated field reference. Using the field reference, the field value can be shown on the form.