CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-10-04T21:07:14Zhttps://lab.civicrm.org/dev/core/-/issues/2761Proposal: Change Pay Later Billing Address to look up a profile rather than a...2022-10-04T21:07:14ZBarijohnProposal: Change Pay Later Billing Address to look up a profile rather than a coded block.Overview
----------------------------------------
Currently on the pay later option when you use the option of Billing Address the fields are hard coded. This would be better to use a profile then it could be edited by the end user witho...Overview
----------------------------------------
Currently on the pay later option when you use the option of Billing Address the fields are hard coded. This would be better to use a profile then it could be edited by the end user without having to mess with the code.
Example use-case
----------------------------------------
Click on Pay Later Option and enable Billing Fields. This shows multiple fields that might not be required depending on the part of the world. So in that case there could be a reserved profile just for billing fields. This could have a help field to show where this profile is saved, so it would easily amended.
Current behaviour
----------------------------------------
Currently this is set in Core/Payment.php and /civicrm/templates/CRM/Core/BillingBlock.tpl (based on communications with our devs).
Proposed behaviour
----------------------------------------
Make this block look up a billing address profile instead.
Comments
----------------------------------------
Currently this field asks for information that isn't required in the UK and most of our clients would like to be able to edit this directly.https://lab.civicrm.org/dev/core/-/issues/2760Proposal: Stop storing file ids in two tables2023-04-17T15:39:24ZcolemanwProposal: Stop storing file ids in two tablesFile fields in CiviCRM are strange.
When you upload a file to a custom field, it stores a record in the `civicrm_file` table. Then it stores that id in **two** other tables. Once in the custom value column for that field, as you'd expec...File fields in CiviCRM are strange.
When you upload a file to a custom field, it stores a record in the `civicrm_file` table. Then it stores that id in **two** other tables. Once in the custom value column for that field, as you'd expect, and then it also adds a record in the `civicrm_entity_file` table.
https://github.com/civicrm/civicrm-core/blob/5.40/CRM/Core/BAO/CustomValueTable.php#L161-L171
From a data archetecture POV, there's no upside to storing the same value twice in two places, it just creates problems.https://lab.civicrm.org/dev/core/-/issues/2755Proposal: add `civicrm_contact.image_file_id` column2023-04-20T00:24:59ZcolemanwProposal: add `civicrm_contact.image_file_id` columnProblem
-----------
Handling of contact images is nonstandard and difficult to work with.
Current Behavior
--------------
**Uploading a contact image will:**
1. Store the file in (by default) `civicrm/custom`.
2. Update the `civicrm_...Problem
-----------
Handling of contact images is nonstandard and difficult to work with.
Current Behavior
--------------
**Uploading a contact image will:**
1. Store the file in (by default) `civicrm/custom`.
2. Update the `civicrm_contact.image_URL` column with a link to an ajax callback for accessing the image.
3. Not create a record in the `civicrm_file` table.
4. Not create a record in the `civicrm_entity_file` table.
**Deleting a contact image in the UI will:**
1. Not delete the file.
2. Set `civicrm_contact.image_URL` to `null`.
Proposed New Behavior
-------------------
*Add a `civicrm_contact.image_file_id` column, FK to `civicrm_file.id`.*
**Uploading a contact image will:**
1. Store the file as before.
2. Update the `civicrm_contact.image_URL` column as before.
3. Create a record in the `civicrm_file` table.
4. Store the file id in the `civicrm_contact.image_file_id` column
5. *Undecided:* should an entry also be created in `civicrm_entity_file`? See #2760
**Deleting a contact image in the UI will:**
1. Delete the file if an id is present in `image_file_id` column.
2. Set `civicrm_contact.image_URL` and `civicrm_contact.image_file_id` to `null`.
See PR https://github.com/civicrm/civicrm-core/pull/21141https://lab.civicrm.org/dev/core/-/issues/2752Financial entity permissions2023-11-08T05:03:19ZeileenFinancial entity permissionsI hit an issue where a contact without 'Administer CiviCRM' but WITH 'view all contributions' cannot access a payment search display - [as described](https://civicrm.org/blog/eileen/searching-payments-civi)
I think the VIEW permissions ...I hit an issue where a contact without 'Administer CiviCRM' but WITH 'view all contributions' cannot access a payment search display - [as described](https://civicrm.org/blog/eileen/searching-payments-civi)
I think the VIEW permissions on all financial entities should be 'view all contributions' because otherwise we will keep hitting issues where part but not all of a contribution can be retrieved
@JoeMurray @monish.deb @seamusleehttps://lab.civicrm.org/dev/core/-/issues/2750Events RSS Feed doesn't include Event Date Field2023-09-14T05:03:24ZBarijohnEvents RSS Feed doesn't include Event Date FieldOverview
----------------------------------------
Add Event Date to Event RSS template to allow easy aggregation into external websites.
Example use-case
----------------------------------------
To display events on an external website ...Overview
----------------------------------------
Add Event Date to Event RSS template to allow easy aggregation into external websites.
Example use-case
----------------------------------------
To display events on an external website using the inbuilt RSS feed and CiviCRM Event functionality to reduce duplication of work.
Current behaviour
----------------------------------------
```
<item>
<title>Fall Fundraiser Dinner</title>
<link>https://dmaster.demo.civicrm.org/civicrm/event/info?reset=1&id=1</link>
<description> Kick up your heels at our Fall Fundraiser Dinner/Dance at Glen Echo Park! Come by yourself or bring a partner, friend or the entire family! This event benefits our teen programs. Admission includes a full 3 course meal and wine or soft drinks. Grab your dancing shoes, bring the kids and come join the party! When: January 26th, 2022 5:00 PM through January 28th, 2022 5:00 PM Where: 14S El Camino Way E Collinsville, CT 6022 United States </description>
<category>Fundraiser</category>
<author>development@example.org</author>
<guid isPermaLink="false">CiviCRM_EventID_1_f90c7968e68e8bc667d6d4c8808f6985@dmaster.demo.civicrm.org</guid>
</item>
```
Proposed behaviour
----------------------------------------
Remove author and add Event Start Date and Time.
Comments
----------------------------------------
Currently the default display of the RSS Feed doesn't include the start date of the event which makes it rather pointless as a RSS feed into external websites. I am sure this used to be there but it was rather a long time ago! It has the field of author which I don't feel is a useful field at the expense of start date at least.https://lab.civicrm.org/dev/core/-/issues/2720Consider bringing export permission into core2024-02-26T05:03:21ZeileenConsider bringing export permission into coreI took a look at https://github.com/progressivetech/net.ourpowerbase.exportpermission in the light of https://github.com/civicrm/civicrm-core/pull/20945 and felt like maybe this should be in core. It basically adds and checks 4 permissio...I took a look at https://github.com/progressivetech/net.ourpowerbase.exportpermission in the light of https://github.com/civicrm/civicrm-core/pull/20945 and felt like maybe this should be in core. It basically adds and checks 4 permissions
- 'Access "Export as CSV" drop down menu item from actions menu on after search/report'
- Access "Print" drop down menu item from actions menu on search/report
- Access "Print/Merge document (PDF Letter)" drop down menu item from actions menu on search/report
- Access "Print Mailing Labels" drop down menu item from actions menu on search/report
In terms of reasons why this would be better in an extension than core - here are some questions I think we would consider
1) does it impose a maintenance burden on core (in this case I would say no)
2) does it have/need unit tests. In this case (incredibly) I would be OK without tests - but they would be super-easy to add to https://github.com/civicrm/civicrm-core/pull/20944
3) does it meet a generic needs or a specific need - this feels fairly generic
4) does it over-complicate using core
5) is it just too hard to negotiate with the community on this topic.
My suspicicion is that the reason for not putting this in core in the past falls between 4 & 5 - ie. some people feel that adding more permissions over-complicates the permissions UI as a matter of principle. But I think it's worth asking the question againhttps://lab.civicrm.org/dev/core/-/issues/2669Target contact missing for automatically generated case activities2023-02-23T16:00:45ZAndreasandreas.howiller@civiservice.deTarget contact missing for automatically generated case activitiesOverview
----------------------------------------
Some actions on cases leave automatically generated activities in the case activity log, but have no target contacts. Examples: Change case title, change case tags. As a result, they cann...Overview
----------------------------------------
Some actions on cases leave automatically generated activities in the case activity log, but have no target contacts. Examples: Change case title, change case tags. As a result, they cannot be edited through the user interface. While this is a minor issue, some users may want to leave notes about the activity (for example, why they changed a case title) and therefore need to edit it.
Reproduction steps
----------------------------------------
1. Open any case in CiviCRM and change the case title.
2. Tap edit for the corresponding activity in the activity timeline.
3. Tap save.
Current behaviour
----------------------------------------
The dialog will freeze while the CiviCRM logo keeps turning. A fatal error "DB Error: constraint violation" will be filed in the logs.
If you add any contact as a target contact in the database or in the edit screen the error won't appear anymore.
What is confusing, too: When editing the activity the client contact already wrongly shows up as target contact in this dialog and if you'd like to change it there you need to search the contact (the link to choose the client contact below the search field won't do the change here).
Expected behaviour
----------------------------------------
The Client contact is filed as target contact by default and connected problems disappear. E.g. editable activities can be saved after edit through UI now.
Environment information
----------------------------------------
* __CiviCRM:__ _5.35.2_ and _5.38.0_
* __CMS:__ _WordPress 5.7.2_https://lab.civicrm.org/dev/core/-/issues/2644Proposal - new core extension for scheduled reminders using criteria from sea...2023-08-28T12:20:35ZeileenProposal - new core extension for scheduled reminders using criteria from search-kitThis replaces https://lab.civicrm.org/dev/core/-/issues/2267 as a way to address the same issue - ie our search criteria for scheduled reminders is way too brittle due to the inflexible schema. For example it is not possible to use contr...This replaces https://lab.civicrm.org/dev/core/-/issues/2267 as a way to address the same issue - ie our search criteria for scheduled reminders is way too brittle due to the inflexible schema. For example it is not possible to use contributions > x amount or contributions from campaign y.
Given that we Apiv4 / search kit is the way we are going with search criteria it makes sense to use these as criteria for the reminder search too to replace (in the distant future) the existing fields.
#2267 proposed adding api params & api entity to the scheduled reminder table but I now think it makes more sense as an extension - which I have been experimenting with.
This extension does not have to go into core - it could be something I just maintain to the degree I see fit.
However, the main reason we would consider it as a core extension is that it could eventually replace the existing scheduled reminder form (which would fit our LEXIM plan to get off quick forms and onto everything being apiv4 based). The hope is not to replace the additional functionality in CiviRules for people who want that but to reduce pain points in the scheduled reminder code that is already in core and as a path away from maintaining the relevant quickforms.
Note that if we proceed with this as a core extension I will PR it in once it hits 'alpha' but we would not enable by default and we can have a discussion at that point as to whether it should be hidden or not depending on how mature it is.
I note @totten's response to the question as to whether it should go into core rather seemed to hinge on whether the UI is any good - and since it's not yet written we can't address that at this stage.https://lab.civicrm.org/dev/core/-/issues/2639Money: Plan to migrate from currency separators from locale2023-08-16T05:03:18ZeileenMoney: Plan to migrate from currency separators from localeThere is a goal to switch to sites specifying their money_locale from specifying currency separators
The original discussion on how to do this was in the dev-digest and a PR. @mattwire has since suggested an alternate https://github.com...There is a goal to switch to sites specifying their money_locale from specifying currency separators
The original discussion on how to do this was in the dev-digest and a PR. @mattwire has since suggested an alternate https://github.com/civicrm/civicrm-core/pull/20296#issuecomment-855377189
"Override currency separators" - "By default CiviCRM will format currency in accordance with the locale for the user that is viewing the information"
I've moved the text below from a comment on the github PR to here ....
In terms of adding a setting I went hunting for where it was discussed before & it is here
https://github.com/civicrm/civicrm-core/pull/19753
![image](https://user-images.githubusercontent.com/336308/120940640-63d47800-c772-11eb-8b46-302f4d311ef3.png)
Further down the same PR is the content that was pasted into the dev-digest
![image](https://user-images.githubusercontent.com/336308/120940681-92eae980-c772-11eb-9ff9-588d1e3ca663.png)
Compared to @mattwire's suggestion this is
1) implicitly opt in at the start - ie let early adopters set it & when we are confident be more aggressive
2) a different setting name / description - I think setting money_locale might be less intuitive short term (since it magically disables the other settings) and more intuitive longer term since the other settings should become meaningless & disappear over time.
Revisiting @jaapjansma's comment
![image](https://user-images.githubusercontent.com/336308/120940808-33410e00-c773-11eb-9bae-9910a3ff7583.png)
It DOES seem like site locale is going to be wanted as a setting - although it could be that this is not the point where we add ithttps://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/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/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/2611Change default_value column for custom fields from varchar to text2023-08-20T02:32:58ZlarsssandergreenChange default_value column for custom fields from varchar to textA custom field can be of many types, including note. For a custom field that is a note, you may want to use a default value that is longer than 255 characters, but currently the default value is stored as a varchar(255). It would make se...A custom field can be of many types, including note. For a custom field that is a note, you may want to use a default value that is longer than 255 characters, but currently the default value is stored as a varchar(255). It would make sense to change this column to text, so that longer values can be entered.
In the custom fields UI, this field would be changed to a textarea when note is selected.
For us, the use case would be storing the content of a short waiver, so that the exact value of the waiver at the time of signing can be stored on the participant for an event, but I can imagine there may be other use cases.
Will submit PR if supported.https://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/2597Tabset for manage contribution pages or manage events requires Classname to e...2023-08-07T15:13:57ZlarsssandergreenTabset for manage contribution pages or manage events requires Classname to equal pathIf you add a tab to a tabset for Configure Event, it will work fine with the last word of the class name different from the last word of the path, except for trying to save, which will save, but redirect to Manage Events instead of stayi...If you add a tab to a tabset for Configure Event, it will work fine with the last word of the class name different from the last word of the path, except for trying to save, which will save, but redirect to Manage Events instead of staying on the same tab. This is because [code here](https://github.com/civicrm/civicrm-core/blob/5db0bc3c1f54eaca4307f103a73bda596ae914d6/CRM/Event/Form/ManageEvent.php#L377) expects lastWord from CRM_myExtension_Form_lastWord to be the same as the path, i.e. /civicrm/event/manage/lastword. Everything else works as expected if these are different, except Save.
Looks like this same issue exists for [Contribution Pages](https://github.com/civicrm/civicrm-core/blob/5db0bc3c1f54eaca4307f103a73bda596ae914d6/CRM/Contribute/Form/ContributionPage.php#L427
) and probably elsewhere.
For now, I've added a warning to the docs for [the tabset hook](https://lab.civicrm.org/documentation/docs/dev/-/merge_requests/908). It would be good to fix this so the code linked above uses the path for the url instead of the class, at some point.https://lab.civicrm.org/dev/core/-/issues/2595Change Log Tab Excrutiatingly Slow - Poorly Performing Query and Fix (from 8 ...2023-08-14T13:09:44ZgordanChange Log Tab Excrutiatingly Slow - Poorly Performing Query and Fix (from 8 minutes down to 4 seconds)The page takes about 8 minutes to return which is absurdly slow for anything expected to be remotely interactive. It is so slow that my client is referring to it as the "Triangle of Doom".
I tracked it down to this query:
```
INSERT IG...The page takes about 8 minutes to return which is absurdly slow for anything expected to be remotely interactive. It is so slow that my client is referring to it as the "Triangle of Doom".
I tracked it down to this query:
```
INSERT IGNORE INTO civicrm_tmp_e_logsummary_ffa3ac146126d178ade367f2a5d17bf5
SELECT activity_id, IF (entity_log_civireport.log_action = 'Insert' AND extra_table.activity_type_id = 51 , GROUP_CONCAT(entity_log_civireport.contact_id), 1) , entity_log_civireport.log_action as log_civicrm_entity_log_action, 'log_civicrm_activity_contact' as log_civicrm_entity_log_type, entity_log_civireport.log_user_id as log_civicrm_entity_log_user_id, entity_log_civireport.log_date as log_civicrm_entity_log_date, modified_contact_civireport.display_name as log_civicrm_entity_altered_contact, modified_contact_civireport.id as log_civicrm_entity_altered_contact_id, entity_log_civireport.log_conn_id as log_civicrm_entity_log_conn_id, modified_contact_civireport.is_deleted as log_civicrm_entity_is_deleted, altered_by_contact_civireport.display_name as altered_by_contact_display_name
FROM staging_civicrm.log_civicrm_activity_contact entity_log_civireport
JOIN civicrm_contact modified_contact_civireport ON (entity_log_civireport.contact_id = modified_contact_civireport.id )
JOIN staging_civicrm.log_civicrm_activity extra_table ON extra_table.id = entity_log_civireport.activity_id
LEFT JOIN civicrm_contact altered_by_contact_civireport ON (entity_log_civireport.log_user_id = altered_by_contact_civireport.id)
WHERE modified_contact_civireport.id = 338520 AND
entity_log_civireport.log_action != 'Initialization'
GROUP BY entity_log_civireport.log_conn_id,
entity_log_civireport.log_user_id,
EXTRACT(DAY_MICROSECOND FROM entity_log_civireport.log_date),
entity_log_civireport.id
ORDER BY entity_log_civireport.log_date DESC;
EXPLAIN shows:
```
```
+------+-------------+-------------------------------+--------+---------------+---------+---------+---------------------------------------------------+---------+-------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------------------------------+--------+---------------+---------+---------+---------------------------------------------------+---------+-------------------------------------------------+
| 1 | SIMPLE | modified_contact_civireport | const | PRIMARY | PRIMARY | 4 | const | 1 | Using temporary; Using filesort |
| 1 | SIMPLE | extra_table | ALL | NULL | NULL | NULL | NULL | 3014020 | |
| 1 | SIMPLE | entity_log_civireport | ALL | NULL | NULL | NULL | NULL | 5518537 | Using where; Using join buffer (flat, BNL join) |
| 1 | SIMPLE | altered_by_contact_civireport | eq_ref | PRIMARY | PRIMARY | 4 | staging_civicrm.entity_log_civireport.log_user_id | 1 | Using where |
+------+-------------+-------------------------------+--------+---------------+---------+---------+---------------------------------------------------+---------+-------------------------------------------------+
```
The fix passes:
First pass:
```
ALTER TABLE log_civicrm_activity_contact ADD INDEX index_activity_id (activity_id);
```
With no further changes, this alone makes the above query go from 8 minutes to 1m45s.
Explain plain:
```
+------+-------------+-------------------------------+--------+-------------------+-------------------+---------+---------------------------------------------------+---------+---------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------------------------------+--------+-------------------+-------------------+---------+---------------------------------------------------+---------+---------------------------------+
| 1 | SIMPLE | modified_contact_civireport | const | PRIMARY | PRIMARY | 4 | const | 1 | Using temporary; Using filesort |
| 1 | SIMPLE | extra_table | ALL | NULL | NULL | NULL | NULL | 3014020 | Using where |
| 1 | SIMPLE | entity_log_civireport | ref | index_activity_id | index_activity_id | 5 | staging_civicrm.extra_table.id | 1 | Using where |
| 1 | SIMPLE | altered_by_contact_civireport | eq_ref | PRIMARY | PRIMARY | 4 | staging_civicrm.entity_log_civireport.log_user_id | 1 | Using where |
+------+-------------+-------------------------------+--------+-------------------+-------------------+---------+---------------------------------------------------+---------+---------------------------------+
```
Second pass:
```
ALTER TABLE log_civicrm_activity ADD INDEX index_id (id);
```
Change the JOIN order explicitly and add a hint for the query optimizer to not re-order the JOINs:
```
SELECT STRAIGHT_JOIN activity_id, IF (entity_log_civireport.log_action = 'Insert' AND extra_table.activity_type_id = 51 , GROUP_CONCAT(entity_log_civireport.contact_id), 1) , entity_log_civireport.log_action as log_civicrm_entity_log_action, 'log_civicrm_activity_contact' as log_civicrm_entity_log_type, entity_log_civireport.log_user_id as log_civicrm_entity_log_user_id, entity_log_civireport.log_date as log_civicrm_entity_log_date, modified_contact_civireport.display_name as log_civicrm_entity_altered_contact, modified_contact_civireport.id as log_civicrm_entity_altered_contact_id, entity_log_civireport.log_conn_id as log_civicrm_entity_log_conn_id, modified_contact_civireport.is_deleted as log_civicrm_entity_is_deleted, altered_by_contact_civireport.display_name as altered_by_contact_display_name
FROM civicrm_contact modified_contact_civireport
JOIN staging_civicrm.log_civicrm_activity_contact entity_log_civireport ON entity_log_civireport.contact_id = modified_contact_civireport.id
JOIN staging_civicrm.log_civicrm_activity extra_table ON extra_table.id = entity_log_civireport.activity_id
LEFT JOIN civicrm_contact altered_by_contact_civireport ON entity_log_civireport.log_user_id = altered_by_contact_civireport.id
WHERE modified_contact_civireport.id = 338520 AND
entity_log_civireport.log_action != 'Initialization'
GROUP BY entity_log_civireport.log_conn_id,
entity_log_civireport.log_user_id,
EXTRACT(DAY_MICROSECOND FROM entity_log_civireport.log_date),
entity_log_civireport.id
ORDER BY entity_log_civireport.log_date DESC;
```
New EXPLAIN:
```
+------+-------------+-------------------------------+--------+-------------------+----------+---------+---------------------------------------------------+---------+---------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------------------------------+--------+-------------------+----------+---------+---------------------------------------------------+---------+---------------------------------+
| 1 | SIMPLE | modified_contact_civireport | const | PRIMARY | PRIMARY | 4 | const | 1 | Using temporary; Using filesort |
| 1 | SIMPLE | entity_log_civireport | ALL | index_activity_id | NULL | NULL | NULL | 5518537 | Using where; Using filesort |
| 1 | SIMPLE | extra_table | ref | index_id | index_id | 5 | staging_civicrm.entity_log_civireport.activity_id | 1 | |
| 1 | SIMPLE | altered_by_contact_civireport | eq_ref | PRIMARY | PRIMARY | 4 | staging_civicrm.entity_log_civireport.log_user_id | 1 | Using where |
+------+-------------+-------------------------------+--------+-------------------+----------+---------+---------------------------------------------------+---------+---------------------------------+
```
This gets it down to 4 seconds!
Since the first index we started with is no longer getting used in the final variant, we can just not add it.
Summary:
To fix "Change Log" tab taking forever to load, the following fix is needed:
Add index:
```
ALTER TABLE log_civicrm_activity ADD INDEX index_id (id);
```
Make the code emit the query modified as follows:
```
INSERT IGNORE INTO civicrm_tmp_e_logsummary_ffa3ac146126d178ade367f2a5d17bf5
SELECT STRAIGHT_JOIN activity_id, IF (entity_log_civireport.log_action = 'Insert' AND extra_table.activity_type_id = 51 , GROUP_CONCAT(entity_log_civireport.contact_id), 1) , entity_log_civireport.log_action as log_civicrm_entity_log_action, 'log_civicrm_activity_contact' as log_civicrm_entity_log_type, entity_log_civireport.log_user_id as log_civicrm_entity_log_user_id, entity_log_civireport.log_date as log_civicrm_entity_log_date, modified_contact_civireport.display_name as log_civicrm_entity_altered_contact, modified_contact_civireport.id as log_civicrm_entity_altered_contact_id, entity_log_civireport.log_conn_id as log_civicrm_entity_log_conn_id, modified_contact_civireport.is_deleted as log_civicrm_entity_is_deleted, altered_by_contact_civireport.display_name as altered_by_contact_display_name
FROM civicrm_contact modified_contact_civireport
JOIN staging_civicrm.log_civicrm_activity_contact entity_log_civireport ON entity_log_civireport.contact_id = modified_contact_civireport.id
JOIN staging_civicrm.log_civicrm_activity extra_table ON extra_table.id = entity_log_civireport.activity_id
LEFT JOIN civicrm_contact altered_by_contact_civireport ON entity_log_civireport.log_user_id = altered_by_contact_civireport.id
WHERE modified_contact_civireport.id = 338520 AND
entity_log_civireport.log_action != 'Initialization'
GROUP BY entity_log_civireport.log_conn_id,
entity_log_civireport.log_user_id,
EXTRACT(DAY_MICROSECOND FROM entity_log_civireport.log_date),
entity_log_civireport.id
ORDER BY entity_log_civireport.log_date DESC;
```
Not only does this speed it up from 8 minutes down to 4 seconds, it also doesn't wreak havoc with row locking where every row scanned gets locked by the transaction engine, potentially resulting in a massive query pile-up in the database.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/2572Prevent unintentional removal from group for anonymous users filing out profiles2023-09-01T19:44:06ZlarsssandergreenPrevent unintentional removal from group for anonymous users filing out profilesCurrently, if an anonymous contact submits a profile that contains a groups field and the profile submission is deduped on submission with an existing contact, the group selections in the profile overwrite the contact's previous groups, ...Currently, if an anonymous contact submits a profile that contains a groups field and the profile submission is deduped on submission with an existing contact, the group selections in the profile overwrite the contact's previous groups, for the groups that are included in the profile (i.e. the public groups). The result is that if someone is subscribed to a mailing list and fills in a profile anonymously and doesn't check the same group name, they will be unsubscribed from the group. This is definitely not what users expect! I think it's clear that checking the box will add you to the group, but I doubt many expect that they will be removed from a group if they don't check the box that they've checked in the past.
This is also not what happens with other profile fields that are left blank, nor is it what happens if two contacts are merged manually.
I propose to ignore group checkboxes that are not checked in a profile submitted anonymously. No change for profiles submitted with known cids (as these will have the appropriate checkboxes already checked, allowing the contact to unsubscribe by unchecking them if desired). Currently, all group ids in the profile are being [passed here](https://github.com/civicrm/civicrm-core/blob/5db0bc3c1f54eaca4307f103a73bda596ae914d6/CRM/Contact/BAO/GroupContact.php#L534), removing the contact from groups that were unchecked. Will submit PR if supported.
EDIT: Here is some discussion on StackExchange: [Unwanted unsubscribe in profile](https://civicrm.stackexchange.com/questions/39403/unwanted-unsubscribe-in-profile/39406), [Anonymous user filing out a profile unintentionally remove themselves from groups](https://civicrm.stackexchange.com/questions/29337/anonymous-user-filing-out-a-profile-unintentionally-remove-themselves-from-group)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.