CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-01-15T11:40:21Zhttps://lab.civicrm.org/dev/core/-/issues/4900Crash when disabling an extension that provides an entity that is referenced ...2024-01-15T11:40:21ZufundoCrash when disabling an extension that provides an entity that is referenced in a custom fieldReproduction steps
----------------------------------------
1. Enable an extension which adds a new entity
1. Add a Custom Field through the UI which is an EntityReference to the entity from the extension
1. Disable the extension
2. Cras...Reproduction steps
----------------------------------------
1. Enable an extension which adds a new entity
1. Add a Custom Field through the UI which is an EntityReference to the entity from the extension
1. Disable the extension
2. Crash ensues
Current behaviour
----------------------------------------
Every Civi page crashes with
```
The website encountered an unexpected error. Please try again later.
TypeError: CRM_Core_DAO_AllCoreTables::getTableForEntityName(): Return value must be of type string, null returned in CRM_Core_DAO_AllCoreTables::getTableForEntityName() (line 365 of /var/www/html/vendor/civicrm/civicrm-core/CRM/Core/DAO/AllCoreTables.php).
Civi\Api4\Service\Schema\SchemaMapBuilder::getTableName('MyCustomEntity') (Line: 149)
Civi\Api4\Service\Schema\SchemaMapBuilder->addCustomFields(Object, Object, 'Contact') (Line: 74)
Civi\Api4\Service\Schema\SchemaMapBuilder->loadTables(Object) (Line: 52)
Civi\Api4\Service\Schema\SchemaMapBuilder->build() (Line: 309)
Civi\Api4\Utils\CoreUtil::getSchemaMap() (Line: 773)
Civi\Api4\Query\Api4SelectQuery->autoJoinFK('dashboard_contact.id') (Line: 183)
Civi\Api4\Query\Api4SelectQuery->buildSelectClause() (Line: 79)
Civi\Api4\Query\Api4Query->getSql() (Line: 90)
Civi\Api4\Query\Api4Query->getResults() (Line: 106)
Civi\Api4\Query\Api4SelectQuery->run() (Line: 107)
Civi\Api4\Generic\DAOGetAction->getObjects(Object) (Line: 94)
Civi\Api4\Generic\DAOGetAction->_run(Object) (Line: 72)
Civi\Api4\Provider\ActionObjectProvider->invoke(Object) (Line: 156)
Civi\API\Kernel->runRequest(Object) (Line: 256)
Civi\Api4\Generic\AbstractAction->execute() (Line: 91)
civicrm_api4('Dashboard', 'get', Array) (Line: 69)
CRM_Core_BAO_Dashboard::getContactDashlets() (Line: 46)
CRM_Contact_Page_DashBoard->run(Array, NULL) (Line: 322)
CRM_Core_Invoke::runItem(Array) (Line: 69)
CRM_Core_Invoke::_invoke(Array) (Line: 36)
CRM_Core_Invoke::invoke(Array) (Line: 88)
Drupal\civicrm\Civicrm->invoke(Array) (Line: 83)
Drupal\civicrm\Controller\CivicrmController->main(Array, '')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 592)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
```
Expected behaviour
----------------------------------------
I think it would be good to check for any custom fields referencing entities that are about to disappear before disabling the extension, and then:
a) disable those custom fields
OR
b) prevent you disabling the extension
Comments
----------------------------------------
I wonder if some very diligent extension authors may already handle this case in the extension disable logic and/or maybe there should be an option c) resolve the issue in some custom way specified by the extension?
Or maybe the `SchemaMapBuilder` could fail less catastrophically?
Only tested on D10.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/4891[PHP 8.1] Weight notices @ trash contact folder2024-02-09T20:39:06Zjofranzfranz@systopia.de[PHP 8.1] Weight notices @ trash contact folderOverview
----------------------------------------
_Weight notices @ trash contact folder_
Reproduction steps
----------------------------------------
1. Delete a contact in a non-permanent way
2. Go to: https://dmaster.demo.civicrm.org/...Overview
----------------------------------------
_Weight notices @ trash contact folder_
Reproduction steps
----------------------------------------
1. Delete a contact in a non-permanent way
2. Go to: https://dmaster.demo.civicrm.org/civicrm/contact/search/advanced (user/pass: demo demo)
3. Select: "Search in Trash
(deleted contacts)" (Important!!!)
4. Hit "Search"
Current behaviour
----------------------------------------
Many weight notices:
```
Warning: Undefined array key "weight" in CRM_Core_Action::{closure}() (line 318 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Action.php).
Warning: Undefined array key "weight" in CRM_Core_Action::{closure}() (line 318 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Action.php).
Warning: Undefined array key "weight" in CRM_Core_Action::{closure}() (line 318 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Action.php).
Warning: Undefined array key "weight" in CRM_Core_Action::{closure}() (line 318 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Action.php).
```
Expected behaviour
----------------------------------------
No notices.
Environment information
----------------------------------------
* __Browser:__ _Firefox_
* __CiviCRM:__ _5.68.1 (guess also below and above)_
* __PHP:__ _8.1+_
* __CMS:__ _Drupal10_
* __Database:__ _WhateverDB_
* __Web Server:__ _An amazing one even!_
----------------------------------------
_systopia reference: 23444_eileeneileenhttps://lab.civicrm.org/dev/core/-/issues/4890CiviCRM could not create trigger2024-02-01T10:38:38ZktatgenhorstCiviCRM could not create triggerOverview
----------------------------------------
_Please describe your problem or bug in detail._
Installation of version 5.69.0 on a fresh Ubuntu install with WordPress.
1. I used this link to setup Wordpress on Ubuntu:
https://ub...Overview
----------------------------------------
_Please describe your problem or bug in detail._
Installation of version 5.69.0 on a fresh Ubuntu install with WordPress.
1. I used this link to setup Wordpress on Ubuntu:
https://ubuntu.com/tutorials/install-and-configure-wordpress#1-overview
2. I followed this set of instructions to install CiviCRM:
https://docs.civicrm.org/installation/en/latest/wordpress/
3. When I go to the installation/setup wizard I add the credentials for the database I created (separate from WP database and the user has grant all and specifically grant trigger on civicrm.*). I did destroy the VM and build a second time with same steps and results.
_If you have already posted on https://civicrm.stackexchange.com or https://chat.civicrm.org, please include the link to that conversation._
I have not posted there, but I see older posts regarding this on previous versions. None of those offer a valid solution for this present issue,
Reproduction steps
----------------------------------------
1. Click on **Contacts -> New Individual**.
1. Entered **First Name** and **Last Name** and clicked **Save**.
1. Got an error "**Fatal error: DB error**".
Current behaviour
The setup stops after DB connect and reports unable to create triggers.
----------------------------------------
_What happens currently. Please provide error messages, screenshots or gifs ([LICEcap](http://www.cockos.com/licecap/), [SilentCast](https://github.com/colinkeenan/silentcast)) where appropriate._
```
TIP: The best way to convey an error message is to copy it in here and use
three backtick ` symbols. You may edit the message to remove private
information (like passwords). The backticks will help to preserve any
special characters or spaces.
```
Expected behaviour
----------------------------------------
_What should happen._
I should pass through the setup screen and have a functioning CiviCRM install.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
Ubuntu 20.04
MySqlD 8.0.35
Php 8.2.4
Apache2 2.4.41
CiviCRM 5.69.0
* __Browser:__ _Firefox 59.0.1/Chrome 78.0.3904/Safari 13_
* __CiviCRM:__ _Master/5.20.0/5.19.1/5.18.2/..._ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.0/7.1/7.2/7.3/...__
* __CMS:__ _Backdrop 1.5/Drupal 7.30/Joomla 3.3/WordPress 4.5/..._
* __Database:__ _MySQL 5.7.7/MariaDB 10.4/..._
* __Web Server:__ _Apache 2.4/Nginx 1.16/..._
Comments
----------------------------------------
_Anything else you would like the reviewer to note._
Thank you,
Karl Tatgenhorsthttps://lab.civicrm.org/dev/core/-/issues/4868Add action for copy activity2023-12-20T19:16:21ZyashodhaAdd action for copy activityWe do have copy action on various entities like _Contribution Page_, _Events_.
It might be handy to have the same for _Activity _as well.
Also provide _Save as New_ feature/ when clicked we can have a new activity created with addition...We do have copy action on various entities like _Contribution Page_, _Events_.
It might be handy to have the same for _Activity _as well.
Also provide _Save as New_ feature/ when clicked we can have a new activity created with additional tweaks based on a pre-existing activity. This would come esp handy for activities which have lots of Activity Contacts/Targets/assignees and custom dat awith the original activity acting as a template.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4865The "X" on advanced search accordions isn't doing the right thing anymore2023-12-20T19:15:35ZDaveDThe "X" on advanced search accordions isn't doing the right thing anymoreFollowup to https://lab.civicrm.org/dev/core/-/issues/4856
It looks like it's been a problem since at least 5.63.
What used to happen was if you just collapsed the accordion, it still used whatever search criteria had been entered (bec...Followup to https://lab.civicrm.org/dev/core/-/issues/4856
It looks like it's been a problem since at least 5.63.
What used to happen was if you just collapsed the accordion, it still used whatever search criteria had been entered (because after the search the form still needs to retain the search criteria even with them collapsed), and in fact even just opening the accordion would make it do the table joins (e.g. if you open the contributions accordion it's the same as "only show me contacts who have at least one contribution"). That's all working now again after 4856. But the "X" at the far right of the accordion header was there to completely remove the criteria and table joins from the query. That's not working anymore, and broke before any accordion changes.
It is _sort of_ working in the sense that it will clear contribution date for example, but not some other fields like id or transaction. And in both cases the accordion still pops open after search. Also note the defaults disappear so it's now including test and template contributions.
And additionally, for transaction, if you repeat and close the accordion again and click search again, you get a crash because it tries to pass array for some reason to mysqli_escape_string.https://lab.civicrm.org/dev/core/-/issues/4858Contact id quicksearch broken2024-03-15T13:24:20ZAndy ClarkContact id quicksearch brokenContact id quicksearch has broken in 5.67.3, albeit occasionally. User cannot locate any contacts by id at all, and using Drupal 'masquerade I verified this to be the case. The fix was to run the 'Cleanup Caches' option. What may be a...Contact id quicksearch has broken in 5.67.3, albeit occasionally. User cannot locate any contacts by id at all, and using Drupal 'masquerade I verified this to be the case. The fix was to run the 'Cleanup Caches' option. What may be a clue is that this system uses ACLs and although this user would have been restricted by ACLs she would have had access to the contacts she was searching for. As an administrator I could see the contacts when she couldn't which does seem to point to ACLs as the problem.https://lab.civicrm.org/dev/core/-/issues/4845CiviEvent with approvals: Registration form not pre-filled with (custom) part...2023-12-20T19:21:06ZTobias Voigttobias.voigt@civiservice.deCiviEvent with approvals: Registration form not pre-filled with (custom) participant dataI'm not sure wether this is a proposal or an issue. I'm using the approval workflow for CiviEvent where participants get a confirmation link after they've been approved by admins.
While this works great for simple registration use cases...I'm not sure wether this is a proposal or an issue. I'm using the approval workflow for CiviEvent where participants get a confirmation link after they've been approved by admins.
While this works great for simple registration use cases, where only contact information is gathered in the initial registration form, this feature regrettably can't be used for more comlex use cases, where the initial form also contains additional (custom) participant data (e.g. "Do you want the vegetarian option for dinner?").
So, if there's any fields for custom participant data in the initial registration form, users would fill out the form and send it. Afterwards, admins approve the registration and a confirmation link is sent out to the approved user. If he/she clicks on the confirmation link and chooses to confirm, all contact data gets pre-filled into the form - BUT: the participant data - which is already stored in the database from the initial form - is not pre-filled and has to be filled out again.
This drastically limits the scope of use cases this feature could work for, since in almost all our client's projects we work with additional / custom participant data.
So my question is: Is this a bug and the participant data should actually be loaded during the confirmation process? Or was this feature never intended? Or maybe the feature was intended but never realized? In any case: What might be the scope of development work necessary to not only pre-fill the confirmation form with contact data but also with participant data?https://lab.civicrm.org/dev/core/-/issues/4790Can't set time format to 24 hr anymore2023-11-22T18:27:13ZDaveDCan't set time format to 24 hr anymoree.g. for date preferences set activityDate to 24 hr time. Then on a contribution the time field should be 24 hrs.
I have a feeling it's related to the same problem as https://lab.civicrm.org/dev/financial/-/issues/221 and the fix there ...e.g. for date preferences set activityDate to 24 hr time. Then on a contribution the time field should be 24 hrs.
I have a feeling it's related to the same problem as https://lab.civicrm.org/dev/financial/-/issues/221 and the fix there isn't entirely correct because something else changed about time_format. I'm not sure it's supposed to be a boolean but haven't confirmed.https://lab.civicrm.org/dev/core/-/issues/4776Todo: Look at whether these test fails mean anything2023-11-14T16:38:47ZDaveDTodo: Look at whether these test fails mean anythingSomewhere in their flow, they call CRM_Core_Form::getAuthenticatedCheckSumContactID and it calls CRM_Core_Form::getRequestedContactID which returns null. Should it be null or the correct contact id?
This maybe qualifies as a regression ...Somewhere in their flow, they call CRM_Core_Form::getAuthenticatedCheckSumContactID and it calls CRM_Core_Form::getRequestedContactID which returns null. Should it be null or the correct contact id?
This maybe qualifies as a regression but at the moment I don't have a specific bug. It came up in the context of https://github.com/civicrm/civicrm-core/pull/28128 where they all fail if validateAuthenticatedCheckSumContactID() is expecting not null.
api_v3_ContributionPageTest.testValidate
api_v3_ContributionPageTest.testValidatePost
api_v3_ContributionPageTest.testValidateOutputOnMissingRecurFields
CRM_Contribute_Form_Contribution_ConfirmTest.testPayNowPayment
CRM_Contribute_Form_Contribution_ConfirmTest.testSeparatePaymentConfirm
CRM_Contribute_Form_Contribution_MainTest.testSetRecurFunction
CRM_Contribute_Form_Contribution_MainTest.testSetRecurFunctionOptionalYes
CRM_Contribute_Form_Contribution_MainTest.testSetRecurFunctionOptionalNo
CRM_Contribute_Form_Contribution_MainTest.testSetRecurFunctionNotAvailable
CRM_Contribute_Form_Contribution_MainTest.testExpiredPriceSet
CRM_Contribute_Form_ContributionTest.testContributionBasePreProcess
CRM_Core_FormTest.testGetAuthenticatedUser
CRM_Event_Form_Registration_ConfirmTest.testSubmit
CRM_Event_Form_Registration_ConfirmTest.testWaitlistRegistrationContactIDParam
CRM_Event_Form_Registration_ConfirmTest.testTaxMultipleParticipant
CRM_Event_Form_Registration_ConfirmTest.testMailMultipleParticipant
CRM_Event_Form_Registration_ConfirmTest.testOnlineRegNoPrice
CRM_Event_Form_Registration_ConfirmTest.testSubmitNonPrimaryEmail
CRM_Event_Form_Registration_ConfirmTest.testRegistrationWithoutCiviContributeEnabled
CRM_Event_Form_Registration_ConfirmTest.testPaidSubmit with data set #0
CRM_Event_Form_Registration_ConfirmTest.testPaidSubmit with data set #1
CRM_Event_Form_ParticipantTest.testTransferParticipantRegistration
CRM_Event_Form_SelfSvcTransferTest.testCancel
CRM_Event_Form_Registration_ConfirmTest.testNoteSubmissionhttps://lab.civicrm.org/dev/core/-/issues/4765Add label field to OAuthClient entity2023-11-14T16:35:42ZjensschuppeAdd label field to OAuthClient entity## Overview
We came across a use-case for multiple _OAuthClient_ entites with the same _Client ID_, which makes differentiating them difficult in the UI. We'd like to propose adding a field for an administrative label to the _OAuthClien...## Overview
We came across a use-case for multiple _OAuthClient_ entites with the same _Client ID_, which makes differentiating them difficult in the UI. We'd like to propose adding a field for an administrative label to the _OAuthClient_ entity and defining it as the `label_field`. It might also be a good idea to make labels required.
## Proposed behaviour
We're currently building an API extension for synchronizing data from another CRM-like system that requires authorization via OAuth and differentiates multiple instances/sources by using different access tokens for the same client ID/secret.
Our sync API uses configurable profiles which have the OAuth client as a configuration option, so there's a field for selecting an OAuth client in the UI. The only attribute for differentiating OAuth clients in that field is their internal (CiviCRM) ID, as Client ID and secret are the same and the access token should not be exposed and might change. This is not convenient for admins, as they will have to remember which (internal) OAuth client ID corresponds to which instance, which is likely to cause misconfigurations and errors.
I guess this will need:
* the XML schema of the `OAuthClient` entity be extended with a `label` field
* `civix generate:entity-boilerplate`
* Upgrade script for applying schema changes - thanks @eileen!
* anything else?
Happy to hear your thoughts!https://lab.civicrm.org/dev/core/-/issues/4762SearchUI: Manage Extensions with SK/FB2023-11-14T16:34:11Zaydunsaidan.saunders@squiffle.ukSearchUI: Manage Extensions with SK/FBIssues relating to replacing the 'Manage Extensions' page with SK/FB
Enable SearchUI extension then go to Administer > Experimental > Extensions
## Required to match current functionality:
- [ ] Way to determine whether extension ne...Issues relating to replacing the 'Manage Extensions' page with SK/FB
Enable SearchUI extension then go to Administer > Experimental > Extensions
## Required to match current functionality:
- [ ] Way to determine whether extension needs updating
- [ ] API enhancement (?) to get info.xml data
- [ ] Expandable sections - or show in pop-up?
- [ ] Metadata update to add 'Install', 'Upgrade' and 'Disable' actions
- [ ] Functionality to show not-installed extensions (ie 'Add New' tab)
## Improvements:
- [ ] Separate core/required from community extensions (could be filters or tabs)
- [ ] Better handling of extensions with local githttps://lab.civicrm.org/dev/core/-/issues/4753Afform - Custom fields of type YesNo (boolean): Defaults not displayed and ch...2024-03-10T20:37:04Zmattwiremjw@mjwconsult.co.ukAfform - Custom fields of type YesNo (boolean): Defaults not displayed and changes not savedTo reproduce set up a simple submission form:
1. Add Individual
2. Add "is_deceased" field (a Yes / No radio field) (optional)
3. Add a contact custom field of type "YesNo" (optional)
Create a contact and set the contact is_deceased = t...To reproduce set up a simple submission form:
1. Add Individual
2. Add "is_deceased" field (a Yes / No radio field) (optional)
3. Add a contact custom field of type "YesNo" (optional)
Create a contact and set the contact is_deceased = true and custom field "YesNo" = true
Load the form with URL parameter eg. #?Individual1=169 to load that contact
See that is_deceased field is set to Yes but the customfield is not set.
Now set the customfield to "No" and submit the form.
Reload the form and see that it did not save the value of the custom field :-(
So two issues:
1. Custom field value is not displayed: It is retrieved via prefill as a bool but the field is added with radios that have values 0,1.
2. Custom field value is not saved: It is converted to int (0 or 1) once submitted whether submitted as "false" or 0.
I've been round and round trying to work out how this should be fixed but have hit a dead end!
The display issue can be "fixed" by either not passing the options to the form or by passing them with true/false instead of 0,1. But the value still doesn't save.
@colemanw Any ideas?https://lab.civicrm.org/dev/core/-/issues/4738Fields disappear when there is a number validation in Activity custom fields2023-11-02T15:22:36ZbgmFields disappear when there is a number validation in Activity custom fieldsSeen in #4154, but not a new issue:
- Create a new Custom Group, for Activities
- In that group, create a new custom field of type numeric
Then go to a contact, and create a new activity (ex: meeting), and in the numeric field, enter s...Seen in #4154, but not a new issue:
- Create a new Custom Group, for Activities
- In that group, create a new custom field of type numeric
Then go to a contact, and create a new activity (ex: meeting), and in the numeric field, enter something invalid (ex: 123abc).
Result: validation error causes a fatal error:
![image](/uploads/4507a214a62f15c31b74672d392041cb/image.png)
And the custom fields, which are loaded using ajax, are not displayed.https://lab.civicrm.org/dev/core/-/issues/4715The Search-UI extension gives a menu item Experimental2023-10-26T11:36:52ZjaapjansmaThe Search-UI extension gives a menu item Experimental**Steps to reproduce**
1. Install a fresh CiviCRM (version 5.66)
2. Enable Search UI extension
**Results**
A new menu item called Experimental appears. See attached screenshot
![Untitled](/uploads/219b7c83f1303681f6afbbc15497eacf/Unt...**Steps to reproduce**
1. Install a fresh CiviCRM (version 5.66)
2. Enable Search UI extension
**Results**
A new menu item called Experimental appears. See attached screenshot
![Untitled](/uploads/219b7c83f1303681f6afbbc15497eacf/Untitled.png)
**Why is this an issue?**
This is an issue because the extension ships with a stable version of CiviCRM Core. And installing this on a production site gives some unexpected menu item.
When I download a stable version of CiviCRM I am not sure whether I would expect a menu item Experimental.
**Possible solution**
1. Move the extension out of core. This also has the benefit it can be installed on other versions of CiviCRM as well.
2. Do not use the menu item experimental but place the items provided in this extension in a more suitable place.
My opinion would be as long as this extension is experimental to not ship it with core.https://lab.civicrm.org/dev/core/-/issues/4711Make it easier for extensions to add Navigation Menu items2023-10-24T14:13:07ZcolemanwMake it easier for extensions to add Navigation Menu itemsBackground
------
Extensions have a few ways of adding to the navigation menu, and none of them are great.
1. `hook_civicrm_navigationMenu()` - brute-forces an item into the menu. It's relatively easy to implement (thanks to some extra...Background
------
Extensions have a few ways of adding to the navigation menu, and none of them are great.
1. `hook_civicrm_navigationMenu()` - brute-forces an item into the menu. It's relatively easy to implement (thanks to some extra fudging that `civix` does for you) but defeats the whole configurability idea; users and administrators have no control over the item.
2. `install`/`uninstall` hooks - this is hard to implement as there are a lot of edge cases to consider (domains, weights, etc) and you have to manage the full lifecycle yourself (install, disable, enable, uninstall).
3. `hook_civicrm_managed()` - this handles the lifecycle for you, but not the domains, and the weights are completely by guesswork. Changes made by the user (e.g. deleting the menu item) might be undone by `Managed::reconcile`.
4. `.aff.php` - Afforms allow you to declare a navigation menu as part of the form - this gets delegated to `hook_civicrm_managed()`, with all the same problems that carries, plus the additional problem that user-changes to the item can lose sync with the Afform settings (see https://lab.civicrm.org/dev/core/-/issues/4364).
IMO items 1 and 2 are unfixable, but item 3 has promise, and item 4 could be deprecated in favor of 3.
Outstanding problems with Managed Navigation Menu Items.
----------
- [x] 1. ManagedEntities cannot be deleted. If a user deletes a managed Navigation item, it will respawn with the next `Managed::reconcile`.
- [x] 2. Navigation BAO doesn't even call hooks, defeating the ManagedEntity `update=unmodified` mode.
- [x] 3. ManagedEntities are not domain-aware; if you want your navigation item to appear on all domains (which you do, since your extension will be enabled globally - there are no per-domain extensions), you have to declare a managed navigation item once per domain (which is [a bit awkward](https://github.com/civicrm/civicrm-core/blob/f04bfacb5ed5131c9d29e8a9c0725c3059caeef0/ext/legacycustomsearches/managed/Navigation.mgd.php#L7)).
- [ ] 4. Picking a `weight` is pure guesswork. You just have to put in an integer and hope it lands in the right spot. Picking `0` will pretty reliably place it at the top; anything else is a roll of the dice.
Proposed Solutions
-------
1. Fixed via [ManagedEntities - Recreate deleted records at discretion of update policy](https://github.com/civicrm/civicrm-core/pull/27844).
2. Fixed via [dev/core#4364 Use writeRecord for Navigations so menu changes for managed entities don't reset](https://github.com/civicrm/civicrm-core/pull/27832).
3. Fixed via [ManagedEntity - Replicate multi-domain entities when multisite is enabled](https://github.com/civicrm/civicrm-core/pull/27876).
4. [Here is a PR](https://github.com/civicrm/civicrm-core/pull/27894) to add a `previous` and `next` join in APIv4 which would allow you to specify the name of the menu item you wish to insert next to. For example, to add a menu item just below the "Find Contacts" menu item, you'd say `['previous.name' => 'Find Contacts']` in your managed declaration (in lieu of `'weight' => 5').
5. To deprecate the Afform navigation handling, we can still support it in the Admin form, but instead of writing to the `.aff.json` file and that getting picked up by `afform_civicrm_managed()` the admin form could just save the navigation item directly. We can also teach the new [`civix export` command](https://github.com/totten/civix/pull/312) to generate a `.mgd.php` for every navigation menu item associated with an Afform.https://lab.civicrm.org/dev/core/-/issues/4702Cannot clear country and state/province in contact summary address2023-12-13T20:24:15ZlarsssandergreenCannot clear country and state/province in contact summary address1. Open an address on a contact summary for editing.
2. Remove the country, which clears state/province (or remove state/province and then country).
3. Attempt to save.
Result: ![image](/uploads/4d69fc6535ffa916febbca831c393998/image.pn...1. Open an address on a contact summary for editing.
2. Remove the country, which clears state/province (or remove state/province and then country).
3. Attempt to save.
Result: ![image](/uploads/4d69fc6535ffa916febbca831c393998/image.png)
I think this a problem of the chain select not working correctly to deselect the option value, as it doesn't show a value, but the element still has a value when retrieved [here](https://github.com/civicrm/civicrm-core/blob/c911736f714c1bde28f6cdcc3b1bd0e1afbb894e/CRM/Core/Form.php#L2871). Maybe something between chain select and Select2?
If you save again, it does work.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?https://lab.civicrm.org/dev/core/-/issues/4636Deleting group invalidates ACL2023-10-05T11:56:00Zaydunsaidan.saunders@squiffle.ukDeleting group invalidates ACLOverview
----------------------------------------
Groups used in ACL's can be deleted without warning resulting in invalid ACL's.
Setup
----------------------------------------
1. Create a group: TestGroup
1. Create an ACL: Role: Every...Overview
----------------------------------------
Groups used in ACL's can be deleted without warning resulting in invalid ACL's.
Setup
----------------------------------------
1. Create a group: TestGroup
1. Create an ACL: Role: Everyone, Operation: View, Type: Group, Group: TestGroup (just created)
1. Note that the ACL display will shows `Type` as 'Group' and shows the group name
1. In SQL, look at the `civicrm_acl` table and note the `object_table` is 'civicrm_group', and `object_id` is the new group id.
Now delete the TestGroup:
- There is no warning that this group is used in an ACL
- In the ACL display the group name is now blank - a situation which cannot be created through the Add or Edit ACL screens.
- In SQL, the `civicrm_acl` table still show the `object_id` as the now non-existent group id.
Prior to https://github.com/civicrm/civicrm-core/pull/27679 this causes DB Syntax Errors when calling `CRM_Contact_BAO_Contact_Permission::allow()`
Expected behaviour
----------------------------------------
Good question! Maybe a warning that the group is being used in an ACL, but what should then happen to the ACL? Disable it?
Environment information
----------------------------------------
* __CiviCRM:__ _Master but may be longstanding_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->https://lab.civicrm.org/dev/core/-/issues/4625Inconsistent search result when "Modified By" field and apply an action2023-09-26T12:28:52Zthomas_SYSTOPIAInconsistent search result when "Modified By" field and apply an action**Description:**
When apply an action (like "Tag - add to contacts") on a search result using "Change Log->Modified By" field the result scope is lost. Instead the action would be applied to all contacts.
**Steps to reproduce** (tested...**Description:**
When apply an action (like "Tag - add to contacts") on a search result using "Change Log->Modified By" field the result scope is lost. Instead the action would be applied to all contacts.
**Steps to reproduce** (tested on https://d9-master.demo.civicrm.org/):
1. Use the advanced search form with "Change Log->Modified By" = _admin_. The result includes exactly one contact.
2. Choose "Tag - add to contacts" from the action menu.
3. You'll see "Number of selected contacts: 204" (204 are the sum of all contacts.)