Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-11-08T00:54:22Zhttps://lab.civicrm.org/dev/core/-/issues/4755Activity type label has gone missing when editing case activity2023-11-08T00:54:22ZDaveDActivity type label has gone missing when editing case activityIt's blank and you get a warning about Undefined array key "label"
Probably https://github.com/civicrm/civicrm-core/pull/27498It's blank and you get a warning about Undefined array key "label"
Probably https://github.com/civicrm/civicrm-core/pull/274985.68.0https://lab.civicrm.org/dev/core/-/issues/4362civiimport failures with `cv`2023-11-08T00:50:25Zaydunsaidan.saunders@squiffle.ukciviimport failures with `cv`Overview
----------------------------------------
The `civiimport` extension causes log "API Request Authorization failed" messages when using `cv`
Reproduction steps
----------------------------------------
1. On a system where the `ci...Overview
----------------------------------------
The `civiimport` extension causes log "API Request Authorization failed" messages when using `cv`
Reproduction steps
----------------------------------------
1. On a system where the `civiimport` extension is not enabled: run `cv en civiimport`
Also, when installed run `cv flush`
Current behaviour
----------------------------------------
In the log file, note the backtrace:
```
Jun 15 11:26:51 [debug] $API Request Authorization failed = #0 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php(153): CRM_Core_Error::backtrace("API Request Authorization failed", TRUE)
#1 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/AbstractAction.php(250): Civi\API\Kernel->runRequest(Object(Civi\Api4\Generic\DAOGetAction))
#2 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/ext/civiimport/Civi/Api4/Event/Subscriber/ImportSubscriber.php(221): Civi\Api4\Generic\AbstractAction->execute()
#3 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/ext/civiimport/Civi/Api4/Event/Subscriber/ImportSubscriber.php(197): Civi\Api4\Event\Subscriber\ImportSubscriber::getImportForms()
#4 [internal function](): Civi\Api4\Event\Subscriber\ImportSubscriber::on_civi_afform_get(Object(Civi\Core\Event\GenericHookEvent), "civi.afform.get", Object(Civi\Core\UnoptimizedEventDispatcher))
#5 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Core/Event/ServiceListener.php(53): call_user_func_array((Array:2), (Array:3))
#6 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php(251): Civi\Core\Event\ServiceListener->__invoke(Object(Civi\Core\Event\GenericHookEvent), "civi.afform.get", Object(Civi\Core\UnoptimizedEventDispatcher))
#7 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php(73): Symfony\Component\EventDispatcher\EventDispatcher->callListeners((Array:2), "civi.afform.get", Object(Civi\Core\Event\GenericHookEvent))
#8 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Core/CiviEventDispatcher.php(260): Symfony\Component\EventDispatcher\EventDispatcher->dispatch(Object(Civi\Core\Event\GenericHookEvent), "civi.afform.get")
#9 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/ext/afform/core/Civi/Api4/Action/Afform/Get.php(40): Civi\Core\CiviEventDispatcher->dispatch("civi.afform.get", Object(Civi\Core\Event\GenericHookEvent))
#10 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/BasicGetAction.php(52): Civi\Api4\Action\Afform\Get->getRecords()
#11 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Api4/Provider/ActionObjectProvider.php(72): Civi\Api4\Generic\BasicGetAction->_run(Object(Civi\Api4\Generic\Result))
#12 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php(158): Civi\Api4\Provider\ActionObjectProvider->invoke(Object(Civi\Api4\Action\Afform\Get))
#13 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/AbstractAction.php(250): Civi\API\Kernel->runRequest(Object(Civi\Api4\Action\Afform\Get))
#14 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/ext/afform/core/afform.php(399): Civi\Api4\Generic\AbstractAction->execute()
#15 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Utils/Hook.php(272): afform_civicrm_alterMenu((Array:498))
#16 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Utils/Hook/WordPress.php(136): CRM_Utils_Hook->runHooks((Array:33), "civicrm_alterMenu", 1, (Array:498), NULL, NULL, NULL, NULL, NULL)
#17 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Core/CiviEventDispatcher.php(307): CRM_Utils_Hook_WordPress->invokeViaUF(1, (Array:498), NULL, NULL, NULL, NULL, NULL, "civicrm_alterMenu")
#18 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php(251): Civi\Core\CiviEventDispatcher::delegateToUF(Object(Civi\Core\Event\GenericHookEvent), "hook_civicrm_alterMenu", Object(Civi\Core\UnoptimizedEventDispatcher))
#19 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php(73): Symfony\Component\EventDispatcher\EventDispatcher->callListeners((Array:1), "hook_civicrm_alterMenu", Object(Civi\Core\Event\GenericHookEvent))
#20 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Core/CiviEventDispatcher.php(260): Symfony\Component\EventDispatcher\EventDispatcher->dispatch(Object(Civi\Core\Event\GenericHookEvent), "hook_civicrm_alterMenu")
#21 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Utils/Hook.php(168): Civi\Core\CiviEventDispatcher->dispatch("hook_civicrm_alterMenu", Object(Civi\Core\Event\GenericHookEvent))
#22 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Utils/Hook.php(661): CRM_Utils_Hook->invoke((Array:1), (Array:498), NULL, NULL, NULL, NULL, NULL, "civicrm_alterMenu")
#23 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Menu.php(78): CRM_Utils_Hook::alterMenu((Array:498))
#24 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Menu.php(180): CRM_Core_Menu::xmlItems(TRUE)
#25 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Menu.php(294): CRM_Core_Menu::items(TRUE)
#26 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(389): CRM_Core_Menu::store()
#27 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Extension/Manager.php(319): CRM_Core_Invoke::rebuildMenuAndCaches(TRUE)
#28 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/api/v3/Extension.php(42): CRM_Extension_Manager->install((Array:4))
#29 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_extension_install((Array:3))
#30 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php(158): Civi\API\Provider\MagicFunctionProvider->invoke((Array:8))
#31 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest((Array:8))
#32 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/api/api.php(22): Civi\API\Kernel->runSafe("Extension", "install", (Array:3))
#33 phar:///home/XXX/private/bin/cv/src/Command/BaseCommand.php(39): civicrm_api("Extension", "install", (Array:3))
#34 phar:///home/XXX/private/bin/cv/src/Command/ExtensionEnableCommand.php(68): Civi\Cv\Command\BaseCommand->callApiSuccess(Object(Cvphar\Symfony\Component\Console\Input\ArgvInput), Object(Cvphar\Symfony\Component\Console\Output\ConsoleOutput), "Extension", "install", (Array:3))
#35 phar:///home/XXX/private/bin/cv/vendor/symfony/console/Command/Command.php(127): Civi\Cv\Command\ExtensionEnableCommand->execute(Object(Cvphar\Symfony\Component\Console\Input\ArgvInput), Object(Cvphar\Symfony\Component\Console\Output\ConsoleOutput))
#36 phar:///home/XXX/private/bin/cv/vendor/symfony/console/Application.php(637): Cvphar\Symfony\Component\Console\Command\Command->run(Object(Cvphar\Symfony\Component\Console\Input\ArgvInput), Object(Cvphar\Symfony\Component\Console\Output\ConsoleOutput))
#37 phar:///home/XXX/private/bin/cv/vendor/symfony/console/Application.php(190): Cvphar\Symfony\Component\Console\Application->doRunCommand(Object(Civi\Cv\Command\ExtensionEnableCommand), Object(Cvphar\Symfony\Component\Console\Input\ArgvInput), Object(Cvphar\Symfony\Component\Console\Output\ConsoleOutput))
#38 phar:///home/XXX/private/bin/cv/src/Application.php(66): Cvphar\Symfony\Component\Console\Application->doRun(Object(Cvphar\Symfony\Component\Console\Input\ArgvInput), Object(Cvphar\Symfony\Component\Console\Output\ConsoleOutput))
#39 phar:///home/XXX/private/bin/cv/vendor/symfony/console/Application.php(101): Civi\Cv\Application->doRun(Object(Cvphar\Symfony\Component\Console\Input\ArgvInput), Object(Cvphar\Symfony\Component\Console\Output\ConsoleOutput))
#40 phar:///home/XXX/private/bin/cv/src/Application.php(32): Cvphar\Symfony\Component\Console\Application->run()
#41 phar:///home/XXX/private/bin/cv/bin/cv(28): Civi\Cv\Application::main("phar:///home/XXX/private/bin/cv/bin")
#42 /home/XXX/private/bin/cv(14): require("phar:///home/XXX/private/bin/cv/bin/cv")
#43 {main}
```
For `cv flush`:
```
Jun 15 11:35:11 [debug] $API Request Authorization failed = #0 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php(153): CRM_Core_Error::backtrace("API Request Authorization failed", TRUE)
#1 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/AbstractAction.php(250): Civi\API\Kernel->runRequest(Object(Civi\Api4\Generic\DAOGetAction))
#2 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/ext/civiimport/Civi/Api4/Event/Subscriber/ImportSubscriber.php(221): Civi\Api4\Generic\AbstractAction->execute()
#3 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/ext/civiimport/Civi/Api4/Event/Subscriber/ImportSubscriber.php(197): Civi\Api4\Event\Subscriber\ImportSubscriber::getImportForms()
#4 [internal function](): Civi\Api4\Event\Subscriber\ImportSubscriber::on_civi_afform_get(Object(Civi\Core\Event\GenericHookEvent), "civi.afform.get", Object(Civi\Core\UnoptimizedEventDispatcher))
#5 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Core/Event/ServiceListener.php(53): call_user_func_array((Array:2), (Array:3))
#6 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php(251): Civi\Core\Event\ServiceListener->__invoke(Object(Civi\Core\Event\GenericHookEvent), "civi.afform.get", Object(Civi\Core\UnoptimizedEventDispatcher))
#7 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php(73): Symfony\Component\EventDispatcher\EventDispatcher->callListeners((Array:2), "civi.afform.get", Object(Civi\Core\Event\GenericHookEvent))
#8 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Core/CiviEventDispatcher.php(260): Symfony\Component\EventDispatcher\EventDispatcher->dispatch(Object(Civi\Core\Event\GenericHookEvent), "civi.afform.get")
#9 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/ext/afform/core/Civi/Api4/Action/Afform/Get.php(40): Civi\Core\CiviEventDispatcher->dispatch("civi.afform.get", Object(Civi\Core\Event\GenericHookEvent))
#10 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/BasicGetAction.php(52): Civi\Api4\Action\Afform\Get->getRecords()
#11 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Api4/Provider/ActionObjectProvider.php(72): Civi\Api4\Generic\BasicGetAction->_run(Object(Civi\Api4\Generic\Result))
#12 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php(158): Civi\Api4\Provider\ActionObjectProvider->invoke(Object(Civi\Api4\Action\Afform\Get))
#13 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/AbstractAction.php(250): Civi\API\Kernel->runRequest(Object(Civi\Api4\Action\Afform\Get))
#14 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/ext/afform/core/afform.php(399): Civi\Api4\Generic\AbstractAction->execute()
#15 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Utils/Hook.php(272): afform_civicrm_alterMenu((Array:498))
#16 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Utils/Hook/WordPress.php(136): CRM_Utils_Hook->runHooks((Array:33), "civicrm_alterMenu", 1, (Array:498), NULL, NULL, NULL, NULL, NULL)
#17 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Core/CiviEventDispatcher.php(307): CRM_Utils_Hook_WordPress->invokeViaUF(1, (Array:498), NULL, NULL, NULL, NULL, NULL, "civicrm_alterMenu")
#18 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php(251): Civi\Core\CiviEventDispatcher::delegateToUF(Object(Civi\Core\Event\GenericHookEvent), "hook_civicrm_alterMenu", Object(Civi\Core\UnoptimizedEventDispatcher))
#19 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php(73): Symfony\Component\EventDispatcher\EventDispatcher->callListeners((Array:1), "hook_civicrm_alterMenu", Object(Civi\Core\Event\GenericHookEvent))
#20 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/Core/CiviEventDispatcher.php(260): Symfony\Component\EventDispatcher\EventDispatcher->dispatch(Object(Civi\Core\Event\GenericHookEvent), "hook_civicrm_alterMenu")
#21 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Utils/Hook.php(168): Civi\Core\CiviEventDispatcher->dispatch("hook_civicrm_alterMenu", Object(Civi\Core\Event\GenericHookEvent))
#22 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Utils/Hook.php(661): CRM_Utils_Hook->invoke((Array:1), (Array:498), NULL, NULL, NULL, NULL, NULL, "civicrm_alterMenu")
#23 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Menu.php(78): CRM_Utils_Hook::alterMenu((Array:498))
#24 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Menu.php(180): CRM_Core_Menu::xmlItems(TRUE)
#25 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Menu.php(294): CRM_Core_Menu::items(TRUE)
#26 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(389): CRM_Core_Menu::store()
#27 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/api/v3/System.php(33): CRM_Core_Invoke::rebuildMenuAndCaches(FALSE, FALSE)
#28 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_system_flush((Array:2))
#29 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php(158): Civi\API\Provider\MagicFunctionProvider->invoke((Array:8))
#30 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest((Array:8))
#31 /home/XXX/www/www/wp-content/plugins/civicrm/civicrm/api/api.php(22): Civi\API\Kernel->runSafe("System", "flush", (Array:2))
#32 phar:///home/XXX/private/bin/cv/src/Command/BaseCommand.php(39): civicrm_api("System", "flush", (Array:2))
#33 phar:///home/XXX/private/bin/cv/src/Command/FlushCommand.php(28): Civi\Cv\Command\BaseCommand->callApiSuccess(Object(Cvphar\Symfony\Component\Console\Input\ArgvInput), Object(Cvphar\Symfony\Component\Console\Output\ConsoleOutput), "System", "flush", (Array:2))
#34 phar:///home/XXX/private/bin/cv/vendor/symfony/console/Command/Command.php(127): Civi\Cv\Command\FlushCommand->execute(Object(Cvphar\Symfony\Component\Console\Input\ArgvInput), Object(Cvphar\Symfony\Component\Console\Output\ConsoleOutput))
#35 phar:///home/XXX/private/bin/cv/vendor/symfony/console/Application.php(637): Cvphar\Symfony\Component\Console\Command\Command->run(Object(Cvphar\Symfony\Component\Console\Input\ArgvInput), Object(Cvphar\Symfony\Component\Console\Output\ConsoleOutput))
#36 phar:///home/XXX/private/bin/cv/vendor/symfony/console/Application.php(190): Cvphar\Symfony\Component\Console\Application->doRunCommand(Object(Civi\Cv\Command\FlushCommand), Object(Cvphar\Symfony\Component\Console\Input\ArgvInput), Object(Cvphar\Symfony\Component\Console\Output\ConsoleOutput))
#37 phar:///home/XXX/private/bin/cv/src/Application.php(66): Cvphar\Symfony\Component\Console\Application->doRun(Object(Cvphar\Symfony\Component\Console\Input\ArgvInput), Object(Cvphar\Symfony\Component\Console\Output\ConsoleOutput))
#38 phar:///home/XXX/private/bin/cv/vendor/symfony/console/Application.php(101): Civi\Cv\Application->doRun(Object(Cvphar\Symfony\Component\Console\Input\ArgvInput), Object(Cvphar\Symfony\Component\Console\Output\ConsoleOutput))
#39 phar:///home/XXX/private/bin/cv/src/Application.php(32): Cvphar\Symfony\Component\Console\Application->run()
#40 phar:///home/XXX/private/bin/cv/bin/cv(28): Civi\Cv\Application::main("phar:///home/XXX/private/bin/cv/bin")
#41 /home/XXX/private/bin/cv(14): require("phar:///home/XXX/private/bin/cv/bin/cv")
#42 {main}
```
Both get to `/home/XXX/www/www/wp-content/plugins/civicrm/civicrm/ext/civiimport/Civi/Api4/Event/Subscriber/ImportSubscriber.php(197): Civi\Api4\Event\Subscriber\ImportSubscriber::getImportForms()`
Expected behaviour
----------------------------------------
No errors.
Note that if you run `cv ext import -U admin` or `cv flush -U admin`, these run without errors but are not the normal invocations. I'm not clear if this should be fixed in `cv` or `civiimport`.
`cv` mostly lets you do 'adminy things' without specifying a user. Some actions (like `cv scr`, `cv ev`) need a user but `cv flush` and `cv en`, `cv dis` have not needed this.
Environment information
----------------------------------------
* __CiviCRM:__ 5.62.0 <!-- Not new - issue exists earlier as well. -->
* __PHP:__ 7.4.32
* __cv:__ v0.3.42
Comments
----------------------------------------
ping @tottenhttps://lab.civicrm.org/dev/core/-/issues/4025Import Memberships: activity date set to date of import instead of Membership...2023-11-08T00:50:05ZcomposerjkImport Memberships: activity date set to date of import instead of Membership Start DateOverview
----------------------------------------
For _Memberships > Import Memberships_, I would expect that the _Activity Date_ for _Membership Signup_ would be the required _Membership Start Date_. Instead, when one views Activities,...Overview
----------------------------------------
For _Memberships > Import Memberships_, I would expect that the _Activity Date_ for _Membership Signup_ would be the required _Membership Start Date_. Instead, when one views Activities, the _Membership Signup_ activity date is the date/time of the import.
Query on chat.civicrm.org (no replies, yet): https://chat.civicrm.org/civicrm/pl/jgrmtpxr878w3fbtrm6iia4rsw
It looks like @petednz also mentioned this issue back in 2017: https://chat.civicrm.org/civicrm/pl/sbj5yeuccfr65yy9wwmam3mxte
Reproduction steps
----------------------------------------
1. _Memberships > Import Memberships_ for an existing contact with a Membership Start Date set to some date in the past.
1. View the Membership Signup activity, perhaps via _Search > Find Activities_.
Current behaviour
----------------------------------------
The listed Activity Date is the date of the import.
Expected behaviour
----------------------------------------
I would expect that the _Activity Date_ would be the _Membership Start Date_, similar to how the _Activity Date_ for a _Contribution_ is set to the _Payment Received Date_.
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. -->
- __CiviCRM:__ 5.56.0, 5.55.2, 5.55.0, 5.54.0
- __CMS:__ WordPress 6.1.1
- __PHP:__ 8.1.13 (fpm-fcgi)
- __Database:__ 10.3.31-MariaDB engine: InnoDB 10 row format: Dynamic
- __Webserver:__ nginx/1.20.2
- __OS:__ Linux
Comments
----------------------------------------
In my case, part of this is maintaining history. At some point, I hope to import data for membership archives going back 80 years. From @petednz's mention, it sounds like the _Membership Dashboard_ will also look wrong.https://lab.civicrm.org/dev/core/-/issues/4756CV crashes if LoginSecurity extension is enabled on Drupal8/9/102023-11-08T00:49:16ZufundoCV crashes if LoginSecurity extension is enabled on Drupal8/9/10Any cv call crashes if the [LoginSecurity](https://lab.civicrm.org/extensions/loginsecurity/-/issues) extension is enabled on D8+.
```
civicrm@c307847fd84a:/var/www/html$ cv -vvv vars:show
... [all looks good until] ...
[Bootstrap:no...Any cv call crashes if the [LoginSecurity](https://lab.civicrm.org/extensions/loginsecurity/-/issues) extension is enabled on D8+.
```
civicrm@c307847fd84a:/var/www/html$ cv -vvv vars:show
... [all looks good until] ...
[Bootstrap:notice] Call core bootstrap
In Drupal.php line 169:
[Drupal\Core\DependencyInjection\ContainerNotInitializedException]
\Drupal::$container is not initialized yet. \Drupal::setContainer() must be called with a real container.
Exception trace:
at /var/www/html/web/core/lib/Drupal.php:169
Drupal::getContainer() at /var/www/html/web/core/lib/Drupal.php:267
Drupal::request() at /var/www/html/vendor/civicrm/civicrm-core/CRM/Utils/System/Drupal8.php:945
CRM_Utils_System_Drupal8->ipAddress() at /var/www/html/vendor/civicrm/civicrm-core/CRM/Utils/System.php:1292
CRM_Utils_System::ipAddress() at /var/www/html/web/modules/civicrm/ext/loginsecurity/CRM/Loginsecurity/BAO/LoginSecurityDevice.php:37
CRM_Loginsecurity_BAO_LoginSecurityDevice::logCurrentSession() at /var/www/html/web/modules/civicrm/ext/loginsecurity/loginsecurity.php:16
loginsecurity_civicrm_config() at /var/www/html/vendor/civicrm/civicrm-core/CRM/Utils/Hook.php:272
CRM_Utils_Hook->runHooks() at /var/www/html/vendor/civicrm/civicrm-core/CRM/Utils/Hook/DrupalBase.php:73
CRM_Utils_Hook_DrupalBase->invokeViaUF() at /var/www/html/vendor/civicrm/civicrm-core/Civi/Core/CiviEventDispatcher.php:310
Civi\Core\CiviEventDispatcher::delegateToUF() at /var/www/html/vendor/symfony/event-dispatcher/EventDispatcher.php:220
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() at /var/www/html/vendor/symfony/event-dispatcher/EventDispatcher.php:56
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() at /var/www/html/vendor/civicrm/civicrm-core/Civi/Core/CiviEventDispatcher.php:263
Civi\Core\CiviEventDispatcher->dispatch() at /var/www/html/vendor/civicrm/civicrm-core/CRM/Utils/Hook.php:168
CRM_Utils_Hook->invoke() at /var/www/html/vendor/civicrm/civicrm-core/CRM/Utils/Hook.php:1440
CRM_Utils_Hook::config() at /var/www/html/vendor/civicrm/civicrm-core/CRM/Core/Config.php:94
CRM_Core_Config::singleton() at phar:///usr/local/bin/cv/lib/src/Bootstrap.php:97
Civi\Cv\Bootstrap->boot() at phar:///usr/local/bin/cv/lib/src/Util/BootTrait.php:73
Civi\Cv\Command\ShowCommand->_boot_full() at phar:///usr/local/bin/cv/lib/src/Util/BootTrait.php:47
Civi\Cv\Command\ShowCommand->boot() at phar:///usr/local/bin/cv/src/Command/ShowCommand.php:21
Civi\Cv\Command\ShowCommand->execute() at phar:///usr/local/bin/cv/vendor/symfony/console/Command/Command.php:127
Cvphar\Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/cv/vendor/symfony/console/Application.php:637
Cvphar\Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/cv/vendor/symfony/console/Application.php:190
Cvphar\Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/cv/src/Application.php:67
Civi\Cv\Application->doRun() at phar:///usr/local/bin/cv/vendor/symfony/console/Application.php:101
Cvphar\Symfony\Component\Console\Application->run() at phar:///usr/local/bin/cv/src/Application.php:33
Civi\Cv\Application::main() at phar:///usr/local/bin/cv/bin/cv:28
require() at /usr/local/bin/cv:14
```
It looks to me like the extension is trying to call the `CRM_Utils_System::ipAddress()` function before the Drupal container is ready.
And that something like https://lab.civicrm.org/dev/core/-/commit/5e383d9d992335f2f6e743c3e1f3d0ce1b175ab9 should fix it?5.69.0https://lab.civicrm.org/dev/core/-/issues/4739Fatal Error "invalid locale" with scheduled jobs and tax receipts (and others...2023-11-07T12:25:25ZkcristianoFatal Error "invalid locale" with scheduled jobs and tax receipts (and others) and php 8.1.25 & civicrm 5.66.xAfter updating to php 8.1.25
```
PHP 8.1.25 (cli) (built: Oct 27 2023 13:02:10) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.25, Copyright (c) Zend Technologies
with Zend OPcache v8.1.25, Copyright (c), by Zend Technologies
``...After updating to php 8.1.25
```
PHP 8.1.25 (cli) (built: Oct 27 2023 13:02:10) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.25, Copyright (c) Zend Technologies
with Zend OPcache v8.1.25, Copyright (c), by Zend Technologies
```
Any attempt to call cron (cli with cv, or in the UI) fails with the following erro:
```
[28-Oct-2023 10:50:42 America/New_York] PHP Fatal error: Uncaught IntlException: datefmt_create: invalid locale: U_ILLEGAL_ARGUMENT_ERROR in /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/vendor/pear/log/php-8.1-strftime.php:105
Stack trace:
#0 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/vendor/pear/log/php-8.1-strftime.php(105): IntlDateFormatter->__construct()
#1 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/vendor/pear/log/php-8.1-strftime.php(204): PHP81_BC\{closure}()
#2 [internal function]: PHP81_BC\{closure}()
#3 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/vendor/pear/log/php-8.1-strftime.php(185): preg_replace_callback()
#4 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/vendor/pear/log/Log.php(887): PHP81_BC\strftime()
#5 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/vendor/pear/log/Log/file.php(294): Log->formatTime()
#6 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(590): Log_file->log()
#7 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(562): CRM_Core_Error::debug_log_message()
#8 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(442): CRM_Core_Error::debug_var()
#9 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(39): CRM_Core_Error::handleUnhandledException()
#10 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm.php(1199): CRM_Core_Invoke::invoke()
#11 /home/cvdemo/public_html/wp-includes/class-wp-hook.php(310): CiviCRM_For_WordPress->invoke()
#12 /home/cvdemo/public_html/wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters()
#13 /home/cvdemo/public_html/wp-includes/plugin.php(517): WP_Hook->do_action()
#14 /home/cvdemo/public_html/wp-admin/admin.php(259): do_action()
#15 {main}
thrown in /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/vendor/pear/log/php-8.1-strftime.php on line 105
```
I am finding this on:
WP 6.3.2
CiviCRM 5.64.x and greater
The only workaround I could find was temporarily reverting to php 7.45.67.0https://lab.civicrm.org/dev/core/-/issues/3010authx: Users that are disabled/blocked in the cms can still log in, even if t...2023-11-07T10:19:00ZDaveDauthx: Users that are disabled/blocked in the cms can still log in, even if the `XXX_user` setting is set to "require"At https://docs.civicrm.org/dev/en/latest/framework/authx/#settings you have a choice for whether the cms user needs to exist in order to log in, but even if you set it to "require", it will let a disabled/blocked user log in. My expecta...At https://docs.civicrm.org/dev/en/latest/framework/authx/#settings you have a choice for whether the cms user needs to exist in order to log in, but even if you set it to "require", it will let a disabled/blocked user log in. My expectation is that it would work the same way as regular logins if I choose "require" as the policy.
Some cms's may also allow other ways to block users, such as throttling or temporary IP bans. I would argue it should respect those too - i.e. if the cms doesn't allow login then authx shouldn't (when using "require").https://lab.civicrm.org/dev/core/-/issues/483New Individual: Unfilled fields "Custom Email Greeting", "Custom Postal Greet...2023-11-07T05:03:22ZPradeep Nayakpradpnayak@gmail.comNew Individual: Unfilled fields "Custom Email Greeting", "Custom Postal Greeting", "Custom Addressee" are hiddenLog in to CRM
Select menu item "Contacts"
Click submenu item "New Individual"
Input the data to the fields "First Name" and "Last Name" : [Test @name__of__creator]
Open block "Communication Preferences"
Choose for fields "Email Greeting"...Log in to CRM
Select menu item "Contacts"
Click submenu item "New Individual"
Input the data to the fields "First Name" and "Last Name" : [Test @name__of__creator]
Open block "Communication Preferences"
Choose for fields "Email Greeting", "Postal Greeting" and "Addressee": Customized
Click the button "Save"
Result: The fields "Custom Email Greeting", "Custom Postal Greeting", "Custom Addressee" are hidden (see Custom.png). The fields are visible after choosing another data in the fields "Custom Email Greeting", "Custom Postal Greeting", "Custom Addressee" then choosing 'Customized'. (see custom1.png)
Note: The same for page "New Organization"
Expected result: This fields are required. The user should be warned that the fields are required.
![custom1](/uploads/8d7265787c9266bf152b82fb607fe1ee/custom1.png)
![Custom](/uploads/63f96c694e860d5bbe0188378112f973/Custom.png)https://lab.civicrm.org/dev/core/-/issues/1206False negative on installer screen for DOES THE SERVER EXIST when installing ...2023-11-07T05:03:22ZDaveDFalse negative on installer screen for DOES THE SERVER EXIST when installing on Azure MySQL(It's not a recent issue.)
Some details at [Stackexchange 1](https://civicrm.stackexchange.com/questions/31794/civicrm-on-azure-not-finding-the-server) and [Stackexchange 2](https://civicrm.stackexchange.com/questions/28884/your-databas...(It's not a recent issue.)
Some details at [Stackexchange 1](https://civicrm.stackexchange.com/questions/31794/civicrm-on-azure-not-finding-the-server) and [Stackexchange 2](https://civicrm.stackexchange.com/questions/28884/your-database-settings-dont-appear-to-be-correct-all-green-but-still-error) but the short version is the DOES THE SERVER EXIST check in the installer is a bit odd - https://github.com/civicrm/civicrm-core/blob/5.16.2/install/index.php#L1038 - it doesn't use the username and password, and then as long as the error is less than code 2000 it says ok that's probably fine. On Azure though the error code is 9002 if you don't provide a properly formatted username and password.
So simple fix is to use the username/password. And it should also use the port for completeness but that's not the problem here.
For reference whether the username/pass is the right combo or not doesn't matter to Azure at this stage, as long as it's the right format it will return the same error code 1045 that the current code receives back from other systems when you pass nulls.
It's not clear if the check even needs to be there when there's similar checks right after - I guess to help narrow down whether the problem is the hostname or something else. But is that really needed.https://lab.civicrm.org/dev/core/-/issues/3007Use of translation functions in menu logic is... odd.2023-11-07T00:43:20ZBradley TaylorUse of translation functions in menu logic is... odd.See this screenshot of the CiviCRM nav menu with the site locale set to Spanish:
![Screenshot_2021-12-24_at_15.10.04](/uploads/869b3e37c228d258c61ee6fe40867771/Screenshot_2021-12-24_at_15.10.04.png)
The bulk of the labels are translate...See this screenshot of the CiviCRM nav menu with the site locale set to Spanish:
![Screenshot_2021-12-24_at_15.10.04](/uploads/869b3e37c228d258c61ee6fe40867771/Screenshot_2021-12-24_at_15.10.04.png)
The bulk of the labels are translated, except for the middle "Hide menu". My first thought was that this was just down to a lack of translation, but it turns out things are not that simple.
The home menu items themselves are defined as hardcoded strings in `app/public/wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/Navigation.php` (`CRM_Core_BAO_Navigation::buildHomeMenu`):
```
$item['child'] = [
[
'attributes' => [
'label' => 'CiviCRM Home',
'name' => 'CiviCRM Home',
'url' => 'civicrm/dashboard?reset=1',
'weight' => 1,
],
],
[
'attributes' => [
'label' => 'Hide Menu',
'name' => 'Hide Menu',
'url' => '#hidemenu',
'weight' => 2,
],
],
[
'attributes' => [
'label' => 'Log out',
'name' => 'Log out',
'url' => 'civicrm/logout?reset=1',
'weight' => 3,
],
],
];
```
Later in `CRM_Admin_Page_AJAX::formatMenuItems` the labels are passed through the `ts()` function:
```
if (!empty($props['label'])) {
$item['label'] = ts($props['label'], ['context' => 'menu']);
}
```
Some of the strings are used elsewhere (e.g. 'CiviCRM Home') and so are caught by the translation string extraction, and therefore get translated when passed into `ts()` as a variable `$props['label']`. This isn't the case for the string 'Hide Menu' however.
I suggest that `CRM_Core_BAO_Navigation::buildHomeMenu` is updated so that each label is passed through `ts()`. I'm not sure if this should include `['context' => 'menu']` to match `CRM_Admin_Page_AJAX::formatMenuItems`.
Best practice says that variables should not be passed as the first argument to `ts()`. However, `CRM_Admin_Page_AJAX::formatMenuItems` already works in this way, so it could be seen as a break to backwards compatiability to change this. If we don't change this, then there is the edge-case where a string would be double-translated, which could lead to unexpected results when combined with word replacement. So I'm not sure if this method should be updated or not.https://lab.civicrm.org/dev/core/-/issues/4694PHP 8.2 Deprecated ${} string interpolation drupal.module file2023-11-06T18:55:40ZAndrew WassonPHP 8.2 Deprecated ${} string interpolation drupal.module file## Overview
_CiviCRM can not be installed or updated on PHP 8.2.x because of a PHP 8.2 Deprecated ${} string interpolation issue with the file at line 1058 of /civicrm/drupal/civicrm.module._
_This issue is referenced at:_ https://lab....## Overview
_CiviCRM can not be installed or updated on PHP 8.2.x because of a PHP 8.2 Deprecated ${} string interpolation issue with the file at line 1058 of /civicrm/drupal/civicrm.module._
_This issue is referenced at:_ https://lab.civicrm.org/dev/core/-/issues/3958#note_152174
## Reproduction steps
1. Provision a Drupal website on PHP 8.2.x
2. Install of update CiviCRM.
3. Got an error "**Fatal error:** _Deprecated ${} string interpolation issue with the file at line 1058 of /civicrm/drupal/civicrm.module._".
## Environment information
* **CiviCRM:** version 5.66.0 (any version)
* **PHP:** _8.2.x_
* **CMS:** Drupal 7.98 (any Drupal 7 version)
* **Database:** _MySQL 5.7.7/MariaDB 10.4/..._
* **Web Server:** _Apache 2.4/Nginx 1.16/..._
## Comments
_Will supply PR shortly._
* How do I add Labels to relate this to PHP 8.2 and Drupal 7?5.68.0https://lab.civicrm.org/dev/core/-/issues/3020Environments as collections of settings2023-11-06T05:03:22ZtottenEnvironments as collections of settingsOverview
----------------------------------------
Revise the conception of "environment" so that it can more usefully model these distinctions:
* As a developer working on patches with abstract sample data, you want to toggle some sett...Overview
----------------------------------------
Revise the conception of "environment" so that it can more usefully model these distinctions:
* As a developer working on patches with abstract sample data, you want to toggle some settings/behaviors (eg `backtrace=1`).
* As a developer/trainer/etc working on with a local copy of real data, you want to toggle different settings/behaviors (eg restricting cron jobs that might communicate to real people).
This issue proposes that an `environment` is *merely and strictly* a collection of settings - changing the environment will change the active settings.
Off-shoot of discussion circa https://github.com/civicrm/civicrm-core/pull/22377#issuecomment-1006058134
Current behaviour
----------------------------------------
* Sysadmins can design bespoke meta-settings by editing `civicrm.settings.php`
* `civibuild` users can design bespoke meta-settings by placing files [`/etc/civicrm.settings.d/*.php`](https://docs.civicrm.org/dev/en/latest/tools/civibuild/#settings-civicrm)
* The setting `environment` has the primary effect of toggling some guards for `JobManager` / `mailing_backend` / `runInNonProductionEnvironment`.
Proposed behaviour
----------------------------------------
1. Use `environment` to load files which list standard/default values for various settings. eg
* `civicrm-core.git:env/Development.json` has a list of defaults to use in "Development" envs
* `/etc/civicrm.settings.d/env/Development.json` has a list of local overrides to use in "Development" envs
2. Make it easier to set `environment` on new builds, eg
* Add an install option (eg `cv core:install --env=Demo`)
* Add an env-var (eg `CIVICRM_ENVIRONMENT=Staging`) - respected by both installer+runtime
* Add a self-documenting subcommand to configure `civibuild`, eg
```bash
civibuild config --env=Development
```
3. Don't hard-code `environment` behaviors in PHP. Always use settings. eg
* For the JobManager/runInNonProductionEnvironment stuff, there should be a setting `restrictScheduledJobs`. For "Development" envs, the effective-default is `restrictScheduledJobs=true`.
For example, the standard definition of a "Development" environment might be:
```javascript
// FILE: civicrm-core.git:env/Development.json
{
"debug_enabled": true,
"backtrace": true,
"restrictScheduledJobs": true,
"assetCache": 0
}
```
But I could still tune it for my system:
```javascript
// FILE: /etc/civicrm.settings.d/env/Development.json
{
"restrictScheduledJobs": false,
"mailing_backend": {
"outBound_option" => 0,
"smtpServer": "localhost",
"smtpPort": 1025,
"smtpAuth": FALSE
}
}
```
In a similar vein, it may also help to allow `global $civicrm_setting` to target by environment:
```php
## Normal usage
$civicrm_setting['domain']['backtrace'] = 1;
## Target settings per environment.
$civicrm_setting['#Development']['backtrace'] = 1;
$civicrm_setting['#Production']['backtrace'] = 0;
```https://lab.civicrm.org/dev/core/-/issues/2855Preserve pristine ids' for further manipulation via hooks for reports2023-11-06T05:03:21ZyashodhaPreserve pristine ids' for further manipulation via hooks for reportsPreserve pristine ids' for further manipulation via hooks for reports. Ids like state_province_id, country_id, etc are all over-written by the respective look up.
There could be a use-case to display abbreviated forms for some of these ...Preserve pristine ids' for further manipulation via hooks for reports. Ids like state_province_id, country_id, etc are all over-written by the respective look up.
There could be a use-case to display abbreviated forms for some of these fields for which we need the id. I suggest that we push the pristine ids to the bunch (we already have link, hover, etc).yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4465Afform - Default value for boolean filters not displayed correctly in all fie...2023-11-06T00:00:55Zxavi-xalocAfform - Default value for boolean filters not displayed correctly in all field types## Overview
A PR (https://github.com/civicrm/civicrm-core/pull/25605) has been merged to solve issues ( https://lab.civicrm.org/dev/core/-/issues/4113, for instance) with default values for booleans filters in Search Kit. Although that ...## Overview
A PR (https://github.com/civicrm/civicrm-core/pull/25605) has been merged to solve issues ( https://lab.civicrm.org/dev/core/-/issues/4113, for instance) with default values for booleans filters in Search Kit. Although that PR solves many of the issues identified, some problems still remain.
## Current behaviour
Although filter works fine when the field is of type "radio button", that's not the case when the type is "select" or "checkboxes":
- Select: Works fine when "yes" is the default value, but doesn't show default value when it is set to "no"
- Checkboxes: Doesn't get checked when default value is set to "yes".
## Environment information
* **CiviCRM:** _5\.61.2_Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/2122Account for time zone on event registration pages2023-11-05T14:13:53ZwmortadaAccount for time zone on event registration pagesOverview
----------------------------------------
There doesn't appear to be a way to account for the time zone on an event registration page.
This is less of an issue for a local event, but is quite a problem for a global online event....Overview
----------------------------------------
There doesn't appear to be a way to account for the time zone on an event registration page.
This is less of an issue for a local event, but is quite a problem for a global online event.
At a minimum I would expect there to be an option to set the time zone for the event and for the time zone to display on the event registration page. (Ideally you'd want the page to show the time in the user's time zone.)
Current behaviour
----------------------------------------
There is no option to set the time zone for an event. (I presume that the system time zone is used but I'm not sure.)
![image](/uploads/6727ccb71e4b3129120a3275240c56cf/image.png)
The time zone isn't displayed on the event registration page.
![image](/uploads/a16d1c595ab9020e2d9e9c2d668e114c/image.png)
Proposed behaviour
----------------------------------------
There is an option to set the time zone when creating an event. This should default to the user's time zone.
The time zone is displayed on the event registration page.
Comments
----------------------------------------
I became aware of this when trying to register for this event: https://civicrm.org/civicrm/event/info?reset=1&id=1553
Probably relates to https://lab.civicrm.org/dev/core/-/issues/441
Agileware Ref: CIVICRM-404 (feature not found)https://lab.civicrm.org/dev/core/-/issues/4746Standalone - Syntax error2023-11-04T21:40:17ZtottenStandalone - Syntax errorThis appears to be a consistent test-regression circa 5.68.alpha:
* List: https://test.civicrm.org/job/CiviCRM-E2E-Matrix/BKPROF=min,BLDTYPE=standalone-clean,CIVIVER=master,label=bknix-tmp/
* Example: https://test.civicrm.org/job/CiviCR...This appears to be a consistent test-regression circa 5.68.alpha:
* List: https://test.civicrm.org/job/CiviCRM-E2E-Matrix/BKPROF=min,BLDTYPE=standalone-clean,CIVIVER=master,label=bknix-tmp/
* Example: https://test.civicrm.org/job/CiviCRM-E2E-Matrix/BKPROF=min,BLDTYPE=standalone-clean,CIVIVER=master,label=bknix-tmp/6857/console
The test-log shows a PHP fatal:
```
In PasswordReset.php line 23:
[ParseError]
syntax error, unexpected 'string' (T_STRING), expecting function (T_FUNCTIO
N) or const (T_CONST)
```RichRichhttps://lab.civicrm.org/dev/core/-/issues/4747testRegexpOperators fails on `max`2023-11-04T21:39:46ZtottentestRegexpOperators fails on `max`Starting in 5.68, the test `api\v4\Action\ContactGetTest::testRegexpOperators` appears to be failing consistently on `max` environment (php81 + mysql80).
* Example: https://test.civicrm.org/job/CiviCRM-Core-Matrix/BKPROF=max,CIVIVER=mas...Starting in 5.68, the test `api\v4\Action\ContactGetTest::testRegexpOperators` appears to be failing consistently on `max` environment (php81 + mysql80).
* Example: https://test.civicrm.org/job/CiviCRM-Core-Matrix/BKPROF=max,CIVIVER=master,SUITES=phpunit-api4,label=bknix-tmp/13173/testReport/(root)/api_v4_Action_ContactGetTest/testRegexpOperators/
* List: https://test.civicrm.org/job/CiviCRM-Core-Matrix/BKPROF=max,CIVIVER=master,SUITES=phpunit-api4,label=bknix-tmp/
(*Since this would've gotten through PR review, it probably works on `php81`+`mysql57`. This smells like a mysqld compatibility issue.*)
cc @colemanwhttps://lab.civicrm.org/dev/core/-/issues/4750clear cache does not reliably remove durable temp tables2023-11-04T16:45:03Zlcdwebclear cache does not reliably remove durable temp tablesDurable (civicrm_tmp_d%) temp tables are intended for use when the table must be used in multiple transactions and therefore cannot be a true MySQL temp table. These should be cleared out when the clean cache function is triggered from t...Durable (civicrm_tmp_d%) temp tables are intended for use when the table must be used in multiple transactions and therefore cannot be a true MySQL temp table. These should be cleared out when the clean cache function is triggered from the UI, scheduled jobs, or CLI -- with a few exceptions for those created within the last two days or that are tied to the civicrm_user_job table. Currently there is faulty logic that causes them to persist much longer than necessary, thus cluttering the DB.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/3005DB Error on smart group with form values stored as html entities2023-11-04T05:03:20ZjitendraDB Error on smart group with form values stored as html entitiesWe're encountering DB errors on some sites for those who have smart group form values stored as `&lt;` or `&gt;`.
It seems these smart groups were created using search builder with >, < as the operator. Eg payment with amount < 30, etc....We're encountering DB errors on some sites for those who have smart group form values stored as `<` or `>`.
It seems these smart groups were created using search builder with >, < as the operator. Eg payment with amount < 30, etc.
To replicate, probably just try hitting `Update Smart Group Counts` button on Manage group page. It errors if form_values has any saved_search entry with `<` or `>` in it.
````
SELECT * FROM `civicrm_saved_search` WHERE `form_values` LIKE '%<%' OR `form_values` LIKE '%>%';
````
If i try creating a new smart group using the operator, it correctly decodes the value before storing it in the database, so probably it just affects the existing groups.
Approach to fix:
- Replace these characters while retrieving the SQL for group contact cache - https://github.com/civicrm/civicrm-core/blob/master/CRM/Contact/BAO/GroupContactCache.php#L633 -
return str_replace(['<', '>'], ['<', '>'], "$select {$sqlParts['from']} {$sqlParts['where']} {$sqlParts['group_by']} {$sqlParts['having']}");
Might be Related - https://lab.civicrm.org/dev/core/-/issues/1328 & https://github.com/civicrm/civicrm-core/pull/21556https://lab.civicrm.org/dev/core/-/issues/3009authx: Proposal: Make "require" the default user policy instead of "optional"2023-11-04T05:03:19ZDaveDauthx: Proposal: Make "require" the default user policy instead of "optional"If you look at https://docs.civicrm.org/dev/en/latest/framework/authx/#settings the default setting for the `XXX_user` settings is "optional" which means a corresponding cms user doesn't need to exist in order to log in. This seems unint...If you look at https://docs.civicrm.org/dev/en/latest/framework/authx/#settings the default setting for the `XXX_user` settings is "optional" which means a corresponding cms user doesn't need to exist in order to log in. This seems unintuitive as a default. My expectation is that it would work the same way as regular logins by default, so should default to "require".https://lab.civicrm.org/dev/core/-/issues/4734ADMIN_UI: default checkbox2023-11-03T15:31:20ZGuillaumeSorelADMIN_UI: default checkboxCould it be possible to have checkboxes per default for each new admin screen using SK, so it becomes possible to select multiple lines (for mailings, messages templates, custom fields...) and proceed bulk actions on them, especially del...Could it be possible to have checkboxes per default for each new admin screen using SK, so it becomes possible to select multiple lines (for mailings, messages templates, custom fields...) and proceed bulk actions on them, especially delete?
New SK screens are sweet but actions still need to be proceeded one-by-one.