CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-11-10T01:45:09Zhttps://lab.civicrm.org/dev/core/-/issues/3325Using separate donation with free membership result into Pending (incomplete ...2023-11-10T01:45:09ZMonish DebUsing separate donation with free membership result into Pending (incomplete transaction) 0$ contributionSteps to replicate:
1. Create a 0$ fixed membership type
2. Configure a new/existing online contribution page, with separate donation and choose 0$ membership type under `Membership Fee`
3. Do a online contribution with $1 separate dona...Steps to replicate:
1. Create a 0$ fixed membership type
2. Configure a new/existing online contribution page, with separate donation and choose 0$ membership type under `Membership Fee`
3. Do a online contribution with $1 separate donation with 0$ membership
Bug:
Two donation are created, one with Completed 1$ contribution and other `Pending (Incomplete Transaction)` 0$ contribution linked with Pending free membership:
![Screenshot_2021-06-22_at_2.06.49_PM](/uploads/0cbd58fb74d7bc9467613571f70bb74a/Screenshot_2021-06-22_at_2.06.49_PM.png)
Expected result:
Complete 0$ membership's donation associated with `new` free membership
cc @eileen @JoeMurrayMonish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/4745Joomla: Fails to download extension feed2023-11-09T23:56:48ZtottenJoomla: Fails to download extension feedOverview
----------------------------------------
There appears to be a Guzzle conflict when fetching the extension feed on Joomla.
Reproduction steps
----------------------------------------
1. Install CiviCRM on Joomla
1. Navigate to...Overview
----------------------------------------
There appears to be a Guzzle conflict when fetching the extension feed on Joomla.
Reproduction steps
----------------------------------------
1. Install CiviCRM on Joomla
1. Navigate to dashboard
Current behaviour
----------------------------------------
The first pageload fails with:
![Screen_Shot_2023-11-01_at_4.20.15_PM](/uploads/bfab953fd770a8c09af0658b11529f04/Screen_Shot_2023-11-01_at_4.20.15_PM.png)
The NACK is cached for a while, so you won't immediately see the problem again. But we should expect it to recur.
Expected behaviour
----------------------------------------
No crash.
Environment information
----------------------------------------
The "hydra sites" (https://test.civicrm.org/view/Sites/job/hydra-sites/) are clean CMS installations. (They have the Civi source code preloaded -- but the installer hasn't run.) The error was observed on the hydra site for Joomla with CiviCRM `5.67.beta2` circa Nov 1, 2023.
* __Browser:__ Firefox
* __CiviCRM:__ 5.67.beta2
* __PHP:__ 7.4
* __CMS:__ Joomla
* __Database:__ 5.7
* __Web Server:__ Apachehttps://lab.civicrm.org/dev/core/-/issues/3584Denial of service - CiviCRM Mailing Job, if there are 5 errors sequentially w...2023-11-09T13:25:31Zjustinfreeman (Agileware)Denial of service - CiviCRM Mailing Job, if there are 5 errors sequentially which are caused by an invalid email domain. The Mailing Job will abort and mailing will not sendCiviCRM Mailing Job, if there are 5 errors sequentially which are caused by an invalid email domain. The Mailing Job will abort and the mailing will not send.
An invalid email domain returns an SMTP error 451: _SMTP error 451 Unable to ...CiviCRM Mailing Job, if there are 5 errors sequentially which are caused by an invalid email domain. The Mailing Job will abort and the mailing will not send.
An invalid email domain returns an SMTP error 451: _SMTP error 451 Unable to complete command, DNS not available or timed out 451 Domain of sender address does not resolve_
When the CiviCRM Mailing Job executes again, the process repeats, the same invalid email addresses are used, the same errors are returned and the mailing again will not send.
This process will repeat until someone intervenes, cancelling the mailing, locating and removing the contacts which have the invalid email addresses.
The CiviCRM Mailing Job does not currently check the actual SMTP error code and just treats all SMTP errors as "SMTP Connection Errors". Counting up to 5 and then aborting the job when the threshold is reached.
I think it's fair to call this a "denial of service" because a bad actor could sign up a bunch of fake Contacts to a CiviCRM mailing list with either invalid email domains or valid email domains which are then rendered invalid - and thus cause that mailing list to cease processing.
**Possible solutions**
Change the CiviCRM Mailing Job to check the return SMTP error code and only increment the count for valid "SMTP Connection Errors".
Change the CiviCRM Mailing Job to continue with the mailing, regardless of the 5 errors encountered, which will also skip sending the emails to those Contacts with an invalid email domain. As shown in the patch below.
```
Index: CRM/Mailing/BAO/MailingJob.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/CRM/Mailing/BAO/MailingJob.php b/CRM/Mailing/BAO/MailingJob.php
--- a/CRM/Mailing/BAO/MailingJob.php (revision 20a0376709a4616e32689a821a7e95ca255ed85f)
+++ b/CRM/Mailing/BAO/MailingJob.php (date 1620794367592)
@@ -672,20 +672,9 @@
if ($smtpConnectionErrors <= 5) {
$mailer->disconnect();
$retryGroup = TRUE;
+ CRM_Core_Error::debug_log_message("More than 5 consecutive SMTP Socket Errors. Re-starting mailer.");
continue;
}
-
- // seems like we have too many of them in a row, we should
- // write stuff to disk and abort the cron job
- $this->writeToDB(
- $deliveredParams,
- $targetParams,
- $mailing,
- $job_date
- );
-
- CRM_Core_Error::debug_log_message("Too many SMTP Socket Errors. Exiting");
- CRM_Utils_System::civiExit();
}
// Register the bounce event.
Index: ext/flexmailer/src/Listener/DefaultSender.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/ext/flexmailer/src/Listener/DefaultSender.php b/ext/flexmailer/src/Listener/DefaultSender.php
--- a/ext/flexmailer/src/Listener/DefaultSender.php (revision 20a0376709a4616e32689a821a7e95ca255ed85f)
+++ b/ext/flexmailer/src/Listener/DefaultSender.php (date 1620794390628)
@@ -76,15 +76,9 @@
if ($smtpConnectionErrors <= 5) {
$mailer->disconnect();
$retryBatch = TRUE;
+ \CRM_Core_Error::debug_log_message("More than 5 consecutive SMTP Socket Errors. Re-starting mailer.");
continue;
}
-
- // seems like we have too many of them in a row, we should
- // write stuff to disk and abort the cron job
- $job->writeToDB($deliveredParams, $targetParams, $mailing, $job_date);
-
- \CRM_Core_Error::debug_log_message("Too many SMTP Socket Errors. Exiting");
- \CRM_Utils_System::civiExit();
}
else {
$this->recordBounce($job, $task, $result->getMessage());
```
Agileware Ref: CIVICRM-1728https://lab.civicrm.org/dev/core/-/issues/4749PHP8 Fatal error when adding files on Case custom field2023-11-08T20:40:37ZPradeep Nayakpradpnayak@gmail.comPHP8 Fatal error when adding files on Case custom fieldReplicated on https://dmaster.demo.civicrm.org/civicrm/case/cd/edit?cgcount=1&action=update&reset=1&type=Case&entityID=1&groupID=4&cid=160&subType=1
Error:
TypeError: strtolower(): Argument #1 ($string) must be of type string, array giv...Replicated on https://dmaster.demo.civicrm.org/civicrm/case/cd/edit?cgcount=1&action=update&reset=1&type=Case&entityID=1&groupID=4&cid=160&subType=1
Error:
TypeError: strtolower(): Argument #1 ($string) must be of type string, array given in strtolower() (line 1423 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/DAO.php).
Steps to replicate:
1. Create custom sets for case, add file type custom field.
2. Create a case
3. On manage case screen, click on Edit button under custom group set, and try to upload a file
File is uploaded but system throws fatal error.
Backtrace:
````
#0 /var/sites//drupal10/vendor/civicrm/civicrm-core/CRM/Core/DAO.php(1418): CRM_Core_Error::backtrace()
#1 /var/sites//drupal10/vendor/civicrm/civicrm-core/CRM/Core/BAO/CustomField.php(1323): CRM_Core_DAO::getFieldValue("CRM_Core_DAO_File", (Array:2), "id", "uri")
#2 /var/sites//drupal10/vendor/civicrm/civicrm-core/CRM/Core/BAO/CustomField.php(1193): CRM_Core_BAO_CustomField::formatDisplayValue((Array:2), (Array:45), 100025185)
#3 /var/sites//drupal10/vendor/civicrm/civicrm-core/api/v3/CustomValue.php(425): CRM_Core_BAO_CustomField::displayValue((Array:2), Object(CRM_Core_BAO_CustomField), 100025185)
#4 /var/sites//drupal10/vendor/civicrm/civicrm-core/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_custom_value_getdisplayvalue((Array:4))
#5 /var/sites//drupal10/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(158): Civi\API\Provider\MagicFunctionProvider->invoke((Array:8))
#6 /var/sites//drupal10/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest((Array:8))
#7 /var/sites//drupal10/vendor/civicrm/civicrm-core/api/api.php(133): Civi\API\Kernel->runSafe("CustomValue", "getdisplayvalue", (Array:4))
#8 /var/sites//drupal10/vendor/civicrm/civicrm-core/CRM/Case/Form/CustomData.php(184): civicrm_api3("CustomValue", "getdisplayvalue", (Array:4))
#9 /var/sites//drupal10/vendor/civicrm/civicrm-core/CRM/Case/Form/CustomData.php(127): CRM_Case_Form_CustomData->formatCustomDataChangesForDetail((Array:20))
#10 /var/sites//drupal10/vendor/civicrm/civicrm-core/CRM/Core/Form.php(624): CRM_Case_Form_CustomData->postProcess()
#11 /var/sites//drupal10/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Upload.php(153): CRM_Core_Form->mainProcess()
#12 /var/sites//drupal10/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Upload.php(120): CRM_Core_QuickForm_Action_Upload->realPerform(Object(CRM_Case_Form_CustomData), "upload")
#13 /var/sites//drupal10/vendor/civicrm/civicrm-packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Upload->perform(Object(CRM_Case_Form_CustomData), "upload")
#14 /var/sites//drupal10/vendor/civicrm/civicrm-packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Case_Form_CustomData), "upload")
#15 /var/sites//drupal10/vendor/civicrm/civicrm-core/CRM/Core/Controller.php(355): HTML_QuickForm_Page->handle("upload")
#16 /var/sites//drupal10/vendor/civicrm/civicrm-core/CRM/Utils/Wrapper.php(98): CRM_Core_Controller->run()
#17 /var/sites//drupal10/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(292): CRM_Utils_Wrapper->run("CRM_Case_Form_CustomData", "Case Custom Set", (Array:0))
#18 /var/sites//drupal10/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem((Array:18))
#19 /var/sites//drupal10/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:4))
#20 /var/sites//drupal10/web/modules/contrib/civicrm/src/Civicrm.php(88): CRM_Core_Invoke::invoke((Array:4))
#21 /var/sites//drupal10/web/modules/contrib/civicrm/src/Controller/CivicrmController.php(83): Drupal\civicrm\Civicrm->invoke((Array:4))
#22 [internal function](): Drupal\civicrm\Controller\CivicrmController->main((Array:4), "")
#23 /var/sites//drupal10/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array((Array:2), (Array:2))
#24 /var/sites//drupal10/web/core/lib/Drupal/Core/Render/Renderer.php(592): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#25 /var/sites//drupal10/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#26 /var/sites//drupal10/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext((Array:2), (Array:2))
#27 /var/sites//drupal10/vendor/symfony/http-kernel/HttpKernel.php(182): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#28 /var/sites//drupal10/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#29 /var/sites//drupal10/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#30 /var/sites//drupal10/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#31 /var/sites//drupal10/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#32 /var/sites//drupal10/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#33 /var/sites//drupal10/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#34 /var/sites//drupal10/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#35 /var/sites//drupal10/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#36 /var/sites//drupal10/web/core/lib/Drupal/Core/DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#37 /var/sites//drupal10/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#38 {main
````
API params for getdisplayvalue
````
Array ( [custom_field_id] => 30 [entity_id] => 100025185 [custom_field_value] => Array ( [id] => 201 [data] => ) )
````https://lab.civicrm.org/dev/core/-/issues/4748PHP 8 - Fatal error in CRM_Contribution_Form_ContributionCharts, passes subst...2023-11-08T20:40:11ZFrancis (Agileware)PHP 8 - Fatal error in CRM_Contribution_Form_ContributionCharts, passes substring instead of int to mktime() in year fieldOverview
----------------------------------------
Contribution Dashboard crashes due to incorrectly passed arguments in the charts implementation
Reproduction steps
----------------------------------------
1. Use PHP version 8.1
2. Have...Overview
----------------------------------------
Contribution Dashboard crashes due to incorrectly passed arguments in the charts implementation
Reproduction steps
----------------------------------------
1. Use PHP version 8.1
2. Have a Contribution with a receive data before Year 1000 (Yes this will be bogus, but data is not always clean)
3. Go to Contributions / Dashboard
Current behaviour
----------------------------------------
CiviCRM site crashes with:
```
Uncaught TypeError: mktime(): Argument #6 ($year) must be of type ?int, string given in /path/to/civicrm/CRM/Contribute/Form/ContributionCharts.php:176
```
Expected behaviour
----------------------------------------
Contributions dashboard is loaded
Environment information
----------------------------------------
* __CiviCRM:__ Master, 5.66.2, 5.67
* __PHP:__ 8.1.25
* __CMS:__ WordPress 6.3.3
Comments
----------------------------------------
Was unable to reproduce this on dmaster, reason being that I don't know *how* the invalid date got in where I found the bug.https://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/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/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/4731SearchKit/Form Builder: re-positioning menu links column in table display bre...2023-11-02T17:26:41ZtomrosenbloomSearchKit/Form Builder: re-positioning menu links column in table display breaks csv downloadTo reproduce:
1. add a Menu column to a SK table display - it will appear in the last column by default
2. move menu links column to a different position
3. create afform from this display
4. use action menu to download results to csv
5...To reproduce:
1. add a Menu column to a SK table display - it will appear in the last column by default
2. move menu links column to a different position
3. create afform from this display
4. use action menu to download results to csv
5. now check the download - the column data immediately to the right of the menu column is missing and the data in subsequent columns is shifted to the left
I guess this could be due to something not being closed off properly and corrupting the table, and in that case it could be relevant that one of my menu links is `civicrm/case-detail#/?id=[id]`
EDIT: no, don't think it's that: I removed this link and the problem persists5.68.0https://lab.civicrm.org/dev/core/-/issues/4744Proposal - remove 'record contribution' from back office participant form whe...2023-11-02T15:27:49ZeileenProposal - remove 'record contribution' from back office participant form where pending contribution existsIf a participant record is updated where a pending record exists you need to update the status from pending to completed
![image](/uploads/1450500ef919017c7eee5c9ef326de6c/image.png)
![image](/uploads/87bc885b56fd756e897dc416a47eccd9/...If a participant record is updated where a pending record exists you need to update the status from pending to completed
![image](/uploads/1450500ef919017c7eee5c9ef326de6c/image.png)
![image](/uploads/87bc885b56fd756e897dc416a47eccd9/image.png)
However - this ONLY updates the contribution - without a separate action to update the participant status the participant status is unchanged
This is wildly confusing.
I propose we don't show 'record contribution' section when there is an existing payment & instead offer an 'add payment' button that pops up the Add payment form if clicked...https://lab.civicrm.org/dev/core/-/issues/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/4733Where art thou APIv4: MailingEventSubscribe Create? Missing parity with civic...2023-11-02T15:16:06Zjustinfreeman (Agileware)Where art thou APIv4: MailingEventSubscribe Create? Missing parity with civicrm_api3('MailingEventSubscribe', 'Create')Where art thou APIv4: MailingEventSubscribe Create? Missing parity with civicrm_api3('MailingEventSubscribe', 'Create')
Agileware Ref: CVAP-50Where art thou APIv4: MailingEventSubscribe Create? Missing parity with civicrm_api3('MailingEventSubscribe', 'Create')
Agileware Ref: CVAP-50https://lab.civicrm.org/dev/core/-/issues/2976Feature Request: Form Builder and Permissions - Provide ability to restrict a...2023-11-02T12:39:11Zjustinfreeman (Agileware)Feature Request: Form Builder and Permissions - Provide ability to restrict access to selected Roles rather than just specific Permission GrantsWould be great if the Form Builder, Permissions had the ability to restrict access to selected Roles rather than just specific Permission Grants.
Roles being far more flexible, can be automatically granted and removed for user accounts ...Would be great if the Form Builder, Permissions had the ability to restrict access to selected Roles rather than just specific Permission Grants.
Roles being far more flexible, can be automatically granted and removed for user accounts and this is a common pattern on Member websites. Whereas Permission Grants are not used in this way.
For example: When a user with the Member role views a Form Builder page, they are granted access to use the Form and view the Search Results because they have the Member role.
![Screenshot_20211202_130808](/uploads/25c2fbadece5eea59beb05d7b269e937/Screenshot_20211202_130808.png)
Agileware Ref: CIVICRM-1899https://lab.civicrm.org/dev/core/-/issues/4622Running queues following the docs' example might lead to infinite loops2023-10-27T08:36:37ZjensschuppeRunning queues following the docs' example might lead to infinite loopsFollowing the [_Queue Reference_ example](https://docs.civicrm.org/dev/en/latest/framework/queues/#3-run-the-queue) for running a queue in `CRM_Queue_Runner::ERROR_CONTINUE` mode with a `while` loop that only `break`s for `is_continue!=1...Following the [_Queue Reference_ example](https://docs.civicrm.org/dev/en/latest/framework/queues/#3-run-the-queue) for running a queue in `CRM_Queue_Runner::ERROR_CONTINUE` mode with a `while` loop that only `break`s for `is_continue!=1` will lead to infinite loops when a queue item has not been released yet (e.g. due to the script terminating without an exception being caught and the queue being re-run before release of the next item).
That's because `CRM_Queue_Queue_Sql::claimItem()` fetches the _first_ queue item and filters for `release_time` _afterwards_ - yielding no result, but reporting more items to be in the queue (`is_continue=1`). The only way to catch these cases with code calling the `CRM_Queue_Runner::runNext()` method is to check for `is_error=1` and the `exception` message being `Failed to claim next task`.
So, I've got some questions regarding Queues:
* Is there any best practice for handling errors during `claimItem()` any better?
* Would you agree there should be another indicator in the task result for those cases, or maybe that exception actually being thrown?
* Alternatively, should `is_continue` be `0` instead for those cases (i.e. its meaning would change from _queue finished_ to _queue processing can continue_)?
* Can the `$lease_time` parameter for SQL queues' `claimItem()` be exposed to all queues, so that the caller can modify it?
I see that the query was altered with https://github.com/civicrm/civicrm-core/pull/15421 by @artfulrobothttps://lab.civicrm.org/dev/core/-/issues/4728Form Builder Issue: Filter for "Contact (Near Side) / Contact (Far Side)" not...2023-10-26T11:44:33ZTobias Voigttobias.voigt@civiservice.deForm Builder Issue: Filter for "Contact (Near Side) / Contact (Far Side)" not workingI start with the "contacts" entity in Search Kit, then include "Contact Related Contacts" as an additonal entity and create a form in Form Builder for this composed search.
In Form Builder I then add a filter for both "Contact (Near Sid...I start with the "contacts" entity in Search Kit, then include "Contact Related Contacts" as an additonal entity and create a form in Form Builder for this composed search.
In Form Builder I then add a filter for both "Contact (Near Side)" and "Contact (Far Side)". When I then search for and choose a contact through one "Contact (Near Side)", the results table shows ALL possible results. When I search for and choose a contact through one "Contact (Far Side)", the results table is empty.
I was able to reproduce this behaviour in https://dmaster.demo.civicrm.org.
Side note: When I create a form directly for the composed search (rather than for a Search Kit table), I also get a warning: "Warning: Trying to access array offset on value of type null in Civi\Api4\Action\SearchDisplay\GetDefault->getColumnLabel() (line 418 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/Civi/Api4/Generic/Traits/SavedSearchInspectorTrait.php)."
Not sure if this is related to the issue or not.
If it would work, this filter would be extremely helpful and great to have.https://lab.civicrm.org/dev/core/-/issues/4721Get rid of `civicrm_option_value.domain_id`2023-10-26T11:41:06ZcolemanwGet rid of `civicrm_option_value.domain_id`Background/Motivation
------
Most tables with a `domain_id` column have that field *required* for every record.
`civicrm_option_value` is an outlier; most option groups don't care about domains. In fact there are only two that do:
```p...Background/Motivation
------
Most tables with a `domain_id` column have that field *required* for every record.
`civicrm_option_value` is an outlier; most option groups don't care about domains. In fact there are only two that do:
```php
/**
* $_domainIDGroups array maintains the list of option groups for whom
* domainID is to be considered.
*
* FIXME: Hardcoded list = bad. It would be better to make this a column in the civicrm_option_group table
* @var array
*/
public static $_domainIDGroups = [
'from_email_address',
'grant_type',
];
```
The `civicrm_option_value.domain_id` column and that lovely accompanying hardcoded list were added [in this commit](https://github.com/civicrm/civicrm-svn/commit/406091dc969907753a56fd7fae73320b1b012e67) as part of [this issue](https://issues.civicrm.org/jira/browse/CRM-5546). The assumption at the time seemed to be that the list might grow in the future, but that's proven to not be the case. Instead, we have this extra column making the already overloaded `civicrm_option_value` table even more complex to deal with. It would have been better at the time to move those two option groups into their own tables. It may not be too late to do so.
Proposal
-----------
1. Create a new table `civicrm_grant_type` - manage that table from the `civigrant` extension.
2. Create a new table `civicrm_from_email_address`.
3. Migrate all options into the new tables. Update pseudoconstant metadata in the schema.
4. Add some legacy handling at a few key points like `civicrm_api()` & `CRM_Core_OptionGroup::values()` to fetch options from the new table, for backward compatibility.
5. Deprecate the `civicrm_option_value.domain_id` column and eventually drop it.https://lab.civicrm.org/dev/core/-/issues/4712Move the PHP Storm extension out of core2023-10-26T11:37:31ZjaapjansmaMove the PHP Storm extension out of coreI have just installed a fresh Civi 5.66 site for production at a client and I see that core now ships a PHP storm extension.
I believe this extension is very useful for developers but probably not for production sites.
So can this exte...I have just installed a fresh Civi 5.66 site for production at a client and I see that core now ships a PHP storm extension.
I believe this extension is very useful for developers but probably not for production sites.
So can this extension moved out of core? That also gives other flexibility to install this extensions on older CiviCRM sites on which I am doing development on.https://lab.civicrm.org/dev/core/-/issues/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.