CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2021-03-27T15:11:01Zhttps://lab.civicrm.org/dev/core/-/issues/1750View sent emails in activities2021-03-27T15:11:01ZshitijgView sent emails in activitiesOverview
----------------------------------------
As it stands currently, a CiviCRM user can send an email to a contact via a few methods. The user can also use tokens which personalise the content per contact they are sending an email t...Overview
----------------------------------------
As it stands currently, a CiviCRM user can send an email to a contact via a few methods. The user can also use tokens which personalise the content per contact they are sending an email too.
On submission, an activity is created for this. However, the activity only stores the tokens and not the actual content sent to a contact.
The behaviour for how the content of the email when we use the “send email” activity functionality is different to that from mass mailings with respect to tokens, and any used tokens aren’t replaced in the resultant stored body of the content in the activity with the actual content.
To see the content of the sent email (rather than just “token” itself) is important to users as
- They should be able to see what was sent to a contact at any given time and not just the tokens
- information might change with time i.e. the data in the field may change so the user will not know what was actually sent to the contact
Current behaviour
----------------------------------------
A mailing can be sent to the user in multiple ways in CiviCRM eg. bulk mailings, through send email activity on the contact record, inside a case, scheduled reminders, and through extensions like CiviRules.
However, when we use the send email activity form, any used tokens aren’t replaced in the resultant stored body of the content in the activity eg
![image1](/uploads/7419b37d976e1603ae2ad05d1c8619f2/image1.png)
This is happening due to an issue in the following create email activity functionality:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Contact/Form/Task/EmailCommon.php#L467-L483
This is used:
1. When creating an activity from the contact record: This can be done by clicking on the ‘Send email’ action which triggers the form above
2. From within a case: The same form is used when creating a ‘Send email’ activity from within a case
Proposed behaviour
----------------------------------------
The created activity should store (in the content) the "resultant value" of any "tokens" with the content they were actually sent as to the recipient rather than just the {token} field name itself.
Technical implementation suggestions:
- The email activity is created before the token replacements is done here: https://github.com/civicrm/civicrm-core/blob/master/CRM/Activity/BAO/Activity.php#L1122.
- Token replacements are done here: https://github.com/civicrm/civicrm-core/blob/master/CRM/Activity/BAO/Activity.php#L1193-L1216
- Change will be to move the activity creation to just before the email is sent, after token replacements are done to somewhere like here: https://github.com/civicrm/civicrm-core/blob/master/CRM/Activity/BAO/Activity.php#L1227
with the following code:
$activityID = self::createEmailActivity($userID, $tokenSubject, $tokenHtml, $tokenText, $additionalDetails, $campaignId, $attachments);
We have tested this on our local and are happy to submit a core PR if the concept is approved.5.36.0https://lab.civicrm.org/dev/core/-/issues/2998Epic: Re-implement CiviCRM Standalone (CMS-less CiviCRM)2024-02-09T14:12:15ZbgmEpic: Re-implement CiviCRM Standalone (CMS-less CiviCRM)Follow-up to dev/core#1153, and [more context in this wiki page](https://lab.civicrm.org/dev/core/-/wikis/standalone), this is an epic to track the main tasks to implement CiviCRM Standalone.
- [x] Base classes (Hook, System, Permission...Follow-up to dev/core#1153, and [more context in this wiki page](https://lab.civicrm.org/dev/core/-/wikis/standalone), this is an epic to track the main tasks to implement CiviCRM Standalone.
- [x] Base classes (Hook, System, Permission and css/tpl so that Standalone can boot / proof-of-concept [PR22227](https://github.com/civicrm/civicrm-core/pull/22227)
- [x] Basic composer project to handle the code-case (see: https://github.com/civicrm/civicrm-standalone)
- [x] Composer template project that follows best-practices (see: https://github.com/civicrm/civicrm-core/pull/26771)
- [x] Implement a breadcrumb (see: https://github.com/civicrm/civicrm-core/pull/26782)
- [x] Login page (standaloneusers ext now included in core)
- [x] dev/core#4053 User management and permissions
- [x] initial user roles dev/core#4466
- [x] Password reset by email [PR28505](https://github.com/civicrm/civicrm-core/pull/28505), [PR27681](https://github.com/civicrm/civicrm-core/pull/28505)
- [x] Clean URLs
- [x] [Language switcher](https://civicrm.org/extensions/language-switcher) - language links are missing `lcMessages=xx_YY` and session change is not sticky. See #4425 and [PR#27040](https://github.com/civicrm/civicrm-core/pull/27040)
- [x] GenCode
- [x] Installer (using 'civicrm-setup')
- [x] Buildkit (mostly, requires `cv` support, see: https://github.com/civicrm/civicrm-buildkit/pull/662)
- [x] cv (workaround: `CIVICRM_SETTINGS="/var/www/standalone/data/civicrm.settings.php" cv sql:cli`)
- [x] Backend themes (test [known themes](https://civicrm.org/extensions?field_extension_civi_use_target_id=356))
- [x] Releaser support (create tar.gz for official downloads) - https://github.com/civicrm/civicrm-core/pull/27104
- [x] Demo site (https://github.com/civicrm/civicrm-buildkit/pull/794)
- [X] Installation documentation https://docs.civicrm.org/installation/en/latest/standalone/
- [x] Getting started dashlet - alert.civicrm.org needs to be updated to understand "uf=Standalone" since it currently gives error 500, e.g. `https://alert.civicrm.org/welcome?prot=1&ver=5.46.alpha1&uf=Standalone&sid=blah&lang=en_US&co=`
- [x] https://lab.civicrm.org/infra/community-messages/-/merge_requests/2
- [x] High-level error handler. https://github.com/civicrm/civicrm-core/pull/26965
- [x] How to treat cms.root. The rest of the work so far is treating "standalone" as if it were a cms, so it should probably return _something_ for it.
- [x] Nicer Role/Permission UI, permission for adding users
Known minor bugs:
- [x] On the `/civicrm/admin` page, the links are missing the leading `/`
- [x] Because CRM/Utils/System/Standalone.php automatically sets `userID = 1`, that CID is the default org record, so some public forms such as Event Registrations, behave incorrectly. Will be fixed when we implement users.
- [x] Might be a local issue but I [DaveD] get the old files system status warning. There's an open ticket somewhere about this happening for drupal 8 sometimes so might be similar.
Nice to haves, but not release-critical:
- [ ] Front-end theme?https://lab.civicrm.org/dev/core/-/issues/2640User experience improvement, hide by default the Latitude and Longitude fiel...2023-08-23T00:28:55Zjustinfreeman (Agileware)User experience improvement, hide by default the Latitude and Longitude fields, users can enable display if neededWe have found that users are somewhat confused by the default display of the Latitude and Longitude fields in the Address section for Contacts. This is a proposal to change the default so that the Latitude and Longitude fields are not di...We have found that users are somewhat confused by the default display of the Latitude and Longitude fields in the Address section for Contacts. This is a proposal to change the default so that the Latitude and Longitude fields are not displayed by default. This would affect both new sites and existing sites that rely on the default settings and require an upgrade message to notify existing sites of this change.
The change is to de-select the Latitude and Longitude fields in the Address Settings. CiviCRM > Administer CiviCRM > Address Settings
![Screenshot_20210608_091407](/uploads/ca7ad12a7aa0e9472d92c40b41b6f485/Screenshot_20210608_091407.png)
This change was initially discussed in MM and support indicated, see https://chat.civicrm.org/civicrm/channels/product-roadmap/pzm9gqjy4jdeznennqi6kuhceo
Agileware will provide a PR at some stage.
Agileware Ref: CIVIUX-1415.66.0https://lab.civicrm.org/dev/core/-/issues/2243Add created_date column to the civicrm_note table2021-03-28T16:44:34ZjasonmAdd created_date column to the civicrm_note tableOverview
----------------------------------------
After merging contacts, we noticed that when viewing the notes of the merged contact, the notes merged from the duplicated contact display the timestamp of when the merge happened. It wou...Overview
----------------------------------------
After merging contacts, we noticed that when viewing the notes of the merged contact, the notes merged from the duplicated contact display the timestamp of when the merge happened. It would be helpful for note records to store both the created date and the last modified date and to display both dates in the notes list view at /civicrm/contact/view?reset=1&cid=xxxxxx
Example use-case
----------------------------------------
The user wants to see the date that a note was created in addition to when a note was last modified.
Current behaviour
----------------------------------------
Currently the civicrm_note table has only a modified_date field so the date a note is created is lost upon any update.
Proposed behaviour
----------------------------------------
Add a created_date column to the civicrm_note table and display both created and modified dates at /civicrm/contact/view?reset=1&cid=xxxxxx
![screenshot-a](/uploads/99cabcdde44fa725841c2d5de5afd28a/screenshot-a.png)
![screenshot-b](/uploads/003327183320ec3af790840cbe835393/screenshot-b.png)
![screenshot-c](/uploads/d8ecdc89bb06f23037df82ea81e4974e/screenshot-c.png)5.37.0https://lab.civicrm.org/dev/core/-/issues/732Parsing of addresses in the format of different countries2023-03-05T05:03:27ZjaapjansmaParsing of addresses in the format of different countriesCiviCRM has the ability to parse addresses into a street name, house number and street unit.
This parsing is based on I assume US address formats.
E.g. an address like _799 E DRAGRAM SUITE 5A_ is parsed into house number: 799, street n...CiviCRM has the ability to parse addresses into a street name, house number and street unit.
This parsing is based on I assume US address formats.
E.g. an address like _799 E DRAGRAM SUITE 5A_ is parsed into house number: 799, street name: E Dragram, and Street unit Suite 5a.
In the Netherlands and Belgium the adresses are formatted in a different way, first it is the street name, then the house number and then the street unit.
Some examples:
* _Grote straat 1a_, which should be parsed to Street name: Grote straat, house number 1, and street unit a
* _Grote straat 2-3_, which should be parsed to Street name: Grote straat, House number 2, and street unit 3
* _Plein 40-45 60-II_, which should be parsed to Street name: Plein 40-45, house number 60 and street unit II
**What I think CiviCRM should be capable of (either with an extension or in core):**
1. Parse addresses based on the country of the address
2. Format addresses based on the country of the address, meaning glue the individual address (Street name, house number, street unit) parts into one address
**How does it work currently?**
When I enable Address Parsing I can enther a full address into CiviCRM.
If I enter _Grote straat 1a_ it gets parsed into Address name: Grote straat 1a, House number: _empty_ and street unit _empty_
If I enter _Plein 40-45 60-II_ it gets parsed into Address name: Plein 40-45 60-II, House number: _empty_ and street unit _empty_
If I enter the individual parts, street name: Grote straat, house number: 1 and street unit a, it gets formatted to 1 Grote straat a
As you can see the formatting and parsing of Dutch and Belgium addresses does not work.
**Proposed solution**
I do think it will be good when the address parsing functionality could be made in such way that extensions could hook into it.
I am thinking of a hook which provides callback functions for address parsing based on the country ID of the address.
Example code
```php
$callbacks[1020] = array('CRM_Address_BAO_Address', 'parseBelgiumAddress');
$callbacks['default'] = array('CRM_Address_BAO_Address', 'parseAddress');
/**
* Alter the callbacks for address parsing
*
* @param array $callbacks
*/
hook_civicrm_alter_address_parser_callbacks(&$callbacks) {
// Add a custom address parser
// For example the dutch one:
$callbakcs[1152] = array('CRM_MyExtension_DutchAddressParser', 'parseDutchAddress');
}
```
This way CiviCRM core could provide a default address parser, and a set of address parser for certain countries and if one is missing an extension developer could write the missing parser.
What do you think of this? If everyone is happy I am happy to implement this.jaapjansmajaapjansmahttps://lab.civicrm.org/dev/core/-/issues/392Support MySQL 8.0 now that it is GA2021-04-01T01:52:03ZJoeMurraySupport MySQL 8.0 now that it is GA# Overview
MySQL 8.0 went General Availability on April 19, 2018. CiviCRM's aim is to support the latest GA for required infrastructure (MySQL, PHP) as soon as feasible.
In reviewing removed features that cause incompatibilities (htt...# Overview
MySQL 8.0 went General Availability on April 19, 2018. CiviCRM's aim is to support the latest GA for required infrastructure (MySQL, PHP) as soon as feasible.
In reviewing removed features that cause incompatibilities (https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html) I noticed a couple of issues that definitely require changes, one that might cause syntax errors that are easily fixed when found, and a fourth that we may want to change to improve our functionality and get current.
This is a meta issue for tracking what's needed for MySQL8. I have added a MySQL8 flag to lab for the moment to help in tracking. We can delete that flag after this issue is deemed complete.
# Related issue: Upgrade test infrastructure to enable testing against a version on the edge of being officially supported: https://lab.civicrm.org/dev/core/issues/1142
# Issue: Field Names now Reserved Words https://lab.civicrm.org/dev/core/issues/1143
# Testing issue: dependence on PHP version for MySQL authentication ~~https://lab.civicrm.org/dev/core/issues/1144~~
# Document dealing with changes to MySQL user password library https://lab.civicrm.org/dev/core/issues/1145
# Possible issue: Sort order on GROUP BY clauses
~~I don't think we have any code that tries to specify sort order on GROUP BY fields, but if so we will need to change to add an ORDER BY clause with the sort order. I think we should just try running tests on MySQL 8.0 and using it manually to determine locations in code with this issue, and play whack-a-mole on anything missed.~~
# Nice to have: Upgrade our text fields to support all utf8 characters https://lab.civicrm.org/dev/core/issues/339https://lab.civicrm.org/dev/core/-/issues/1500Add system check for required PHP extensions (bcmath, curl, etc.)2023-03-21T05:03:21ZAllenShawAdd system check for required PHP extensions (bcmath, curl, etc.)I was recently bitten by the bcmath requirement (along the lines of https://civicrm.stackexchange.com/q/31932/907), on a system that (for unrelated reasons) was making error messages fairly hard to get to.
It occurs to me that since Civ...I was recently bitten by the bcmath requirement (along the lines of https://civicrm.stackexchange.com/q/31932/907), on a system that (for unrelated reasons) was making error messages fairly hard to get to.
It occurs to me that since CiviCRM core requires several php extensions (https://docs.civicrm.org/sysadmin/en/latest/requirements/#php-extensions), it would be helpful to have a system check that uses `extension_loaded()` to confirm these are installed, and presents a 'critical' error if any are missing.https://lab.civicrm.org/dev/core/-/issues/785Differentiate smart group from regular group using icon in select2 field2020-07-27T19:47:10ZMonish DebDifferentiate smart group from regular group using icon in select2 fieldCurrently there is no way to tell which group is smart or regular group from UI. It would be ideal to use icon against such smart group options to differentiate them from regular ones.Currently there is no way to tell which group is smart or regular group from UI. It would be ideal to use icon against such smart group options to differentiate them from regular ones.5.29.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/630CiviCase multi-category/ multi-instance support2022-10-29T05:03:41ZguanhuanCiviCase multi-category/ multi-instance supportRecently having had some discussions with a few of our clients and participants of CiviMeetup, We have realised that there are a lot of interest in using CiviCase to manage many different types of workflows in different organisations. So...Recently having had some discussions with a few of our clients and participants of CiviMeetup, We have realised that there are a lot of interest in using CiviCase to manage many different types of workflows in different organisations. Some of them require a change to evolve CiviCase’s data model to a multi-level structure.
To support this idea, I have attached a diagram to demonstrate the multi-level structure. We have suggested that a new field “case type category” would provide a lot of flexibility.
![CiviCase_Structure](/uploads/b73a3f3e8eb1d71034ac9121e1379f9c/CiviCase_Structure.jpg)
The basic idea is, an organisation’s business is made up of many different workflows for different business areas, such as Service delivery (i.e. a Helpdesk, Counselling service or Delivering care/housing support), Prospecting (i.e. major donors, grants bid writing in), Awards (i.e. Grants out), Volunteer vacancy management and even perhaps as a set of tasks for an event etc. These completely different workflows often are managed by completely different teams (who would need to manage their own case types), produce very different data and therefore require very different analysis and reports. "Case Type” is not sufficient to support all these needs as there may be several case types which apply to any specific business area.
Each team would probably want:
- The ability to create/configure case types of their category. For example with a volunteer vacancy managers they may want to create multiple vacancies, or with Grants, there may be multiple open opportunities. For Major donors they may split these between different types of donor - i.e. trusts, individuals, government which have different timelines and activities.
- The ability to add additional fields at the case type level for each category.
- Only having access to cases with the case type category they should have access to
- Some modifications to the case screen for cases of that case type category.
We've made a more detailed [draft proposal](https://compucorp.atlassian.net/wiki/spaces/PS/pages/1014398991/CiviCase+multi-category+support) of what we need to do to eliminate these caveats. The main target is to bring out the full potential of CiviCase as CiviCRM’s workflow management suite.https://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/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/2866Start phasing out 'preferred_mail_format'2024-02-27T05:03:24ZeileenStart phasing out 'preferred_mail_format'Preferred mail format was the idea of sending a message in html or text or both depending what you knew about their preferrences. However, mostly this is an email client setting - you send both and the client deals with it.
We actually ...Preferred mail format was the idea of sending a message in html or text or both depending what you knew about their preferrences. However, mostly this is an email client setting - you send both and the client deals with it.
We actually invest quite a lot of code & unnecessary queries into this feature & when it came up there was general support for removing it. I also included it in the dev digest on 12 Sep 2021 - so I think we are a couple of emojis away from concept approval on this
https://github.com/civicrm/civicrm-core/pull/21426#pullrequestreview-751423307https://lab.civicrm.org/dev/core/-/issues/1987Fix theme configuration section on Display preference and improve `isFrontend...2020-10-14T01:27:41Zswastik-compucorpFix theme configuration section on Display preference and improve `isFrontendPage` function for Drupal CMSProblem Motivation
----------------------------------------
While working on the Drupal web-forms, when we are using CiviCRM fields (like payment processors) on the Drupal webform pages, the CiviCRM current theme JS and CSS files were le...Problem Motivation
----------------------------------------
While working on the Drupal web-forms, when we are using CiviCRM fields (like payment processors) on the Drupal webform pages, the CiviCRM current theme JS and CSS files were leaking (rendering) on the Drupal webform page. This was making the page styling more difficult as one has to first reset the leaking CSS and then style on top of them. Also, there were some bootstrap JS libraries (when Shoreditch is the CiviCRM) file which was loading on the page. So, if a developer wants to develop a bootstrap based Drupal 7 themes and try to style the CiviCRM components, the Shoreditch bootstrap JS files conflicts with Drupal 7 bootstrap theme JS files.
To fix this we had to find a way to stop CiviCRM to apply its theme assets. The best way of it is to find a way in CiviCRM which will contextually select/deselect a CiviCRM theme on Drupal CMS pages. And apparently, the CiviCRM core provides such a feature under the display preference page to select different Front-end and Back-end theme. Unfortunately, this feature was not for Drupal CMS and hence the issue.
Problem Overview
----------------------------------------
For the Drupal CMS, the CiviCRM doesn't provide separate configurations for setting the frontend theme (FE) and the backend theme (BE). This is however present for other CMS integrations
For Drupal, on the Display Preference page, we only have one option for setting the global theme and it sets the BE only and the user can only set the BE.
![3ffa703e-9774-4224-abb0-c967b809dbef](/uploads/821e12db022a5accb4c5d8f7d8063ae3/3ffa703e-9774-4224-abb0-c967b809dbef.png)
The problem with this is that the Drupal User couldn't set the front end theme and the backend theme separately. So, to fix this we remove [the extra if logic](https://github.com/civicrm/civicrm-core/blob/master/templates/CRM/Admin/Form/Preferences/Display.tpl#L210-L225) just for Drupal CMS which hides the configuration for the FE-theme and BE-theme and loads the configuration for drupal as well. This will print both the configuration fields.
![3403e6d0-6a80-4e20-ac50-bd24190cc858](/uploads/d9efbd1d109e2bb15b0938debda8e32e/3403e6d0-6a80-4e20-ac50-bd24190cc858.png)
Also, the CiviCRM theme CSS was leaking on drupal pages too which uses the CiviCRM fields (and in turn called `civicrm_initialise()` function). This is because `$config->userSystem->isFrontEndPage()` function is buggy for Drupal CMS as it return `false` if the user opens a drupal public page. This is because [`isFrontEndPage()` function ](https://github.com/civicrm/civicrm-core/blob/master/CRM/Utils/System/DrupalBase.php#L658-L664))doesn't take care of the corner case of page URLs which are not CiviCRM's one. As it only checks if the URLs is a CiviCRM public URL
```
$item = CRM_Core_Menu::get($path);
// What if `$item` is empty?
return !empty($item['is_public']);
```
If `$item` is empty (that means it's a non-CiviCRM page) even then it returns `false` because the logic is incomplete. It doesn't check if the `$item` is empty.
This [fix](https://github.com/civicrm/civicrm-core/pull/18322) addresses both these issues.
Example use-case
----------------------------------------
1. Click on **Administration -> Customise data and screens -> Display preference**.
2. Go to `Theme` section
Current behaviour
----------------------------------------
![3ffa703e-9774-4224-abb0-c967b809dbef](/uploads/821e12db022a5accb4c5d8f7d8063ae3/3ffa703e-9774-4224-abb0-c967b809dbef.png)
Proposed behaviour
----------------------------------------
![3403e6d0-6a80-4e20-ac50-bd24190cc858](/uploads/d9efbd1d109e2bb15b0938debda8e32e/3403e6d0-6a80-4e20-ac50-bd24190cc858.png)5.31.0https://lab.civicrm.org/dev/core/-/issues/1356Add user friendly way to report issues2023-01-19T05:03:35ZRichAdd user friendly way to report issues
We should have a way from within CiviCRM to provide the user with a template they can use to submit an issue.
See https://github.com/civicrm/civicrm-core/pull/15665#issuecomment-548268840
Having an "issue reporting" helper could just...
We should have a way from within CiviCRM to provide the user with a template they can use to submit an issue.
See https://github.com/civicrm/civicrm-core/pull/15665#issuecomment-548268840
Having an "issue reporting" helper could just do that paperwork for me so I could copy and paste.
- might reduce the barrier to contributing
- might get more accurate data (civicrm version, nginx, php, browser...) leading to quicker fixes
- we have better control of the template - could ask questions intereactively to generate it.
- we would have space to explain things like gitlab/hub to users.
- (one day could use api to search/report to gitlab!)homotechsualhomotechsualhttps://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/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/3444Contribution balance token2023-09-24T22:55:47Zmagnolia61Contribution balance tokenOverview
----------------------------------------
Would it be technically easy and functional desired to have contribution balance token?
Example use-case
----------------------------------------
We would like to advocate for an contrib...Overview
----------------------------------------
Would it be technically easy and functional desired to have contribution balance token?
Example use-case
----------------------------------------
We would like to advocate for an contribution balance token
Current behaviour
----------------------------------------
1. We want to send our customers an email with the amount due, or the amount that is pending refund.
2. There is a balance field in the event participant context. But this is absent in the contribution context.
Proposed behaviour
----------------------------------------
A custom token field like {contribution.balance} is available in the contribution context
Comments
----------------------------------------
Eileen opened an issue to enable a balance field for api4 (and an total paid field): https://lab.civicrm.org/dev/core/-/issues/2890https://lab.civicrm.org/dev/core/-/issues/3035Notify updates to unapproved extensions2023-11-13T05:03:21ZwmortadaNotify updates to unapproved extensionsOverview
----------------------------------------
I've noticed that updates aren't flagged for some CiviCRM extensions. In this particular case we weren't being shown updates for the [Transactional Emails Extension](https://civicrm.org/...Overview
----------------------------------------
I've noticed that updates aren't flagged for some CiviCRM extensions. In this particular case we weren't being shown updates for the [Transactional Emails Extension](https://civicrm.org/extensions/transactional-emails). I'm guessing that this is because this particular extension isn't approved for automated distribution.
I think it makes sense that some extensions aren't shown in the UI for installation, but if they have been installed and they are listed on civicrm.org I think the UI should flag when there is an update. I had presumed that the updates would show up so was surprised that they hadn't.
Current behaviour
----------------------------------------
System Status only shows available updates for extensions that are approved for automated distribution.
Updates for other extensions aren't shown so the user may assume that the extension is up to date.
Proposed behaviour
----------------------------------------
System Status shows available updates for **all** extensions that are listed on civicrm.org.
Comments
----------------------------------------
Potentially this could be extended to also show updates for extensions that aren't listed on civicrm.org but are publicly available on GitLab or GitHub.
Related issue #2548
Workarounds
----------------------------------------
For those that can't wait for this to be implemented in core, there is an extension that provides this functionality here: https://lab.civicrm.org/extensions/allavailableupgrades
See also this post on StackExchange about a [settings change that will show all available upgrades](https://civicrm.stackexchange.com/questions/39299/does-the-system-status-check-and-upgrade-version-check-only-list-available-updat/).https://lab.civicrm.org/dev/core/-/issues/2916Alter default frequency for scheduled reminders job2021-11-05T17:46:04ZwmortadaAlter default frequency for scheduled reminders jobAs [discussed on Mattermost](https://chat.civicrm.org/civicrm/pl/hcnos88x3pdzdgfkqbjbdktggh) with @bgm, the default for sending scheduled reminders is daily. This seems too infrequent, particularly if you have event reminders to be sent ...As [discussed on Mattermost](https://chat.civicrm.org/civicrm/pl/hcnos88x3pdzdgfkqbjbdktggh) with @bgm, the default for sending scheduled reminders is daily. This seems too infrequent, particularly if you have event reminders to be sent and want to send a reminder e.g. 2 hours before the event starts.
I propose that the default is changed to hourly.
The default is set here: https://lab.civicrm.org/dev/core/-/blob/ca09f9073ec01ba0a67e1c435213dea878069299/xml/templates/civicrm_data.tpl#L16835.45.0https://lab.civicrm.org/dev/core/-/issues/2638Money - create new Civi:: facade - now format helper2023-09-24T22:53:25ZeileenMoney - create new Civi:: facade - now format helperOur CRM_Utils_Money class wound up a mess so we talked about creating a new supported/tested/readable class to put our money functions in and this class would be supported for use by core & external code.
@seamuslee did a first cut here...Our CRM_Utils_Money class wound up a mess so we talked about creating a new supported/tested/readable class to put our money functions in and this class would be supported for use by core & external code.
@seamuslee did a first cut here https://github.com/civicrm/civicrm-core/pull/20296 which highlighted some of the issues / complexity
I made comments there but I've moved them to this gitlab
Useful framing by @jaapjansma
CiviCRM has the following ways of displaying data:
- On the screen in back office (this is the language and locale of the logged in user)
- On the screen in front office screens (such as registering for an event, this should be the sites locale and language)
- In communications with the contact, such as letters and pdf. We should use the language and locale of the contact
Ideally we should also have a setting for the locale and not only the language.
Looking at @jaapjansma's list it seems that at the end of the day we want (these don't have to be all working / added now but I think we might want to comment in the intent into the class)
```
Money()->formatMachine($amount, $currency);
Money()->formatSiteLocale($amount, $currency);
Money()->formatUserLocale($amount, $currency, $contactID); // defaults to logged in user
Money()->formatSpecifiedLocale($amount, $currency, $locale);
```
We also have 2 other variables in the mix - precision & noCurrencySymbol
I tend to prefer to use separate functions for noCurrencySymbol - eg
```
Money()->formatNumericOnlyMachine($amount, $currency);
Money()->formatNumericOnlySiteLocale($amount, $currency);
Money()->formatNumericOnlyUserLocale($amount, $currency, $contactID); // defaults to logged in user
Money()->formatNumericOnlySpecifiedLocale($amount, $currency, $locale);
```
but it could be a consistent parameter in the other functions
On the precision question we have
- fixed precision
- no rounding
- currency specific precision
Perhaps this is a parameter on all the above functions ('fixed', NULL or 'by_currency' ) - I personally prefer documenting that in the comment block than using a constant although some people like constants
This is quickly getting us back into the confusion of CRM_Core_Money which this PR was intended to get us away from but hopefully we can figure out the set of signatures we want this time AND remember what they actually mean!
Also - we probably want functions that returns the actual Money object - not just the output
Note that where we want to be is that the CRM_Utils_Money class can be an internal class and the Civi::Money is an external class - so how we deal with the thousand separator in CRM_Utils_Money can change over time