CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-09-24T22:53:25Zhttps://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 timehttps://lab.civicrm.org/dev/core/-/issues/2635Download latest version of an extension without installing2023-08-19T05:03:24Zmagnolia61Download latest version of an extension without installingOverview
----------------------------------------
It would be good to be able to download the latest version of an extension without installing it for security reasons.
Current behaviour
----------------------------------------
1. an ex...Overview
----------------------------------------
It would be good to be able to download the latest version of an extension without installing it for security reasons.
Current behaviour
----------------------------------------
1. an extension that was previously installed but since disabled or uninstalled remains present in the extension directory
2. the extensions management ui provides buttons to download and install
![image](/uploads/c618c97b6ec39f98d9b884b0211187fb/image.png)
Proposed behaviour
----------------------------------------
1. an extension that was previously installed but since disabled or uninstalled remains present in the extension directory
2. the extensions management ui provides buttons to "download" or to "download and install"
Comments
----------------------------------------
Of course best practice is to remove any extension which is uninstalled, but disabled extensions are also present in the filesystem. Being able to update extensions that are not installed, improves security as the latest stable code can be downloaded.https://lab.civicrm.org/dev/core/-/issues/2634Membership api for v42021-08-25T22:27:29ZeileenMembership api for v4Apiv4 doesn't have a membership api yet - mostly because of issues with the membership.create process.
I caught up with @kcristiano this week & we fleshed out what the 3 issues are
1) Membership api does financial stuff including creat...Apiv4 doesn't have a membership api yet - mostly because of issues with the membership.create process.
I caught up with @kcristiano this week & we fleshed out what the 3 issues are
1) Membership api does financial stuff including creating line items and in some cases creating contribution. I worked through getting rid of one of these bits of magic, converting the back office form to use Order api when setting up a new recurring membership. Getting review on this was slow going so it will take a long time to convert other places. (I have started on the batch membership form & Kevin is going to help with review there).
However, I made a proposal that Kevin agreed with that we simply don't touch ANY of that financial stuff if $params['version'] === 4. The idea is that the handling (which may or may not be right) for apiv3 and for those calls that still call the BAO directly will be unchanged but for v4 callers need to either
a) call the order api (which we will fix to call the v4 membership api internally) or
b) create their own line items. Note that memberships without contributions actually should have line items according to the model.
I will work on this once we have fixed some issues with the order api's integrity - https://github.com/civicrm/civicrm-core/pull/20656 is the most obvious but the intent is to get the extra cover that deprecating our random magic will provide https://github.com/civicrm/civicrm-core/pull/20678 too. (This is not a big piece of work but it requires fairly experienced review )
2) Membership date handling for new memberships is in the v3 api (and the form layer). I did a patch for this. https://github.com/civicrm/civicrm-core/pull/20759 -
3) Membership date handling for renewals. Apiv3 has some magic around this that is not in the BAO. I have come to the conclusion we can handle this by
-- using the Order->payment flow. In other words the dates are calculated at the point when Payment.create is added, using the membership_num_terms as stored in https://github.com/civicrm/civicrm-core/pull/20672
-- OR - if that flow won't work for people for any reason, they can pass in all the date values.5.42.0https://lab.civicrm.org/dev/core/-/issues/2629Participant Status: pending refund can have two conflicting meanings2024-01-17T05:03:29Zmagnolia61Participant Status: pending refund can have two conflicting meaningsOverview
----------------------------------------
With partial payments and partial refunds becoming mainstream in CiviCRM, I think it is time to reconsider the connection between contribution status and participant status. I think there...Overview
----------------------------------------
With partial payments and partial refunds becoming mainstream in CiviCRM, I think it is time to reconsider the connection between contribution status and participant status. I think there are more than one aspects of this, but I will focus on 'pending refund'
Example use-cases
----------------------------------------
1. change the payment or price-set to make a partial refund necessary
2. cancel the participant to make a (partial) refund necessary
Current behaviour
----------------------------------------
Currently a participant status: Pending Refund defaults as a positive count.
But there are two scenario's that can cause this participant status:
1. there is a contribution total that is higher than the total event fee amount
2. there has been a cancellation for the event and the fee is pending to be refunded
In scenario 1: The participant is still expected to attend the event
In scenario 2: The participant will not attend the event
Proposed behaviour
----------------------------------------
I think it is becoming troublesome to relate the contribution status with the event status.
The default is that 'Pending refund' counts positive towards attendance.
Two proposals could be
a) to remove participant statuses connected with the contribution
- may cause other difficulties, might me the best in the long end
b) to add a new status and to differentiate between two types of pending refund scenarios:
- Pending refund (cancelled)
- Pending refund (attending)
First one would have count status 0, second one count status 1
Comments
----------------------------------------
Any thoughts on this one? Can I find agreement on this proposal?https://lab.civicrm.org/dev/core/-/issues/2624Line items not visible on recurring contribution2021-07-28T14:48:48ZjaapjansmaLine items not visible on recurring contributionWhen creating a new contribution recur with a contribution page and a price set with multiple line items. The line items are not stored within the contribution recur entity.
**Steps to reproduce**
1. Create a new price set (Financial t...When creating a new contribution recur with a contribution page and a price set with multiple line items. The line items are not stored within the contribution recur entity.
**Steps to reproduce**
1. Create a new price set (Financial type donation)
2. Create a price set field (Financial type Campaign donation)
3. Create a second price set field (Financial type Products)
4. Create a contribution page:
Financial type: donation
Amounts tab: Payment Processor: test processor
Amounts tab: Contributions amount section enabled: checked
Amounts tab: Price set: _select the created price set_
Amounts tab: Recurring contributions: check
5. Create a new contribution recur through the contribution page
6. Lookup the contribution recur on the Contact Summary
**Expected result**
Showing the line items. The total amount is correct.
**Actual result**
Line items are not visible at the contribution recur.
Below a screenshot of the contribution
![Screenshot_20210520_211830](/uploads/2447b95df431002e4405559a72fec4b5/Screenshot_20210520_211830.png)
And of the recurring contribution
![Screenshot_20210520_211918](/uploads/4036a932904649bbaa7c0d93b13879fb/Screenshot_20210520_211918.png)
**Possible solution**
I have looked up the line items in the database and there are no line items linked to the recurring contribution.
So the possible solution would exists of two steps:
1. Connect the line items to contribution recur
2. Make the line items visible in a similar way as on the contribution.
**Remarks**
Creating a new contribution with the `contribution.repeattransaction` api based on the first contribution and the recurring contribution correctly creates the line items at the contribution level.
**Funding**
I have some funding to work on this. So PR's might follow soon.
**PRs**
* ~~Fix for saving line items at the recurring contribution: https://github.com/civicrm/civicrm-core/pull/20398~~
* Fix for showing the line items from the template contribution: https://github.com/civicrm/civicrm-core/pull/20399
* Fix for excluding template contributions from reports: https://github.com/civicrm/civicrm-core/pull/20450
* Fix for searching template contributions: https://github.com/civicrm/civicrm-core/pull/20451
* Fix for excluding template contributions on the contact summary tab: https://github.com/civicrm/civicrm-core/pull/20452
* Fix for adding a button view template on the recurring contributions tab: https://github.com/civicrm/civicrm-core/pull/20685
* ~~Fix for creation of template contributions: https://github.com/civicrm/civicrm-core/pull/20453~~
**To do**
* Update user documentation
* Make sure an upgrade path exists
See also financial#65.41.0jaapjansmajaapjansmahttps://lab.civicrm.org/dev/core/-/issues/2622APiv4 does not handled display name when only email is provided2021-05-27T22:27:30ZeileenAPiv4 does not handled display name when only email is providedDemonstrated in the test https://github.com/civicrm/civicrm-core/pull/18865
Options are
1) accept that it's OK to pass 'email' to contact.create bao even though it is not a 'contact field' or
2) do an extra check on every primary email...Demonstrated in the test https://github.com/civicrm/civicrm-core/pull/18865
Options are
1) accept that it's OK to pass 'email' to contact.create bao even though it is not a 'contact field' or
2) do an extra check on every primary email save - note that historically parsing the smarty greeting tpl for the display name is expensive so we'd need to only set if empty.
I'm on the fence about the performance of 2 - most of our db locks these days are actually db insert locks on the email table for some reason (now that we have eliminated the acl related locks)
@colemanw - but to gitlab as promisedhttps://lab.civicrm.org/dev/core/-/issues/2609Move full text search to an extension?2023-08-11T05:03:16ZeileenMove full text search to an extension?We just hit an issue where someone crashed our db with the full text search. It feels like something that should be deliberately enabled rather than available by default....We just hit an issue where someone crashed our db with the full text search. It feels like something that should be deliberately enabled rather than available by default....https://lab.civicrm.org/dev/core/-/issues/2584Proposal - Separation of Default Language for contacts from the default Language2023-08-05T05:03:23ZVangelisPProposal - Separation of Default Language for contacts from the default Language## Scenario
Right now, the preferred communication language for new contacts is bound to what the site's default language is in or to 'use language in use at the time' is in but as it seems, neither of them fits the scenario below:
A m...## Scenario
Right now, the preferred communication language for new contacts is bound to what the site's default language is in or to 'use language in use at the time' is in but as it seems, neither of them fits the scenario below:
A multinational organization in country A has 2 (or more) enabled languages in their Drupal configuration, thus into each user's profile. They want to have the preferred communication language for each of their contacts set to country A's language while the menus needs to be retained in English by force.
## How to replicate
1. On a Drupal 7 site, allow 2 languages, set the English as default
1. In CiviCRM > Administer > Localisation, set:
* the default language to the non-English
* Inherit CMS language to 'Yes'
* Available Languages: Add the 2 languages that you've added in Drupal
* Default Language for contacts: Any (I tried all options)
* Logout and login again
1. Try to create a new contact
## Possible solution
The suggestion is besides what already is in the selector, to add also a list of available languages to the field 'Default Language for contacts' so that we can enforce a language.
I've already worked on a patch that does the above, I'm not sure if my approach of this idea hides any potentials flaws.
Selector before:
![image](/uploads/f19b2c389213236f81e0df86a5335d33/image.png)
Selector after:
![image](/uploads/75e42b33fe04528f1e2b0d298b03ac30/image.png)
Example: Danish
![Screenshot_from_2021-05-03_09-58-12](/uploads/b12950fd7f96ee0604c839ee1bcbb61e/Screenshot_from_2021-05-03_09-58-12.png)
![Screenshot_from_2021-05-03_09-56-50](/uploads/96302b55f8779875e89b5b565cdd07d0/Screenshot_from_2021-05-03_09-56-50.png)
---
PR is [here - 20214](https://github.com/civicrm/civicrm-core/pull/20214)https://lab.civicrm.org/dev/core/-/issues/2570Option to identify 'deceased' contacts when viewing relationships2023-07-31T05:03:26ZrebeccatregennaOption to identify 'deceased' contacts when viewing relationshipsOverview
----------------------------------------
Marking a contact record as 'is_deceased' doesn't currently appear to have any impact on the contact's relationships, however, it would be extremely useful when viewing relationships on c...Overview
----------------------------------------
Marking a contact record as 'is_deceased' doesn't currently appear to have any impact on the contact's relationships, however, it would be extremely useful when viewing relationships on contact records to know whether one of the contacts involved in the relationship is deceased.
Current behaviour
----------------------------------------
- John is the 'partner of' Fiona
- John is deceased but the relationship (as not manually changed) remained active
- A system user is taking a call from Fiona and looks up her contact record and casually asks how John is, as nothing indicates his passing on the relationship tab thus causing upset and potentially losing a donor
Proposed behaviour
----------------------------------------
Add an icon to the relationship to indicate the contact is deceased.https://lab.civicrm.org/dev/core/-/issues/2557Add hook support for Report tabs.2023-08-06T05:03:24ZyashodhaAdd hook support for Report tabs.Add hook support for Report tabs.Add hook support for Report tabs.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/2551Proposal - add support for defining 'fields' within json blobs2023-07-29T05:03:23ZeileenProposal - add support for defining 'fields' within json blobsThis covers a discussion at https://chat.civicrm.org/civicrm/pl/pt4nizctz7db8xecrq1triy38e
whereby we have a few entities with configuration options that can't be adequately captured in fields. We sort of make this work with payment_pro...This covers a discussion at https://chat.civicrm.org/civicrm/pl/pt4nizctz7db8xecrq1triy38e
whereby we have a few entities with configuration options that can't be adequately captured in fields. We sort of make this work with payment_processor by having fields that we kinda rename via the payment_processor_type table and as long as there are only 4 fields it's fine. However, it's not a great structure.
I'm working on a monolog extension and like payment processor and geocoders the configuration options desired by the service varies - but it's not 100% open ended - ie we don't want to just pass through 'whatever'. The best data model to store this is a json blob- however, we then have no UI knowledge of what would go in there and afform is unable to present this field in a UI-friendly way
We looked at the idea of having something like
```
<field>
<name>contact_type</name>
</field>
<field>
<name>contact_sub_type</name>
</field>
<field>
<name>options</name>
<type>text</type>
<serialize>json</serialize>
<schema-callback>CRM_My_Schema::getFields</schema-callback>
<schema-watch>contact_type,contact_sub_type</schema-watch>
</field>
```
Where the UI layer would need to implement the ability to watch the fields defined as schema-watch and update the UI based on it (presumably only for fields that are ALSO already displayed)
A simple xml definition of subfields might look like https://gist.github.com/totten/84c140310d4adc9b5d3842b5d3364a9e - which could be rendered by a generic function.
@totten @seamuslee - anything else you think is important to transfer over here?https://lab.civicrm.org/dev/core/-/issues/2548Improvements to the extensions UI and update notifications.2023-11-12T05:03:27ZhomotechsualImprovements to the extensions UI and update notifications.Overview
----------------------------------------
_Following a post on MatterMost from @DaveD we discussed how valuable the extension he wrote about and posted here: https://civicrm.org/node/11234 is and I think it's worth working into c...Overview
----------------------------------------
_Following a post on MatterMost from @DaveD we discussed how valuable the extension he wrote about and posted here: https://civicrm.org/node/11234 is and I think it's worth working into core. @KarinG then raised a related and equally valuable point that extensions managed outside of CiviCRM e.g. with Git or just existing on the filesystem are marked Green like up-to-date extensions when actually we lack enough data to determine if these extensions are, in fact, up-to-date._
_Therefore I would like to fold Dave's extension's functionality into CiviCRM core and make changes to the extensions UI to remove the green highlight and possibly at a notice to extensions that don't exist on CiviCRM.org to indicate that we cannot determine whether these are up-to-date and extension authors should check manually._
In the discussion I proposed the following:
**Core:**
* Checks for extension updates if extension is on `c.o/extensions` but only updates those approved for in-app (at the moment at least!)
* Displays a message on extensions it doesn't manage (that don't exist on `c.o`) to the effect of "We can't check for updates for this extension." - similar to how Drupal displays a notice on git-managed or custom extensions.
**Contrib:**
* Could provide for update checking for git-managed and possibly custom extensions.
I have time available to work on this last week of April.homotechsualhomotechsualhttps://lab.civicrm.org/dev/core/-/issues/2545Free memberschip sign up (eg. prayerteam) assumes contribution involved2023-07-29T05:03:22Zmagnolia61Free memberschip sign up (eg. prayerteam) assumes contribution involvedOverview
----------------------------------------
Managing memberships in civicrm currently pretty much assumes a contribution is involved. Which is not the case for many forms of memberships. It is even not possible to create a membersh...Overview
----------------------------------------
Managing memberships in civicrm currently pretty much assumes a contribution is involved. Which is not the case for many forms of memberships. It is even not possible to create a membership sign up page without using a contribution page!
Right now for our summercamps it's pretty strange for people to sign up to become a member of the prayerteam to "review their contribution". Although technically they give their contribution in the form of prayer one could argue.
Example use-case
----------------------------------------
1. Create a membership sign up page in CiviCRM for a free membership
2. Look at the wording of the sign-up button
Current behaviour
----------------------------------------
The current button to sign up for a membership says 'review your contribution'.
Proposed behaviour
----------------------------------------
The button text here should be editable, or for signing up for free memberships a different default wording should be used.
Comments
----------------------------------------
Consistent UI would be I guess to be able to create a membership sign up page from the membership menu. Underwater this could be a contribution page with or without fees involved.https://lab.civicrm.org/dev/core/-/issues/2544Move Contact Layout Editor to a core extension2023-07-27T05:03:20ZcolemanwMove Contact Layout Editor to a core extensionAt some point, it would be good to get rid of the hard-coded contact summary screen, and just let the Contact Layout Editor manage the display.
As an intermediary step, it probably makes sense to move Contact Layout Editor into the core...At some point, it would be good to get rid of the hard-coded contact summary screen, and just let the Contact Layout Editor manage the display.
As an intermediary step, it probably makes sense to move Contact Layout Editor into the core tarball (via distmaker import), or the `ext/` directory of the core repo.
Today might not be the day for that, but logging some notes on it anyway:
- Today, the only benefit of moving the extension into core is it would be more visible to end-users.
However, in the future, benefits might include:
- Easier simultaneous development of extension & core with no version conflicts.
- Possible to enable the extension by default.
- Possible to rip out redundant functionality from core.
Challenges
- There isn't an easy upgrade path when an extension is moved into core; you end up with 2 copies of the extension
- Currently, the extension scanner does not give the core `ext/` directory top priority, which means older versions of the extension outside core would take precedence.
Considerations
- As handy as it is, Contact Layout Editor still uses smarty to render the page.
- Maybe the end-game is to make that page an Afform instead. However, that day is a long way off given Afform's current capabilities.https://lab.civicrm.org/dev/core/-/issues/2540Print report permissions2022-06-02T18:01:45ZDevAppPrint report permissionshttps://civicrm.stackexchange.com/questions/22261/how-to-hide-configuration-tabs-of-a-report-with-the-print-to-pdf-action-remain
But when disabling the “access Report Criteria” permission, the "Print report" and "Print to PDF" functions...https://civicrm.stackexchange.com/questions/22261/how-to-hide-configuration-tabs-of-a-report-with-the-print-to-pdf-action-remain
But when disabling the “access Report Criteria” permission, the "Print report" and "Print to PDF" functions on a report appear, but do not function.
The user is just redirected back to the same report.
The functionality appears broken, as the report gives the option to print but it does not work without the additional permission.
Possible solutions:
- Give permissions to print if access report permissions are already granted and the user can view a report
- Add a new print permission and only show the print option if enabled for user
- Hide existing print options if view report criteria not selected, as the user can't print5.51.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/2522Afform - Add submit actions2022-04-01T00:40:25ZcolemanwAfform - Add submit actionsOther form-builder libraries typically have some options for post-submit, e.g.
1. Display a popup message to the user (maybe with token replacement).
2. Display a full-screen message (replacing the body of the form).
3. Redirect to anot...Other form-builder libraries typically have some options for post-submit, e.g.
1. Display a popup message to the user (maybe with token replacement).
2. Display a full-screen message (replacing the body of the form).
3. Redirect to another form/page.
All of those would be nice-to-have options. `#3` feels like the most critical (and also the easiest to code).colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/2508Improve unit tests by checking if session::setStatus sets errors2023-07-20T05:03:20ZDaveDImprove unit tests by checking if session::setStatus sets errorsThe alert popups that come up in civi happen two ways: One is via javascript-only, which is difficult to test in the regular phpunit tests, and the other is via CRM_Core_Session::setStatus().
One approach is as in https://github.com/civ...The alert popups that come up in civi happen two ways: One is via javascript-only, which is difficult to test in the regular phpunit tests, and the other is via CRM_Core_Session::setStatus().
One approach is as in https://github.com/civicrm/civicrm-core/pull/19939 but it's not workable in practice because it generates too much extra visual noise on screen. However it pointed out some tests which could be improved. See also https://github.com/civicrm/civicrm-core/pull/19939#issuecomment-809683859 for some additional details. The last one here about financialtype I think I saw a variation of on-screen once and was just that the type of popup was wrong (i.e. using error instead of success).
```
not ok 599 - Error: CRM_Contact_Form_Task_EmailCommonTest::testPostProcessWithSignature
not ok 603 - Error: CRM_Contact_Form_Task_UseraddTest::testUserCreateFail
not ok 653 - Error: CRM_Contact_Page_View_UserDashBoardTest::testDashboardContentEmptyContact
not ok 654 - Error: CRM_Contact_Page_View_UserDashBoardTest::testDashboardContentContributionsWithInvoicingEnabled
not ok 655 - Error: CRM_Contact_Page_View_UserDashBoardTest::testDashboardContentContributions
not ok 698 - Failure: CRM_Contribute_BAO_ContributionRecurTest::testAutoRenewalWhenOneMemberIsDeceased
not ok 944 - Error: CRM_Core_BAO_AddressTest::testSharedAddressChaining3
not ok 1115 - Error: CRM_Core_BAO_SettingTest::testGetItemGroup_Override
not ok 1116 - Error: CRM_Core_BAO_SettingTest::testDefaults
not ok 1117 - Error: CRM_Core_BAO_SettingTest::testOnChange
not ok 1118 - Error: CRM_Core_BAO_SettingTest::testSetCivicrmEnvironment
not ok 1119 - Error: CRM_Core_BAO_SettingTest::testPseudoConstants
not ok 507 - Error: api_v3_ContactTest::testMergedGetWithPermanentlyDeletedContact
not ok 1382 - Failure: api_v3_JobTest::testProcessMembershipDeceased
not ok 1418 - Failure: api_v3_LoggingTest::testEnableDisableLogging
not ok 1522 - Failure: api_v3_MembershipStatusTest::testDeceasedMembershipInline
not ok 280 - Error: Civi\Test\ExampleHookTest::testPageOutput
fatal error - ext/oauth-client/tests/phpunit/CRM/OAuth/MailSetupTest.php:18
not ok 2 - Failure: Civi\Financialacls\FinancialTypeTest::testChangeFinancialTypeName
```https://lab.civicrm.org/dev/core/-/issues/2505CiviReport does not localize custom fields of type Number2023-02-16T13:30:23ZjaapjansmaCiviReport does not localize custom fields of type Number**How to reproduce**
1. Set localization settings: **decimal separator** to `,` and **thousand separator** to `.`
2. Add a custom group for cases
3. Add a custom field of **Type** `Number` and **Field type** `Text`
4. Enter a value such...**How to reproduce**
1. Set localization settings: **decimal separator** to `,` and **thousand separator** to `.`
2. Add a custom group for cases
3. Add a custom field of **Type** `Number` and **Field type** `Text`
4. Enter a value such as `1,234.56` which is localized `1.234,56`
5. Create a new CiviCase detail report. Check the column to display the custom field.
**Expected result**
Value of the custom field displayed as `1.234,56`
**Actual result**
Value of custom field is displayed as `1234.56` (note the decimal separator and the missing thousand separator).
**Comment**
The display value of custom number fields is also broken on the manage case screen.
We have a function `CRM_Utils_Money::formatLocaleNumericRoundedForDefaultCurrency` to format money fields. However we do not have such a function for number fields with a decimal. So basically nowhere in CiviCRM a number field is formatted according to localization settings. Unless the smarty modifier `|crmNumberFormat` is used in the template.
A fix should probably happen in `CRM_Core_BAO_CustomField::formatDisplayValue`, see https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/CustomField.php#L1187
However I am not exactly sure how to fix this as I could not find a number formatting function such as we have for the money field. Does such a function exists and if so where do I find it?5.38.0https://lab.civicrm.org/dev/core/-/issues/2504CiviReport does not localize custom date fields when exporting to CSV2021-04-09T13:32:59ZjaapjansmaCiviReport does not localize custom date fields when exporting to CSVCiviReport does not localize custom fields of type Date
**How to reproduce**
1. Set localization settings: **Date Format Complete date** to `%d-%m-%Y`
2. Add a custom group for cases
3. Add a custom field of Type Date and no time.
4. E...CiviReport does not localize custom fields of type Date
**How to reproduce**
1. Set localization settings: **Date Format Complete date** to `%d-%m-%Y`
2. Add a custom group for cases
3. Add a custom field of Type Date and no time.
4. Enter a value such as 31-04-2021 (1st of april 2021)
5. Create a new CiviCase detail report. Check the column to display the custom field.
6. Export the report to CSV
**Expected result**
Value of the custom field displayed as `01-04-2021` as it is shown in the report and according to the localization setting.
**Actual result**
Value of custom field is displayed as `2021-04-01` which is ISO format.
**Comment**
The format for iso format is hard coded in: https://github.com/civicrm/civicrm-core/blob/master/CRM/Report/Utils/Report.php#L270
I am not sure if that is the desired behavior. I dont think so as the custom fields of type money are localized into a CSV export. So I would argue that the date should also be formatted according to the localization settings.https://lab.civicrm.org/dev/core/-/issues/2500Run localised unit tests2023-07-18T05:03:23ZBjörn EndresRun localised unit testsOverview
----------------------------------------
Tickets like #2164 highlight again that we have a test gap for localised environments.
Example use-case
----------------------------------------
See #2164
Current behaviour
------------...Overview
----------------------------------------
Tickets like #2164 highlight again that we have a test gap for localised environments.
Example use-case
----------------------------------------
See #2164
Current behaviour
----------------------------------------
Currenlty, afaik, the unit tests are only run in the the native language (en_US).
Proposed behaviour
----------------------------------------
If there is an automated/easy way to do so, we should run the unit test suite in selected (or all?) localisations. Maybe not all the time (as in the PR hooks), but e.g. before a release.
Comments
----------------------------------------
I'm sure somebody has already looked into that, and I'd like to know what the main obstacles were.