CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-03-26T10:22:28Zhttps://lab.civicrm.org/dev/core/-/issues/2Display Inbound Email: linefeed suppressed2024-03-26T10:22:28ZDetlev SieberDisplay Inbound Email: linefeed suppressedWhen viewing an activity of type inbound email, the text is displayed in "details". However, althought the database contains it in plain text and html, it is displayed as plain text without LFs, what makes it hardly readable.When viewing an activity of type inbound email, the text is displayed in "details". However, althought the database contains it in plain text and html, it is displayed as plain text without LFs, what makes it hardly readable.4.7.31https://lab.civicrm.org/dev/core/-/issues/1Allow to search for "in progress" contributions2024-03-01T16:29:50ZxavierAllow to search for "in progress" contributionsThe search is hiding the status "in progress". However, some payment processor do use this status (eg the sepa one), so it is in effect hiding contributions, and therefore makes the users very sad and confused
Fix:
allow to search on s...The search is hiding the status "in progress". However, some payment processor do use this status (eg the sepa one), so it is in effect hiding contributions, and therefore makes the users very sad and confused
Fix:
allow to search on status "in progress". Worse case scenario, no contributions have this status, and it will return an empty list4.7.31https://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/924Advanced search: activity tags should use select22019-06-05T15:24:08ZMonish DebAdvanced search: activity tags should use select2Steps to replicate:
1. add a tag and flag it as available to activities.
2. load advanced search and expand the activity panel.
Note that the activity field is the old format -- checkbox list. It should use select2. See the case panel ...Steps to replicate:
1. add a tag and flag it as available to activities.
2. load advanced search and expand the activity panel.
Note that the activity field is the old format -- checkbox list. It should use select2. See the case panel for comparison.5.12.0Monish DebMonish Debhttps://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/1104Make admin panels hookable2019-08-01T04:07:14ZyashodhaMake admin panels hookableMake it easy to show/hide items on administer screen.Make it easy to show/hide items on administer screen.5.17.0yashodhayashodhahttps://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/987Issue with alterReportVars hook invoke2019-08-01T04:07:14ZsushantpIssue with alterReportVars hook invokeCurrently alterReportVars hook is invoked after grand total and section total calculations.
When alterReportVars used for altering any values in report rows , calculations does not take that into
consideration.
alterReportVars hook ...Currently alterReportVars hook is invoked after grand total and section total calculations.
When alterReportVars used for altering any values in report rows , calculations does not take that into
consideration.
alterReportVars hook should invoked before grand total and section total calculations.5.17.0https://lab.civicrm.org/dev/core/-/issues/91Prevent un-workable searches in search builder (was search builder improvements)2018-05-03T23:37:58ZMonish DebPrevent un-workable searches in search builder (was search builder improvements)Earlier there was a requirement where we need to remove specific MySQL operators which are not valid for specific data type e.g. String type doesn't work with >, <, <= and >= operators. And here's the fix https://github.com/civicrm/civic...Earlier there was a requirement where we need to remove specific MySQL operators which are not valid for specific data type e.g. String type doesn't work with >, <, <= and >= operators. And here's the fix https://github.com/civicrm/civicrm-core/commit/759094bdfa40531e4ec0cf0a644d9edd6b9247cf done earlier as per which it is fetching all columns which are String type and passing them into a separate JSON string identified as ```stringFields``` and another formatted list of valid string operators as ```stringOperators```. Similarly to identify date fields and to do a specific operation on such fields we are passing another variable ```dateFields```. These JSON object in JS are later used to specific operations. Now on the other hand, recently, I encountered another issue where the Boolean type columns don't work with IS EMPTY/IS NOT EMPTY operator and eventually leads to DB syntax error. So if I follow the same approach I need to assign another JSON string, which won't be an ideal fix. This lead me to do following 3 changes to improve the code:
1. Assign a single list of all data columns which are either Boolean, String or Date (as currently, these are the only kind that needs attention)
2. Use this list (as ```fieldTypes```) in JS to filter the operator or do field specific operations like covert a input search field to datepicker if the chosen search field is date kind.
3. Reduce list of variable assignment.5.2.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/1371E Notice 'info' Extension.php:248 -> When installing via cv2019-11-08T01:28:44Zluke.stewartE Notice 'info' Extension.php:248 -> When installing via cvOn a wordpress install running 5.19.beta1 I get the following E Notice when running cv ext:download
`
Notice: Undefined variable: info in /wp-content/plugins/civicrm/civicrm/api/v3/Extension.php on line 248
`
This looks like it ...On a wordpress install running 5.19.beta1 I get the following E Notice when running cv ext:download
`
Notice: Undefined variable: info in /wp-content/plugins/civicrm/civicrm/api/v3/Extension.php on line 248
`
This looks like it was introduced in https://github.com/civicrm/civicrm-core/commit/19ec0aa50bafbe5748fba71a7d94b2e891051717
Which introduces a new parameter to the checkRequirements function, which defaults to NULL.
My reading of this is that the new Check Requirements functionality is only designed to work if executed via the UI. However, it looks like the info parameter is only populated if the 'url' param doesn't exist. If it does exist then the info parameter is not created.
As long as the UI doesn't call this function with a url param then this should be fine, but I'm wondering if it makes sense to populate the $info variable if a url is passed as a parameter to civicrm_api3_extension_download, a quick fix for the E Notice would be to simply initialise this variable to NULL.5.19.1https://lab.civicrm.org/dev/core/-/issues/5008[Enhancement] ContributionRecur edit activity should include more details2024-03-05T15:29:46ZElliott Eggleston[Enhancement] ContributionRecur edit activity should include more detailsOverview
----------------------------------------
When one edits a recurring contribution an activity is saved saying which user edited it. If the amount or the number of installments has been changed, that is included in the activity de...Overview
----------------------------------------
When one edits a recurring contribution an activity is saved saying which user edited it. If the amount or the number of installments has been changed, that is included in the activity details. However, no other changes are included (and the ContributionRecur row changes from log_contribution_recur are not in the contact change log), so it's impossible to tell in the UI if someone changed e.g. the next scheduled contribution date or the cycle day.
Example use-case
----------------------------------------
1. Edit a ContributionRecur
2. Look at the activity tab, and see all the changes you made
Current behaviour
----------------------------------------
Only changes to number of installments and amount are listed in the activity details
Proposed behaviour
----------------------------------------
Changes to other subscription properties are also listed in the activity details5.72.0https://lab.civicrm.org/dev/core/-/issues/4995Standalone - JWT for password resets2024-03-07T22:30:13ZufundoStandalone - JWT for password resetsSwitch Standaloneusers password reset mechanism to use JWT, instead of custom format.
PR from @pfigel is here: https://github.com/civicrm/civicrm-core/pull/28505Switch Standaloneusers password reset mechanism to use JWT, instead of custom format.
PR from @pfigel is here: https://github.com/civicrm/civicrm-core/pull/28505Patrick Figelpfigel@greenpeace.orgPatrick Figelpfigel@greenpeace.orghttps://lab.civicrm.org/dev/core/-/issues/4860VTIMEZONE block in ICS file publishes DSTART in wrong timezone2024-01-17T23:01:42ZjamieVTIMEZONE block in ICS file publishes DSTART in wrong timezoneA lot of great work went into fixing our ICS timezone support in #2887!
But, I _think_ there is still one small problem with timezone support.
I'm testing with the ICS file generated by the Montreal Developer Training on February 26th ...A lot of great work went into fixing our ICS timezone support in #2887!
But, I _think_ there is still one small problem with timezone support.
I'm testing with the ICS file generated by the Montreal Developer Training on February 26th (https://civicrm.org/civicrm/event/ical?reset=1&id=1745). The event is supposed to start at 9:00 AM America/New_York time.
I'm using Thunderbird. I have my Thunderbird timezone set to America/Los_Angeles. It's important to set your calendar timezone to a timezone that does not match the event time zone to replicate the problem.
When I import the ICS file, my calendar shows it as starting at 1:00 am America/Los_Angeles time, which would be 4:00 am America/New_York time. The reason it's off is because Thunderbird percieves the correct time to be 9:00 am UTC rather than 9:00 am America/New_York.
Here are the relevant parts of the ICS file.
First, the timezone is defined:
```
BEGIN:VTIMEZONE
TZID:America/New_York
BEGIN:STANDARD
TZOFFSETFROM:-0500
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:20240226T140000
END:STANDARD
END:VTIMEZONE
```
Then, the event date start is defined:
```
TSTAMP;TZID=America/New_York:20240226T090000
DTSTART;TZID=America/New_York:20240226T090000
DTEND;TZID=America/New_York:20240227T170000
```
The problem is with the timezone definition, specifically:
`DTSTART:20240226T140000`
This represents the start time in UTC. But, the [standards](https://www.rfc-editor.org/rfc/rfc5545#section-3.6.5) says:
> The mandatory "DTSTART" property gives the effective onset date
and local time for the time zone sub-component definition.
"DTSTART" in this usage MUST be specified as a date with a local
time value.
In other words, it should be the local time, not UTC. In this case: `DTSTART:20240226T090000`.
Making that adjustment causes it to import properly in Thunderbird.
I'm happy to work on this, but would love some feedback to make sure I'm not offbase on anything. I know @justinfreeman did a lot of work on this in #2887 so maybe has some thoughts.5.71.0https://lab.civicrm.org/dev/core/-/issues/4826Add is_new as a field on membership api or possibly via membership_status2024-01-05T03:42:40ZeileenAdd is_new as a field on membership api or possibly via membership_statusI've been thinking about https://github.com/civicrm/civicrm-core/pull/28185 & have concluded that the way to determine if it is a new membership or renewal is to check for the new membership status.
However, that is not actually straig...I've been thinking about https://github.com/civicrm/civicrm-core/pull/28185 & have concluded that the way to determine if it is a new membership or renewal is to check for the new membership status.
However, that is not actually straight forward since we can't use {membership.membership_status_id.name} in case they have modified the statuses.
I'm thinking maybe an api calculated field (exposed as a token)
Then in the template it would be something like
```
{if {membership.membership_status_id.is_new|boolean}}
Signup
{else}
Renewal
{/if}
```
One concern with the above is that if you re-sent it after the status had changed from new (3 months by default) if would show 'renewal'. Obviously people can customise the templates, as they do the membership types, so we don't have to catch every possibility. We might consider doing instead
```
{if {membership.membership_status_id.is_new|boolean}}
Signup
{elseif !{contribution.receive_date|boolean}}
-- hasn't been sent already so we can be somewhat confident
Renewal
{else}
-- some mealy mouthed generic alternative
{/if}
```5.69.0https://lab.civicrm.org/dev/core/-/issues/4549Proposal: Remove Transaction ID from message templates2023-09-05T03:28:22ZlarsssandergreenProposal: Remove Transaction ID from message templatesSix message templates (event online and offline, contribution online and offline, membership and payment/refund) include Transaction #. I don't think this is useful information for the recipient, as it is just a long string of characters...Six message templates (event online and offline, contribution online and offline, membership and payment/refund) include Transaction #. I don't think this is useful information for the recipient, as it is just a long string of characters. So my proposal is to remove it, to simplify the templates and only send pertinent information to the recipient.
The only potential use I can think of would be in some edge case where perhaps you can't find a contribution for some reason and you could in that case search by transaction ID, but that seems rare and easily covered by having the exact time, amount, etc. If we did want to have something for that purpose, contribution ID would make a lot more sense, but I don't think we need either. Has anyone ever used the transaction ID from a receipt for any purpose?https://lab.civicrm.org/dev/core/-/issues/4545Events - Self service and change options after initial registration2023-09-06T13:20:42ZtreseroEvents - Self service and change options after initial registrationThis is a common scenario, and I'm not sure why CiviEvents doesn't support it.
Scenario 1: Joe signs up for a multi-day event and pays for the registration. A month later, the event organizers add a golf tournament fundraiser option, Jo...This is a common scenario, and I'm not sure why CiviEvents doesn't support it.
Scenario 1: Joe signs up for a multi-day event and pays for the registration. A month later, the event organizers add a golf tournament fundraiser option, Joe wants to add this to his registration.
Scenario 2: Joe now realizes that he wants to add his wife.
Scenario 3: Joe's friend Jeff wants to go, and also play golf.
You get the idea.
As Events is now, there is no way to adjust your registration and it has to be done manually. That is not an option for 700 - 800 registrations run by all volunteers (i.e. we don't have any paid staff). Another issue is we can't make the payment required as it would have to be paid when there is a "new" change. Making it optional, well, you can see the problem.
My thinking would be to look up email, or something and populate the form etc. We already require them to create a wordpress account so that could also be used. It's just not there.
Also, we have 25,000+ constituents that were imported from a legacy system. They don't have any accounts, but it would be nice if there were a way to match emails (where possible, I know not all have updated/current emails), but this is a less important scenario.
I have coding skills, but as we are all volunteers, I don't have much time. There is some money to budget for a developer. All code will be added back to the public.
![image.png](/uploads/9e7d2100f9b61ee6b871d0467d58338d/image.png)
As you can see, this is an example. Of course, none is not an option. but if we added other additions, or they want to add another person, it has to be manually done.https://lab.civicrm.org/dev/core/-/issues/4484Feature request: New contact buttons on the API 4 autocomplete widget2023-11-01T18:20:41ZbrienneFeature request: New contact buttons on the API 4 autocomplete widgetOverview
----------------------------------------
For using the APIv4 autocomplete widget, such as for the *Existing Contact* field, it would be useful to be able to create new contacts, as is possible with the Select2 drop downs, such a...Overview
----------------------------------------
For using the APIv4 autocomplete widget, such as for the *Existing Contact* field, it would be useful to be able to create new contacts, as is possible with the Select2 drop downs, such as for selecting a Contributor on a backend contribution.
![Selection_015](/uploads/30fc0ecdd3268ebc5906ce0aa06dae9a/Selection_015.png)
Example use-case
----------------------------------------
1. Add the *Existing Contact* field to a FormBuilder form
1. A user can look up a contact to select, but if there are no results/a new one is needed, they can click a **New Individual** button to add one without being redirected from the original form
Current behaviour
----------------------------------------
The APIv4 autocomplete widget does not allow for creating new contacts.
![Selection_014](/uploads/d97659f7dddfd4858bd316acb0dda2b6/Selection_014.png)
Proposed behaviour
----------------------------------------
The APIv4 autocomplete widget should have feature parity when it comes to creating new contacts on the spot as the Select2 optionhttps://lab.civicrm.org/dev/core/-/issues/4350Proposal: Smart Group Profiler to help identify slow smart groups2023-11-02T14:29:14ZlarsssandergreenProposal: Smart Group Profiler to help identify slow smart groupsSlow smart groups are a problem that I'm sure we've all experienced. It's difficult for users to guess which of their potentially many smart groups is exceptionally slow or if they just have too many, each taking a little time. @JonGold ...Slow smart groups are a problem that I'm sure we've all experienced. It's difficult for users to guess which of their potentially many smart groups is exceptionally slow or if they just have too many, each taking a little time. @JonGold has a [profiling script](https://gist.github.com/MegaphoneJon/59089c1e155645a438af41051bca7ce7), but that's not accessible to many. I'm sure many orgs would be happy to cut or re-work their slow smart groups if it meant they could use the listing accordion on individual contacts, etc — but they just don't know which ones they need to cut!
What I propose is a Smart Group Profiler in Admin that lets admin users easily check their smart groups in the UI. Here's a quick sketch:
- The user can select groups to profile or leave the select empty to profile all (active, non-hidden) smart groups
- The user can select to run once or average up to three times, to reduce the potential for random variation
- The profiler queues CRM_Contact_BAO_GroupContactCache::add for each group, in random order
- Once the queue finishes, the user gets a table with average time and links to edit the Smart Group criteria for each
I'd be happy to do this as an extension, but it also seems like something that address a core problem, so I think it makes sense to have in core.5.67.0https://lab.civicrm.org/dev/core/-/issues/4316Allow administrators to restrict which contacts will receive an email notific...2023-05-31T23:54:42Zayush_compucoAllow administrators to restrict which contacts will receive an email notification when an activity is assigned to a contactHow it works currently:
----------------------------------------
Administrators can only choose either to enable or disable sending email notifications (including a copy of the activity) when an activity is assigned to a contact OR limit...How it works currently:
----------------------------------------
Administrators can only choose either to enable or disable sending email notifications (including a copy of the activity) when an activity is assigned to a contact OR limit it to specific types of activity.
![image](/uploads/15806181b9f0204f847f4e8a8a70b817/image.png)
https://dmaster.demo.civicrm.org/civicrm/admin/setting/preferences/display?reset=1
**Improvement**
----------------------------------------
We would like to allow administrators to specify which groups of users would receive an email so that certain users can be assigned an activity, but they would not receive CiviCRM's default activity assignee email.
**Note**
----------------------------------------
Note, there is already some similar (but subtly different!) functionality on CiviCase for case activities:
![image](/uploads/7683b54741cb91ec61227f47c7eb87cc/image.png)
The above restricts **who can be selected** to be assigned an activity, whereas we are specifying **who would be sent** a notification for an activity.
**Proposed solution**
----------------------------------------
We propose adding a new functionality that allows administrators to specify which CiviCRM groups would receive an email notifications. This can be achieved by introducing a new dropdown field.
We would create 2 new settings for this under the setting for "Do not notify assignees for" <Activity types> on the Display Preferences page: https://dmaster.demo.civicrm.org/civicrm/admin/setting/preferences/display?reset=1 which states:
1. Restrict email recipients to groups
- <Select Group> (list all CiviCRM groups or smart groups)
- Multiselect
- Help: Limit which contacts will receive a CiviCRM activity notification email when an activity is assigned to them. You can select any group or smart group. Leave blank for no restriction. Note that you may still assign an activity to a contact who is not in the group, but they will not receive an email.
If the field is blank there will be no restriction. If a group is selected, emails will be restricted to only go to that group.
2. Restrict email recipients to Website Users
- Checkbox
- Help: Limit which contacts will receive a CiviCRM activity notification email to only be those who have a CMS user when an activity is assigned to them. Note that you may still assign an activity to a contact who does not have a CMS user, but they will not receive an email.
Emails will be suppressed in each case.
**Next steps**
----------------------------------------
We are prepared to submit a pull request (PR) for this feature. If the concept is approved, we will promptly submit the core PR.
Thank you.https://lab.civicrm.org/dev/core/-/issues/4298CiviMail - throw 400 (Bad Request) rather than 500 (Server Error) if public u...2023-07-27T17:17:06ZufundoCiviMail - throw 400 (Bad Request) rather than 500 (Server Error) if public url endpoints hit with bad parametersOverview
----------------------------------------
Urls for CiviMail public endpoints like `civicrm/mailing/open` have a few required parameters, identifying the user / url etc. How should we handle if params aren't valid?
Current behavi...Overview
----------------------------------------
Urls for CiviMail public endpoints like `civicrm/mailing/open` have a few required parameters, identifying the user / url etc. How should we handle if params aren't valid?
Current behaviour
----------------------------------------
Current standard behaviour Civi-wide for missing/invalid params is a `CRM_Core_Exception`, which in turn results in a 500 server error.
Proposed behaviour
----------------------------------------
I think a 400 Bad Request error is more appropriate, for the "public" CiviMail links in particular.
Comments
----------------------------------------
It also helps with detecting and blocking spammy click behaviour, which I've seen with random permutations of parameters and things like this.5.65.0