CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-06-11T14:50:44Zhttps://lab.civicrm.org/dev/core/-/issues/3550Email to activity processing: New feature to make the creation of new contact...2022-06-11T14:50:44ZJamie Novick - CompucoEmail to activity processing: New feature to make the creation of new contacts "optional"**User story:**
- As an administrator
- When filing inbound emails
- I would like to configure whether CiviCRM will create a new contact where a contact does not already exist within the system
- So that I can ensure that new contacts a...**User story:**
- As an administrator
- When filing inbound emails
- I would like to configure whether CiviCRM will create a new contact where a contact does not already exist within the system
- So that I can ensure that new contacts are not created in the system when filing an email.
- In the situation of a case email where the email has a valid Case ID or Case token in the subject line the email should still be filed to a case, even if no contacts are matched.
**How it works currently:**
Currently, when CiviCRM performs email to activity processing, Civi will search CiviCRM for a contact with the relevant email address in the From / To / CC fields and then assign the created activity accordingly.
When CiviCRM cannot find a contact with a relevant email address, it simply creates a new "stub" contact with the email address.
**The problem**
For multiple reasons this is might not be desirable behaviour:
This is a security risk, as in most cases CiviCRM email-activity processing works off a mailbox, that might need to be public. As such it is possible that an unscrupulous third party may chose to spam your mailbox and thus spam your CRM with unwanted emails and content. Whilst this can be mitigated by having your automated filing on a separate mailbox, it might be preferable to simply only file the emails for contacts who already exist in your system, and to selectively add the rest.
Also, from a GDPR perspective it may not be desirable to hold the details of the persons who sent an email, whilst the contents of the email might be important (i.e. the attachments) especially in a casework context.
**Proposed solution:**
Add an additional option to the email to activity processing configurations (civicrm/admin/mailSettings?action=add&reset=1)
- When "Used For?" = Email to activity processing
- Show an additional option:
- "Do not create new contacts when filing emails"
- Checkbox
- Default null
- Help:
- If this option is enabled, CiviCRM will not create new contacts when filing emails.
- The email should also always be filed as an activity.
If checked:
- When CiviCRM checks for a matching contact, if no matching contact is found it will not create one and the email is skipped
- unless the email has a valid Case ID or Case token in the subject line, in which it will still be filed against the case, but no contacts will be linked to the email.5.31.0https://lab.civicrm.org/dev/core/-/issues/3547[Regression] "Enable multiple bulk emails" is no longer respected2022-06-11T14:50:40ZJonGold[Regression] "Enable multiple bulk emails" is no longer respected**Steps to Replicate**
* Set **Enable multiple bulk emails** to `TRUE` at **Administer » CiviMail » CiviMail Component Settings**.
* Create a new mailing group.
* Create a new contact with two emails. Set both as bulk email addresses an...**Steps to Replicate**
* Set **Enable multiple bulk emails** to `TRUE` at **Administer » CiviMail » CiviMail Component Settings**.
* Create a new mailing group.
* Create a new contact with two emails. Set both as bulk email addresses and add them to the new group.
* Send a mailing to the group.
**Expected**
Both email addresses will receive the email.
**Actual**
Only the primary address receives the email.
This is a regression as of 5.19 caused by [PR 15404](https://github.com/civicrm/civicrm-core/pull/15404). The SQL is modified to ensure [only primary emails are returned](https://github.com/civicrm/civicrm-core/blob/6ffd7af2d8eae353dafe0b3c8d3d78822379d0d6/CRM/Mailing/BAO/Recipients.php#L67).
core#861 is intended to filter out emails during a mailing for a person who, e.g., was marked deceased after the mailing was scheduled. However, we shouldn't be filtering all non-primary emails.5.22.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3545Make it possible to make a copy of a draft mailing2022-06-11T14:50:35ZlarsssandergreenMake it possible to make a copy of a draft mailingIt would be quite useful to be able to make a copy of a draft mailing. As it stands currently, if you want to duplicate a draft email (for instance, if you want to send two slightly different mailings), you have to send it first and then...It would be quite useful to be able to make a copy of a draft mailing. As it stands currently, if you want to duplicate a draft email (for instance, if you want to send two slightly different mailings), you have to send it first and then reuse it.
I'm not sure if this would be complicated or simple to implement (essentially the same as re-using a mailing or something more complex). Does anyone have thoughts?5.38.0https://lab.civicrm.org/dev/core/-/issues/3544Bounce processing doesn't catch pattern "user doesn't exist"2022-06-11T14:50:31ZDetlev SieberBounce processing doesn't catch pattern "user doesn't exist"CiviCRM bounce processing analyzes the bounce text patterns, and decides what kind of bounce type it is. This is a fragile process, but there seems to be no better solution, since there is no general standardization of bounce patterns.
...CiviCRM bounce processing analyzes the bounce text patterns, and decides what kind of bounce type it is. This is a fragile process, but there seems to be no better solution, since there is no general standardization of bounce patterns.
Some email providers throw the bounce pattern "user doesn't exist", which is not found, and therefore results in bounce_type "syntax". However, this bounce pattern should result in immediately switching the email address to "inactive".
Solution is:
> insert into civicrm_mailing_bounce_pattern (bounce_type_id, pattern) values (6, 'user doesn\'t exist');
5.9Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3542Move the cache for `CRM_Extension_Browser` out of the filesystem and use a `S...2022-06-16T02:21:42ZtiotsopMove the cache for `CRM_Extension_Browser` out of the filesystem and use a `SqlGroup` insteadThe current code in `CRM_Extension_Browser` is coded specifically for an adhoc, file-based caching logic. The recommendation standard is basically to change the backing/storage from a JSON file to the civicrm_cachetable (at least, for th...The current code in `CRM_Extension_Browser` is coded specifically for an adhoc, file-based caching logic. The recommendation standard is basically to change the backing/storage from a JSON file to the civicrm_cachetable (at least, for the typical usage).
Ref [#2](https://lab.civicrm.org/dev/cloud-native/issues/2#note_4790)5.52.0tiotsoptiotsophttps://lab.civicrm.org/dev/core/-/issues/3523Don't cache the full path of extensions so they don't break with dynamic paths2022-06-11T14:41:17ZherbdoolDon't cache the full path of extensions so they don't break with dynamic pathsExtension paths are cached as full paths, which are incompatible with cloud services that might have dynamic filepaths (such as Pantheon). Instead the full path can be determined by other means.
This is an example of what gets cached in...Extension paths are cached as full paths, which are incompatible with cloud services that might have dynamic filepaths (such as Pantheon). Instead the full path can be determined by other means.
This is an example of what gets cached in CRM_Extension_Mapper::getActiveModuleFiles:
```
a:6:{i:0;a:2:{s:6:"prefix";s:4:"iats";s:8:"filePath";s:101:"/var/www/vhosts/httpdocs/sites/all/civicrm_custom/extensions/com.iatspayments.civicrm/iats.php";}i:1;a:2:{s:6:"prefix";s:14:"extendedreport";s:8:"filePath";s:114:"/var/www/vhosts/httpdocs/sites/all/civicrm_custom/extensions/nz.co.fuzion.extendedreport/extendedreport.php";}i:2;a:2:{s:6:"prefix";s:12:"cividiscount";s:8:"filePath";s:116:"/var/www/vhosts/httpdocs/sites/all/civicrm_custom/extensions/org.civicrm.module.cividiscount/cividiscount.php";}i:3;a:2:{s:6:"prefix";s:9:"sumfields";s:8:"filePath";s:108:"/var/www/vhosts/httpdocs/sites/all/civicrm_custom/extensions/net.ourpowerbase.sumfields/sumfields.php";}i:4;a:2:{s:6:"prefix";s:4:"gdpr";s:8:"filePath";s:102:"/var/www/vhosts/httpdocs/sites/all/civicrm_custom/extensions/uk.co.vedaconsulting.gdpr/gdpr.php";}i:5;a:2:{s:6:"prefix";s:10:"l10nupdate";s:8:"filePath";s:107:"/var/www/vhosts/httpdocs/sites/all/civicrm_custom/extensions/com.cividesk.l10n.update/l10nupdate.php";}}
```
Previous solution was to use the patch in this issue https://www.drupal.org/node/2347897 but it meant there was a performance hit by always skipping cache.5.24.0https://lab.civicrm.org/dev/core/-/issues/3522Soften messages for read-only extensionsDir2022-06-11T14:41:07ZtiotsopSoften messages for read-only extensionsDirImprove messaging when someone has a different policy for managing `extensionsDir`.This a continuation of this [PR](https://github.com/civicrm/civicrm-core/pull/11895). Most of the messaging update has already been done. There is only on...Improve messaging when someone has a different policy for managing `extensionsDir`.This a continuation of this [PR](https://github.com/civicrm/civicrm-core/pull/11895). Most of the messaging update has already been done. There is only one message ("Read-Only Extensions"). It still encourages web-writable policy, but it lowers the severity and presents it a choice ("if you want X, do Y").
Probably, changing the `warning` into a `notice` is the only thing to update:- a `warning` implies something is wrong, while a `notice` says it's merely out of the ordinary.5.9tiotsoptiotsophttps://lab.civicrm.org/dev/core/-/issues/3513After completing an activity import, it takes you to the contact import screen2022-06-18T23:13:12ZDaveDAfter completing an activity import, it takes you to the contact import screenIt's maybe more likely to come up during testing than during real life, but if you were importing a series of files it's a bit confusing.
I don't remember if it did this before. I don't think so, but I'm not sure where I'd rank this for...It's maybe more likely to come up during testing than during real life, but if you were importing a series of files it's a bit confusing.
I don't remember if it did this before. I don't think so, but I'm not sure where I'd rank this for priority. It's not high.5.51.0https://lab.civicrm.org/dev/core/-/issues/35125.51beta1: TypeError on CRM_Contact_Import_Parser_Contact::checkStatesForCoun...2022-06-11T20:27:42ZJonGold5.51beta1: TypeError on CRM_Contact_Import_Parser_Contact::checkStatesForCountry()Another TypeError, this time on `CRM_Contact_Import_Parser_Contact::checkStatesForCountry()`
Sidenote - I'm hoping standalone CiviCRM comes to fruition because it would greatly simplify the process of using static analysis (e.g. PhpStan...Another TypeError, this time on `CRM_Contact_Import_Parser_Contact::checkStatesForCountry()`
Sidenote - I'm hoping standalone CiviCRM comes to fruition because it would greatly simplify the process of using static analysis (e.g. PhpStan) on Civi, which would catch type errors.
```
811744 10/Jun 11:23 php Error TypeError: Argument 2 passed to CRM_Contact_Import_Parser_Contact::checkStatesForCountry() must be of the type array, null given, called in
/home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Contact/Import/Parser/Contact.php on line 1794 in CRM_Contact_Import_Parser_Contact->checkStatesForCountry() (line 1854 of
/home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Contact/Import/Parser/Contact.php) #0
/home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Contact/Import/Parser/Contact.php(1794): CRM_Contact_Import_Parser_Contact->checkStatesForCountry(1228, NULL)
#1 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Contact/Import/Parser/Contact.php(1828): CRM_Contact_Import_Parser_Contact->tryToResolveStateProvince('invalid_import_...', '')
#2 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Contact/Import/Parser/Contact.php(1449): CRM_Contact_Import_Parser_Contact->fillStateProvince(Array)
#3 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Import/Parser.php(1665): CRM_Contact_Import_Parser_Contact->getMappedRow(Array)
#4 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Import/Parser.php(1645): CRM_Import_Parser->validateValues(Array)
#5 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Contact/Import/Form/MapField.php(450): CRM_Import_Parser->validate()
#6 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Contact/Import/Form/MapField.php(372): CRM_Contact_Import_Form_MapField->submit(Array)
#7 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Core/Form.php(573): CRM_Contact_Import_Form_MapField->postProcess()
#8 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Core/StateMachine.php(144): CRM_Core_Form->mainProcess()
#9 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Next.php(43): CRM_Core_StateMachine->perform(Object(CRM_Contact_Import_Form_MapField), 'next', 'Next')
#10 /home/jon/local/mysite/web/vendor/civicrm/civicrm-packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Next->perform(Object(CRM_Contact_Import_Form_MapField), 'next')
#11 /home/jon/local/mysite/web/vendor/civicrm/civicrm-packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contact_Import_Form_MapField), 'next')
#12 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Core/Controller.php(355): HTML_QuickForm_Page->handle('next')
#13 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(319): CRM_Core_Controller->run(Array, NULL)
#14 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem(Array)
#15 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke(Array)
#16 /home/jon/local/mysite/web/modules/contrib/civicrm/src/Civicrm.php(88): CRM_Core_Invoke::invoke(Array)
#17 /home/jon/local/mysite/web/modules/contrib/civicrm/src/Controller/CivicrmController.php(80): Drupal\civicrm\Civicrm->invoke(Array)
#18 [internal function]: Drupal\civicrm\Controller\CivicrmController->main(Array, '')
#19 /home/jon/local/mysite/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#20 /home/jon/local/mysite/web/core/lib/Drupal/Core/Render/Renderer.php(564): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#21 /home/jon/local/mysite/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124):
Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#22 /home/jon/local/mysite/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97):
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#23 /home/jon/local/mysite/web/vendor/symfony/http-kernel/HttpKernel.php(158): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#24 /home/jon/local/mysite/web/vendor/symfony/http-kernel/HttpKernel.php(80): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#25 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1,
true)
#26 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1,
true)
#27 /home/jon/local/mysite/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106):
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /home/jon/local/mysite/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85):
Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48):
Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51):
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#31 /home/jon/local/mysite/web/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23):
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#32 /home/jon/local/mysite/web/core/lib/Drupal/Core/DrupalKernel.php(708): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#33 /home/jon/local/mysite/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#34 {main}.
```5.51.0https://lab.civicrm.org/dev/core/-/issues/35115.51beta1: TypeError on import with saved mapping2023-11-16T02:18:19ZJonGold5.51beta1: TypeError on import with saved mappingI wanted to test 5.51's import. I started an import, got to page 3 before I realized I was on a 5.49.5 branch - but after I'd saved my mapping.
I switched to 5.51, and on pressing **Next** on page 1 of the import, I got the following e...I wanted to test 5.51's import. I started an import, got to page 3 before I realized I was on a 5.49.5 branch - but after I'd saved my mapping.
I switched to 5.51, and on pressing **Next** on page 1 of the import, I got the following error, which seems to be related to having a `- do not import -` value in one of my mapping fields:
```
811742 10/Jun 11:18 php Error TypeError: Return value of CRM_Import_ImportProcessor::getFieldMetadata() must be of the type array, null returned in CRM_Import_ImportProcessor->getFieldMetadata() (line 460 of
/home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Import/ImportProcessor.php) #0 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Import/ImportProcessor.php(443):
CRM_Import_ImportProcessor->getFieldMetadata('- do not import...')
#1 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Import/ImportProcessor.php(235): CRM_Import_ImportProcessor->loadSavedMapping()
#2 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Import/ImportProcessor.php(271): CRM_Import_ImportProcessor->getMappingFields()
#3 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Import/ImportProcessor.php(283): CRM_Import_ImportProcessor->getFieldNames()
#4 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Contact/Import/Form/MapField.php(293): CRM_Import_ImportProcessor->getFieldName(0)
#5 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Core/Form.php(689): CRM_Contact_Import_Form_MapField->buildQuickForm()
#6 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Display.php(76): CRM_Core_Form->buildForm()
#7 /home/jon/local/mysite/web/vendor/civicrm/civicrm-packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Display->perform(Object(CRM_Contact_Import_Form_MapField),
'display')
#8 /home/jon/local/mysite/web/vendor/civicrm/civicrm-packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contact_Import_Form_MapField), 'display')
#9 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Core/Controller.php(355): HTML_QuickForm_Page->handle('display')
#10 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(319): CRM_Core_Controller->run(Array, NULL)
#11 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem(Array)
#12 /home/jon/local/mysite/web/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke(Array)
#13 /home/jon/local/mysite/web/modules/contrib/civicrm/src/Civicrm.php(88): CRM_Core_Invoke::invoke(Array)
#14 /home/jon/local/mysite/web/modules/contrib/civicrm/src/Controller/CivicrmController.php(80): Drupal\civicrm\Civicrm->invoke(Array)
#15 [internal function]: Drupal\civicrm\Controller\CivicrmController->main(Array, '')
#16 /home/jon/local/mysite/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#17 /home/jon/local/mysite/web/core/lib/Drupal/Core/Render/Renderer.php(564): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#18 /home/jon/local/mysite/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124):
Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#19 /home/jon/local/mysite/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97):
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#20 /home/jon/local/mysite/web/vendor/symfony/http-kernel/HttpKernel.php(158): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#21 /home/jon/local/mysite/web/vendor/symfony/http-kernel/HttpKernel.php(80): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#22 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1,
true)
#23 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1,
true)
#24 /home/jon/local/mysite/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106):
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /home/jon/local/mysite/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85):
Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48):
Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51):
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /home/jon/local/mysite/web/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23):
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /home/jon/local/mysite/web/core/lib/Drupal/Core/DrupalKernel.php(708): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /home/jon/local/mysite/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#31 {main}.
```5.51.0https://lab.civicrm.org/dev/core/-/issues/35075.51.beta1: upgrade through UI gives DB Error: no such field on civicrm_queue...2022-06-13T00:55:28Zdavej5.51.beta1: upgrade through UI gives DB Error: no such field on civicrm_queue statusIn the course of testing #2566, I started with a local dev instance on 5.47.4, then grabbed civicrm-5.51.beta1-drupal-202206100742.tar.gz and ran the upgrade through the UI. However I got a db error:
```
DB Error: no such field
UPDATE c...In the course of testing #2566, I started with a local dev instance on 5.47.4, then grabbed civicrm-5.51.beta1-drupal-202206100742.tar.gz and ran the upgrade through the UI. However I got a db error:
```
DB Error: no such field
UPDATE civicrm_queue SET status = NULL WHERE name = 'CRM_Upgrade' [nativecode=1054 ** Unknown column 'status' in 'field list']
```
Looks like this query was added recently to CRM_Queue_Runner::runAllViaWeb(), it's not in 5.49.4 for example. I re-tried a couple of times, making sure I had cleared caches / templates_c - same error. `civicrm_domain.version` remained at `5.47.4`.
I then tried `drush cvupdb` and that succeeded.5.51.0https://lab.civicrm.org/dev/core/-/issues/35065.50.1: Import CSV record fails for Country: 'Côte d'Ivoire'2022-06-11T04:49:21ZDmitry Smirnov5.50.1: Import CSV record fails for Country: 'Côte d'Ivoire'Whenever a contact in the imported CSV have a Country: `Côte d'Ivoire`, import fails with an error `Country input value not in country table: "The Country value appears to be invalid. It does not match any value in CiviCRM table of count...Whenever a contact in the imported CSV have a Country: `Côte d'Ivoire`, import fails with an error `Country input value not in country table: "The Country value appears to be invalid. It does not match any value in CiviCRM table of countries."`.
I've specifically checked that CSV have the country name _exactly_ as CiviCRM knows it. The CSV file is properly UTF-8 encoded and the value is quoted correctly.5.51.0https://lab.civicrm.org/dev/core/-/issues/35055.50.1: import CSV record fails due to unicode Website2022-08-04T15:56:33ZDmitry Smirnov5.50.1: import CSV record fails due to unicode WebsiteI'm importing contacts from CSV file and one particular record is not imported due to `Invalid value for field(s) : Website`.
The *Website* is **https://কানাডা.com** and it is valid, as can be seen from clicking on it.
It would be great...I'm importing contacts from CSV file and one particular record is not imported due to `Invalid value for field(s) : Website`.
The *Website* is **https://কানাডা.com** and it is valid, as can be seen from clicking on it.
It would be great to relax website checking to allow import of such URLs. Thanks.5.51.0https://lab.civicrm.org/dev/core/-/issues/3503Grant export Amount Granted or Amount Requested fields are blank2022-07-05T03:54:39ZStoobGrant export Amount Granted or Amount Requested fields are blankTo reproduce in version 5.50.1:
1. Find Grants
2. click Export
3. select primary fields
4. Error: Amount Granted field is missing. This is a primary grant field
5. Find Grants
6. click Export
7. select your own fields, including Amoun...To reproduce in version 5.50.1:
1. Find Grants
2. click Export
3. select primary fields
4. Error: Amount Granted field is missing. This is a primary grant field
5. Find Grants
6. click Export
7. select your own fields, including Amount Granted and Amount requested
8. Error: Amount Granted and Amount Requested are blank
See attached.
![export-grants](/uploads/a14926db363436c3d4b35be76d3c08ac/export-grants.png)
![csv-export](/uploads/42d0884e8732e61b7082dfa7315916fb/csv-export.png)5.51.0https://lab.civicrm.org/dev/core/-/issues/3502CiviCRM has not bootstrapped sufficiently to fire event "hook_civicrm_entity_...2022-06-15T00:32:44ZtottenCiviCRM has not bootstrapped sufficiently to fire event "hook_civicrm_entity_supported_info"Overview
----------------------------------------
The combination of CiviCRM v5.50 + `rules` + `entity` + `civicrm_entity` + `de.systopia.campaign` leads to a fatal exception:
> CiviCRM has not bootstrapped sufficiently to fire event "...Overview
----------------------------------------
The combination of CiviCRM v5.50 + `rules` + `entity` + `civicrm_entity` + `de.systopia.campaign` leads to a fatal exception:
> CiviCRM has not bootstrapped sufficiently to fire event "hook_civicrm_entity_supported_info"
Reported by @francescbassas on Mattermost https://chat.civicrm.org/civicrm/pl/1izo73dcpjfcbem97eek7s6d6w
Current behaviour
----------------------------------------
Full backtrace: https://gist.github.com/totten/a40ac137f52301b42706e4f7510bc7ad
There is a root exception, which works like so:
1. For whatever normal+circumstantial reason, Civi starts to boot (`civicrm_initialize()`). While booting, it loads extensions (like `de.systopia.campaign`).
2. `campaign.civix.php` has an old-template that raises a warning on php74. (`Array and string offset access syntax with curly braces is deprecated`)
3. Drupal captures the warning, which it sends to the logger.
4. The logger is integrated with `rules`, which is further integrated with `entity`. *Before you can log a warning, it wants to know the list of all entities.*
5. The list of entities includes CiviCRM's entities (core+contrib)... so `civicrm_entity` tries to start Civi again (`civicrm_initialize()`), which incorrectly reports that the system has booted (*it hasn't; we're still-midboot*). It proceeds to ask extensions for their entities (`hook_civicrm_entity_supported_info`).
6. `CiviEventDispatcher` complains (`throw new \RuntimeException`) that we are not ready to run `hook_civicrm_entity_supported_info`.
There is also a secondary exception:
1. The root exception is picked up by Drupal's exception-handler.
2. Drupal exception-handler tries to format a pretty page using the theme. A `theme` is a kind of `entity` (apparently).
3. This fires another request along similar path: `entity` => `civicrm_entity` => `CiviEventDispatcher` => `RuntimeException`
Short term mitigations
----------------------------------------
I suspect any one of the following would address the immediate symptom:
* Fix the syntax warning in `campaign.civix.php`
* Disable `de.systopia.campaign` OR `rules` OR `civicrm_entity`
* Use `php73`
Systemic resolutions
----------------------------------------
A few opinions:
* `rules` makes the logging system too heavy/too complex. One should be able to log a message without triggering a scan of all application-modules.
* When Civi boots and loads the ext mainfiles, it is evidently a mistake to trust the CMS with handling warnings. Something in Civi (eg `CRM_Core_Config::singleton()` or `commonBuildModuleList()`) could install a more conservative logger for the duration of bootstrap.
* `civicrm_initialize()` should probably report something clearer if you call it recursively (ie call it a second time, mid-boot) -- and then `civicrm_entity` can be more guarded (*if the system hasn't booted, then you cannot reliably send hooks to exts*)
* `CiviEventDispatcher`'s interpretation of `not-ready` could be more conservative; eg instead of throwing an exception, drop the hook and write to the PHP `error_log()`.
I do believe it is correct for the system to complain about this scenario. To see why, suppose we add another extension (`advanced_events`) which actually listens to `hook_civicrm_entity_supported_info`. It can nominally go through the motions of firing `hook_civicrm_entity_supported_info`, but we're mid-boot. We haven't loaded all of the files yet (files like `advanced_events.php`). We cannot call `advanced_events_civicrm_entity_supported_info()` yet. The hook does not truly run.
To make matters worse, hooks are often tied up with static-caches. Incomplete data will be cached by `rules`, `entity`, and `CRM_Utils_Hook`. Thus, even though the warning in `campaign.civix.php` seems recoverable, there would be spooky effects later on. Diagnosing that kind of spooky effect can be extremely difficult (given that each piece works independently; and given how the symptoms depend on the happenstance of local environment).5.50.2https://lab.civicrm.org/dev/core/-/issues/3499Membership Renewal Message textarea input is absent2022-06-10T14:31:34ZGMCVO DatabasesMembership Renewal Message textarea input is absentOverview
----------------------------------------
The ability to enter a message on membership renewal has been lost
Reproduction steps
----------------------------------------
Find memberships.
Click on the Renew link for a membership ...Overview
----------------------------------------
The ability to enter a message on membership renewal has been lost
Reproduction steps
----------------------------------------
Find memberships.
Click on the Renew link for a membership on the RHS (if present).
You get the Renew Membership popup.
Check the 'Send Confirmation and Receipt?' box.
Should get a textarea called Membership Renewal but you just get the associated help text:
"Enter a message you want included at the beginning of the emailed receipt. EXAMPLE: 'Thanks for supporting our organisation with your membership.'"
Current behaviour
----------------------------------------
Just get the text 'Enter a message you want included at the beginning of the emailed receipt. EXAMPLE: 'Thanks for supporting our organization with your membership.''
The textarea is missing from the html (not just invisible).
Expected behaviour
----------------------------------------
![image](/uploads/d91cb3c23f50862670a5b73ba832745a/image.png)
Environment information
----------------------------------------
Happens on https://dmaster.demo.civicrm.org/
Comments
----------------------------------------
It is working on an old site version CiviCRM 5.46.3 but don't know exactly when it stopped working.5.51.0https://lab.civicrm.org/dev/core/-/issues/3498Import Custom Data - Review of refactorings2022-06-09T21:26:24ZtottenImport Custom Data - Review of refactorings(Off-shoot from https://github.com/civicrm/civicrm-core/pull/23719)
I did some `r-run`, and (broadly) the "Import Custom Data" in `master` appears to work with this update. The examples I used were posted at https://github.com/eileenmcn...(Off-shoot from https://github.com/civicrm/civicrm-core/pull/23719)
I did some `r-run`, and (broadly) the "Import Custom Data" in `master` appears to work with this update. The examples I used were posted at https://github.com/eileenmcnaughton/testdata/pull/2
For a baseline, I compared against 5.49. There were a few quirks and changes.
* (Pre-existing/Unchanged Quirk) The "Start Year" field is defined as "YY" field, but you have to submit a full date. This was true in 5.49 as well.
* (Pre-existing/Unchanged Quirk) "Required" custom-fields are not really required. (That's fair for single-value data attached to another entity - but I'm unsure about multi-value data, where it feels like a separate entity.)
* (Improved) The "Level" field has a more clever/forgiving behavior -- in 5.49, it only matched the option-values numerically (`edu-longdate-full-num.csv`). With this update, matches by number as well as name (`edu-longdate-full-name.csv`). I don't know if that means that are misbehaved edge-cases, but it does generally feel more forgiving.
* (Changed) For invalid "Level" values like [this number](https://github.com/eileenmcnaughton/testdata/pull/2/files#diff-e4e7bafc6e1830e2d67181a2eb2b9e591d91e8ae0abc4dc94abf2804c68cd6d5R6) or [this name](https://github.com/eileenmcnaughton/testdata/pull/2/files#diff-2ede79a5313e574f650035f7ac23d94c7cc20b4847f7fa8ffa8354c4ba982b1bR6), the behavior changed. In 5.49, it completely rejected the record due to the bad value; in 23719, it accepted the record but skipped the value.
* (Regressed) In 5.49, the importer reported the bad "Level" value at the end. In 23719, it inaccurately indicates success.5.51.0eileeneileenhttps://lab.civicrm.org/dev/core/-/issues/3496CiviCRM has not bootstrapped sufficiently to fire event "hook_civicrm_entityT...2022-06-15T03:08:45ZjrobensCiviCRM has not bootstrapped sufficiently to fire event "hook_civicrm_entityTypes".Overview
----------------------------------------
Upgrade to 5.50.1 results in
`CiviCRM has not bootstrapped sufficiently to fire event "hook_civicrm_entityTypes".`
I am using civicrm_entity. Mosaico is the 'non-typical' CiviCRM exten...Overview
----------------------------------------
Upgrade to 5.50.1 results in
`CiviCRM has not bootstrapped sufficiently to fire event "hook_civicrm_entityTypes".`
I am using civicrm_entity. Mosaico is the 'non-typical' CiviCRM extension.
https://civicrm.stackexchange.com/questions/42039/installation-of-v5-50-gives-me-an-immediate-bootstrap-exception/42055#42055
Reproduction steps
----------------------------------------
1. Update CiviCRM
1. Attempt top load any page, run CV or drush
1. CiviCRM is not bootstrapped sufficiently!
Current behaviour
----------------------------------------
There is an initialize error. _civicrm_entity_ is in use. I was able to stop this creating an error by refactoring into using drupal events rather than hooks. This just pushed the problem further into civicrm. The drupal _civicrm_ module then caused an error at the initialize() function and after that block. There are reports in stack overflow of this same symptom occurring in Wordpress.
[initialize-error](/uploads/5b96cc9a779774d4fa6db72e453ea280/initialize-error.png)
Expected behaviour
----------------------------------------
Page should load or CV run.
Environment information
----------------------------------------
* __Browser:__ _Firefox Chrome 100+ /Safari
* __CiviCRM:__ From 5.49.3 to _Master/5.50.0 or 5.50.1 _ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ /7.4/__
* __CMS:__ _Drupal 9.3.15_
* __Database:__ _MariaDB 10.4_
* __Web Server:__ _Apache 2.4/..._
Comments
----------------------------------------
Commenting out _comonModuleBuildList_ in Container.php as added to git on 21/4/2022 enables the page to load.5.50.2https://lab.civicrm.org/dev/core/-/issues/3495Sorting/paging Advanced Search results corrupts search criteria2022-06-16T05:07:08ZBobSSorting/paging Advanced Search results corrupts search criteriaOverview
----------------------------------------
Certain search criteria fields in Advanced Search which have an implied LIKE operator are corrupted upon sorting by clicking on a column or by advancing to a different page in the results...Overview
----------------------------------------
Certain search criteria fields in Advanced Search which have an implied LIKE operator are corrupted upon sorting by clicking on a column or by advancing to a different page in the results.
Two such fields are:
Contribution Source
Case Subject
Others fields, such as Contact Name, do not exhibit this problem.
Reproduction steps
----------------------------------------
1. Login to https://dmaster.demo.civicrm.org
1. Search | Advanced Search
1. Display results as: Contributions
1. Contribution | Contribution Source = "p"
1. Click Search
1. Note 59 results, displayed search criteria includes "Contribution Source Like %p%"
1. Click the City column heading (or any other column heading), or display page 2 of the results.
Current behaviour
----------------------------------------
There are now 108 results, and the displayed search criteria includes "Contribution Source Like %%"
Expected behaviour
----------------------------------------
The search criteria should not be affected by sorting or paging the results.
Environment information
----------------------------------------
* __Browser:__ _Chrome/102.0.5005.63_
* __CiviCRM:__ _5.50.0_
* __PHP:__ _7.4.29_
* __CMS:__ _Drupal 7.88_
* __Database:__ _MariaDB 10.4.13_
* __Web Server:__ _Apache 2.4.43_
Comments
----------------------------------------
Problem traced to /CRM/Core/Form/Search.php:convertTextStringsToUseLikeOperator() calling trim() on $this->_formValues[$fieldName]. That variable, in the affected cases, is an array rather than a string, e.g. ['LIKE' => 'search_value'].5.52.0https://lab.civicrm.org/dev/core/-/issues/3492CiviGrant Date Fields no longer respect relative dates in Advanced Search2022-07-05T03:54:13ZelilisseckCiviGrant Date Fields no longer respect relative dates in Advanced SearchSteps to reproduce:
1) Install new buildkit site on master branch (I used wordpress demo)
2) Enabled the CiviGrant extension packed with Core
3) Navigate to Advanced Search and expand the "Grants" tab
4) Pick a date field such as "Grant...Steps to reproduce:
1) Install new buildkit site on master branch (I used wordpress demo)
2) Enabled the CiviGrant extension packed with Core
3) Navigate to Advanced Search and expand the "Grants" tab
4) Pick a date field such as "Grant Money transfer date" and choose a relative date such as "This Calendar Year"
5) Click "Search" and observe no "Where" clauses have been applied to the results
6) Choose a date range from "Jan 1" to *whatever today is* and observe the search works this way, but not with the relative date
Details:
I have a feeling this has something to do with the grant component being packing into an extension, but i'm not quite sure how yet. Any ideas quite welcome! I could put some dev time into fixing if nobody has an idea yet.
What I have observed is that the advanced search FORM itself is outputting the correct formValues array when compared to a contribution field with a relative date that DOES work, i.e.
`["grant_money_transfer_date_relative"]=> string(9) "this.year" ["grant_money_transfer_date_low"]=> string(0) "" ["grant_money_transfer_date_high"]=> string(0) ""`
vs
`["receive_date_relative"]=> string(9) "this.year" ["receive_date_low"]=> string(0) "" ["receive_date_high"]=> string(0) "" `
(a contribution receive date field with relative date)
The same array also reaches /ext/civigrant/CRM/Grant/BAO/Query.php and i'm not quite sure where it goes after that but something about that processing is not getting "grant_money_transfer_date_relative" translated into a "where" query in SQL.5.51.0