CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-02-02T07:45:34Zhttps://lab.civicrm.org/dev/core/-/issues/4102Custom field content in a repeating event is not copied to all/subsequent ins...2023-02-02T07:45:34ZUpperholmeCustom field content in a repeating event is not copied to all/subsequent instances of the repeated eventOverview
----------------------------------------
I have set up a series of repeating events. I also have a set of custom fields for events. If I populate to a custom field in one instance of the repeating event, and save the change I a...Overview
----------------------------------------
I have set up a series of repeating events. I also have a set of custom fields for events. If I populate to a custom field in one instance of the repeating event, and save the change I am asked if I want to cascade that change to later events in the series, to all of the events, or to none. If I choose to save the change to either all of the events in the series or to later events in the series, I expect the custom field to be populated with an identical value in all of the selected events in the series. This doesn't happen. The change is on ly saved to the specific event that I have edited.
Reproduction steps
----------------------------------------
1. Create a custom field set for events with at least one field.
2. Create an event and specify that it be repeated more than once. Save.
3. Edit one instance of the event series (not the last one in the series). Edit a selected custom field for the event. Save and choose to apply the change to either all of the events in the series, or to later events.
4. Edit a later instance of the event, and note that the change has not been applied.
Current behaviour
----------------------------------------
The change to the selected custom field in only saved to the specific instance of the event.
Expected behaviour
----------------------------------------
I expect the custom field to be populated with an identical value in all of the selected events in the series.
Environment information
----------------------------------------
CiviCRM 5.57.1
Drupal 7.94https://lab.civicrm.org/dev/core/-/issues/4101CiviCRM session management contributing to (causing?) 30s login delays with J...2023-01-30T08:32:33ZTOCM_MMatthewsCiviCRM session management contributing to (causing?) 30s login delays with JetPack and non-default themesOverview
----------------------------------------
There is more info in the CiviCRM StackExchange thread at https://civicrm.stackexchange.com/questions/42896/civicrm-plugin-causes-a-30-second-login-delay/42901#42901. And this is also pro...Overview
----------------------------------------
There is more info in the CiviCRM StackExchange thread at https://civicrm.stackexchange.com/questions/42896/civicrm-plugin-causes-a-30-second-login-delay/42901#42901. And this is also probably related to an old issue that was closed as not being a real problem, https://lab.civicrm.org/dev/wordpress/-/issues/32.
WordPress 6.x (several versions), CiviCRM several versions (including 5.57.0), JetPack (several versions, including latest), and every theme that I tried that wasn't one included with WordPress (currently using Vantage). Note that I have another WP/CiviCRM/JetPack/Vantage site that does NOT have this problem, so it could be extension or plugin related but I haven't been able to figure out what that might be given all the permutations.
But after going several rounds with JetPack engineering & support taking xdebug traces, their conclusion was the session management from CiviCRM was interfering with sessions in general, causing one of their threads to hang. Logins indirectly depended on JetPack threads, so logins hung. The workaround now is to disable the 'Dedicated Sync' thread (which JetPack has to do on their end). Causes some other minor issues or delays in the background, but at least our logins are fast now.
Reproduction steps
----------------------------------------
Wish I could tell you.
Current behaviour
----------------------------------------
Any login takes 30s before finishing. Looking at web server log (modified ssl_request to include # of seconds), the POST /wp-admin/admin-ajax.php?callback=[stuff] call was the one taking 30s. Trace files give more info, which is what JetPack engineering used.
Expected behaviour
----------------------------------------
Quick logins, which are happening now that JetPack isn't trying to keep a dedicate sync thread running. But I'd like to not have to disable features that I'm paying for in JetPack to have a usable site.
Environment information
----------------------------------------
Browser: All. Personally I've used Safari (latest versions since Oct 2022) and Chrome (latest versions since Oct 2022) on MacOS, but this affected every user.
CiviCRM, all versions since 5.54.0.
PHP: Started with 7.4.x, now on 8.0.27.
WordPress: Latest version since Oct 2022.
Database: MySQL 8.0.30
Web Server: Apache 2.4.53
OS: CentOS Stream 9
Comments
----------------------------------------
Understand that this has no easy fix, but I do want to record the fact that it does in fact have a real world impact, and if there's anything else that can be done to solve/mitigate/whatever it, I am more than happy to help get more information.https://lab.civicrm.org/dev/core/-/issues/4100Add setting to disable Smarty in Scheduled reminders2023-04-11T12:40:41ZMichael McAndrewAdd setting to disable Smarty in Scheduled remindersUntil now, Smarty has been turned on in scheduled reminders.
This can cause problems when inline CSS is present in the scheduled reminder (e.g. when the html for the reminder was generated via Mosaico using the https://civicrm.org/exten...Until now, Smarty has been turned on in scheduled reminders.
This can cause problems when inline CSS is present in the scheduled reminder (e.g. when the html for the reminder was generated via Mosaico using the https://civicrm.org/extensions/mosaico-message-templates extension). It causes a fatal error when sending the messages which may not be detected and may cause other scheduled jobs to fail.
We could fix this by turning it off but some sites may want to preserve the current behaviour (those who actually use Smarty in their scheduled reminders - we don't now how many of these exist but we presume that they are in the minority - see https://github.com/civicrm/civicrm-core/pull/15436#issuecomment-541923948 for a discussion of why Smarty was enabled originally).
So we:
1. add a new setting `scheduled_reminder_smarty` which by default is null, i.e. we disable this feature for new sites.
2. enable this feature during the upgrade to preserve the existing behaviour
3. let people know they we might want to turn it off in a post upgrade message
We should also consider mentioning this in the https://civicrm.org/extensions/mosaico-message-templates documentation.
See https://github.com/civicrm/civicrm-core/pull/15436 and https://lab.civicrm.org/dev/core/-/issues/58 for relevant background.5.60.0https://lab.civicrm.org/dev/core/-/issues/4099Form Builder crashes trying to edit Mosaico Templates form.2023-01-30T08:31:04ZRichForm Builder crashes trying to edit Mosaico Templates form.Overview
----------------------------------------
Editing the "Mosaico Templates" form provided by the Mosaico extension causes an AngluarJS crash in Form Builder.
Reproduction steps
----------------------------------------
1. Use Civi...Overview
----------------------------------------
Editing the "Mosaico Templates" form provided by the Mosaico extension causes an AngluarJS crash in Form Builder.
Reproduction steps
----------------------------------------
1. Use Civi 5.57, mosaico ext 2.10.1665574809
1. Go to **Administer » Custom » Form Builder » Search Forms » Edit** on the `afsearchMosaicoTemplateList` one
2. Crash.
Current behaviour
----------------------------------------
Console log first error (there's lots, but I expect it's the first one that causes the others)
> Syntax Error: Token '{' invalid key at column 2 of the expression [{{ts('Configure template categories')}}] starting at [{ts('Configure template categories')}}].
Expected behaviour
----------------------------------------
Should be able to edit the form.
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:__ Firefox 110.0b5
* __CiviCRM:__ 5.57
* __PHP:__ 7.4
* __CMS:__ D7
Comments
----------------------------------------
If I edit the .html file in question and remove the {{ }} parts then it's happy. But those {{ }} parts do work when the form is presented; just not in the editor.
I believe this is a core bug and not to do with mosaico.
https://github.com/veda-consulting-company/uk.co.vedaconsulting.mosaico/blob/9ecdf84b65640c79c73162c4659e94e56442ccea/ang/afsearchMosaicoTemplateList.aff.html#L12https://lab.civicrm.org/dev/core/-/issues/4098Feature Request: Ability to hide FormBuilder Search Forms when there are no r...2023-01-30T08:30:41ZbrienneFeature Request: Ability to hide FormBuilder Search Forms when there are no results foundOverview
----------------------------------------
By the combined powers of SearchKit and FormBuilder, you can create Search Forms and display them on the Contact Summary Page. While you can limit the type of contact on which to display ...Overview
----------------------------------------
By the combined powers of SearchKit and FormBuilder, you can create Search Forms and display them on the Contact Summary Page. While you can limit the type of contact on which to display it, i.e. Organization or Individual, it is currently not possible to hide the display when there are no results returned from the SearchKit search.
Example use-case
----------------------------------------
Creating a display block on Organizations to display the "Primary Contact". If the Organization has a primary contact, then the user would want to see that displayed in the block. If they do not have a primary contact, then a user may want to hide that display altogether.
1. Make a SearchKit search with the following criteria:
* Search for *Contacts*
* With (required) *Contact Related Contacts* if Relationship to contact = *Primary Contact of*
* Contact Type = *Organization*
1. Make a Table display for that SearchKit and configure as desired.
2. Make a Form from that display, check the *Add to Contact Summary Page* option, and select **Organization** next to the *For* label.
Current behaviour
----------------------------------------
Currently, it is not possible to hide the display block when there are no results found. Instead, you get a bright blue box on the Contact Summary Page that states "None found".
![Selection_202](/uploads/d03094d0e269f5e8529084f9e3e91ca6/Selection_202.png)
Proposed behaviour
----------------------------------------
There should a variety of options for users to configure how these blocks are displayed/not displayed when there are no options (such as the "no results options with Drupal Views).
For example, there could be a checkbox on the FormBuilder section that adds the display to the Contact Summary Page that gives the option to hide the display when there are no results. This type of checkbox could also be on the SearchKit display options.
![Selection_204](/uploads/cf167a5469addcff5093897b850b790e/Selection_204.png)
![Selection_205](/uploads/004f81cdb74c390c5568a25cfec1ec5c/Selection_205.png)
Comments
----------------------------------------
This is an unfunded feature request of suggestions for UX improvements.https://lab.civicrm.org/dev/core/-/issues/4097CRM_Utils_Number::formatLocaleNumeric() method throws fatal error with empty ...2023-01-30T21:07:08ZbenmoreassyntCRM_Utils_Number::formatLocaleNumeric() method throws fatal error with empty string parameter.Overview
----------------------------------------
CRM_Utils_Number::formatLocaleNumeric() method throws fatal error due to string parameter.
Reproduction steps
----------------------------------------
1. Generate a report that uses cust...Overview
----------------------------------------
CRM_Utils_Number::formatLocaleNumeric() method throws fatal error due to string parameter.
Reproduction steps
----------------------------------------
1. Generate a report that uses custom fields with numeric values. In my case the custom fields were storing simple integer counts of family members.
1. The following fatal error is thrown: "Fatal error: Uncaught Error: NumberFormatter::format(): Argument #1 ($num) must be of type int|float, string given
in /path/to/civicrm/civicrm/CRM/Utils/Number.php on line 123"
Current behaviour
----------------------------------------
Fatal error is thrown. Error affects multiple reports. Full output follows.
```
Fatal error: Uncaught Error: NumberFormatter::format(): Argument #1 ($num) must be of type int|float, string given
in /path/to/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Utils/Number.php on line 123
Call stack:
NumberFormatter::format()
wp-content/plugins/civicrm/civicrm/CRM/Utils/Number.php:123
CRM_Utils_Number::formatLocaleNumeric()
wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/CustomField.php:1282
CRM_Core_BAO_CustomField::formatDisplayValue()
wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/CustomField.php:1116
CRM_Core_BAO_CustomField::displayValue()
wp-content/plugins/civicrm/civicrm/CRM/Report/Form.php:2388
CRM_Report_Form::alterCustomDataDisplay()
wp-content/plugins/civicrm/civicrm/CRM/Report/Form.php:3293
CRM_Report_Form::sectionTotals()
wp-content/plugins/civicrm/civicrm/CRM/Report/Form.php:2578
CRM_Report_Form::formatDisplay()
wp-content/plugins/civicrm/civicrm/CRM/Report/Form/Contact/Summary.php:154
CRM_Report_Form_Contact_Summary::postProcess()
wp-content/plugins/civicrm/civicrm/CRM/Report/Form.php:956
CRM_Report_Form::preProcess()
wp-content/plugins/civicrm/civicrm/CRM/Report/Form/Contact/Summary.php:125
CRM_Report_Form_Contact_Summary::preProcess()
wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php:668
CRM_Core_Form::buildForm()
wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Display.php:76
CRM_Core_QuickForm_Action_Display::perform()
wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php:203
HTML_QuickForm_Controller::handle()
wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Page.php:103
HTML_QuickForm_Page::handle()
wp-content/plugins/civicrm/civicrm/CRM/Core/Controller.php:355
CRM_Core_Controller::run()
wp-content/plugins/civicrm/civicrm/CRM/Utils/Wrapper.php:98
CRM_Utils_Wrapper::run()
wp-content/plugins/civicrm/civicrm/CRM/Report/Page/Instance.php:74
CRM_Report_Page_Instance::run()
wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:319
CRM_Core_Invoke::runItem()
wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:69
CRM_Core_Invoke::_invoke()
wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:36
CRM_Core_Invoke::invoke()
wp-content/plugins/civicrm/civicrm.php:1199
CiviCRM_For_WordPress::invoke()
wp-includes/class-wp-hook.php:308
WP_Hook::apply_filters()
wp-includes/class-wp-hook.php:332
WP_Hook::do_action()
wp-includes/plugin.php:517
do_action()
wp-admin/admin.php:259
```
Expected behaviour
----------------------------------------
A CiviCRM report of custom fields and data should be shown.
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.57.1
* __PHP:__ reproduced in 8.1 and 8.0
* __CMS:__ WordPress 6.6.1
* __Database:__ reproduced in MySQL 5.7 and MySQL 8.0
* __Web Server:__ Apache 2.4
Comments
----------------------------------------
Possible fix (submitted via pull request):
CRM/Utils/Number.php Insert the following after line 122.
```php
if ((int) $amount == $amount) {
$amount = intval($amount);
} else {
$amount = floatval($amount);
}
```5.59.0https://lab.civicrm.org/dev/core/-/issues/4096Proposal - change title for all `is_primary` fields to 'Is Primary'2023-02-06T03:57:46ZeileenProposal - change title for all `is_primary` fields to 'Is Primary'I just got REALLY confused trying to import to `Primary Email` - which turns out to be the `is_primary` field - I think we should maybe change to `Is Primary` - @colemanw ?I just got REALLY confused trying to import to `Primary Email` - which turns out to be the `is_primary` field - I think we should maybe change to `Is Primary` - @colemanw ?5.59.0https://lab.civicrm.org/dev/core/-/issues/40955.58 rc upgrade error2023-01-25T23:07:10Zeileen5.58 rc upgrade errorI hit an error in the 5.58rc upgrade script - although oddly enough the sql seems to run when run directly & column type seems to be text
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHan...I hit an error in the 5.58rc upgrade script - although oddly enough the sql seems to run when run directly & column type seems to be text
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => -1
[message] => DB Error: unknown error
[mode] => 16
[debug_info] => UPDATE `civicrm_option_group` SET `description`
= 'When recording mobile phone numbers for contacts, it may be useful
to include the Mobile Phone Service Provider (e.g. Cingular, Sprint,
etc.). CiviCRM is installed with the most commonly encountered
service providers. Administrators may define as many additional
providers as needed.' WHERE ( `civicrm_option_group`.`id` = 5 )
[nativecode=1406 ** Data too long for column 'description' at row 1]
[type] => DB_Error
[user_info] => UPDATE `civicrm_option_group` SET `description`
= 'When recording mobile phone numbers for contacts, it may be useful
to include the Mobile Phone Service Provider (e.g. Cingular, Sprint,
etc.). CiviCRM is installed with the most commonly encountered
service providers. Administrators may define as many additional
providers as needed.' WHERE ( `civicrm_option_group`.`id` = 5 )
[nativecode=1406 ** Data too long for column 'description' at row 1]5.58.0https://lab.civicrm.org/dev/core/-/issues/4094Admin UI: Attempting to delete custom field group with custom fields opens th...2023-08-12T05:12:29ZlarsssandergreenAdmin UI: Attempting to delete custom field group with custom fields opens the listing page in modal windowIf you:
1. Enable Admin UI
2. Attempt to delete a custom field group that contains at least one custom field
You will get a message that you cannot do this while the field group contains fields (makes sense), but also modal window will...If you:
1. Enable Admin UI
2. Attempt to delete a custom field group that contains at least one custom field
You will get a message that you cannot do this while the field group contains fields (makes sense), but also modal window will open with the main custom field groups listing page again (this should not happen).
![image](/uploads/539ce85d7607649fe04405e3f14c22bf/image.png)
Also, there is no timeout for the alert generated, so it never goes away. Standard 10s for this seems sufficient.
![image](/uploads/2a520630fe49b4290ba54e6167cc3cd3/image.png)
Verified on dmaster (5.59).https://lab.civicrm.org/dev/core/-/issues/4093Searchkit: Change in place edit fields to textarea2023-01-30T08:26:02Zlevi.kSearchkit: Change in place edit fields to textareaOverview
----------------------------------------
Replace some fields in search kit to textarea
Example use-case
----------------------------------------
1. in place editing on a search display can be frustrating when dealing with more ...Overview
----------------------------------------
Replace some fields in search kit to textarea
Example use-case
----------------------------------------
1. in place editing on a search display can be frustrating when dealing with more than a few words of text
2. The main page for Search Kit also suffers from this issue in the new description field (and same goes for label field altough the label field is usually only a few words)
![image](/uploads/ab66207368f4dd446dba6a8571dc5e72/image.png)
inspired by https://lab.civicrm.org/dev/core/-/issues/3893https://lab.civicrm.org/dev/core/-/issues/4092Resubscribe request processing crashes, blocks cron job2023-01-31T08:29:15ZBobSResubscribe request processing crashes, blocks cron jobOverview
----------------------------------------
When CiviCRM performs bounce processing, a resubscribe request email results in a call to CRM_Mailing_Event_BAO_Resubscribe::resub_to_mailing() which fails as that class does not exist. A...Overview
----------------------------------------
When CiviCRM performs bounce processing, a resubscribe request email results in a call to CRM_Mailing_Event_BAO_Resubscribe::resub_to_mailing() which fails as that class does not exist. As the error occurs before the offending email is removed from the Inbox, subsequent invocations of "civicrm-api job.execute" continue to fail.
Reproduction steps
----------------------------------------
1. Unsubscribe from an email list.
2. Receive confirmation email with the message ```You can re-subscribe by mailing mailto:bounce+e.[redacted]@mydomain.org```
3. Send an email to that address.
In addition, clicking the link in the email fails for the same reason.
Current behaviour
----------------------------------------
* Popup indicating "Cron not running".
* Mail processing (and presumably other scheduled jobs) not running.
* Drupal log entry: ```Error: Class 'CRM_Mailing_Event_BAO_Resubscribe' not found in civicrm_api3_mailing_event_resubscribe_create() (line 29 of /var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/api/v3/MailingEventResubscribe.php).```
Expected behaviour
----------------------------------------
Contact resubscribed.
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 necessary. -->
* __CiviCRM:__ _5.57.0_
* __PHP:__ _7.4.33_
* __CMS:__ _Drupal 7.91_
* __Database:__ _MariaDB 10.4_
* __Web Server:__ _Apache 2.4_
Comments
----------------------------------------
* Most recent bounce+e email we've received before this one was in 11/21, and that caused no issues.
* Marking this Confidential as it could be used in a type of Denial of Service attack, preventing CiviCRM sites from sending email/SMS.5.57.3https://lab.civicrm.org/dev/core/-/issues/4091Smart group contacts from custom search show wrong results2023-02-06T04:26:31ZyashodhaSmart group contacts from custom search show wrong resultsSteps to replicate :
--------------------
- Create a smart group from any of the custom searches
- Remove a few contacts from the smart group
- Go to _Manage Groups_, the count is correct but when you click Contacts link it shows remove...Steps to replicate :
--------------------
- Create a smart group from any of the custom searches
- Remove a few contacts from the smart group
- Go to _Manage Groups_, the count is correct but when you click Contacts link it shows removed Contacts as well.
Count (correct)
![count](/uploads/0875a1556b0aa8bcd8a619d47e22d7fa/count.png)
Contacts link (wrong)
![wrong_results](/uploads/f4d8b04b546712f5166b3424c4263fe7/wrong_results.png)
- Go to _Find Contacts_, search for the smart group - it works as expected
![smart_](/uploads/a5491f1eea0ec5474d003c8aaa70a58a/smart_.png)yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4090Managed Entity reconciliation fails if entity exists without Managed entity2023-06-08T16:37:28Zaydunsaidan.saunders@squiffle.ukManaged Entity reconciliation fails if entity exists without Managed entityOverview
----------------------------------------
Follow along now: "Managed Entities" involve both a `Managed` entity and the entity being managed. If the managed entity exists but the corresponding `Managed` entity does not, errors a...Overview
----------------------------------------
Follow along now: "Managed Entities" involve both a `Managed` entity and the entity being managed. If the managed entity exists but the corresponding `Managed` entity does not, errors are thrown.
For example, if an extension provides a `.mgd.php` file specifying a `PaymentProcessorType` entity, the reconciliation process will create the `PaymentProcessorType` entity and a `Managed` entity and then manage updates or deletion when the extension is updated or uninstalled.
In some (unknown) circumstances, the `Managed` entity does not exist but the managed (eg `PaymentProcessorType`) entity does exist. `CRM_Core_ManagedEntities::reconcile()` does not check for the existence of the `PaymentProcessorType` entity and so attempts to create a duplicate which fails. This happens any time a cache clear occurs.
Reproduction steps
----------------------------------------
I don't know how this has occurred on live systems, but to simulate:
1. Install Stripe (or other extension with `.mgd.php`)
2. Delete the `Managed` entity for Stripe: `cv api4 Managed.delete +w 'name = "Stripe"'`
3. `cv flush`
Current behaviour
----------------------------------------
```
$ cv flush
Flushing system caches
Error: API Call Failed: Array
(
[entity] => System
[action] => flush
[params] => Array
(
[debug] => 1
[version] => 3
)
[result] => Array
(
[trace] => #0 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(192): CRM_Core_ManagedEntities->onApiError()
#1 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(152): CRM_Core_ManagedEntities->insertNewEntity()
#2 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(113): CRM_Core_ManagedEntities->reconcileEntities()
#3 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Invoke.php(417): CRM_Core_ManagedEntities->reconcile()
#4 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/api/v3/System.php(33): CRM_Core_Invoke::rebuildMenuAndCaches()
#5 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_system_flush()
#6 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(158): Civi\API\Provider\MagicFunctionProvider->invoke()
#7 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest()
#8 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/api/api.php(22): Civi\API\Kernel->runSafe()
#9 phar:///opt/buildkit/bin/cv/src/Command/BaseCommand.php(63): civicrm_api()
#10 phar:///opt/buildkit/bin/cv/src/Command/FlushCommand.php(37): Civi\Cv\Command\BaseCommand->callApiSuccess()
#11 phar:///opt/buildkit/bin/cv/vendor/symfony/console/Command/Command.php(255): Civi\Cv\Command\FlushCommand->execute()
#12 phar:///opt/buildkit/bin/cv/vendor/symfony/console/Application.php(1009): Symfony\Component\Console\Command\Command->run()
#13 phar:///opt/buildkit/bin/cv/vendor/symfony/console/Application.php(273): Symfony\Component\Console\Application->doRunCommand()
#14 phar:///opt/buildkit/bin/cv/src/Application.php(82): Symfony\Component\Console\Application->doRun()
#15 phar:///opt/buildkit/bin/cv/vendor/symfony/console/Application.php(149): Civi\Cv\Application->doRun()
#16 phar:///opt/buildkit/bin/cv/src/Application.php(49): Symfony\Component\Console\Application->run()
#17 phar:///opt/buildkit/bin/cv/bin/cv(27): Civi\Cv\Application::main()
#18 /opt/buildkit/bin/cv(14): require('phar:///opt/bui...')
#19 {main}
[is_error] => 1
[error_message] => API error: DB Error: already exists on PaymentProcessorType.create( entity name Stripe)
)
)
```
Expected behaviour
----------------------------------------
No error - or at least a helpful error message.
I think `reconcile()` could just create the missing `Managed` entity but there may be other ramifications of doing that.
Environment information
----------------------------------------
* __CiviCRM:__ _Master_
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/4089Batch Data Entry for Membership2024-02-09T02:31:39ZmollconsBatch Data Entry for MembershipSee https://chat.civicrm.org/civicrm/pl/43n5d1d8tfr5xkc1ptmqhpn7iw for detail of issue.
I have created the contacts successfully and am now attempting to perform a "Batch Data Entry for Memberships". I have created the membership types ...See https://chat.civicrm.org/civicrm/pl/43n5d1d8tfr5xkc1ptmqhpn7iw for detail of issue.
I have created the contacts successfully and am now attempting to perform a "Batch Data Entry for Memberships". I have created the membership types (3 types) and when I attempt to "Enter Records" the error occurs.
If I delete all of the member type records, then I am able to enter the batch entry. But then I am not able to select any member type.
I am using Chrome browser on Joomla 4.2.6 and with CiviCRM 5.57.0 (or 5.57.1).https://lab.civicrm.org/dev/core/-/issues/4088Regression - CiviCRM core unit tests interfere with running non-CiviCRM tests2023-02-09T22:51:30ZeileenRegression - CiviCRM core unit tests interfere with running non-CiviCRM testsWe run our own unit tests on CiviCRM, using the tarball in our CiviCRM folder. We use a set up that @totten did many many years back when `civibuild` was first created.
It ran fine on 5.54 & does not on 5.58 due to changes in core
The ...We run our own unit tests on CiviCRM, using the tarball in our CiviCRM folder. We use a set up that @totten did many many years back when `civibuild` was first created.
It ran fine on 5.54 & does not on 5.58 due to changes in core
The error is
```
Error: Class 'api\v4\Api4TestBase' not found in include() (line 12 of /srv/civi-sites/wmff/drupal/sites/all/modules/civicrm/ext/afform/core/tests/phpunit/Civi/Afform/AfformContactSummaryTest.php).
```
We are not trying to run this test & the file does not ship with CiviCRM.
There are 2 recent changes in play
1) Class scanning was touched mid last year - this may not be relevant as the net effect of the code may not have changed
![image](/uploads/b7520bb506f68e8bc34301deb7dc0373/image.png)
2) A dependency was added by @colemanw in tests that DO ship with core on files that do NOT ship with core.
![image](/uploads/e2b1ecbc9b5666d9ec484a7a8b75f56c/image.png)
The net effect is that if tries & fails to load these unit test classes despite them being out-of-scope for what we are testing.
I think the basic principle is either the tests should not ship at all in the tarball or they should be shipped with their dependencies.
In this case it seems likely we should consider whether the `Api4TestBase` class is mature enough to ship under `Civi\Test` (with the implied support for extensions that creates). I would probably prefer to offer a trait over a `BaseClass` if we do that - although there might be blockers on that.https://lab.civicrm.org/dev/core/-/issues/4087Offline Event confirmation receipt prints waitlist message2023-01-19T18:32:47ZPradeep Nayakpradpnayak@gmail.comOffline Event confirmation receipt prints waitlist messageReplicate:
1. Register for Event
2. View participant record
3. Click on Change selection link under selections
4. Select on Send Confirmation and add confirmation text and Save
Expected result:
Email should display confirmation text
Ac...Replicate:
1. Register for Event
2. View participant record
3. Click on Change selection link under selections
4. Select on Send Confirmation and add confirmation text and Save
Expected result:
Email should display confirmation text
Actual result:
Waitlist message displayed in email
```You have been added to the WAIT LIST for this event. If space becomes available you will receive an email with a link to a web page where you can complete your registration.```
Regression from: [5.53.0](https://github.com/civicrm/civicrm-core/commit/a0b74a905e2)5.58.0https://lab.civicrm.org/dev/core/-/issues/4086`processor_id` and `trxn_id` is not properly being set on recurring contribut...2023-08-08T15:16:15Zbrienne`processor_id` and `trxn_id` is not properly being set on recurring contributions with PayPal ProOverview
----------------------------------------
When a user submits a new, recurring payment on a site that uses PayPal Pro, the `processor_id` and `trxn_id` are immediately set to a long alphanumeric string on submission and these val...Overview
----------------------------------------
When a user submits a new, recurring payment on a site that uses PayPal Pro, the `processor_id` and `trxn_id` are immediately set to a long alphanumeric string on submission and these values are not getting updated with the proper format (a shorter, alphanumeric string that starts with 'I-') that is sent back from PayPal.
This causes an immense issue if the user then wants to cancel their recurring contribution because even though it may seem canceled in CiviCRM, the payment is not canceled on PayPal's side, and so the user continues to be charged. This happens because the PayPalPro IPN is no longer being properly set in the CiviCRM database, so when the request to cancel the recurring payment profile goes to PayPal, it does not have the correct `processor_id` needed to cancel it.
Reproduction steps
----------------------------------------
0. If you don't already have one, set up a PayPal Pro Sandbox account that has DPRP enabled for testing recurring payments. Add the API credentials (found in **Activity > API Access > NVP/SOAP API integration**) of this sandbox account to CivCRM as a test payment processor.
* *Fair warning, this set up process with PayPal was not that easy, so if you don't have PayPal Pro, I wouldn't recommend trying this*
1. From your PayPal Pro Sandbox account settings, go to **Notifications**, then click **Update** on **Instant payment notifications**. If your site is not publicly accessible to the internet (i.e. a local dev site for testing), then set up a [webhook.site](https://webhook.site) listening endpoint.
1. Submit a new, recurring contribution (*while not logged in on CiviCRM and using a [PayPal generated credit card for testing](https://developer.paypal.com/tools/sandbox/card-testing/)*) using the PayPal Pro payment processor.
1. On the web UI of webhook.site, take a look at the `recurring_payment_id` for the POST request that has `'recurring_payment_profile_created'` as the `'txn_type'`.
1. In CiviCRM, either with the API explorer or however you look at the data in the databases, look at the `processor_id` and `trxn_id` in the `civicrm_contribution_recur` table.
1. You will find that these strings don't match.
Current behaviour
----------------------------------------
The `processor_id` and `trxn_id` are being set to long alphanumeric strings, such as 'e13d51f14f7fff9fb6923820022ebc77' upon submission of a recurring payment on a CiviCRM installation that is using PayPal Pro. These values are stored in the `civicrm_contribution_recur` table and become problematic for updating or canceling recurring payments.
Expected behaviour
----------------------------------------
The `processor_id` and `trxn_id` should be set to (and stored as) the PayPal Pro IPN that is generated when the `'txn_type'` is `'recurring_payment_profile_created'`. The PayPal Pro IPN is an alphanumeric string that notably starts with 'I-', such as 'I-818V5WCCXF2H'
Additional Info
----------------------------------------
Some backstory - a few years ago, `processor_id` was initially set to `NULL` and was later updated with the IPN. In that scenario, the logic that CiviCRM used (in `/CRM/Core/PaymentPayPalProIPN.php`) made sense, as it checked if that value was set and returned early if it was. However, [PR #21539](https://github.com/civicrm/civicrm-core/pull/21539) added `processor_id` to parameters that get passed to the `recur()` function in PayPalProIPN.php, so the code that sets the value of `processor_id` (and `trxn_id`) to the properly formatted IPN was not being reached.
@JonGold and I currently have a PR with a fix for this in the works, but are doing further testing with a client.
Given that this issue has been going on for a while (9 months, at least), there are many recurring contributions that have a malformed `processor_id`. The PR that will be submitted also includes a check for when `'txn_type'` is `'recurring_payment'` (i.e. subsequent recurring payments) to update the `processor_id` and `trxn_id` to the proper format, if needed.https://lab.civicrm.org/dev/core/-/issues/4085SearchKit can't export more than a couple thousand rows2023-05-26T16:17:22ZJonGoldSearchKit can't export more than a couple thousand rowsOverview
----------------------------------------
When attempting to "Download Spreadsheet" in SK, it times out with more than a couple thousand rows. It's very PHP-intensive to do the pseudoconstant lookups, Smarty calculations, etc. ...Overview
----------------------------------------
When attempting to "Download Spreadsheet" in SK, it times out with more than a couple thousand rows. It's very PHP-intensive to do the pseudoconstant lookups, Smarty calculations, etc. That's not noticeable when it's calculating a page of 50, but doesn't scale.
Reproduction steps
----------------------------------------
1. Create an SK query that yields a large number of contacts. Ensure you have 2-3 pseudoconstant fields in your `SELECT`.
1. Attempt to export with "Download Spreadsheet"
Current behaviour
----------------------------------------
Times out, but appears to still be downloading.
Expected behaviour
----------------------------------------
Finishes successfully, or at least reports back to the user that the export won't finish.
Comments
----------------------------------------
Most systems that offer exports of large data sets - including our competitors like NationBuilder etc., but also many apps like PayPal - do not attempt to offer the export in real-time. They queue the export, then you visit a queue page to download the completed exports (most systems will email you when it's ready).
@eileen @totten I know you've both been working on queuing mechanisms. I can drum up some funding (maybe $750 USD? Need to check) to support this. I'm not sure if it's a heavy lift or a light one though, so I don't know if that's a substantial amount of funding.
Ideally, this would work like imports or CiviMail, where the queue job can build the export over multiple cron runs. The client who would fund this is on Pantheon, which doesn't have an unlimited cron job run time.https://lab.civicrm.org/dev/core/-/issues/4084Assign participant_status_id in both edit/create modes2023-01-19T22:46:24ZyashodhaAssign participant_status_id in both edit/create modesAssign participant_status_id in both edit/create modes to template.
Right now, it is assigned in just edit mode.Assign participant_status_id in both edit/create modes to template.
Right now, it is assigned in just edit mode.5.59.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4083Cannot fill in FormBuilder fields when using Existing Contact autocomplete2023-01-20T00:07:09ZbrienneCannot fill in FormBuilder fields when using Existing Contact autocompleteOverview
----------------------------------------
On FormBuilder forms that use autocomplete option "Existing Contact", users cannot fill in other fields. If it is a text box that was not filled in by the autocomplete, then the user is u...Overview
----------------------------------------
On FormBuilder forms that use autocomplete option "Existing Contact", users cannot fill in other fields. If it is a text box that was not filled in by the autocomplete, then the user is unable to type anything. If the text box was filled out by the autocomplete, then any changes made to that field are temporarily visible, but disappear. Selects and checkboxes may be clicked, but those changes are also temporary. Even if the user does not search/select a contact, then they still cannot fill out the form.
Reproduction steps
----------------------------------------
1. Create a FormBuilder form based on a contact (i.e. Organization)
1. Add an "Existing Contact" field, as well as one text box field for testing (i.e Email)
1. Save, and click **View Page**
2. Try to type into the text box field, both before and after selecting a contact
Here is the markup for the form that I tested on in dmaster:
```html
<af-form ctrl="afform">
<af-entity data="{contact_type: 'Organization', source: 'Test'}" type="Contact" name="Organization1" label="Organization 1" actions="{create: true, update: true}" security="RBAC" />
<fieldset af-fieldset="Organization1" class="af-container" af-title="Organization 1">
<div class="af-container">
<af-field name="id" />
<div class="af-container af-layout-inline"></div>
</div>
<div af-join="Email">
<div class="af-container af-layout-inline">
<af-field name="email" />
</div>
</div>
</fieldset>
<button class="af-button btn btn-primary" crm-icon="fa-check" ng-click="afform.submit()">Submit</button>
</af-form>
```
![Selection_185](/uploads/00187e18cc7b108e67f9e341b6a3b7f1/Selection_185.png)
Current behaviour
----------------------------------------
When a FormBuilder form has an "Existing Contact" autocomplete, users cannot fill in or edit fields.
Expected behaviour
----------------------------------------
Users should be able to fill out or edit fields with an "Existing Contact" autocomplete on the form.
Environment information
----------------------------------------
This type of form does not work on 5.57.1, but does work on 5.56.2.
I did a `git bisect` and located the first bad commit as 2aaaa86bb041d6214c17a0d2a85f9f28838b2904, which is PR [24974](https://github.com/civicrm/civicrm-core/pull/24974) (Use APIv4-based Autocomplete widget throughout SearchKit, Afform & API Explorer)