CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-06-30T05:03:20Zhttps://lab.civicrm.org/dev/core/-/issues/533Update recaptcha to v32023-06-30T05:03:20ZMartinUpdate recaptcha to v3Google recaptcha v3 has now been officially released:
https://webmasters.googleblog.com/2018/10/introducing-recaptcha-v3-new-way-to.html
Obviously v2 is still working for the time being but it would be beneficial to update core to use v...Google recaptcha v3 has now been officially released:
https://webmasters.googleblog.com/2018/10/introducing-recaptcha-v3-new-way-to.html
Obviously v2 is still working for the time being but it would be beneficial to update core to use v3. For example one of our clients is currently seeing this issue (significant usability bug in iOS):
https://github.com/google/recaptcha/issues/130
Thanks!https://lab.civicrm.org/dev/core/-/issues/416Schedule job time shifting every day2022-08-30T13:42:45ZsamuelsovSchedule job time shifting every dayWhen scheduling a cron job daily, the starting hour is shifting a little bit every day.
It means that eventually, we'll get a day skipped from 23:59 to 00:01, 2 days later.
It can be a problem e.g. for membership schedule reminders wher...When scheduling a cron job daily, the starting hour is shifting a little bit every day.
It means that eventually, we'll get a day skipped from 23:59 to 00:01, 2 days later.
It can be a problem e.g. for membership schedule reminders where we check for all membership that correspond to the today's date. Some schedule reminders won't be sent.https://lab.civicrm.org/dev/core/-/issues/392Support MySQL 8.0 now that it is GA2021-04-01T01:52:03ZJoeMurraySupport MySQL 8.0 now that it is GA# Overview
MySQL 8.0 went General Availability on April 19, 2018. CiviCRM's aim is to support the latest GA for required infrastructure (MySQL, PHP) as soon as feasible.
In reviewing removed features that cause incompatibilities (htt...# Overview
MySQL 8.0 went General Availability on April 19, 2018. CiviCRM's aim is to support the latest GA for required infrastructure (MySQL, PHP) as soon as feasible.
In reviewing removed features that cause incompatibilities (https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html) I noticed a couple of issues that definitely require changes, one that might cause syntax errors that are easily fixed when found, and a fourth that we may want to change to improve our functionality and get current.
This is a meta issue for tracking what's needed for MySQL8. I have added a MySQL8 flag to lab for the moment to help in tracking. We can delete that flag after this issue is deemed complete.
# Related issue: Upgrade test infrastructure to enable testing against a version on the edge of being officially supported: https://lab.civicrm.org/dev/core/issues/1142
# Issue: Field Names now Reserved Words https://lab.civicrm.org/dev/core/issues/1143
# Testing issue: dependence on PHP version for MySQL authentication ~~https://lab.civicrm.org/dev/core/issues/1144~~
# Document dealing with changes to MySQL user password library https://lab.civicrm.org/dev/core/issues/1145
# Possible issue: Sort order on GROUP BY clauses
~~I don't think we have any code that tries to specify sort order on GROUP BY fields, but if so we will need to change to add an ORDER BY clause with the sort order. I think we should just try running tests on MySQL 8.0 and using it manually to determine locations in code with this issue, and play whack-a-mole on anything missed.~~
# Nice to have: Upgrade our text fields to support all utf8 characters https://lab.civicrm.org/dev/core/issues/339https://lab.civicrm.org/dev/core/-/issues/3721Add Entity Reference custom field type (implementing EntityRef QuickForm elem...2023-07-28T15:04:53ZjensschuppeAdd Entity Reference custom field type (implementing EntityRef QuickForm element type)Overview
----------------------------------------
`EntityRef` ist a QuickForm element type being used to reference CiviCRM entities in several forms. But there is no custom field type implementing this, apart from the *ContactReference* ...Overview
----------------------------------------
`EntityRef` ist a QuickForm element type being used to reference CiviCRM entities in several forms. But there is no custom field type implementing this, apart from the *ContactReference* custom field type, which is (surprise!) restricted to referencing contacts.
Allowing users to model their "real world" use cases in CiviCRM using the UI without mis-using entity types for things they have not been intended for, just because you need some kind of relation between two things, would be a great improvement.
At this time, we are evaluating requirements for a current project where this might be needed, but wanted to discuss our thoughts with some Core people, especially @colemanw who already offered help with reviewing code, before we start, because this will have to be a PR to Core, probably with some refactoring involved.
Example use-case
----------------------------------------
With either Core or custom entities (such as multi-value custom field groups or [ECK entities](https://github.com/systopia/de.systopia.eck)), you might want to model references to different "things" in your business logic, not just contacts.
Imagine a *Project* entity that you would like to add references to contacts, but also to specific activities, contributions, etc. - without a *Project* having to be a contact type or a *Case*, or a *Campaign* because that might not be suitable because of reasons.
Current behaviour
----------------------------------------
Only contact entites can be referenced in custom fields.
Proposed behaviour
----------------------------------------
* Add a custom field type *Entity Reference* with configurable
* entity type
* label property (a property of the selected entity type that will be used for displaying the referenced entity when rendering the field value)
* entity filters (API parameters for the entity)
* Migrate the *Contact Reference* custom field type to be an *Entity Reference* field type with *Contact* as the referenceable entity type and the `display_name` as the label property
* Maybe allow custom field types be extendable, i.e. allow extensions to define additional custom field types
* Maybe add support for SearchKit (e.g. for defining filters or providing widget displays)
Technical Details
----------------------------------------
* *Contact Reference* fields currently store their API filters in the `filter` column of the `civicrm_custom_field` table. The entity itself might be just added there
* The label/title property might be stored in the `attributes` column, which is used for different stuff depending on the custom field type. Alternatively, a new column could be added to the `civicrm_custom_field` table (just as there are columns for other field types), although this is not that good of a design IMO
* Alternatively, all field-type-specific configuration could be migrated into a generic JSON-formatted `configuration` or `properties` column, at least for this new field type for now. There are many columns only needed for specific field types:
* `mask`
* `options_per_line`
* `text_length`
* `start_date_years`
* `end_date_years`
* `date_format`
* `time_format`
* `note_columns`
* `note_rows`
* `option_group_id`
* `filter`
I think adding a new custom field type that stores its configuration in existing columns would be a good first step. Any thoughts on that?
After storing information about a custom field in civicrm_custom_field, a table is created for each group or set of custom fields to store the value of each field for each instance of the set of custom fields. The name of this table is stored in custom_field_group.table_name. This table correlates each record of custom field values with the entity they extend using meta-data about the custom field set to identify the table extended (I think there is a translation of value in custom_field_group.extends to the table name of the entity extended) and the id of the instance extended.
It would be good to support regular CiviCRM entities that are implemented as tables as well as the higher order entities of Order and Payment that have id fields and APIs but not table implementations.
Funding
---------------------
Required: 40
Pledged:
- Third Sector Design - 8
- Systopia - 18
- Megaphone tech - 4 (depending on timeframe)
- JMA - 10
- Humanists UK - 55.60.0https://lab.civicrm.org/dev/core/-/issues/2765Revisit the decision to enforce the CMS new user account option, allow CiviCR...2023-09-26T05:03:25Zjustinfreeman (Agileware)Revisit the decision to enforce the CMS new user account option, allow CiviCRM to create CMS user accounts when CMS has public registrations disabledRaising this a request to revisit the decision [originating in 2009 (CRM-4036)](https://issues.civicrm.org/jira/browse/CRM-4036.html) to enforce the CMS new user account option and instead **allow CiviCRM to create CMS user accounts when...Raising this a request to revisit the decision [originating in 2009 (CRM-4036)](https://issues.civicrm.org/jira/browse/CRM-4036.html) to enforce the CMS new user account option and instead **allow CiviCRM to create CMS user accounts when CMS has public registrations disabled**.
There are three key reasons to have this functionality:
1. Public registrations on websites attract spamming and therefore require moderation and anti-spam systems to be in place.
2. For member-only websites, the method to because a member is using the membership sign-up form (CiviCRM) and when the membership fee is paid, that's when the corresponding CMS user account should be created. And not by any other means.
3. With user account creation disabled, a separate and in some cases manual process needs to be performed to create the corresponding user account for members - which is a waste of effort.
With the current logic where CiviCRM uses the CMS configuration, the site must be open for public user registrations to support CiviCRM registering a member user account.
The change is relatively simple and would be removing the check of the user registration option for each supported CMS. Thus CiviCRM Profiles can be used to create CMS accounts.
See also related, _User Profiles, the User account registration option is displayed even when the CMS has the "User can register" option disabled_ - https://lab.civicrm.org/dev/user-interface/-/issues/41
Agileware Ref: CIVICRM-1809https://lab.civicrm.org/dev/core/-/issues/2241Don't check for .git in the isDevelopment() function2021-01-11T22:35:28ZDaveDDon't check for .git in the isDevelopment() functionThe function isDevelopment() checks if there's a .git folder present. The function controls for example mysql strict mode and whether deprecations throw errors (more about deprecations in ticket dev/core#2240). But it's not crazy for a l...The function isDevelopment() checks if there's a .git folder present. The function controls for example mysql strict mode and whether deprecations throw errors (more about deprecations in ticket dev/core#2240). But it's not crazy for a live site to have a .git folder.
Previous discussion at https://github.com/civicrm/civicrm-core/pull/17276. Where it stalled was not really on whether using .git is wrong, it was on what it should do instead. Summary of alternates:
1. Use the Environment setting at System Settings - Debugging.
* There may be some differences between what that setting is actually for and what this function gets used for.
* Also switching to this setting has some side effects which aren't blockers but would need to be dealt with (test suite, buildkit defaults).
1. Instead of "is dev", have a way to tell "for testing" and "not for testing".
* CIVICRM_UF(?)
1. Use whatever the symfony environment is set to.
@mattwire @AlanDixon @MikeyMJCO @artfulrobot5.35.0https://lab.civicrm.org/dev/core/-/issues/1500Add system check for required PHP extensions (bcmath, curl, etc.)2023-03-21T05:03:21ZAllenShawAdd system check for required PHP extensions (bcmath, curl, etc.)I was recently bitten by the bcmath requirement (along the lines of https://civicrm.stackexchange.com/q/31932/907), on a system that (for unrelated reasons) was making error messages fairly hard to get to.
It occurs to me that since Civ...I was recently bitten by the bcmath requirement (along the lines of https://civicrm.stackexchange.com/q/31932/907), on a system that (for unrelated reasons) was making error messages fairly hard to get to.
It occurs to me that since CiviCRM core requires several php extensions (https://docs.civicrm.org/sysadmin/en/latest/requirements/#php-extensions), it would be helpful to have a system check that uses `extension_loaded()` to confirm these are installed, and presents a 'critical' error if any are missing.https://lab.civicrm.org/dev/core/-/issues/1448Upgrade - confirm navigation away from page2023-01-15T05:03:23ZarborrowUpgrade - confirm navigation away from pageSo yesterday, I had one of those moments where I just wanted to kick myself while upgrading CiviCRM. I had fired off the database upgrade (civicrm/upgrade?reset=1) and saw a bunch of notices related to templates which I copied for docume...So yesterday, I had one of those moments where I just wanted to kick myself while upgrading CiviCRM. I had fired off the database upgrade (civicrm/upgrade?reset=1) and saw a bunch of notices related to templates which I copied for documentation purposes while the database upgrade continued.
I intended to switch over to a new browser tab and paste the documentation into a document there when before I new it I had migrated away from the upgrade page abandoning the upgrade mid-process. Hoping against hope, I went back and thought perhaps it might be able to pickup where it left off. No such luck. The installation had been interrupted and it was suggested that I restore my backup (which of course I hadn't done because well I never have these sorts of troubles :p) and then try the upgrade process again.
I suspect I am not the first to do this but believe it would be a good idea to add some type of confirmation button on the database upgrade page to save me from myself and make it one step harder to interrupt the upgrade process with a "are you sure you want to continue to interrupt the database upgrade". It just seems a little too easy to interrupt this crucial process.
I was thinking something along the lines of: https://code-maven.com/prevent-leaving-the-page-using-plain-javascripthttps://lab.civicrm.org/dev/core/-/issues/1331Don't freeze fields for auto-renew memberships2020-03-30T14:18:17ZwmortadaDon't freeze fields for auto-renew membershipsIf a membership is linked to a recurring payment some of the fields are frozen, which means that a user is unable to edit them when they visit the edit membership screen.
This affects the following fields:
* Membership organisation
* M...If a membership is linked to a recurring payment some of the fields are frozen, which means that a user is unable to edit them when they visit the edit membership screen.
This affects the following fields:
* Membership organisation
* Membership type
* ~~Membership end date~~ [no longer frozen]
* Membership status
![image](/uploads/2ac776a76bf0a662e89f6426604da0ce/image.png)
This issue is split out from https://lab.civicrm.org/dev/core/issues/1126 which looked specifically at the end_date field. This fix has now been merged into core ([PR #15540](https://github.com/civicrm/civicrm-core/pull/15540)).
I've created this ticket to look at the other fields that are also frozen following discussion in my [original PR](https://github.com/civicrm/civicrm-core/pull/15505).
# Issue
The ability to edit the membership type is an issue for our organisation because sometimes people sign up for the wrong membership type and we need to change this. For non-recurring payments this is no problem, we can just change it manually and if necessary take additional payment or make a refund. But for recurring payments we are unable to do this because the field is frozen. We are then stuck and have no way of changing the membership type in CiviCRM through the UI.
The ability to edit the membership organisation isn't an issue for us as we only have one membership organisation. However, other organisations may want to be able to do this for the same reason as above.
The ability to edit the membership status also isn't an issue for us, but I don't really understand the logic of freezing it for auto-renew memberships and so I'm also including it here for consistency.
# Proposal
My proposal is that CiviCRM core shouldn't freeze any of these fields. If required they can be frozen by an individual payment processor or other extension.
My feeling was that the logic about whether the fields should be editable or not will vary from organisation to organisation depending on the business processes of the organisation and the payment processor that they use. So, I don't feel that CiviCRM core should be imposing this. It should be down to each organisation to make their own customisations as required. If and where appropriate it could be included in the logic for an individual payment processor.
This involves removing the relevant code as per [PR #15505](https://github.com/civicrm/civicrm-core/pull/15505).
# Summary of changes
*This summary is for the benefit of those who don't want to read the lengthy discussions below. It can also be used in the release notes.*
This change fixes an issue which meant that it wasn't possible to edit some membership fields when a membership was set to auto-renew. Following the change it is now possible to edit all of the fields on the edit membership form.
* These fields are no longer frozen:
* Membership Organisation
* Membership Type
* Membership Status
* A warning is displayed to alert users that any changes they make to the membership may not be reflected in the payment processor
* The Membership Organisation/Type field is initially uneditable but there is a link to make it editable
If the membership is *not* set to auto-renew there is no change to the edit membership form. So this change will have no effect on organisations that don't offer recurring payments for membership.
If your organisation *does* offer recurring payments for membership you should make staff aware of these changes. In particular you should make them aware that changes they make to the membership may not be reflected in the payment processor. This means that if you make a change you may also need to update the corresponding record in the payment processor. This depends on the particular payment processor that your organisation uses so you will need to check the functionality that your payment processor supports.
If you would like to restore the previous functionality so that these fields are frozen and uneditable you can install this extension: [Freeze Membership Fields](https://lab.civicrm.org/extensions/freeze-membership-fields).
The change will be included in CiviCRM version 5.25 which is due for release in May 2020. See [PR #16609](https://github.com/civicrm/civicrm-core/pull/16609) for more details on the change.
https://lab.civicrm.org/dev/core/-/issues/1137Feature Request: Ability to enable SSL for database connection.2020-08-11T09:02:23ZtodddFeature Request: Ability to enable SSL for database connection.As far as I can tell, there is no way within civicrm core to enable SSL connections to a remote database. This would be a major concern for anyone running CiviCRM with separate web and database servers. I've 'solved' this issue for mys...As far as I can tell, there is no way within civicrm core to enable SSL connections to a remote database. This would be a major concern for anyone running CiviCRM with separate web and database servers. I've 'solved' this issue for myself by making the changes to civicrm/civicrm/packages/DB/common.php and civicrm/civicrm/packages/DB/mysqli.php detailed [here](https://civicrm.stackexchange.com/questions/31422/ssl-encypted-database-connection-for-civicrm), but it's rather sloppy and may need to be re-done after an update. Would be very useful to be able to set a flag within civicrm.settings.php (or even the initial install page) to enable SSL.5.29.0https://lab.civicrm.org/dev/core/-/issues/785Differentiate smart group from regular group using icon in select2 field2020-07-27T19:47:10ZMonish DebDifferentiate smart group from regular group using icon in select2 fieldCurrently there is no way to tell which group is smart or regular group from UI. It would be ideal to use icon against such smart group options to differentiate them from regular ones.Currently there is no way to tell which group is smart or regular group from UI. It would be ideal to use icon against such smart group options to differentiate them from regular ones.5.29.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/630CiviCase multi-category/ multi-instance support2022-10-29T05:03:41ZguanhuanCiviCase multi-category/ multi-instance supportRecently having had some discussions with a few of our clients and participants of CiviMeetup, We have realised that there are a lot of interest in using CiviCase to manage many different types of workflows in different organisations. So...Recently having had some discussions with a few of our clients and participants of CiviMeetup, We have realised that there are a lot of interest in using CiviCase to manage many different types of workflows in different organisations. Some of them require a change to evolve CiviCase’s data model to a multi-level structure.
To support this idea, I have attached a diagram to demonstrate the multi-level structure. We have suggested that a new field “case type category” would provide a lot of flexibility.
![CiviCase_Structure](/uploads/b73a3f3e8eb1d71034ac9121e1379f9c/CiviCase_Structure.jpg)
The basic idea is, an organisation’s business is made up of many different workflows for different business areas, such as Service delivery (i.e. a Helpdesk, Counselling service or Delivering care/housing support), Prospecting (i.e. major donors, grants bid writing in), Awards (i.e. Grants out), Volunteer vacancy management and even perhaps as a set of tasks for an event etc. These completely different workflows often are managed by completely different teams (who would need to manage their own case types), produce very different data and therefore require very different analysis and reports. "Case Type” is not sufficient to support all these needs as there may be several case types which apply to any specific business area.
Each team would probably want:
- The ability to create/configure case types of their category. For example with a volunteer vacancy managers they may want to create multiple vacancies, or with Grants, there may be multiple open opportunities. For Major donors they may split these between different types of donor - i.e. trusts, individuals, government which have different timelines and activities.
- The ability to add additional fields at the case type level for each category.
- Only having access to cases with the case type category they should have access to
- Some modifications to the case screen for cases of that case type category.
We've made a more detailed [draft proposal](https://compucorp.atlassian.net/wiki/spaces/PS/pages/1014398991/CiviCase+multi-category+support) of what we need to do to eliminate these caveats. The main target is to bring out the full potential of CiviCase as CiviCRM’s workflow management suite.https://lab.civicrm.org/dev/core/-/issues/449Bug: log_civicrm_group table grows insanely quickly2019-11-04T04:08:32ZAgilewareBug: log_civicrm_group table grows insanely quicklyBest demonstrated by example:
```
select count(id) `entries`, count(distinct id) `ids`, min(log_date) `since`, now() `now` from log_civicrm_group;
```
| entries | ids | since | now |
|---------|-----|-----...Best demonstrated by example:
```
select count(id) `entries`, count(distinct id) `ids`, min(log_date) `since`, now() `now` from log_civicrm_group;
```
| entries | ids | since | now |
|---------|-----|---------------------|---------------------|
| 31813 | 223 | 2018-10-16 14:14:51 | 2018-10-17 11:03:18 |
This is for a < 22hr period after I cleared this table to try and solve a data migration issue; before, this particular log table had grown to nearly 7 gigabytes (for the same 223 distinct group ids).
What appears to be happening is that every time the group_rebuild job is called, the cache_date is being NULLed and filled back in, creating two additional pointless log entries.
Per group id, I counted up to 250 log entries where only these fields had changed.
I think it should be possible to fix this by one of:
1. Disabling logging the the group_rebuild API call runs; or
2. excluding changes to just the cache_date and refresh_date fields from the civicrm_group triggers
Agileware ref CIVICRM-10015.12.0https://lab.civicrm.org/dev/core/-/issues/441Proposal - Add Timezone support for all Date/Time fields in CiviCRM2023-07-02T19:22:33Zjustinfreeman (Agileware)Proposal - Add Timezone support for all Date/Time fields in CiviCRMAdd Timezone support for all Date/Time fields in CiviCRM. Currently, CiviCRM does not have any timezone handling for date/time fields - timezone is not stored with the value.
The first change is to start storing a timezone with the date...Add Timezone support for all Date/Time fields in CiviCRM. Currently, CiviCRM does not have any timezone handling for date/time fields - timezone is not stored with the value.
The first change is to start storing a timezone with the date/time field. After this is implemented then other changes can follow which deal with the display of the date/time field in the local time zone or showing the timezone for the value.
**Proposed Change**
Have ability to set the timezone for a date/time field and store that value with the field.
Default timezone should set using the CMS timezone default and/or a new setting on the Localisation Settings page.
Agileware Ref: CIVICRM-995https://lab.civicrm.org/dev/core/-/issues/339Support utf8mb4 so notes can save Emojis and other good things2021-12-16T21:04:12ZgharrisSupport utf8mb4 so notes can save Emojis and other good things(Joe is highjacking this bug report issue to deal with general support for utf8mb4 as suggested by @gharris at https://lab.civicrm.org/dev/core/issues/392#note_8614)
As part of moving to support MySQL8, we should plan on better support ...(Joe is highjacking this bug report issue to deal with general support for utf8mb4 as suggested by @gharris at https://lab.civicrm.org/dev/core/issues/392#note_8614)
As part of moving to support MySQL8, we should plan on better support for utf8mb4 charset.
This issue was originally about bug with emojis that will be solved by this. It needs planning and agreement on approach as well as eventual development.
Now is a good time to consider shifting from charset utf8 (which only supports 3 bytes and doesn't fully implement the UTF8 standard https://medium.com/@adamhooper/in-mysql-never-use-utf8-use-utf8mb4-11761243e434) to the new default charset of utf8mb4, and at same time change the collation from utf8_unicode_ci to the new default of utf8mb4_0900_ai_ci. This will allow new emoticons as well as more languages and their characters to be properly stored in CiviCRM. My sense is that this is not difficult to code in GenCode. However, extensions that define fields in other collations and then compare them to core fields will likely need to be modified. Maybe an extension that changes the charset and collation of all core fields, and that hooks into the dynamic creation of fields for custom fields, is a way to start down this path.
---------- Original description below
Apparently Notes don't like emoji characters. Kind of funny that watching the logs via SSH the emoji renders, but it won't save. After only removing the emoji characters from the text, the note saved correctly.
Characters that were removed:
😳❤️ ❤️ 😜
```
Here's a backtrace:
Aug 17 13:15:39 [info] $backTrace = #0 /basedir/civicrm/civicrm/CRM/Core/Error.php(232): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /basedir/civicrm/civicrm/packages/PEAR.php(921): CRM_Core_Error::handle(Object(DB_Error))
#2 /basedir/civicrm/civicrm/packages/DB.php(985): PEAR_Error->__construct("DB Error: unknown error", -1, 16, (Array:2), "INSERT INTO civicrm_note (entity_table , entity_id , note , contact_id , modi...")
#3 /basedir/civicrm/civicrm/packages/PEAR.php(575): DB_Error->__construct(-1, 16, (Array:2), "INSERT INTO civicrm_note (entity_table , entity_id , note , contact_id , modi...")
#4 /basedir/civicrm/civicrm/packages/PEAR.php(223): PEAR->_raiseError(Object(DB_mysqli), NULL, -1, 16, (Array:2), "INSERT INTO civicrm_note (entity_table , entity_id , note , contact_id , modi...", "DB_Error", TRUE)
#5 /basedir/civicrm/civicrm/packages/DB/common.php(1907): PEAR->__call("raiseError", (Array:7))
#6 /basedir/civicrm/civicrm/packages/DB/mysqli.php(933): DB_common->raiseError(-1, NULL, NULL, "INSERT INTO civicrm_note (entity_table , entity_id , note , contact_id , modi...", "1366 ** Incorrect string value: '\xF0\x9F\x98\xB3\xE2\x9D...' for column 'not...")
#7 /basedir/civicrm/civicrm/packages/DB/mysqli.php(403): DB_mysqli->mysqliRaiseError()
#8 /basedir/civicrm/civicrm/packages/DB/common.php(1216): DB_mysqli->simpleQuery("INSERT INTO civicrm_note (entity_table , entity_id , note , contact_id , modi...")
#9 /basedir/civicrm/civicrm/packages/DB/DataObject.php(2415): DB_common->query("INSERT INTO civicrm_note (entity_table , entity_id , note , contact_id , modi...")
#10 /basedir/civicrm/civicrm/packages/DB/DataObject.php(1040): DB_DataObject->_query("INSERT INTO civicrm_note (entity_table , entity_id , note , contact_id , modi...")
#11 /basedir/civicrm/civicrm/CRM/Core/DAO.php(571): DB_DataObject->insert()
#12 /basedir/civicrm/civicrm/CRM/Core/BAO/Note.php(173): CRM_Core_DAO->save()
#13 /basedir/civicrm/civicrm/CRM/Note/Form/Note.php(194): CRM_Core_BAO_Note::add((Array:26), (Array:0))
#14 /basedir/civicrm/civicrm/CRM/Core/Form.php(489): CRM_Note_Form_Note->postProcess()
#15 /basedir/civicrm/civicrm/CRM/Core/QuickForm/Action/Upload.php(169): CRM_Core_Form->mainProcess()
#16 /basedir/civicrm/civicrm/CRM/Core/QuickForm/Action/Upload.php(136): CRM_Core_QuickForm_Action_Upload->realPerform(Object(CRM_Note_Form_Note), "upload")
#17 /basedir/civicrm/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Upload->perform(Object(CRM_Note_Form_Note), "upload")
#18 /basedir/civicrm/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Note_Form_Note), "upload")
#19 /basedir/civicrm/civicrm/CRM/Core/Controller.php(351): HTML_QuickForm_Page->handle("upload")
#20 /basedir/civicrm/civicrm/CRM/Contact/Page/View/Note.php(182): CRM_Core_Controller->run()
#21 /basedir/civicrm/civicrm/CRM/Contact/Page/View/Note.php(225): CRM_Contact_Page_View_Note->edit()
#22 /basedir/civicrm/civicrm/CRM/Core/Invoke.php(309): CRM_Contact_Page_View_Note->run((Array:4), NULL)
#23 /basedir/civicrm/civicrm/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:14))
#24 /basedir/civicrm/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:4))
#25 /basedir/civicrm/civicrm.php(1246): CRM_Core_Invoke::invoke((Array:4))
#26 /wp-base-dir/wp-includes/class-wp-hook.php(286): CiviCRM_For_WordPress->invoke("")
#27 /wp-base-dir/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters("", (Array:1))
#28 /wp-base-dir/wp-includes/plugin.php(453): WP_Hook->do_action((Array:1))
#29 /wp-base-dir/wp-admin/admin.php(224): do_action("toplevel_page_CiviCRM")
#30 {main}
```
Edit: Reordered emojis to match the way they appeared in original log file.
Summary of current state (edited Oct. 2, 2018):
Proposed ideas:
I. Create Extension for changing the way database definitions are handled in order to fit the LExIM approach
1. Create blog post and extension developer heads up materials based on proposed changes
2. Create new global variables that reside in civicrm.settings.php, thus creating new defaults for new installations
a. dbChar=utf8mb4 - To define the character set used by the installation
b. dbColl=utf8mb4_unicode_520_ci - To define the collation used by the installation
c. dbEngine=InnoDB - To define whether the table is innodb or myisam or whatever comes next
3. Define new global variables that can replace some of code (I believe that JoeMurray has expressed concerns with this step. If I've misread which concerns are being raised, please redirect.)
a. dbEngineCharColl - a concatenation that would end up looking like "ENGINE=InnoDB DEFAULT CHARACTER SET utf8 COLLATE utf8mb4_unicode_520_ci"
b. dbCharColl - another common concatenation that looks like it is reused multiple times throughout the code
4. During bootstrap, check if the new variables are set, and if they are empty, fill them with the current defaults of utf8 and utf8_unicode_ci, this keeps current installs from breaking on upgrade
5. Replace all instances of database definitions with the appropriate variables (I think this is a set of five SED commands that I haven't built yet!)
II. Create an extension to upgrade existing installs to the new defaults, similar to Eileen's innodbtriggers extension, perhaps utilizing something similar to the script posted above, though it should probably utilize SQL commands directly, rather than a bash script
1. Check current installed version of MySQL to see if utf8mb4_0900_ai_ci is available and act accordingly.
a. For MySQL 5.7 and below the current preferred collation seems to be utf8mb4_unicode_520_ci.
b. For MySQL 8.0 the current preferred collation seems to be utf8mb4_0900_ai_ci.
2. Convert existing database to the determined collation above
a. There's a bash script below to get started (https://lab.civicrm.org/dev/core/issues/339#note_8461)
b. Is this done via PHP script or via MySQL commands?
c. Should this conversion be limited to only the core fields as to not break existing extensions?
3. Change the value of civicrm.settings.php dbChar and dbColl variables to match above via PHP script.
4. Create a warning in System Status if my.cnf defaults do not match dbEngine, dbChar, and dbColl variables
5. Create a hook into post event on creation of custom fields (https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_post/) to change the charset and collation of tables and fields created to support newly defined custom fields.
III. Figure out what to do about other Extensions that have hard coded collation/charsets
1. Create helpful documentation for converting code to the Database variable model
2. Create template-able MySQL conversion scripts to be included in the update. Or can this be done with the hook?
IV. Rejoice in the sound of crickets instead of phone calls!https://lab.civicrm.org/dev/core/-/issues/306Main payment method is not getting updated after modifying it in payment details2023-01-22T05:03:42Zrita_compucorpMain payment method is not getting updated after modifying it in payment detailsWhen you create a contribution with payment method A and then go and change the payment method to B, on the main contribution it will still show the payment method A instead of B.
Steps:
- create a new contribution with Payment Method:...When you create a contribution with payment method A and then go and change the payment method to B, on the main contribution it will still show the payment method A instead of B.
Steps:
- create a new contribution with Payment Method: Check http://nimb.ws/3HN4qv
- then go and edit the contribution, change the payment method using the Pen icon on the payment detail
- change the payment method to Cash
- save it, and save the contribution too
- then open to View the contribution and you can see the changed payment details, but the main contribution's payment method is still Check and not Cash http://nimb.ws/FOUCj9
--> the main Payment Method field should reflect the modified payment method, not the original onehttps://lab.civicrm.org/dev/core/-/issues/302End of life plans for 5.x php versions & planning for 7.0 EOL2020-01-30T02:01:26ZeileenEnd of life plans for 5.x php versions & planning for 7.0 EOLWe have had some discussion about EOL on php 5.x versions. The text below is a proposed blog post:
**End of life plans for 5.x php versions & planning for 7.0 EOL **
This blog serves as advance notice of our intention to stop supportin...We have had some discussion about EOL on php 5.x versions. The text below is a proposed blog post:
**End of life plans for 5.x php versions & planning for 7.0 EOL **
This blog serves as advance notice of our intention to stop supporting php versions 5.5, 5.6 and our ongoing evaluation of 7.0.
For php 5.5 we intend to end support in January 2019. This is already unsupported by php and we strongly recommend you upgrade off it as soon as possible. The release in February 2019 will be the first release that does not support php 5.5
For php 5.6 our TARGET is to end support in September 2019 (Oct release would support php 7.0+). 5.6 and 7.0 will unsupported by php from the end of this year. Usage of these versions is still pretty high amongst CiviCRM users http://stats.civicrm.org/?tab=sites so we will review this target in the first quarter of next year & extend it if we feel it will cause undue pain. Supporting 5.6 has downsides in that it restricts the external packages and versions of those packages we can use. As time goes on the risk of it leaving us without a secure option increases, as well as reducing opportunities to use more modern packages and to improve our code and product.
For php 7.0 our TARGET is the end of 2019. We will be reviewing this in March as well to see how reasonable that is. There is less to gain from dropping 7.0 than 5.6 so we will take that into account.
**What version of php should you be using?**
In general you should aim to be on php 7.1 or 7.2. For drupal 7 users you may find that there are extensions that you rely on that do not yet support php 7.1 - although this will be less and less likely over time. See https://www.drupal.org/docs/7/system-requirements/drupal-7-php-requirements#php_required for more information.
Note that as of writing there are only a small number of sites on 7.2 http://stats.civicrm.org/?tab=technology so you may wish to check php 7.2 adoption stats before choosing php 7.1 over php 7.2 in case there are any remaining issues.https://lab.civicrm.org/dev/core/-/issues/4350Proposal: Smart Group Profiler to help identify slow smart groups2023-11-02T14:29:14ZlarsssandergreenProposal: Smart Group Profiler to help identify slow smart groupsSlow smart groups are a problem that I'm sure we've all experienced. It's difficult for users to guess which of their potentially many smart groups is exceptionally slow or if they just have too many, each taking a little time. @JonGold ...Slow smart groups are a problem that I'm sure we've all experienced. It's difficult for users to guess which of their potentially many smart groups is exceptionally slow or if they just have too many, each taking a little time. @JonGold has a [profiling script](https://gist.github.com/MegaphoneJon/59089c1e155645a438af41051bca7ce7), but that's not accessible to many. I'm sure many orgs would be happy to cut or re-work their slow smart groups if it meant they could use the listing accordion on individual contacts, etc — but they just don't know which ones they need to cut!
What I propose is a Smart Group Profiler in Admin that lets admin users easily check their smart groups in the UI. Here's a quick sketch:
- The user can select groups to profile or leave the select empty to profile all (active, non-hidden) smart groups
- The user can select to run once or average up to three times, to reduce the potential for random variation
- The profiler queues CRM_Contact_BAO_GroupContactCache::add for each group, in random order
- Once the queue finishes, the user gets a table with average time and links to edit the Smart Group criteria for each
I'd be happy to do this as an extension, but it also seems like something that address a core problem, so I think it makes sense to have in core.5.67.0https://lab.civicrm.org/dev/core/-/issues/4118SearchKit: Decide on available actions per display (funded)2023-03-02T16:50:07ZAndreasandreas.howiller@civiservice.deSearchKit: Decide on available actions per display (funded)Overview
----------------------------------------
Sometimes it would be very helpful to be able to decide in a SearchKit display which actions can be used. One example: Your Case Mangers need a SearchKit on contacts having a role in a ca...Overview
----------------------------------------
Sometimes it would be very helpful to be able to decide in a SearchKit display which actions can be used. One example: Your Case Mangers need a SearchKit on contacts having a role in a case to do some bulk actions. For obvious reasons you don't want them to be able to delete contacts here but in general you do want them to have the permission to delete contacts.
Another Example [from StackExchange where this has already been discussed](https://civicrm.stackexchange.com/questions/41790/controlling-available-search-kit-actions-at-a-granular-level): "I may want contacts to merge records but not delete records en masse on a search display. Other actions don't have a specific permission tied to them that have no other way of being controlled."
Current behaviour
----------------------------------------
All actions corresponding to the user's permission level are available in the dropdown.
Proposed behaviour
----------------------------------------
For each display you can configure in the UI which actions are available.
Comments
----------------------------------------
Any thoughts are welcome.
We could fund up to 5hrs on this.https://lab.civicrm.org/dev/core/-/issues/3991Drop php 7.2 support from CiviCRM 5.58 (after 5.57 ESR)2023-11-28T10:48:51ZeileenDrop php 7.2 support from CiviCRM 5.58 (after 5.57 ESR)Per previous efforts to drop PHP version support I propose we drop 7.2 in 5.58. This means people who want another 6 months can use the ESR. Usage numbers for php 7.2 (around 1k) are around the levels where we dropped previous versions &...Per previous efforts to drop PHP version support I propose we drop 7.2 in 5.58. This means people who want another 6 months can use the ESR. Usage numbers for php 7.2 (around 1k) are around the levels where we dropped previous versions & support is starting to get harder - see https://github.com/civicrm/civicrm-core/pull/24952