CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-06-11T14:57:24Zhttps://lab.civicrm.org/dev/core/-/issues/3626"New Mailing" prematurely schedules blasts and old mailings can be resent2022-06-11T14:57:24Ztotten"New Mailing" prematurely schedules blasts and old mailings can be resent## Steps to reproduce
* Open a MySQL console where you can monitor the content of `civicrm_mailing_job`.
* Make a `Mailing => New Mailing`
* Fill in name/subject/recipients/body on the first page.
* Go to the second page
* __Observe__:...## Steps to reproduce
* Open a MySQL console where you can monitor the content of `civicrm_mailing_job`.
* Make a `Mailing => New Mailing`
* Fill in name/subject/recipients/body on the first page.
* Go to the second page
* __Observe__: In the MySQL console, observe that there are no jobs scheduled for this mailing.
* Set a delivery time. *But don't hit `Submit`*. (You're just thinking about delivery... but not actually sending yet.)
* Open an HTML or plain-text preview.
* __Observe__: In the MySQL console, observe that there is now a scheduled job for this mailing.
To resend an old mailing:
* Any mailing will be queued for redelivery if a user with permission to use CiviMail visits URL `civicrm/a/#/mailing/<MAILING_ID>` (we've seen several users end up on this URL, apparently via browser history)
## Mitigating factors
The only way I've found to trigger the premature mailing (so far) has been to explicitly set the delivery date. It's quite bad to be sending prematurely, but I think it's taken a while to recognize because the delivery date is *the last thing* in the entire process -- *most of the time*, one doesn't set the delivery date until everything else has been settled. This probably means the real-world impact hasn't been as bad one might fear.
## Context
This appears to be a regression in 4.7.31. Related PRs:
* https://issues.civicrm.org/jira/browse/CRM-21260
* https://issues.civicrm.org/jira/browse/CRM-21316
* https://issues.civicrm.org/jira/browse/CRM-21749
* https://github.com/civicrm/civicrm-core/pull/11142/
* https://github.com/civicrm/civicrm-core/pull/11653/
## Solution
* Because the fix is in javascript, resolving this bug requires flushing CiviCRM caches (`cv flush` command) after upgrading to CiviCRM 5.0.05.0.0https://lab.civicrm.org/dev/core/-/issues/3554On 'New Mailing' review page, it doesn't show recipients count2022-06-11T14:50:56ZMonish DebOn 'New Mailing' review page, it doesn't show recipients countSimply visit the second page of `New Mailing` and you will notice that 'Recipients' section has an inappropriate message instead of recipient count.
## Context
This appears to be a regression in 4.7.31. Related PR - https://github.com/...Simply visit the second page of `New Mailing` and you will notice that 'Recipients' section has an inappropriate message instead of recipient count.
## Context
This appears to be a regression in 4.7.31. Related PR - https://github.com/civicrm/civicrm-core/pull/110915.0.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3549On multilingual mode, choosing mailing group doesn't affect recipient count a...2022-06-11T14:50:42ZMonish DebOn multilingual mode, choosing mailing group doesn't affect recipient count and list## Steps to reproduce
1. Enable multilingual mode
2. Go to `Mailing => New Mailing`
3. Choose one or more mailing group.
__Observe__: The recipient count doesn't affect
## Context
This appears to be a regression in 4.7.31. Related...## Steps to reproduce
1. Enable multilingual mode
2. Go to `Mailing => New Mailing`
3. Choose one or more mailing group.
__Observe__: The recipient count doesn't affect
## Context
This appears to be a regression in 4.7.31. Related PRs:
* https://issues.civicrm.org/jira/browse/CRM-21260
* https://issues.civicrm.org/jira/browse/CRM-21316
* https://issues.civicrm.org/jira/browse/CRM-21749
* https://github.com/civicrm/civicrm-core/pull/11142/
* https://github.com/civicrm/civicrm-core/pull/11653/5.0.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/42On multilingual mode, choosing mailing group doesn't affect recipient count a...2018-03-31T09:48:01ZMonish DebOn multilingual mode, choosing mailing group doesn't affect recipient count and list## Steps to reproduce
1. Enable multilingual mode
2. Go to `Mailing => New Mailing`
3. Choose one or more mailing group.
__Observe__: The recipient count doesn't affect
## Context
This appears to be a regression in 4.7.31. Related...## Steps to reproduce
1. Enable multilingual mode
2. Go to `Mailing => New Mailing`
3. Choose one or more mailing group.
__Observe__: The recipient count doesn't affect
## Context
This appears to be a regression in 4.7.31. Related PRs:
* https://issues.civicrm.org/jira/browse/CRM-21260
* https://issues.civicrm.org/jira/browse/CRM-21316
* https://issues.civicrm.org/jira/browse/CRM-21749
* https://github.com/civicrm/civicrm-core/pull/11142/
* https://github.com/civicrm/civicrm-core/pull/11653/5.0.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/12Improvement: for crmUiWizard-driven workflows, scroll back to top between steps2023-06-23T17:54:21ZginkgofjgImprovement: for crmUiWizard-driven workflows, scroll back to top between stepsSome "steps" in a wizard are fairly long and require scrolling to reach all the required fields. See the CiviMail wizard (civicrm/a/#/mailing) for example.
Differences in height between the steps can make clicking the buttons that contr...Some "steps" in a wizard are fairly long and require scrolling to reach all the required fields. See the CiviMail wizard (civicrm/a/#/mailing) for example.
Differences in height between the steps can make clicking the buttons that control the workflow (back, forward, etc.) at the bottom of the wizard a jarring experience. Sometimes the next step is significantly shorter than the previous one, and the user is left looking at white space. Sometimes the next step is very similar to the previous step, and it is unclear that anything occurred after the user's click because the user's view hasn't changed.
In any case, a better user experience would be to move the user to the top of the wizard at each transition.5.0.0ginkgofjgginkgofjghttps://lab.civicrm.org/dev/core/-/issues/3582Using ACL to restrict mailing recipients leads to fatal error2022-06-11T14:54:50ZMonish DebUsing ACL to restrict mailing recipients leads to fatal errorSteps to replicate:
1. Assign an ACL permission for one or more contacts
2. Compose a mailing and select a recipient group. Ensure that those contacts are included in that group
3. Submit and Send Mailing immediately
Result into fatal ...Steps to replicate:
1. Assign an ACL permission for one or more contacts
2. Compose a mailing and select a recipient group. Ensure that those contacts are included in that group
3. Submit and Send Mailing immediately
Result into fatal error - https://pastebin.com/aMa2KYy0
## Context
This appears to be a regression in 4.7.31. Related PRs:
* https://issues.civicrm.org/jira/browse/CRM-21260
* https://github.com/civicrm/civicrm-core/pull/11142/
5.1.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/68DB Error on 'Find Participant' page when MySQL FULL_GROUP_BY_MODE is enabled2018-05-17T11:38:27ZMonish DebDB Error on 'Find Participant' page when MySQL FULL_GROUP_BY_MODE is enabledSteps to replicate:
1. Ensure that FULL_GROUP_BY_MODE is enabled in MySQL
2. Go to 'Find Participant' search form and do a simple search
This leads to
DB Error - https://pastebin.com/jxbaAbpSSteps to replicate:
1. Ensure that FULL_GROUP_BY_MODE is enabled in MySQL
2. Go to 'Find Participant' search form and do a simple search
This leads to
DB Error - https://pastebin.com/jxbaAbpS5.1.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/25Wrap split_jobs in a transaction2023-06-23T17:54:22ZseamusleeWrap split_jobs in a transactionThe split_jobs function should be wrapped in a MySQL transaction to ensure that no mailing can be delivered whilst we are still trying to populate the mailing_job table with all the necessary jobs.The split_jobs function should be wrapped in a MySQL transaction to ensure that no mailing can be delivered whilst we are still trying to populate the mailing_job table with all the necessary jobs.5.1.0seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/119Notice error2018-11-09T22:11:44ZJoeMurrayNotice errorhttp://dmaster.demo.civicrm.org/civicrm/contact/map/event?eid=3&reset=1
Notice: Undefined variable: is_public in CRM_Contact_Form_Task_Map_Event->preProcess() (line 54 of /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Contact/...http://dmaster.demo.civicrm.org/civicrm/contact/map/event?eid=3&reset=1
Notice: Undefined variable: is_public in CRM_Contact_Form_Task_Map_Event->preProcess() (line 54 of /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Contact/Form/Task/Map/Event.php).5.8Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/907[php 7.2 support] deprecation notice in cli.clas2019-04-30T09:24:54Zeileen[php 7.2 support] deprecation notice in cli.clasThis won't cause any issues but gives a deprecation notice & needs fixing
PHP Deprecated: The each() function is deprecated. This message will be suppressed on further calls in
/home/kaiva276/menscommission.in/wp-content/plugins/civi...This won't cause any issues but gives a deprecation notice & needs fixing
PHP Deprecated: The each() function is deprecated. This message will be suppressed on further calls in
/home/kaiva276/menscommission.in/wp-content/plugins/civicrm/civicrm/bin/cli.class.php
(row appears to have changed as that is 5.10)
https://github.com/civicrm/civicrm-core/blob/62bf1e4237e6332b29aace76c1c5fbaf8a52bdff/bin/cli.class.php#L1495.13.0https://lab.civicrm.org/dev/core/-/issues/706Edit contribution : wrong decimal separator on total_amount for participant(s)2019-03-18T01:07:09ZwouterhEdit contribution : wrong decimal separator on total_amount for participant(s)When I want to register a participant payment, I can not save it because the amount is not in a valid format. There should be a comma instead of a point sign.
This does work for membership payments.![problem_participant_contribution](/u...When I want to register a participant payment, I can not save it because the amount is not in a valid format. There should be a comma instead of a point sign.
This does work for membership payments.![problem_participant_contribution](/uploads/40e1cc7f95b63593d554a5cda946db14/problem_participant_contribution.png)5.13.0https://lab.civicrm.org/dev/core/-/issues/1226Smart groups: Relative date filters saved incorrectly2019-09-03T06:50:14ZPradeep Nayakpradpnayak@gmail.comSmart groups: Relative date filters saved incorrectly(*Original title: "Regression: Smart group with Change log criteria is not saved."*)
If you create a smart group which uses a relative date filter (e.g. "Last 60 days" or "This calendar current year"), the relative date filter is not sa...(*Original title: "Regression: Smart group with Change log criteria is not saved."*)
If you create a smart group which uses a relative date filter (e.g. "Last 60 days" or "This calendar current year"), the relative date filter is not saved correctly.
This issue entails two aspects:
1. (*Code update in 5.16.4*) Fix the code so that smart groups are properly saved
2. (*Data cleanup; case-by-case*) Identify any smart-groups which were created or edited in the past month (5.16.x). Determine if they should be updated to use a relative date filter.
The following fields are believed to affected:
* `log_date_relative`
* `pledge_payment_date_relative`
* `pledge_start_date_relative`
* `pledge_end_date_relative`
* `pledge_create_date_relative`
* `member_join_date_relative`
* `member_start_date_relative`
* `member_end_date_relative`
* `birth_date_relative`
* `deceased_date_relative`
* `mailing_date_relative`
* `relation_date_relative`
* `relation_start_date_relative`
* `relation_end_date_relative`
* `relation_action_date_relative`
* `contribution_recur_start_date_relative`
* `contribution_recur_next_sched_contribution_date_relative`
* `contribution_recur_cancel_date_relative`
* `contribution_recur_end_date_relative`
* `contribution_recur_create_date_relative`
* `contribution_recur_modified_date_relative`
* `contribution_recur_failure_retry_date_relative`5.17.0Pradeep Nayakpradpnayak@gmail.comPradeep Nayakpradpnayak@gmail.comhttps://lab.civicrm.org/dev/core/-/issues/1120Export help info does not match code2019-07-16T20:03:55ZeileenExport help info does not match codeIn the export screen we see that the postal greeting or addressee greeting can change if more than 2 contacts are merged
![Screen_Shot_2019-07-16_at_9.32.04_AM](/uploads/871c946c283258e8e4c6e68bae72e1d7/Screen_Shot_2019-07-16_at_9.32.04...In the export screen we see that the postal greeting or addressee greeting can change if more than 2 contacts are merged
![Screen_Shot_2019-07-16_at_9.32.04_AM](/uploads/871c946c283258e8e4c6e68bae72e1d7/Screen_Shot_2019-07-16_at_9.32.04_AM.png)
In the code the rules are that 2 or more contacts being merged use the rules (ie if contacts are merged then use the rules). (There is some mickey mouse separate handling where it seems the code attempts to only use the 'other' logic for 2 or more
I can't see why you wouldn't use the merge string for any merges - which would simplify the code a lot too
@lcdweb @colemanw thoughts - can we tweak the above to '(when merging contacts to one row)' & clean up the code to just do that (without extra code that with more or less success attempts to do ? something ? when there are only 2 & use the merge string where there is more than 2
I *think* the intent might have been that you could choose different behaviour for many vs just 2 but in practice you can't actually select that in the UI5.17.0https://lab.civicrm.org/dev/core/-/issues/1073Performance : Expose some important smarty configuration variables outside th...2021-03-29T14:14:27ZVangelisPPerformance : Expose some important smarty configuration variables outside the smarty classWhile working with multiple "complex" civicrm sites on dedicated server instances, I've noticed that even though the database was highly optimized, all sites were having some sort of overhead of nearly 1.5-2 seconds before rendering the...While working with multiple "complex" civicrm sites on dedicated server instances, I've noticed that even though the database was highly optimized, all sites were having some sort of overhead of nearly 1.5-2 seconds before rendering the results. That is on the contact display page, on search, advanced search and so on.
Added Redis caching to CiviCRM, helped with a bit of small improvement but again, the delay was there.
Digging deeper with XHProf, I've found out that for every page that was loading, Smarty was checking if the templates needed recompiling.
Long story short, inside the /packages/Smarty/Smarty.class.php there's a variable that is `true` by default:
`var $compile_check = true;`
Description is the following:
> This tells Smarty whether to check for recompiling or not. Recompiling does not need to happen unless a template or config file is changed. Typically you enable this during development, and disable for production.
Disabling this in production, i did see a big improvement in terms of speed, as Smarty is now being instructed not scan every time if it needs to recompile the templates.
My suggestion would be to expose that variable (along with `$caching`) as a constant so that for example we can add it to `settings.php` as 'false' in production environments.
I could provide a patch (if needed) that does that.
PS. "complex" = a CiviCRM instance with many extensions and many tpl injections through custom extensions.5.17.0https://lab.civicrm.org/dev/core/-/issues/949Export table field size is inadequate for State/Province data values2019-08-06T20:35:08ZorigamiusaExport table field size is inadequate for State/Province data valuesExporting a custom data field of type State/Province crashes with a db error "Data too long for column" if the State/Province has a long name (example: no crash with "Massachusetts", but crash with "District of Columbia"). The temporary ...Exporting a custom data field of type State/Province crashes with a db error "Data too long for column" if the State/Province has a long name (example: no crash with "Massachusetts", but crash with "District of Columbia"). The temporary table is created with a column size of varchar(16), presumably because the State/Province key is stored as a LONG; but the exported quantity is the value, which could be of arbitrary length (and certainly includes examples longer than 16 characters in normal usage).
This appears to be a similar issue to https://lab.civicrm.org/dev/core/issues/181 and https://lab.civicrm.org/dev/core/issues/877.5.17.0https://lab.civicrm.org/dev/core/-/issues/5026Price Sets: total calculation wrong it decimal separator is different than "."2024-02-26T20:12:20ZmasettoPrice Sets: total calculation wrong it decimal separator is different than "."If I use price sets, when the decimal separator is "," and not "." the calculation of the total does not consider decimals.
Tested on dmaster:
![image](/uploads/beefe52fdfaeb4ff4ec06729528cfd25/image.png)
![image](/uploads/72de7f9df4...If I use price sets, when the decimal separator is "," and not "." the calculation of the total does not consider decimals.
Tested on dmaster:
![image](/uploads/beefe52fdfaeb4ff4ec06729528cfd25/image.png)
![image](/uploads/72de7f9df42afb6097e0e287c817c496/image.png)5.72.0https://lab.civicrm.org/dev/core/-/issues/5021Edit message templates permission not working as expected2024-03-15T20:38:58Za.valllloveraEdit message templates permission not working as expected## Overview
Users without the `CiviCRM: edit message templates` permision, can update Templates via the `Print/Merge Document`.
## Reproduction steps
1. Assign a role without the `CiviCRM: edit message templates` permision to an **Use...## Overview
Users without the `CiviCRM: edit message templates` permision, can update Templates via the `Print/Merge Document`.
## Reproduction steps
1. Assign a role without the `CiviCRM: edit message templates` permision to an **User**
2. Log in with that **User** and get to any **Contact**.
3. Create a **Print/Merge Document** Activity.
4. Use an already created **Template**.
5. Modify it in the Document Body
6. It will appear the Check box Update and if the User select it, it will **Update** the Template
![image.png](/uploads/4c57e46478fd7ad9df9de98cd3b4104b/image.png)
## Expected behaviour
The checkbox that let you Update a Template shouldn't appear if the User doesn't have the `CiviCRM: edit message templates` permision.
## Environment information
* **CiviCRM:** _5.69.1_
* **CMS:** _Drupal 10_5.73.0https://lab.civicrm.org/dev/core/-/issues/4954Upgrade to Smarty4....2024-03-15T21:05:34ZeileenUpgrade to Smarty4....Now that we have upgraded many sites to Smarty3 & seem close to ironing out the issues I had a go at Smarty4 and was able to get it working. The extra fixes were entirely in our core compatibility layer so the challenges of moving a site...Now that we have upgraded many sites to Smarty3 & seem close to ironing out the issues I had a go at Smarty4 and was able to get it working. The extra fixes were entirely in our core compatibility layer so the challenges of moving a site from Smarty2 to Smarty4 are now equivalent to moving to Smarty3.
https://smarty-php.github.io/smarty/5.x/upgrading/#removed-php-constants
One annoying thing we did was name our Smarty mixin & the define in a version specific way. In fact there is nothing v2 specific about our mixin and the methodology of defining ` CIVICRM_SMARTY3_AUTOLOAD_PATH` works for Smarty4 as well as it does for Smarty3. If it wasn't for those naming issues I would recommend we simply replace the contents of packages/smarty3 with the Smarty 4 library.
However, given where we are I recommend we
1) merge Smarty4 into packages here https://github.com/civicrm/civicrm-packages/pull/380
2) add a new define `CIVICRM_SMARTY_AUTOLOAD_PATH` - respect it but fall back to `CIVICRM_SMARTY3_AUTOLOAD_PATH` if present
3) update our demo sites / build sites etc to Smarty4
4) update all our messaging to encourage people to use Smarty4 not 3 (but if they have already switched to 3 don't further message as being off Smarty2 is enough to flush out any extension or issues that would impede our medium term plans to put Smarty4 in vendor & stop shipping Smarty3
Note that Smarty4 hard-fails on `{php}` tags in tpls whereas Smarty3 has a backwards compatibility layer that would have supported it, had we chosen to enable it, which we didn't.5.72.0https://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/4913[PHP 8.2] mail wrongly formatted2024-01-18T02:51:14Zaydunsaidan.saunders@squiffle.uk[PHP 8.2] mail wrongly formattedOverview
----------------------------------------
When running CiviCRM on PHP8 on Linux, email can be badly formatted.
See https://civicrm.stackexchange.com/q/45782/225 for a description, analysis and fix.
Current behaviour
----------...Overview
----------------------------------------
When running CiviCRM on PHP8 on Linux, email can be badly formatted.
See https://civicrm.stackexchange.com/q/45782/225 for a description, analysis and fix.
Current behaviour
----------------------------------------
Some email headers are not correctly formatted, including the Content-Type boundary specifier. The boundary is ignored and the mail is displayed wrongly.
Solution
--------
The problem is in the Pear Mail library. ~~A [fix](https://github.com/pear/Mail/pull/24) was committed in November for the [2.0.0 release](https://github.com/pear/Mail/issues/33) but this has not yet been released.~~
Environment information
----------------------------------------
* __CiviCRM:__ _Master_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _8.2_5.71.0