Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-01-12T17:29:15Zhttps://lab.civicrm.org/dev/core/-/issues/4048Fatal error when changing membership type, on membership with 0 contributions2024-01-12T17:29:15ZBradley TaylorFatal error when changing membership type, on membership with 0 contributions## Steps to reproduce
1. Create a membership without a contribution.
2. Edit the membership you just created, change the membership type, and save (again without a contribution)
## Expected result
The membership should correctly save ...## Steps to reproduce
1. Create a membership without a contribution.
2. Edit the membership you just created, change the membership type, and save (again without a contribution)
## Expected result
The membership should correctly save both times.
## Expected result
The second save does not save correctly/ causes a 500 server error.
The error message is:
```
Fatal error: Uncaught Error: max(): Argument #1 ($value) must contain at least one element
in /app/web/app/plugins/civicrm/civicrm/CRM/Member/Form/Membership.php on line 1547
Call stack:
1. max()
app/plugins/civicrm/civicrm/CRM/Member/Form/Membership.php:1547
2. CRM_Member_Form_Membership::setStatusMessage()
app/plugins/civicrm/civicrm/CRM/Member/Form/Membership.php:1380
3. CRM_Member_Form_Membership::submit()
app/plugins/civicrm/civicrm/CRM/Member/Form/Membership.php:881
4. CRM_Member_Form_Membership::postProcess()
app/plugins/civicrm/civicrm/CRM/Core/Form.php:573
...
```
The membership does appear to actually be saved correctly upon refreshing the page.
## Environment information
PHP 8.1
I cannot reproduce this on dmaster. I think this is because calling `max(array_keys([]))` on PHP 7.4 merely causes a warning, whereas on PHP 8.x it causes an `Uncaught ValueError`.https://lab.civicrm.org/dev/core/-/issues/4047htmlspecialchars() issue on PHP8 and CiviReport2023-01-04T07:44:17ZJonGoldhtmlspecialchars() issue on PHP8 and CiviReport**Note** I've been seeing this `htmlspecialchars()` error on this line frequently on PHP 8. This is just the one instance I investigated thoroughly.
When attempting to use a particular CiviReport instance, we get a WSOD with this error...**Note** I've been seeing this `htmlspecialchars()` error on this line frequently on PHP 8. This is just the one instance I investigated thoroughly.
When attempting to use a particular CiviReport instance, we get a WSOD with this error in watchdog:
```
TypeError: htmlspecialchars(): Argument #1 ($string) must be of type string, array given in htmlspecialchars() (line 144 of /var/www/mysite/vendor/civicrm/civicrm-packages/HTML/Common.php)
#0 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/Common.php(144): htmlspecialchars()
#1 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/input.php(154): HTML_Common->_getAttrString()
#2 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/Renderer/Array.php(307): HTML_QuickForm_input->toHtml()
#3 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/Renderer/ArraySmarty.php(189): HTML_QuickForm_Renderer_Array->_elementToArray()
#4 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/Form/Renderer.php(87): HTML_QuickForm_Renderer_ArraySmarty->_elementToArray()
#5 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/Renderer/Array.php(221): CRM_Core_Form_Renderer->_elementToArray()
#6 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/element.php(415): HTML_QuickForm_Renderer_Array->renderElement()
#7 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm.php(1705): HTML_QuickForm_element->accept()
#8 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/Form.php(1136): HTML_QuickForm->accept()
#9 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Display.php(95): CRM_Core_Form->toSmarty()
#10 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Display.php(83): CRM_Core_QuickForm_Action_Display->renderForm()
#11 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Display->perform()
#12 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle()
#13 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/Controller.php(355): HTML_QuickForm_Page->handle()
#14 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Utils/Wrapper.php(98): CRM_Core_Controller->run()
#15 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Report/Page/Instance.php(74): CRM_Utils_Wrapper->run()
#16 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(319): CRM_Report_Page_Instance->run()
#17 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem()
#18 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke()
#19 /home/jon/local/mysite/web/modules/contrib/civicrm/src/Civicrm.php(88): CRM_Core_Invoke::invoke()
#20 /home/jon/local/mysite/web/modules/contrib/civicrm/src/Controller/CivicrmController.php(80): Drupal\civicrm\Civicrm->invoke()
#21 [internal function]: Drupal\civicrm\Controller\CivicrmController->main()
#22 /home/jon/local/mysite/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array()
#23 /home/jon/local/mysite/web/core/lib/Drupal/Core/Render/Renderer.php(580): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#24 /home/jon/local/mysite/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext()
#25 /home/jon/local/mysite/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
#26 /home/jon/local/mysite/vendor/symfony/http-kernel/HttpKernel.php(169): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#27 /home/jon/local/mysite/vendor/symfony/http-kernel/HttpKernel.php(81): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#28 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle()
#29 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#30 /home/jon/local/mysite/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#31 /home/jon/local/mysite/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass()
#32 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle()
#33 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#34 /home/jon/local/mysite/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#35 /home/jon/local/mysite/web/core/lib/Drupal/Core/DrupalKernel.php(707): Stack\StackedHttpKernel->handle()
#36 /home/jon/local/mysite/web/index.php(19): Drupal\Core\DrupalKernel->handle()
#37 {main}
```
I tracked it down to my `form_values` which is this:
```
a:27:{s:6:"fields";a:4:{s:9:"sort_name";s:1:"1";s:8:"event_id";s:1:"1";s:9:"status_id";s:1:"1";s:7:"role_id";s:1:"1";}s:12:"sort_name_op";s:3:"has";s:15:"sort_name_value";s:0:"";s:8:"email_op";s:3:"has";s:11:"email_value";s:0:"";s:11:"event_id_op";s:2:"in";s:14:"event_id_value";a:0:{}s:6:"sid_op";s:2:"in";s:9:"sid_value";a:0:{}s:6:"rid_op";s:2:"in";s:9:"rid_value";a:0:{}s:34:"participant_register_date_relative";s:1:"0";s:30:"participant_register_date_from";s:0:"";s:28:"participant_register_date_to";s:0:"";s:6:"eid_op";s:2:"in";s:9:"eid_value";a:0:{}s:11:"custom_4_op";s:2:"in";s:14:"custom_4_value";a:0:{}s:16:"blank_column_end";s:0:"";s:11:"description";s:44:"Provides lists of participants for an event.";s:13:"email_subject";s:0:"";s:8:"email_to";s:0:"";s:8:"email_cc";s:0:"";s:10:"permission";s:16:"access CiviEvent";s:6:"groups";s:0:"";s:7:"options";N;s:9:"domain_id";i:1;}
```
Unserialized:
```
array (
'fields' =>
array (
'sort_name' => '1',
'event_id' => '1',
'status_id' => '1',
'role_id' => '1',
),
'sort_name_op' => 'has',
'sort_name_value' => '',
'email_op' => 'has',
'email_value' => '',
'event_id_op' => 'in',
'event_id_value' => array (),
'sid_op' => 'in',
'sid_value' => array (),
'rid_op' => 'in',
'rid_value' => array (),
'participant_register_date_relative' => '0',
'participant_register_date_from' => '',
'participant_register_date_to' => '',
'eid_op' => 'in',
'eid_value' => array (),
'custom_4_op' => 'in',
'custom_4_value' => array (),
'blank_column_end' => '',
'description' => 'Provides lists of participants for an event.',
'email_subject' => '',
'email_to' => '',
'email_cc' => '',
'permission' => 'access CiviEvent',
'groups' => '',
'options' => NULL,
'domain_id' => 1,
)
```
The issue is `custom_4`, which is save as `in` `array()`. However, this is (and always has been) a free-entry text field, so "IN" should never have been an option. Pre-PHP8, this was ignored, now it's a fatal error.
I see @seamuslee made a [partial fix](https://github.com/civicrm/civicrm-packages/pull/346) but I'll submit a patch to handle the "empty array" case.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4046Civi incompatible with composer 2.5 (serialization of closure is not allowed)2022-12-23T16:28:53ZDaveDCivi incompatible with composer 2.5 (serialization of closure is not allowed)In https://github.com/composer/composer/commit/39de9899a70d8351db134027dc24ed35fc629346#diff-2f0f90552ea46ccb1d7d485298d70262be6825e776fa8e35de15f2f6c4e3efedR114 they added a closure to composer's classloader.
In civi, it creates a cach...In https://github.com/composer/composer/commit/39de9899a70d8351db134027dc24ed35fc629346#diff-2f0f90552ea46ccb1d7d485298d70262be6825e776fa8e35de15f2f6c4e3efedR114 they added a closure to composer's classloader.
In civi, it creates a cache of the extension classloader (which extends composer's) by serializing it: https://github.com/civicrm/civicrm-core/blob/04edd1c101b3d4982c727aae083f7f92c8440928/CRM/Extension/ClassLoader.php#L85
You can't serialize closures, so it gives an error.
Note to reproduce this when using `cv`, you'll need to build cv from source using composer 2.5, since when using cv it uses its own vendor's copy of the composer classloader, not the one in the civi install's vendor folder. So the one in cv might be an older one if using a phar, and then you won't see the error.https://lab.civicrm.org/dev/core/-/issues/4045Ideas for (funded) speed improvements in mailings2023-08-28T14:44:15ZAndrew WestIdeas for (funded) speed improvements in mailingsWe'd be interested in funding some speed improvements when building mailing recipients in CiviMail. They'd inherently feed through to Mosaico, I think.
We find the mailings screens pretty snappy apart from selecting recipients. There a...We'd be interested in funding some speed improvements when building mailing recipients in CiviMail. They'd inherently feed through to Mosaico, I think.
We find the mailings screens pretty snappy apart from selecting recipients. There are few bottlenecks that it'd be nice to get rid of:
**Improve the dropdown**
When you have lots of groups and mailings the dropdown doesn't work very well. It stalls, with multiple spinners appearing, or wipes out your text while typing, or says 'none found' for a bit before updating, or alternates between 'Searching' and 'Loading', and generally takes an achingly long time to find the groups in its own dropdown.
![image](/uploads/91dcd7a0a2c2e7d3230c4016d1d49db0/image.png)
Compare this to the smart group dropdown in Search Kit, which is blindingly fast.
Maybe this could be replaced with the new API4-based entityref? Possibly split into two (or even four?): Groups to include / Groups to Exclude / Mailings to include / Mailings to exclude?
**Improve generating the list of recipients**
A complicated selection of groups can easily take 30 seconds to update and save, for us. This is very frustrating when adding one smart group at a time in the dropdown. Possible fixes:
- Refactor CRM_Mailing_BAO_Mailing::getRecipients(). At the moment this function seems to create a lot of temp tables, and uses a bunch of heavy queries to compare them against each other. Again, Search Kit can do complicated includes/excludes way faster. So I figure this could be modernised.
- Possibly the slow part here is emptying/filling civicrm_mailing_recipients each time the criteria are changed. Maybe add a 'getRecipientCountPreview' function to get a count of recipients without actually populating the table? This would let people experiment in the mailing screen quickly. Then only generate the actual recipient list when the mailing is scheduled or saved as a draft?
Any other ideas? Or thoughts on whether the above makes sense?
We could fund maybe 15hrs on this atm. If anyone wants to join us that'd be great too :-)https://lab.civicrm.org/dev/core/-/issues/4044User authentication via authx is not working for non CMS users using formbuil...2022-12-22T08:14:28ZKurund JalmiUser authentication via authx is not working for non CMS users using formbuilder formsSteps to replicate:
- Create a form and enable tokens
- Send an email with form's complete url token to the non CMS user contact
- Open link in the email in the incognito window
- Form does not set defaults for the contact and saving the...Steps to replicate:
- Create a form and enable tokens
- Send an email with form's complete url token to the non CMS user contact
- Open link in the email in the incognito window
- Form does not set defaults for the contact and saving the form also fails.https://lab.civicrm.org/dev/core/-/issues/4043translation of extension strings fails after upgrade from 5.52.2 to 5.562023-02-08T15:12:50Zjamietranslation of extension strings fails after upgrade from 5.52.2 to 5.56Overview
----------------------------------------
After upgrading from 5.52.2 to 5.56.0, translations in a message template that is sent by email using a custom invocation of the token code fail to translate.
Other UI translations are p...Overview
----------------------------------------
After upgrading from 5.52.2 to 5.56.0, translations in a message template that is sent by email using a custom invocation of the token code fail to translate.
Other UI translations are properly displayed (e.g. in the angular app).
Example use-case
----------------------------------------
1. We have defined custom message templates in `templates/MessageTemplates/Folder/html.tpl` (see for example: https://code.mayfirst.org/mfmt/outreach/-/blob/master/web/sites/all/extensions/mayfirst/templates/MessageTemplate/MayfirstDuesReminderGrace/html.tpl).
2. We have defined that path in our `*.mgd.php` file (see https://code.mayfirst.org/mfmt/outreach/-/blob/master/web/sites/all/extensions/mayfirst/mayfirst.mgd.php).
3. We send the email via custom code. Here's a sample:
```
$p = new \Civi\Token\TokenProcessor(\Civi::dispatcher(), array(
'controller' => __CLASS__,
// We need smarty for translation.
'smarty' => TRUE,
'schema' => [ 'contactId', 'membershipId' ],
));
// Fill the processor with a batch of data.
$p->addMessage('body_html', $html, 'text/html');
$p->addMessage('subject', $subject, 'text/plain');
// Now we have to create content for each of the contactIds that we
// need to send to. Each message might be different (different first name
// and also it might be in english or spanish).
foreach($recipients as $recipientContactId => $recipient) {
$p->addRow()
->context('contactId', $recipientContactId)
->context('membershipId', $this->membershipId)
->context('contributionId', $this->contributionId)
->context('locale', $recipient['locale']);
}
$p->evaluate();
```
Full code available here: https://code.mayfirst.org/mfmt/outreach/-/blob/master/web/sites/all/extensions/mayfirst/Civi/Mayfirst/Email.php#L450
4. When we send to a contact with locale set to `es_MX` using the UI, it sends the english content.
5. Interestingly, in our unit test, it translates the strings present in CiviCRM core's translation file, but not the extension's translation file.
Current behaviour
----------------------------------------
The email is not properly translated.
Proposed behaviour
----------------------------------------
The email should be translated.
Comments
----------------------------------------
I traced the change to this [commit](https://github.com/civicrm/civicrm-core/commit/1190626dc6669a5a9242ab788a64d058e42dd9cb). Specifically, when I changed these lines, it started working in the UI (but not in the unit tests):
```
diff --git a/web/sites/all/modules/civicrm/CRM/Core/I18n.php b/web/sites/all/modules/civicrm/CRM/Core/I18n.php
index b1aa48974..4e690fc64 100644
--- a/web/sites/all/modules/civicrm/CRM/Core/I18n.php
+++ b/web/sites/all/modules/civicrm/CRM/Core/I18n.php
@@ -672,18 +672,18 @@ class CRM_Core_I18n {
}
// Change the language of the CMS as well, for URLs.
- CRM_Utils_System::setUFLocale($civicrmLocale->uf);
+ CRM_Utils_System::setUFLocale($locale);
// For sql queries, if running in DB multi-lingual mode.
global $dbLocale;
if ($dbLocale) {
- $dbLocale = '_' . $civicrmLocale->db;
+ $dbLocale = '_' . $locale;
}
// For self::getLocale()
global $tsLocale;
- $tsLocale = $civicrmLocale->ts;
+ $tsLocale = $locale;
CRM_Core_I18n::singleton()->reactivate();
}
```
The weird part is that `$locale` seems to be the same as `$civicrmLocale->ts`, `$civicrmLocale->db`, and `$civicrmLocale->uf`. It's merely accessing the {ts,db,uf} properties of `$civicrmLocale` that causes the problem. In other words, if I simply log `$civicrmLocale->ts` it fails to translate.
@totten - since the commit is yours I was hoping you might have some insight? I'm available to try things out if you have any suggestions.https://lab.civicrm.org/dev/core/-/issues/4042Link to import search display goes to front end form in wordpress2022-12-20T10:02:03ZeileenLink to import search display goes to front end form in wordpressAfter doing an import with Civi-Import enabled there is a link from the import summary screen to the error page (perhaps not if there are no errors?) - that links to the search kit display, filtered for errors - but on Wordpress I'm lan...After doing an import with Civi-Import enabled there is a link from the import summary screen to the error page (perhaps not if there are no errors?) - that links to the search kit display, filtered for errors - but on Wordpress I'm landing on a front end url.
E.g you can go back to the contact summary screen via Reports->My imports
![image](/uploads/f729ec641ae159fdbf18e922fc4f12b9/image.png)
And I'm looking at the link to view errors
![image](/uploads/05b060cfa95c0b5371a3e104235db5c0/image.png)
On drupal I correctly end up at https://dmaster.localhost:32353/civicrm/search#/display/Import_5/Import_5?_status=ERROR
Currently it is being assigned [here](https://github.com/civicrm/civicrm-core/blob/da9cd2454fbca7e38a78f7cb1539decaa5c2f4ff/ext/civiimport/civiimport.php#L278) in a non-WP-friendly way
```
if ($formName === 'CRM_Contact_Import_Form_Summary') {
$form->assign('downloadErrorRecordsUrl', '/civicrm/search#/display/Import_' . $form->getUserJobID() . '/Import_' . $form->getUserJobID() . '?_status=ERROR');
}
```
On my WP site the search display url is
The correct url is
https://bepartoftheart.co.nz/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fsearch#/display/Import_36/Import_36
- with the `_status=Error` added - which doesn't seem to work...
But the things I tried to generate the url didn't work...
```
if ($formName === 'CRM_Contact_Import_Form_Summary') {
$form->assign('downloadErrorRecordsUrl', CRM_Utils_System::url('civicrm/search', ['_status'=> 'ERROR'], FALSE, '/display/Import_' . $form->getUserJobID() . '/Import_' . $form->getUserJobID(), FALSE, TRUE));
}
```
But wind up at
https://bepartoftheart.co.nz/civicrm/search/?_status=ERROR#/display/Import_36/Import_36
Or
```
if ($formName === 'CRM_Contact_Import_Form_Summary') {
$form->assign('downloadErrorRecordsUrl', CRM_Utils_System::url('civicrm/search/display/Import_' . $form->getUserJobID() . '/Import_' . $form->getUserJobID(), ['_status'=> 'ERROR'], FALSE, NULL, FALSE, TRUE));
}
```
But wind up at
https://bepartoftheart.co.nz/civicrm/search/display/Import_36/Import_36/?_status=ERRORdhttps://lab.civicrm.org/dev/core/-/issues/4041Should we hard-code messages that event registration cancellations are not re...2022-12-20T10:01:32ZlarsssandergreenShould we hard-code messages that event registration cancellations are not refundable?Self-service cancellation of event registrations does not support refunds, so there are at least two places where the registrants are told that there are no refunds (in the registration confirmation email if self-service cancellation is ...Self-service cancellation of event registrations does not support refunds, so there are at least two places where the registrants are told that there are no refunds (in the registration confirmation email if self-service cancellation is enabled and when they actually try to cancel, though this has been broken since 5.43).
I wonder if it makes sense for CiviCRM to put this expectation that there are no refunds into code. Even though refunds are not supported via the self-service form, organizations may have policies that are different and may manually process refunds in some cases. I think it would make more sense to simply not say anything about refunds and allow organizations to define their own policies in the event registration.
So my proposal: Remove the warning about no refunds from self-service cancellation (which doesn't currently work anyways), remove the text about no refunds from event registration confirmation templates and remove the help text that mentions no refunds from the self-service cancellation option on the event registration set up.
It's far from ideal either way, but I think leaving it open is better than specifying a policy that may not work for all.https://lab.civicrm.org/dev/core/-/issues/4040FormBuilder - can no longer customise via GUI editor2022-12-20T10:00:19ZeileenFormBuilder - can no longer customise via GUI editorDeduper has long had an afform supplied by the extension. It pre-dates much recent work.
I seem to have lost the ability to edit these - even though the code editor is enabled
![image](/uploads/ddbaf635f2ee64fe325df5f3493638ae/image.pn...Deduper has long had an afform supplied by the extension. It pre-dates much recent work.
I seem to have lost the ability to edit these - even though the code editor is enabled
![image](/uploads/ddbaf635f2ee64fe325df5f3493638ae/image.png)
I understand the code editor is deprecated but I find myself a bit stuck
- Deduper ships with a form that displays basic contact info an uses the editable angular plugin to do a kind of editability I don't think I can do with a configured afform - ie
Both contact panes are instances of `basicContact.aff`
![image](/uploads/b2780a2cf589716008db7a1c383f6fa0/image.png)
However the editability is edit-in-place but Not edit field-by-field in place (& not all fields are permitted)
![image](/uploads/96f5aa35f12bfda5a91a5349593bbde9/image.png)
My expectation was that sites would use the Code Editor to add non-standard fields in (in our case 'Partner') - but I no longer seem to be able to (it's been a while since I last tried).
Ideally I would simplify / standardise the form using FormBuilder https://github.com/eileenmcnaughton/deduper/blob/master/ang/contactBasic.aff.html
- but I don't think it can provide all the features
Note - I don't quite know why the edit links are gone - perhaps that is resolvable? I did just check the extension is enabled & permissions are there - @colemanw do you know?https://lab.civicrm.org/dev/core/-/issues/4039Invoices have started miscalculating on save in version 5.56.0, rounding down...2022-12-23T16:33:29ZphilmckInvoices have started miscalculating on save in version 5.56.0, rounding down quantitiesOverview
----------------------------------------
_Please describe your problem or bug in detail._
Since version 5.56.0 (or possibly a slightly earlier version) my generated invoices have started to calculate incorrectly. The item quanti...Overview
----------------------------------------
_Please describe your problem or bug in detail._
Since version 5.56.0 (or possibly a slightly earlier version) my generated invoices have started to calculate incorrectly. The item quantities are rounded down to integers. Fractional quantities can still be entered and the Total Value looks correct until the Save button is pressed, at which point the total value of the invoice becomes incorrect (lower than expected). It appears that all item quantities are now being rounded down to integers.
_If you have already posted on https://civicrm.stackexchange.com or https://chat.civicrm.org, please include the link to that conversation._
Reproduction steps
----------------------------------------
1. In **CiviContribute Component Settings** check **Enable Tax and Invoicing**. Create a price set in **CiviContribute > Manage Price Sets** and add a price field of type **Text / Numeric Quantity**. Give it a value.
2. Go to the **Contributions** tab for any individual and click **Record Contribution**. Select the price set and field created in the previous step, and add a non-integer value (e.g. 1.5). Press TAB. Observe that the Total Amount is calculated correctly.
3. Click the **Save** button. Observe that the total amount is now incorrect. Click the **View** link and observe that the item quantity has been rounded down to an integer.
Current behaviour
----------------------------------------
_What happens currently. Please provide error messages, screenshots or gifs ([LICEcap](http://www.cockos.com/licecap/), [SilentCast](https://github.com/colinkeenan/silentcast)) where appropriate._
Item quantities in invoices are rounded down to integers when the "Save" button for a new contribution is pressed (but are allowed and calculated correctly up to that point).
```
TIP: The best way to convey an error message is to copy it in here and use
three backtick ` symbols. You may edit the message to remove private
information (like passwords). The backticks will help to preserve any
special characters or spaces.
```
Expected behaviour
----------------------------------------
_What should happen._
Fractional item quantities allowed, as they were in previous versions. If they have been deliberately removed (why?), the restriction should be flagged earlier, rather than quietly recalculating after the invoice disappears from the screen.
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. -->
* __Browser:__ _Chrome 108.0.5359.125_
* __CiviCRM:__ _5.56.0_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _8.0__
* __CMS:__ _WordPress 6.1.1_
* __Database:__ _MariaDB version 10.4.27_
* __Web Server:__ _Apache version 2.4.54_
Comments
----------------------------------------
_Anything else you would like the reviewer to note._5.57.0https://lab.civicrm.org/dev/core/-/issues/4038Import contribution fails in update mode even if contribution id is provided.2023-11-08T01:41:46ZKurund JalmiImport contribution fails in update mode even if contribution id is provided.Here is the error:
![Screenshot_from_2022-12-18_14-06-52](/uploads/f55f363f6c213e0280815a7d69321e44/Screenshot_from_2022-12-18_14-06-52.png)Here is the error:
![Screenshot_from_2022-12-18_14-06-52](/uploads/f55f363f6c213e0280815a7d69321e44/Screenshot_from_2022-12-18_14-06-52.png)Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/4037SearchKit: In place edit for gender incorrect field type2022-12-19T00:52:53ZlarsssandergreenSearchKit: In place edit for gender incorrect field typeThe in place edit field for gender shows as integer field type, instead of the expected select for gender options.
![image](/uploads/e513535286251c13ed021034e16b8d1a/image.png)The in place edit field for gender shows as integer field type, instead of the expected select for gender options.
![image](/uploads/e513535286251c13ed021034e16b8d1a/image.png)https://lab.civicrm.org/dev/core/-/issues/4036"New Batch" page no longer loads2022-12-17T19:15:25ZJonGold"New Batch" page no longer loadsOverview
----------------------------------------
"New Batch" no longer loads. When you try, you get an error.
Reproduction steps
----------------------------------------
1. Go to http://yoursite/civicrm/batch/add?reset=1&action=add
C...Overview
----------------------------------------
"New Batch" no longer loads. When you try, you get an error.
Reproduction steps
----------------------------------------
1. Go to http://yoursite/civicrm/batch/add?reset=1&action=add
Current behaviour
----------------------------------------
![image001](/uploads/2a7a6b049f0917e4c112cb72616659ba/image001.png)
Expected behaviour
----------------------------------------
No error.
Comments
----------------------------------------
This is a regression in https://github.com/civicrm/civicrm-core/pull/24770. I did some checking to see what other classes might be affected (using `ag -l 'extends CRM_Admin_Form' | xargs ag -L DefaultEntity` as a base) but couldn't find any others.5.56.1JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4035Cannot run scheduled jobs - cli.php errors out with uninformative "Error"2023-01-11T13:57:48Zthoni56Cannot run scheduled jobs - cli.php errors out with uninformative "Error"Overview
----------------------------------------
Our scheduled jobs stopped working, possibly after upgrading to 5.56. Investigating this further revealed that the crontab command failed.
Reproduction steps
----------------------------...Overview
----------------------------------------
Our scheduled jobs stopped working, possibly after upgrading to 5.56. Investigating this further revealed that the crontab command failed.
Reproduction steps
----------------------------------------
1. Execute `cd $CIVI_ROOT; $PHP bin/cli.php -j -s $CIVISITE -u $CIVIUSER -p $CIVIPASS -e Job -a execute`
Current behaviour
----------------------------------------
The command exits without triggering the scheduled jobs, displaying the text "Error".
Expected behaviour
----------------------------------------
That the scheduled CiviCRM jobs are triggered.
Environment information
----------------------------------------
* __CiviCRM:__ _5.56.0_
* __PHP:__ _7.4__
* __CMS:__ _Joomla 3.10.11_
* __Web Server:__ _Apache 2.4_
Comments
----------------------------------------
Is there a way to debug/trace the execution of the `bin/cli.php`?5.57.1https://lab.civicrm.org/dev/core/-/issues/4034CRM Builder - Profiles allow multiple Formatting Free HTML fields in forms2023-01-03T14:46:14ZJonny ToomeyCRM Builder - Profiles allow multiple Formatting Free HTML fields in formsOverview
----------------------------------------
When building a conribution form, or altering the profile for a form, the Javascript rightly detects duplciate fields and prevents saving. Would like to make an exception for Free HTML fi...Overview
----------------------------------------
When building a conribution form, or altering the profile for a form, the Javascript rightly detects duplciate fields and prevents saving. Would like to make an exception for Free HTML fields (could be expanded to anything from the Formatting section if that section should expand)
Current workaround
----------------------------------------
Saving after each change gets around this for now
Proposed behaviour
----------------------------------------
alter the markDuplicates() method so that is_duplicate class is only applied when the ufFieldModel does not have the label 'Free HTML'. This will allow multiple Free HTML fields for formatting forms
Proposed solution
----------------------------------------
civicrm/js/model/crm.uf.js
![markDuplicates](/uploads/fe6b7f9c7da464418d2bd6a27f75639a/markDuplicates.PNG)https://lab.civicrm.org/dev/core/-/issues/4033Proposal: Add optional separate mailing label format for organizations2023-01-11T23:31:32ZlarsssandergreenProposal: Add optional separate mailing label format for organizationsOften, I find myself editing the mailing label format when making mailing labels for organizations. In this case, we want Addressee and Name (the name of the person at the org plus the name of the org on the next line), while for individ...Often, I find myself editing the mailing label format when making mailing labels for organizations. In this case, we want Addressee and Name (the name of the person at the org plus the name of the org on the next line), while for individuals we just want the Addressee (otherwise, it would say their name twice). I imagine we aren't alone in this.
In order to avoid this hassle, it would make sense to have an option to add a second mailing label format for organizations. If there is a format specified in this field, it would be used for organizations. If this field is left blank, the default label format would be used for organizations. I think that would keep it simple and wouldn't change anything unless someone intentionally added an organizational label format. We could also add a format for households if desired - would that be valuable to anyone?https://lab.civicrm.org/dev/core/-/issues/4032civicrm_group_contact has a email_id field, but this does not appear to be used2022-12-20T10:04:29ZBradley Taylorcivicrm_group_contact has a email_id field, but this does not appear to be usedOverview
----------------------------------------
I'm currently working with an organisation who are moving to CiviCRM. They have contacts, who frequently have multiple employers, typically with a work email address for each employment. ...Overview
----------------------------------------
I'm currently working with an organisation who are moving to CiviCRM. They have contacts, who frequently have multiple employers, typically with a work email address for each employment. When signing up to email groups, it's often useful for these contacts to be able to control which group subscription goes to which email address.
For example:
We have a contact, Bob.
Bob is employed by CompanyA and CompanyB, and has the email addresses bob@company-a.com and bob@company-b.com. bob@company-a.com is the primary email address.
Bob signs up for two three mailing lists, but wants two to go to his primary email address and one to go to his secondary email address.
Current behaviour
----------------------------------------
This isn't something which is possible through the current CiviCRM UI, which is fine (I can't imagine this use-case is that common).
However, looking at the database table `civicrm_group_contact` it has a field `email_id`, with the comment `Optional email to associate with this membership`. This field is exposed in the CiviCRM API and SearchKit.
As far as I can tell, it appears that this `email_id` field is not actually used by any logic within CiviCRM core. It seems to be at least 10 years old (dating back to the pre-Git days), and so it's possible the `email_id` was introduced as part of a feature that was never finished.
Expected behaviour
----------------------------------------
I had assumed that when `email_id` was set, this email address would be used as the email address to actually be emailed, when sending a bulk mailing to a group via the CiviMail component. This unfortunately does not seem to be the case.
I think if the field exists, it should be used in this way. If not it should probably be deprecated and removed from core.
Currently it is possible to set the "Location Type" and "Selection Method" when selecting a group as part of the new mailing form. If a location type is set I would expect it to take precedence over the configured `email_id` (although this detail could be debated either way).
Whilst it might be nice if there was an associated UI to select the email address, I don't think any UI changes are required to make the `email_id` field useful - if CiviCRM simply uses the value (as set via plugin code or the API) that would be enough to enable the use case detailed above.
Comments
----------------------------------------
It's possible that I'm completely misunderstanding what the `email_id` field is for, and it is actually used - if so I'd love to know the details from someone closer to this area of the core code!https://lab.civicrm.org/dev/wordpress/-/issues/137" is not of type String" when activating, deactivating, installing or uninsta...2022-12-19T06:34:36Zcbpq" is not of type String" when activating, deactivating, installing or uninstalling a pluginI recently migrated a CiviCRM instance from Drupal to WordPress. CiviCRM is mostly functional, but I have multiple issues, namely with payment processors. The following error may be unrelated, but at this point I'm at a loss for what mig...I recently migrated a CiviCRM instance from Drupal to WordPress. CiviCRM is mostly functional, but I have multiple issues, namely with payment processors. The following error may be unrelated, but at this point I'm at a loss for what might be going wrong, so I thought I would bring it up.
- CiviCRM version 5.53
- WordPress version 6.1.1
Whenever I activate, deactivate, install or uninstall a plugin, the action is successful, but I get the following error:
```
Dec 12 17:09:41 [error]
$Fatal Error Details = array:3 [
"message" => " is not of type String"
"code" => null
"exception" => CRM_Core_Exception {#15941
-errorData: array:1 [
"error_code" => 0
]
#cause: null
-_trace: null
#message: " is not of type String"
#code: 0
#file: "/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php"
#line: 1769
trace: {
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php:1769 {
› elseif ($abort) {
› throw new CRM_Core_Exception("{$item[0]} is not of type {$item[1]}");
› }
}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php:1619 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/CustomOption.php:238 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/OptionValue.php:145 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/OptionValue.php:34 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/Traits/DAOActionTrait.php:170 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/Traits/DAOActionTrait.php:141 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/DAOUpdateAction.php:31 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/AbstractUpdateAction.php:93 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/Civi/Api4/Provider/ActionObjectProvider.php:69 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php:149 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/AbstractAction.php:234 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/api/api.php:85 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/ManagedEntities.php:257 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/ManagedEntities.php:144 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/ManagedEntities.php:112 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:417 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Extension/Manager.php:425 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Admin/Form/Extensions.php:197 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php:573 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/StateMachine.php:144 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Next.php:43 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php:203 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Page.php:103 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Controller.php:355 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Page/Basic.php:334 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Page/Basic.php:140 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Admin/Page/Extensions.php:105 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:319 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:69 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:36 { …}
/home/SITE/public_html/wp-content/plugins/civicrm/civicrm.php:1199 { …}
/home/SITE/public_html/wp-includes/class-wp-hook.php:308 { …}
/home/SITE/public_html/wp-includes/class-wp-hook.php:332 { …}
/home/SITE/public_html/wp-includes/plugin.php:517 { …}
/home/SITE/public_html/wp-admin/admin.php:259 { …}
}
}
]
Dec 12 17:09:41 [debug] $backTrace = #0 /home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(441): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /home/SITE/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(39): CRM_Core_Error::handleUnhandledException(Object(CRM_Core_Exception))
#2 /home/SITE/public_html/wp-content/plugins/civicrm/civicrm.php(1199): CRM_Core_Invoke::invoke((Array:3))
#3 /home/SITE/public_html/wp-includes/class-wp-hook.php(308): CiviCRM_For_WordPress->invoke("")
#4 /home/SITE/public_html/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters("", (Array:1))
#5 /home/SITE/public_html/wp-includes/plugin.php(517): WP_Hook->do_action((Array:1))
#6 /home/SITE/public_html/wp-admin/admin.php(259): do_action("toplevel_page_CiviCRM")
#7 {main}
```
It may be worth noting that extension updates fail as well, although the error code is "DB Error: unknown" so I assume it is something else. Sorry for the confusion, I'm really not sure what to do with these issues and if they are related.https://lab.civicrm.org/dev/core/-/issues/4031Searchkit: Download spreadsheet should use standard date format, not the form...2023-05-29T01:37:04ZlarsssandergreenSearchkit: Download spreadsheet should use standard date format, not the format set in Date FormatsIf you're downloading a CSV or other spreadsheet from Searchkit results or a SK Table, you'll get dates formatted per the Date Display format setting, which by default is `August 9th, 2012 1:17 PM`. That's a format that takes some wrang...If you're downloading a CSV or other spreadsheet from Searchkit results or a SK Table, you'll get dates formatted per the Date Display format setting, which by default is `August 9th, 2012 1:17 PM`. That's a format that takes some wrangling to get Excel or other spreadsheet programs to recognize as a date.
Instead, the date should be exported as it is using export from non-SK results, in standard format `2012-08-09 13:17`.
[Related issue](https://lab.civicrm.org/dev/core/-/issues/3730) on data types in ods or xlsx files.
Tested on dmaster (5.58).https://lab.civicrm.org/dev/core/-/issues/4030Searchkit: Escaping for regex breaks search with join2022-12-12T08:10:01ZlarsssandergreenSearchkit: Escaping for regex breaks search with joinIf you try a Searchkit search for Addresses with Street Address matching pattern `[a-z]\s`, the results will return as expected, with the regex pattern shown as `"[a-z]\\s"`. However, if you do a search for Contacts with or without Addre...If you try a Searchkit search for Addresses with Street Address matching pattern `[a-z]\s`, the results will return as expected, with the regex pattern shown as `"[a-z]\\s"`. However, if you do a search for Contacts with or without Addresses with Street Address matching pattern `[a-z]\s`, the results will be borked because the pattern will be `"\"[a-z]\\\\s\""`. Similar results are found with other fields or entities.
Tested on dmaster (5.58) and 5.49.5.