CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-03-02T16:50:05Zhttps://lab.civicrm.org/dev/core/-/issues/3973SearchKit: be able to choose *which* Actions are available on a display2023-03-02T16:50:05ZherbdoolSearchKit: be able to choose *which* Actions are available on a displayThe Actions for SearchKit displays seem to be automatically chosen based on the entities. And it's an all or nothing deal. In my case, I was hoping to allow staff to *only* download the results and nothing else. But there a bunch that sh...The Actions for SearchKit displays seem to be automatically chosen based on the entities. And it's an all or nothing deal. In my case, I was hoping to allow staff to *only* download the results and nothing else. But there a bunch that show up, including delete, update. Even if the search is using a GROUP BY, which doesn't make much sense I think.https://lab.civicrm.org/dev/core/-/issues/3944SearchKit: Show count on both top and bottom of display2022-10-27T20:47:07ZlarsssandergreenSearchKit: Show count on both top and bottom of displayCurrently, the count of results in a SearchKit display is only shown on the bottom of the page. In core, totals are usually shown at the top and bottom of the page in search results. I think it would be more usable to also show the total...Currently, the count of results in a SearchKit display is only shown on the bottom of the page. In core, totals are usually shown at the top and bottom of the page in search results. I think it would be more usable to also show the total count in SearchKit displays at the top of the page, beside the Actions drop down menu. It's a good sanity check for users to be able to see how many entities they are doing an action on before doing so - they shouldn't have to scroll to the bottom of the page and then back up to see the count. It's also not always easy to see how many are selected or if you've selected just one page of results or the whole list.
Something simple like this, which would also show NNN selected of NNN results when some are selected.
![image](/uploads/0587e86d7faed05a9ecf441a64f93378/image.png)
This could be disabled by disabling show count for the display.https://lab.civicrm.org/dev/core/-/issues/3929SearchKit feature request - filter by data segment2022-11-01T21:47:09ZJonGoldSearchKit feature request - filter by data segmentMy client has a request to be able to filter by data segments in a SK embedded in Form Builder.
My initial thought was that this would have to be done in PHP/JS and not SQL, which would have awful performance - but on further thought, I...My client has a request to be able to filter by data segments in a SK embedded in Form Builder.
My initial thought was that this would have to be done in PHP/JS and not SQL, which would have awful performance - but on further thought, I realized that data segments could be used as WHERE clauses.
If someone wants to message me on Mattermost with an estimate, I could bring it to my client.https://lab.civicrm.org/dev/core/-/issues/3839Add system check for updated clean URL settings2022-09-27T19:51:34ZelilisseckAdd system check for updated clean URL settingsOverview
----------------------------------------
Based on my experience and this conversation: https://chat.civicrm.org/civicrm/pl/56au14c7dpb5ddebj69kbfjdir
Clean URLs should be required at this point. It's not as much of a problem in...Overview
----------------------------------------
Based on my experience and this conversation: https://chat.civicrm.org/civicrm/pl/56au14c7dpb5ddebj69kbfjdir
Clean URLs should be required at this point. It's not as much of a problem in Drupal, but in Wordpress if a site has been upgraded from the old Clean URL settings in civicrm.settings.php and ?civiwp style URLs and civicrm.settings.php has not been updated manually, strange things will being to occur. This largely manifests itself as yellow "Cannot find valid value for ID" error screens that confuse users when registering for an Event or making a Contribution on user-facing forms. This message comes from a tricky session issue and setting clean URLs up has always been the fix.
Current behaviour
----------------------------------------
Clean URL settings are often not updated by unsuspecting admins as older sites are upgraded to versions of CiviCRM where they should be required.
Proposed behaviour
----------------------------------------
System check warning appears for Wordpress users if civicrm.settings.php does not include up-to-date clean URL settings.
Comments
----------------------------------------
This check could be extended to other CMS' now or in the future, which is the motivation behind using its own check class rather than modifying the existing "Cms" for Wordpress checks. I haven't seen this issue with other CMS' so far.
Any thoughts welcome! PR will be provided and linked.https://lab.civicrm.org/dev/core/-/issues/3831PHP 8.2 Deprecated ${} string interpolation2022-10-31T03:45:54ZBradley TaylorPHP 8.2 Deprecated ${} string interpolationIn PHP 8.2 (planned to be released this November) ${} string interpolation has been deprecated:
https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation
```
echo "Hello ${name}"; // Deprecated
echo "Hello {$name}"; // Suppo...In PHP 8.2 (planned to be released this November) ${} string interpolation has been deprecated:
https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation
```
echo "Hello ${name}"; // Deprecated
echo "Hello {$name}"; // Supported
```
There are not loads of places where the deprecated version is used, but there are a few. We should swap the position of the dollar to the non-deprecated version.
(I also realise CiviCRM does not fully support PHP 8.1 yet, but it doesn't hurt to start to get ahead).5.54.0Bradley TaylorBradley Taylorhttps://lab.civicrm.org/dev/core/-/issues/3823Scheduled Reminders' effective start/end date incorrectly described.2022-09-02T15:31:27ZRichScheduled Reminders' effective start/end date incorrectly described.e.g.
![image](/uploads/fc3823cd4ec6e288615934a084db52e1/image.png)
You might think from this screenshot that this reminder won't fire unless the membership end date is at least 26 Aug 2022.
But surprise!, you'd be wrong!
It actually ...e.g.
![image](/uploads/fc3823cd4ec6e288615934a084db52e1/image.png)
You might think from this screenshot that this reminder won't fire unless the membership end date is at least 26 Aug 2022.
But surprise!, you'd be wrong!
It actually won't fire until the *trigger date* is at least 26 Aug 2022, and we set the trigger date above to be 1 week before the membership end date.
Expected behaviour
----------------------------------------
Either the queries should be changed to go on the actual date, as the labels say, OR, the labels should be updated to explain this.
The first feels like poking a hornets nest. The latter is like trying to have a rational debate on twitter.
I think I'd propose:
- Change the "When" label to "When (trigger date)"
- Then in the 'effective' dates' descriptions, just put "Earliest trigger date to include".
If folks agree with my proposal I'm happy to put in a PR for this.5.54.0https://lab.civicrm.org/dev/core/-/issues/3811Allow other extensions to use Recaptcha extension for validation2022-08-22T22:01:15ZKurund JalmiAllow other extensions to use Recaptcha extension for validation5.54.0Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/3783Make Recent Items available providers an option group so extensions can exten...2022-08-10T04:17:03ZherbdoolMake Recent Items available providers an option group so extensions can extend itOverview
----------------------------------------
I would like my custom entities to be available to the Recent Items block.
In `CRM_Utils_Recent::getProviders()` there's a comment to make the hard-coded list into an Open Group. I agree...Overview
----------------------------------------
I would like my custom entities to be available to the Recent Items block.
In `CRM_Utils_Recent::getProviders()` there's a comment to make the hard-coded list into an Open Group. I agree. Let's make it so.
Current behaviour
----------------------------------------
Hard-coded list of some core entities.
Proposed behaviour
----------------------------------------
Create an option group and call it from this method.5.53.0https://lab.civicrm.org/dev/core/-/issues/3768Improvement to Case Detail report2024-03-22T05:03:27ZyashodhaImprovement to Case Detail reportExpose some of the useful columns and filters :
- expose city in case detail report
- add filter for 'Activity type of the last activity'Expose some of the useful columns and filters :
- expose city in case detail report
- add filter for 'Activity type of the last activity'yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3757Users with administer_reports should be able to delete dashlets from the dash...2024-03-19T05:03:27ZandyburnsUsers with administer_reports should be able to delete dashlets from the dashboardThe current behavior I see is anyone with `administer_reports` can access the "Access" tab in a given report in CiviReport. Therefore, they can create dashlets. However, upon making a dashlet available for the dashboard, these can not be...The current behavior I see is anyone with `administer_reports` can access the "Access" tab in a given report in CiviReport. Therefore, they can create dashlets. However, upon making a dashlet available for the dashboard, these can not be removed by that same user, potentially resulting in a cluttered dashboard and user frustration.
Non-admins are missing trash can delete function:
![image](/uploads/206f154220c69227a784cc2d40e87a39/image.png)
Admin sees trash can:
![image](/uploads/21dbc1ca9cc3247a4752324df98a68b2/image.png)
Sure, interest in civireport is quite low now but this same behavior affects dashlets created from search kit.
For search kit, I would set that `administer data` or maybe `administer_reports` would be the needed permission to remove dashlets. Currently, it is not enough.https://lab.civicrm.org/dev/core/-/issues/3729Form Builder doesn't use dedupe2023-02-16T22:18:18ZJonGoldForm Builder doesn't use dedupeIdeally Form Builder would allow you to select a dedupe rule on a per-contact basis, but on a basic level contacts should get deduped.Ideally Form Builder would allow you to select a dedupe rule on a per-contact basis, but on a basic level contacts should get deduped.https://lab.civicrm.org/dev/core/-/issues/3692Replace all calls to deprecated method CRM_Core_PseudoConstant::activityType()2024-03-11T05:03:24ZherbdoolReplace all calls to deprecated method CRM_Core_PseudoConstant::activityType()There are calls to `CRM_Core_PseudoConstant::activityType()` (deprecated) in many places such as `$activityTypes = CRM_Core_PseudoConstant::activityType(TRUE, FALSE, FALSE, 'name');` ~~but the actual method accepts no parameters. And cha...There are calls to `CRM_Core_PseudoConstant::activityType()` (deprecated) in many places such as `$activityTypes = CRM_Core_PseudoConstant::activityType(TRUE, FALSE, FALSE, 'name');` ~~but the actual method accepts no parameters. And changes to that method predate the migration from SVN... so some guesswork needs to be done~~.
Update: oops I just noticed it has `func_get_args()` so it is accepting parameters after all.
In some cases it seems that it can be replaced with `CRM_Core_PseudoConstant::getKey('CRM_Activity_BAO_Activity', 'activity_type_id', 'ACTIVITYNAME')` but in other cases it actually does need a list of activity types. And in some cases needs to filter out disabled components, which is what the original method is doing.https://lab.civicrm.org/dev/core/-/issues/3659APIv4 Contact.get - include email, phone, address?2023-01-04T23:44:25Zaydunsaidan.saunders@squiffle.ukAPIv4 Contact.get - include email, phone, address?# Suggestion/Discussion
Many times when creating a SearchKit search, I want a contact's email and phone. That requires joining on the email and phone entities.
1. that's dull and repetitive for such a common requirement
1. for end-user...# Suggestion/Discussion
Many times when creating a SearchKit search, I want a contact's email and phone. That requires joining on the email and phone entities.
1. that's dull and repetitive for such a common requirement
1. for end-users or newcomers to SK, they either don't find how to do it, or they do and it looks excessively complicated and off-putting for something so basic
In APIv3, `Contact.get` includes the primary email, phone and address.
Without polluting APIv4 with lots of special cases, I wonder whether it is worth making an exception for email and phone and returning those fields in APIv4 `Contact.get` Maybe also the address fields, but for me, that comes up less frequently.https://lab.civicrm.org/dev/core/-/issues/3603Undefined index: error-codes in recaptcha_check_answer()2024-02-16T05:03:24Zchris_bluejacUndefined index: error-codes in recaptcha_check_answer()## Overview
When non-authenticated user subscribes to mailing list at /civicrm/mailing/subscribe, checks the "I am not a robot" reCAPTCHA, and clicks subscribe. The subscription request is processed properly, but an error is thrown:
Not...## Overview
When non-authenticated user subscribes to mailing list at /civicrm/mailing/subscribe, checks the "I am not a robot" reCAPTCHA, and clicks subscribe. The subscription request is processed properly, but an error is thrown:
Notice: Undefined index: error-codes in recaptcha_check_answer() (line 159 of /bitnami/drupal/modules/contrib/civicrm/ext/recaptcha/lib/recaptcha/recaptchalib.php).
## Reproduction steps
1. /civicrm/mailing/subscribe
2. complete email address, check relevant mailing list (in this case, "General Newsletter")
3. Check "I'm not a robot" in reCAPTCHA
4. Click "Subscribe"
5. Subscription is processed properly.
6. Error reported on confirmation page.
## Current behaviour
Error message presented.
Functionality of reCAPTCHA and subscription is okay.
~~~
Notice: Undefined index: error-codes in recaptcha_check_answer() (line 159 of /bitnami/drupal/modules/contrib/civicrm/ext/recaptcha/lib/recaptcha/recaptchalib.php).
~~~
## Expected behaviour
No error message
## Environment Information
- CiviCRM: 5.40.2
- PHP: 7.3.27
- CMS: Drupal 7.82
- Database: MySQL 5.7.33
- Web Server: Apache 2.4.46
- reCAPTCHA: Version 5.40.2
![Screenshot_2021-10-31_084608](/uploads/286470768de6dd8bc6a632827856eafd/Screenshot_2021-10-31_084608.png)https://lab.civicrm.org/dev/core/-/issues/3520Proposal: Splitting up delete contacts permission / new permission "CiviCRM s...2024-03-03T05:03:25ZAndreasandreas.howiller@civiservice.deProposal: Splitting up delete contacts permission / new permission "CiviCRM soft delete contacts"?Overview
----------------------------------------
Currently CiviCRM already has a distinction between soft deletion and permanent deletion of contacts: With the permission _CiviCRM: delete contacts_ you're able to put a contact into the ...Overview
----------------------------------------
Currently CiviCRM already has a distinction between soft deletion and permanent deletion of contacts: With the permission _CiviCRM: delete contacts_ you're able to put a contact into the trash bin. Users with the additional permission _CiviCRM: access deleted contacts_ can then permanently delete these contacts. In many usecases this is fine – e.g. when you might just want to prevent temporary volunteer workers from accidently deleting contacts permanentely. However there are very common use cases where an explicit distinction between a soft and a hard delete permission would be needed:
Example use-case 1: Allow restoring but _not_ (hard) deleting contacts
----------------------------------------
Your're glad your temporary volunteers help taking care of your contacts. And you feel safe allowing them (soft) deletion, too, as you're happy with the fact that only a few of your colleagues have the permission to delete these contacts permanently. What you would also like, however, is for them to be able to view and restore the deleted contacts to fix mistakes.
Current behaviour
----------------------------------------
When you allow users to soft delete contacts and to view the bin to restore contacts, this combination also allows permanently deleting contacts.
Proposed behaviour
----------------------------------------
In combination with a new permission _CiviCRM: soft delete contacts_ the permission _CiviCRM: access deleted contacts_ would allow this use case.
It seems like there had been a workaround for that around the permission _CiviCRM: edit all contacts View, Edit and Delete ANY CONTACT in the CiviCRM database_ which is not working anymore ([see this discussion on StackExchange](https://civicrm.stackexchange.com/questions/42008/allow-deletion-of-contacts-but-not-in-trash)).
Example use-case 2: Allow deduplication but _not_ (hard) deleting contacts
----------------------------------------
You deal a lot with event submissions and imports, so deduplication is very important for you. That is why you want your team to be able to deduplicate and also to fix mistakes by looking in the trash. But you don't want everybody to delete contacts in trash.
Current behaviour
----------------------------------------
Same like in use-case 1 except that even the broken workaround mentioned there would not work here as _CiviCRM: merge duplicate contacts_ requires the delete contacts permission.
Proposed behaviour
----------------------------------------
In combination with a new permission _CiviCRM: soft delete contacts_ the permissions _CiviCRM: merge duplicate contacts_ plus _CiviCRM: access deleted contacts_ would allow this use case.
Comment
----------------------------------------
Since this would mean touching a basic thing and might have some unexpected consequences in practice or in code (I'm not a developer) a broader discussion would be great :-)https://lab.civicrm.org/dev/core/-/issues/3489Increase field size for mailing bounce type2024-01-29T10:07:13ZKurund JalmiIncrease field size for mailing bounce typeThe database fields in civicrm_mailing_bounce_type are too restrictive. The name field is limited to 24 characters and the description is limited to 255 characters. This isn’t long enough for the name and description provided by some ema...The database fields in civicrm_mailing_bounce_type are too restrictive. The name field is limited to 24 characters and the description is limited to 255 characters. This isn’t long enough for the name and description provided by some email service providers - e.g. AWS SES.
I propose that the name field should be increased to 256 characters (`VARCHAR(256)`) and the description field should be increased to 2048 characters (`VARCHAR(2048)`).https://lab.civicrm.org/dev/core/-/issues/3479make the hook usable by passing the sql2024-02-04T05:03:25Zyashodhamake the hook usable by passing the sqlCurrently, we are not passing the sql in the _alterReportVar_ hook.
`CRM_Utils_Hook::alterReportVar('sql', $this, $this);`
Objective is to make the hook usable by passing the sql instead of redundant params.Currently, we are not passing the sql in the _alterReportVar_ hook.
`CRM_Utils_Hook::alterReportVar('sql', $this, $this);`
Objective is to make the hook usable by passing the sql instead of redundant params.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3477SearchKit - dashboard tables2023-12-03T16:32:00Zaydunsaidan.saunders@squiffle.ukSearchKit - dashboard tablesOverview
----------------------------------------
This is about how we can produce dashboard-like summary data with SearchKit to replace existing dashboards and make them more customisable.
For example, consider the Cases dashboard:
...Overview
----------------------------------------
This is about how we can produce dashboard-like summary data with SearchKit to replace existing dashboards and make them more customisable.
For example, consider the Cases dashboard:
- the rows are Case Types
- the columns are the values of Case Status
- the table cells are counts of matching cases, linked to another search
Option 1
--------
SearchKit can produce the counts with eg:
![image](/uploads/16d551f0332f28f4f2a5ef8a6e4a1ff4/image.png)
Maybe a new Display type could restructure the data to produce the desired format.
(Note that is should be based off of CaseType rather than Cases so that types with no cases are shown. But CaseType is not currently available.)
Option 2
--------
See https://gist.github.com/aydun/d49197c81205b463ef5cdef38c97b317
The recently added data segmentation functionality adds 'virtual fields' for group-by purposes. Maybe we could add virtual fields based around the idea of the gist to create virtual fields from an option group so an option group of case_status becomes a set of fields `sum(status_id=1), sum(status_id=2)` etc.
However, I don't think SearchKit/Api4 can produce sql like that - but maybe it can!
Both of these would need to accommodate linking the cells to another parameterized search.
Option 3
----------------------------------------
Something else ...https://lab.civicrm.org/dev/core/-/issues/3474Afform - display privacy flag icons2024-03-07T23:35:11Zaydunsaidan.saunders@squiffle.ukAfform - display privacy flag iconsOverview
----------------------------------------
Form builder allows an icon to be selected conditionally when displaying a field. However, the icons that we use for the privacy flags 'do not email', 'do not phone' etc are actually mul...Overview
----------------------------------------
Form builder allows an icon to be selected conditionally when displaying a field. However, the icons that we use for the privacy flags 'do not email', 'do not phone' etc are actually multiple stacked icons and cannot be added to the display.
Example use-case
----------------------------------------
It would be useful (probably recommended) that when displaying an email address (or phone etc) for a contact with the 'do not email' privacy flag that the icon is shown next to the email address.
Current behaviour
----------------------------------------
A single icon can be displayed, but not stacked icons.
Proposed behaviour
----------------------------------------
Be able to display the privacy flag icons.
Comments
----------------------------------------
The privacy icons are added by the smarty function `CRM/Core/Smarty/plugins/function.privacyFlag.php`
Form builder allows using smarty in the rewrite field so I tried a rewrite of:
`{privacyFlag field=do_not_email condition=[do_not_email]} `
but 2 problems:
- the generated html is displayed rather than the icons
- conditional does not work because the `[do_not_email]` is passed as 'Yes' or 'No' instead of 1 or 0.
One approach would be to refactor the stacked icons out of the smarty function and make privacy flag icons a specific option in form builder.
Alternatively the form builder support for icons could be expanded to allow arbitrary stacked icons.https://lab.civicrm.org/dev/core/-/issues/3466On_hold field for phone record2024-02-28T05:03:22Zmagnolia61On_hold field for phone recordOverview
----------------------------------------
I think by design the civicrm_phone table should also have an on_hold field in order to 'block' individual phone numbers from receiving calls and texts.
I think this would help to better...Overview
----------------------------------------
I think by design the civicrm_phone table should also have an on_hold field in order to 'block' individual phone numbers from receiving calls and texts.
I think this would help to better refine the means to comply to privacy regulations.
Current behaviour
----------------------------------------
Only on a contact level do_not_call and do_not_sms are available as options
Proposed behaviour
----------------------------------------
Just like the civicrm_email table individual phone numbers can be 'disabled' from receiving (automatic) texts and calls.
Comments
----------------------------------------
I am not really able to code this but would be able to help think about it and help test.