CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-02-08T10:45:03Zhttps://lab.civicrm.org/dev/core/-/issues/4940Proposal to Change the Invoice date in the default Invoice message template t...2024-02-08T10:45:03ZeileenProposal to Change the Invoice date in the default Invoice message template to contribution.receive_dateThis spins off one discussion topic from https://lab.civicrm.org/dev/core/-/issues/1403 -
As part of our general effort to make the WorkflowMessage templates operate independently of the quickform layer (ie be available as actions from ...This spins off one discussion topic from https://lab.civicrm.org/dev/core/-/issues/1403 -
As part of our general effort to make the WorkflowMessage templates operate independently of the quickform layer (ie be available as actions from SearchKit etc) we should clarify which value is used for the invoice_date in the default message template that we ship from \`{$invoice_date}\`
```html
{domain.now|crmDate:"Full"}
or
{contribution.receive_date|crmDate:"Full"}
```
If we change the default it will affect new installs and un-customised templates. I'm not proposing any push upgrade on the customised templates at this stage so for most invoice-using sites this will be no change at this point. However, I am going to try to 'complete' the variable to token changes in this template so that anyone who is updating their customised template or installing a new site is using the tokens (& hence will be able to benefit from message previewability via MessageAdmin now & sending & rendering from outside QF if they install a relevant extension /when we add to core).
Potentially if we want to make it clear to people that they can change it we can use one of
```html
{domain.now|crmDate:"Full"}{* Code comment: - You can replace the domain.now token with this to show the contribution date instead {contribution.receive_date|crmDate:"Full"} *}
OR
{contribution.receive_date|crmDate:"Full"}{* Code comment: - You can replace the domain.now token with this to show the current date instead with {domain.now|crmDate:"Full"} *}
```
Note that the assumption in this gitlab is that any change would be opt in for existing sites (since basically everyone who uses invoices puts a logo in there). There is a proposal at https://github.com/civicrm/civicrm-core/pull/28630 that would force a change on everyone. I'm not convinced we should do a force update because it is pretty clear from the code & code history that the use of now was a deliberate attempt to meet a use case. However I have added an option to the emjoi poll below to allow people to vote for a forced update - basically a string_replace on upgrade.
EMOJI POLL Options
1) :boom: Change to {domain.now|crmDate:"Full"}
2) :man_dancing_tone2: Change to {contribution.receive_date|crmDate:"Full"}
3) :avocado: Change to 1 with additional in-code comments per above
4) :bellhop: Change to 2 with additional in code comments per above
5) :pick: Do 2 with a forced upgrade to replace {$invoice_date} with the above with {contribution.receive_date|crmDate:"Full"}https://lab.civicrm.org/dev/core/-/issues/4923Possible performance improvement: When a custom field is disabled, automatica...2024-02-08T14:11:58ZDaveDPossible performance improvement: When a custom field is disabled, automatically uncheck the searchable box and remove the db indexSuppose you have about 20 fields in the custom group and they were almost all searchable (had the searchable box checked). Over time let's say half get disabled. The indexes are still in the db, and the searchable checkbox is meaningless...Suppose you have about 20 fields in the custom group and they were almost all searchable (had the searchable box checked). Over time let's say half get disabled. The indexes are still in the db, and the searchable checkbox is meaningless because they don't appear anywhere anyway.
If the table is large, those indexes potentially cause trouble with no benefit.
If you go to re-enable, it's true it won't automatically re-check the searchable box and recreate the index, but there's no real harm, you just go back in and check the box.
An alternative to automatically doing this would be a status check: "The following fields are disabled but marked searchable. Consider making them unsearchable to improve performance on large databases."https://lab.civicrm.org/dev/core/-/issues/4915Sending an invoice per email goes to primary address, not to billing2024-02-09T23:08:39ZMariaVSending an invoice per email goes to primary address, not to billingI have found this post on StackExchange:
https://civicrm.stackexchange.com/questions/9094/sending-an-invoice-per-email-goes-to-primary-address-not-to-billing
I tested on CiviCRM 5.68.1 and it seems that CiviCRM still only sends the invo...I have found this post on StackExchange:
https://civicrm.stackexchange.com/questions/9094/sending-an-invoice-per-email-goes-to-primary-address-not-to-billing
I tested on CiviCRM 5.68.1 and it seems that CiviCRM still only sends the invoice to the primary address.
What do you think about a setting 'send invoice email to Billing if it exists, otherwise send it to Primary'?
The setting could be optional so that nothing changes for users who want to keep it as it is.
Or is there any knowing extension already that I could not find?
Thanks in advance!https://lab.civicrm.org/dev/core/-/issues/4908Integrate Angular calendar for better usability2024-01-15T11:36:56ZshaneonabikeIntegrate Angular calendar for better usabilityI don't mind the existing calendar date picker, but I was wondering if there are other solutions that might work a bit better for usability. I came across this [Angular version](https://laros.io/using-angular-material-calendar-with-date-...I don't mind the existing calendar date picker, but I was wondering if there are other solutions that might work a bit better for usability. I came across this [Angular version](https://laros.io/using-angular-material-calendar-with-date-ranges-and-range-presets) (maybe there is an alternative)
Since we are already starting to use a lot of Angular I thought it could be something to consider. There is even a date range option, which could be interesting for other areas.
You can spin a demo on this stackblitz https://stackblitz.com/edit/angular-material-calendar-with-date-ranges-and-presets?file=package.json
What I like about it:
* When choosing a different year it automatically prompts to choose the month which is fairly logical and usable
* There is the possibility to set ranges (future integration with Events?)
* There is the option to have quick options like Last 30 days, Last 12 months, etc.
![Angular Material Calendar with Date Range and Range Presets](https://laros.io/images/angular-material-calendar-date-range.png)
Anyway it was just something I wanted to raise but it's not a high priority but could be a great enhancement.https://lab.civicrm.org/dev/core/-/issues/4902Unnecessary Event Breadcrumb When Editing Event2024-02-01T10:45:52ZthemakUnnecessary Event Breadcrumb When Editing EventWhen editing an event - the breadcrumbs that display are:
CiviCRM > CiviEvent Dashboard > Manage Events > Manage Events
The first 3 make sense, but the last one actually links to the edit event page that you are editing. While I have se...When editing an event - the breadcrumbs that display are:
CiviCRM > CiviEvent Dashboard > Manage Events > Manage Events
The first 3 make sense, but the last one actually links to the edit event page that you are editing. While I have seen breadcrumbs include the current page you are on, usually they are not linked and sometimes greyed out. To stay consistent with other parts of civi, I would remove the last breadcrumb. If we decide to keep for some reason - at very least it should say Configure Event - not Manage Event.
5.69.1 - also replicated in 5.71.alpha1
![Screenshot_2024-01-10_at_12.52.30_PM](/uploads/d6048cb7a5167aab82e3dca9c2aba45d/Screenshot_2024-01-10_at_12.52.30_PM.png)https://lab.civicrm.org/dev/core/-/issues/4899Modelling many to many relationships with Entity reference, SearchKit, FormBu...2024-01-17T18:18:18ZMichael McAndrewModelling many to many relationships with Entity reference, SearchKit, FormBuilder, ECK, etc.Creating this issue as a way to keep track of different bits of functionality that can be used together to model many to many relationships in CiviCRM as when you put this all together, I think it is quite a game changer for data modelli...Creating this issue as a way to keep track of different bits of functionality that can be used together to model many to many relationships in CiviCRM as when you put this all together, I think it is quite a game changer for data modelling in CiviCRM :grinning:
Might make sense to document this at some point soon, and it would be good to collect feedback on how people are finding this functionality, ideas for improvement, etc.
Also, if you have any budget that you would like to put towards this work: to improve it or build out more features, etc. please get in contact with @colemanw or me :heart:.
* Entity Reference fields - allows you to reference other entities in custom data fields effectively creating **one to many** relationships.
* Multivalue custom data sets - [now available to all entities](https://github.com/civicrm/civicrm-core/pull/27549) allowing you to model **many to many** relationships _with additional meta data_ about the relationship
* Searchkit support for [joining via EntityRef fields in multivalue custom data](https://github.com/civicrm/civicrm-core/pull/28721) - allows you to create searches that span many to many joins
* FormBuilder support - allowing for editing of many to many relationships in entities (could probably do with some improvement)
* [ECK](https://github.com/systopia/de.systopia.eck) which allows people to make arbitrary new entities that can be joined via these relationshipshttps://lab.civicrm.org/dev/core/-/issues/4895Can't delete unused financial types2024-01-15T11:38:54ZJonGoldCan't delete unused financial typesOverview
----------------------------------------
Not a regression!
Financial types associated with quick config price sets can never be deleted.
Reproduction steps
----------------------------------------
1. Create a new financial typ...Overview
----------------------------------------
Not a regression!
Financial types associated with quick config price sets can never be deleted.
Reproduction steps
----------------------------------------
1. Create a new financial type.
1. Create a new event.
1. Select the financial type as the default for the event and save.
1. Delete the event.
1. Delete the financial type.
Current behaviour
----------------------------------------
Obtuse error.
```
The following tables have an entry for this financial type: CRM_Price_DAO_PriceSet, CRM_Price_DAO_PriceFieldValue
```
Expected behaviour
----------------------------------------
Financial type should be deletable.
When the warning `Deleting this event will also delete associated Event Registration Page and Event Fee configurations. This action cannot be undone. Do you want to continue?` appears - continuing should delete the price set if it's a quick-config. But since I hope quick config dies a painful death, let's generalize to "deleting an event
Comments
----------------------------------------
Tangentially - you can't delete a price set that has any payments associated with it. This should be doable IMO and I believe is an artifact of pre-CiviAccounts (Civi 4.3) behavior when line items didn't exist.https://lab.civicrm.org/dev/core/-/issues/4848Nuance logging on API Authorization fails2023-12-07T00:07:32ZeileenNuance logging on API Authorization failsWhen an api request fails authorization one of 2 things happens
1) too much information is logged to our logs
2) too little information is logged.
In the former case some things like SearchKit rely on authorization failing appropriatel...When an api request fails authorization one of 2 things happens
1) too much information is logged to our logs
2) too little information is logged.
In the former case some things like SearchKit rely on authorization failing appropriately and logging can cause people to spend time debugging & trying to fix issues that are normal operation - ultimately both https://github.com/civicrm/civicrm-core/pull/28259 and https://github.com/civicrm/civicrm-core/pull/28260 fall in this category & nearly wound up opening up security to fix log noise
In the latter case an api call is failing authorization but it is hard to tell where. We recently hit this where the logged output was unhelpful because the backtrace being logged only got as far as the api call - we were not getting the trace from the exception itself (and the fail was happening on something the api called, not the main api). Hence we wound up altering the code to
```
\CRM_Core_Error::backtrace('API Request Authorization failed' . $apiRequest['action'] . " " . $apiRequest['entity'], TRUE);
\CRM_Core_Error::debug_var('backtrace', $e->getTraceAsString());
```
I think that it makes sense to be able to specify at the api call level when you don't care about logging exceptions (ie searchkit) but also to get some more info when you dohttps://lab.civicrm.org/dev/core/-/issues/4842Allow bulk-enabling extensions through UI2023-12-08T13:17:56ZnoahAllow bulk-enabling extensions through UICurrent behaviour
----------------------------------------
On Administer > System Settings > Extensions, only one extension can be acted on at a time.
Proposed behaviour
----------------------------------------
It should be possible to...Current behaviour
----------------------------------------
On Administer > System Settings > Extensions, only one extension can be acted on at a time.
Proposed behaviour
----------------------------------------
It should be possible to select multiple extensions and perform the same action (Install, Disable, Uninstall) on all of them.https://lab.civicrm.org/dev/core/-/issues/4824Ship Cors with Core2023-12-06T23:25:46ZeileenShip Cors with CoreIssue for tracking this proposal https://github.com/civicrm/civicrm-core/pull/24767Issue for tracking this proposal https://github.com/civicrm/civicrm-core/pull/24767https://lab.civicrm.org/dev/core/-/issues/4823Prevent more api calls from being added to the upgrader2023-12-06T23:23:32ZeileenPrevent more api calls from being added to the upgraderTicket created for tracking this initiative https://github.com/civicrm/civicrm-core/pull/24364Ticket created for tracking this initiative https://github.com/civicrm/civicrm-core/pull/24364https://lab.civicrm.org/dev/core/-/issues/4813CRM_Report_Form_Activity: Add Employer field, and "contact"-based custom fields2023-12-18T23:06:40ZAllenShawCRM_Report_Form_Activity: Add Employer field, and "contact"-based custom fieldsThis improvement is requested and sponsored by Stuart at Korlon.
We aim to implement the following changes to the CiviCRM core "Activity Detail" report (CRM_Report_Form_Activity):
- add "Current Employer" as an available column (not fi...This improvement is requested and sponsored by Stuart at Korlon.
We aim to implement the following changes to the CiviCRM core "Activity Detail" report (CRM_Report_Form_Activity):
- add "Current Employer" as an available column (not filter), to display with its Display Name, as a link to the employer contact
- auto-include "contact"-based custom fields (currently only "individual"-based custom fields get this treatment)
A PR is forthcoming. If it seems this is not a desirable improvement, please let me know in comments!
(Joinery reference: F#1317)https://lab.civicrm.org/dev/core/-/issues/4808Proposal: Phase out public profile fields and profile listings2023-12-06T22:08:58ZbgmProposal: Phase out public profile fields and profile listingsNow that SearchKit provides this functionality, we should consider deprecating "public profile fields" and profile listings. They are a recurrent source of confusion and a bad configuration can lead to a data leak (I stumble on them regu...Now that SearchKit provides this functionality, we should consider deprecating "public profile fields" and profile listings. They are a recurrent source of confusion and a bad configuration can lead to a data leak (I stumble on them regularly, with the help of the [symbiotic extension](https://civicrm.org/extensions/symbiotic).
I think we should:
- [ ] Add a feature flag (a hidden setting?) that hides
- ~~On Profiles, the option "Standalone Form or Directory"~~ (edit: I guess this might be needed for profile/edit of users with a checksum?)
- On Profile Fields: hide the visibility options, set them by default to "User and Admin only"
- [ ] Remove the feature from the Admin documentation
- [ ] Begin changing the interface to warn that we will be removing this feature, and that they can opt-in to that change right now
- [ ] Set a date for complete removal (or if someone really insists on keeping this feature, help them create an extension for it)https://lab.civicrm.org/dev/core/-/issues/4800Add Card Type and Last 4 to Contribution Import2023-12-06T22:31:00Zlevi.kAdd Card Type and Last 4 to Contribution ImportOverview
----------------------------------------
When importing a contribution there are certain fields like Date, transaction ID from the contribution that get added to the Financial_Trx it would be nice to have the Card Type ID and PA...Overview
----------------------------------------
When importing a contribution there are certain fields like Date, transaction ID from the contribution that get added to the Financial_Trx it would be nice to have the Card Type ID and PAN Truncation fields to be available in the contribution importer
Current behavior
----------------------------------------
currently Card Type ID (Card type like Visa Amex) and PAN Truncation (Last 4 of cc number) fields aren't available during contribution import
Proposed behavior
----------------------------------------
add those fields to contribution importhttps://lab.civicrm.org/dev/core/-/issues/4744Proposal - remove 'record contribution' from back office participant form whe...2023-11-02T15:27:49ZeileenProposal - remove 'record contribution' from back office participant form where pending contribution existsIf a participant record is updated where a pending record exists you need to update the status from pending to completed
![image](/uploads/1450500ef919017c7eee5c9ef326de6c/image.png)
![image](/uploads/87bc885b56fd756e897dc416a47eccd9/...If a participant record is updated where a pending record exists you need to update the status from pending to completed
![image](/uploads/1450500ef919017c7eee5c9ef326de6c/image.png)
![image](/uploads/87bc885b56fd756e897dc416a47eccd9/image.png)
However - this ONLY updates the contribution - without a separate action to update the participant status the participant status is unchanged
This is wildly confusing.
I propose we don't show 'record contribution' section when there is an existing payment & instead offer an 'add payment' button that pops up the Add payment form if clicked...https://lab.civicrm.org/dev/core/-/issues/4721Get rid of `civicrm_option_value.domain_id`2023-10-26T11:41:06ZcolemanwGet rid of `civicrm_option_value.domain_id`Background/Motivation
------
Most tables with a `domain_id` column have that field *required* for every record.
`civicrm_option_value` is an outlier; most option groups don't care about domains. In fact there are only two that do:
```p...Background/Motivation
------
Most tables with a `domain_id` column have that field *required* for every record.
`civicrm_option_value` is an outlier; most option groups don't care about domains. In fact there are only two that do:
```php
/**
* $_domainIDGroups array maintains the list of option groups for whom
* domainID is to be considered.
*
* FIXME: Hardcoded list = bad. It would be better to make this a column in the civicrm_option_group table
* @var array
*/
public static $_domainIDGroups = [
'from_email_address',
'grant_type',
];
```
The `civicrm_option_value.domain_id` column and that lovely accompanying hardcoded list were added [in this commit](https://github.com/civicrm/civicrm-svn/commit/406091dc969907753a56fd7fae73320b1b012e67) as part of [this issue](https://issues.civicrm.org/jira/browse/CRM-5546). The assumption at the time seemed to be that the list might grow in the future, but that's proven to not be the case. Instead, we have this extra column making the already overloaded `civicrm_option_value` table even more complex to deal with. It would have been better at the time to move those two option groups into their own tables. It may not be too late to do so.
Proposal
-----------
1. Create a new table `civicrm_grant_type` - manage that table from the `civigrant` extension.
2. Create a new table `civicrm_from_email_address`.
3. Migrate all options into the new tables. Update pseudoconstant metadata in the schema.
4. Add some legacy handling at a few key points like `civicrm_api()` & `CRM_Core_OptionGroup::values()` to fetch options from the new table, for backward compatibility.
5. Deprecate the `civicrm_option_value.domain_id` column and eventually drop it.https://lab.civicrm.org/dev/core/-/issues/4714Civi-Import change the description2023-10-26T07:16:29ZjaapjansmaCivi-Import change the descriptionI just installed a CiviCRM version 5.66 fresh for a client and saw a core extension Civi-Import.
The description line reads:
`Core extension for us to start moving import logic into, has more functionalit`
My question is what is this ...I just installed a CiviCRM version 5.66 fresh for a client and saw a core extension Civi-Import.
The description line reads:
`Core extension for us to start moving import logic into, has more functionalit`
My question is what is this extension? And who is the us?
I am bit afraid that the wording us also creates a not me and thus a we vs them mentality. I am not sure whether that is intededed.
So my proposal would be: `This is an extension in development to move core import functionality into an extension. This extension helps people who do development work on CiviCRM core. Feel free to contribute.`5.68.0https://lab.civicrm.org/dev/core/-/issues/4713Move the Elavon Payment Processor extension out of core2023-11-28T23:54:24ZjaapjansmaMove the Elavon Payment Processor extension out of coreI have just installed CiviCRM 5.66 for a client and I see it ships with an Elavon Payment Processor extension.
I have never heard of Elavon and I believe this extension is very usefull but not in the use cases I have seen so far. (They...I have just installed CiviCRM 5.66 for a client and I see it ships with an Elavon Payment Processor extension.
I have never heard of Elavon and I believe this extension is very usefull but not in the use cases I have seen so far. (They use CiviSepa for direct debits and Mollie for online payments both are not shipped with core).
I also believe that an extension which lives outside of core is also easier to install on CiviCRM installations which does not have this extension shipped by default (when needed).https://lab.civicrm.org/dev/core/-/issues/4712Move the PHP Storm extension out of core2023-10-26T11:37:31ZjaapjansmaMove the PHP Storm extension out of coreI have just installed a fresh Civi 5.66 site for production at a client and I see that core now ships a PHP storm extension.
I believe this extension is very useful for developers but probably not for production sites.
So can this exte...I have just installed a fresh Civi 5.66 site for production at a client and I see that core now ships a PHP storm extension.
I believe this extension is very useful for developers but probably not for production sites.
So can this extension moved out of core? That also gives other flexibility to install this extensions on older CiviCRM sites on which I am doing development on.https://lab.civicrm.org/dev/core/-/issues/4639New approaches to ACL caching (and smart groups?)2024-02-16T16:22:42ZJonGoldNew approaches to ACL caching (and smart groups?)A lot of work has gone into improving the efficiency and frequency of ACL calculation. Let's attack the performance of writing the results to db?
I have a site where contacts change frequently, and ACLed users need to wait for 100,000 ...A lot of work has gone into improving the efficiency and frequency of ACL calculation. Let's attack the performance of writing the results to db?
I have a site where contacts change frequently, and ACLed users need to wait for 100,000 records to be written each time. Disabling opportunistic flushes only partly mitigates the issue.
Here are some ideas:
* Could we move ACL/smart group caching into `\Civi::cache`? Then we could use Redis etc.
* Instead of truncating and writing all contacts - what if we only `INSERT` and `DELETE` changes from the existing cache?
* When a contact's edited, could we just calculate cache for that contact? For any ACL based on a static group, this should be trivial. Even with smart groups/custom code - are there scenarios where we'd ever need to calculate ACLs for anyone but the changed contact and all their related contacts?