CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-06-28T06:55:29Zhttps://lab.civicrm.org/dev/core/-/issues/4328Double opt-in requires traditional bounce handling to be enabled2023-06-28T06:55:29ZJonGoldDouble opt-in requires traditional bounce handling to be enabledOverview
----------------------------------------
The default double opt-in email says:
> You have a pending subscription to the {subscribe.group} mailing list. To confirm this subscription, reply to this email or click <a href="{subscri...Overview
----------------------------------------
The default double opt-in email says:
> You have a pending subscription to the {subscribe.group} mailing list. To confirm this subscription, reply to this email or click <a href="{subscribe.url}">here</a>.
However, "reply to this email" requires traditional bounce handling (with a bounce mailbox) to be set up. In this day and age that's less common compared to using a third party mailer that sends bounce notifications via API (to [Airmail](https://civicrm.org/extensions/airmail) or one of its many cousins).
Moreover, it's a usability issue to put "here" as the clickable text. It should be more like: "Please click here to <a href="{subscribe.url}">confirm your subscription.</a>.
I want to get concept approval - and also guidance on whether we should update existing templates or just new installs. Personally I think we should update any non-customized template.https://lab.civicrm.org/dev/core/-/issues/4324Add Contribution Page settings for Review and Make Contribution button text2023-11-23T07:47:54ZlarsssandergreenAdd Contribution Page settings for Review and Make Contribution button textContribution Pages can be important to some organizations who do a lot of fundraising. It would be nice if the buttons were customizable, so they could say 'Donate', 'Give', 'Get Membership' or whatever the user might want.
Proposal: Ad...Contribution Pages can be important to some organizations who do a lot of fundraising. It would be nice if the buttons were customizable, so they could say 'Donate', 'Give', 'Get Membership' or whatever the user might want.
Proposal: Add two fields to Contribution Pages: review_button_text and submit_button_text. These settings could live on the main settings tab, underneath "Use a confirmation page?" with review_button_text hidden and shown conditionally. If these are populated, use these values, if not, fall back to the default (Contribute or Review your contribution followed by Make Contribution).https://lab.civicrm.org/dev/core/-/issues/4320API: Should NOT operators return NULL values?2023-07-13T23:50:59ZlarsssandergreenAPI: Should NOT operators return NULL values?If you do != 5 in SQL, you'll get all rows that aren't 5, not including null values. This is the same in the API and SearchKit. I wonder if this is the desired behaviour? I would think the assumption would be that if I search for all Con...If you do != 5 in SQL, you'll get all rows that aren't 5, not including null values. This is the same in the API and SearchKit. I wonder if this is the desired behaviour? I would think the assumption would be that if I search for all Contributions where the Contribution Page is != 5, I would get all Contributions except those that have Contribution Page = 5 — but what I actually get is all Contributions that have a Contribution Page, but where that Contribution Page isn't 5.
In other words, I think you'd generally expect that if you search all Contributions where Contribution Page = 5 OR Contribution Page != 5, you'd just get all Contributions, but you only get Contributions with a Contribution Page. Obviously, your expectation might change based on your familiarity with SQL.
This is the same for NOT LIKE, NOT REGEX, and so on.
On the one hand, it's generally better to keep the behaviour of the API operators the same as SQL to avoid confusion. On the other hand, I'm having a hard time imagining a search you might want to make with a NOT that you wouldn't want to include null values, so this seems unhelpful and potentially frustrating. Is this something we should consider changing?https://lab.civicrm.org/dev/core/-/issues/4297Do help links go after the label or after the field?2023-06-20T20:38:21ZlarsssandergreenDo help links go after the label or after the field?It seems like on some backend forms, the little help links are after the label, while in other places they are after the field itself. If we can agree on one or the other, I will adjust the templates so forms are consistent. My unscienti...It seems like on some backend forms, the little help links are after the label, while in other places they are after the field itself. If we can agree on one or the other, I will adjust the templates so forms are consistent. My unscientific survey indicates that we have about 2/3 after the label and 1/3 after the field right now.
Here's an example with both:
![image](/uploads/28270ce52cc725f384c3e4bcb368442a/image.png)
Additional consideration: When there is both a setting and a help, probably having one after the other would be not great.
![image](/uploads/2966630753c68c090d2a80269a488c34/image.png)
Also, there are a few with help at the end of the description
![image](/uploads/964d812410ed131320947dc6d7b0b7c5/image.png)
Some fields it has to be after the field because there is no label
![image](/uploads/d2f943517edf44b307599502855c4346/image.png)
Checkboxes are always after the label, but that's at the end of the line.
![image](/uploads/f7d02999614ef14009d158d8236b9951/image.png)
With multiple checkboxes, it has to be after the label, there isn't really any other option.
![image](/uploads/155a387d37d5452b9e4f7373cb7a447a/image.png)
Another different layout, I think it only makes sense after the label here
![image](/uploads/d13c5bd26e5bb9aff8f72adf5dc2f109/image.png)https://lab.civicrm.org/dev/core/-/issues/4273Allow double opt-in email (and other emails that you don't want a reply from)...2023-07-05T23:48:40ZJamie Novick - CompucoAllow double opt-in email (and other emails that you don't want a reply from) to use a user configured "mail from" address**How it works currently:**
Currently CiviCRM forces the double opt in email to an email address which is:
the words "do not reply" + the domain of the site from your default mail account configured here: https://dmaster.demo.civicrm.o...**How it works currently:**
Currently CiviCRM forces the double opt in email to an email address which is:
the words "do not reply" + the domain of the site from your default mail account configured here: https://dmaster.demo.civicrm.org/civicrm/admin/mailSettings?reset=1
https://github.com/civicrm/civicrm-core/blob/6f14847526226279076f63cc472afc18f2ce27e6/CRM/Core/BAO/Domain.php#L364
**What is the issue?**
The problem with this is that the default mail account email domain (used for bounce handling), may not be the same domain that you want to use as the from address for your double opt in emails (or for any other email that you don't want a reply from).
**Proposed solution**
We already have a place to configure the available from addresses in the system. This is the option group here: https://dmaster.demo.civicrm.org/civicrm/admin/options/from_email_address?reset=1
As such I would suggest that:
1. We create a new setting on the CiviMail component settings (https://dmaster.demo.civicrm.org/civicrm/admin/setting/preferences/mailing?reset=1) (suggest this is below "Enable Double Opt-in for Profiles which use the "Add to Group" setting":
- called "Email From Address to use where a reply is not expected".
- Field type - single select,
- Options to show from available "Email From Addresses" here: https://dmaster.demo.civicrm.org/civicrm/admin/options/from_email_address?reset=1.
- Not required
- Help: "Specify an Email From Address to use when the system sends an email but a reply is not expected, for example when a user is sent an email for a double opt-in. Leaving this blank will use the default which will be do-not-reply@default_domain where the default_domain will be the email domain address of your default mailing account also used for bounce handling. You can add additional Email From Addresses here [link to admin/options/from_email_address?reset=1].
2. If an email address is specified in the setting above it should be used instead of the current hardcoded default value.
**Next steps**
We're happy to submit a PR for this so if we can get this concept approved we will submit a core PR asap.
Thankshttps://lab.civicrm.org/dev/core/-/issues/4241Refresh custom fields names in "Reuse an existing set"2023-04-18T06:50:39ZkristinecRefresh custom fields names in "Reuse an existing set"Overview
----------------------------------------
When adding a new custom field and selecting "reuse an existing set" of custom fields, the dropdown list for some of the multiple choice option sets do not pick up the custom field set na...Overview
----------------------------------------
When adding a new custom field and selecting "reuse an existing set" of custom fields, the dropdown list for some of the multiple choice option sets do not pick up the custom field set names. For example, you have a multiple choice question called "Educational Status" in Custom Field Set A and the same name "Educational Status" in Custom Field B.
Current behaviour
----------------------------------------
In CiviCRM 5.59, the custom field set labeling are missing for some old custom fields (made before a certain Civi update?).
![Screenshot_2023-04-15_111421](/uploads/dc83d16e1c6fcf8a2e9cce1961260909/Screenshot_2023-04-15_111421.png)
Proposed behaviour
----------------------------------------
The word "refresh" or "reset" the dropdown list probably isn't the right word. But the expected behavior should appear as:
Custom Field Set A:: Educational Status
Custom Field Set B:: Educational Status
P.S. And yes, technically if the options in "Educational Status" are exactly the same, this field set should have been shared rather than exist in two separate custom field sets.https://lab.civicrm.org/dev/core/-/issues/4204Direct Debit agreement is always/never shown depending on which payment proce...2023-04-25T18:46:28ZbgmDirect Debit agreement is always/never shown depending on which payment processor is the defaultTo reproduce:
- Enable the Credit Card dummy processor
- Enable a Direct Debit processor (such as CiviSepa? or iATS)
- Enable both on a Contribution Page
Depending on which Payment Processor is set as the default, that will influence i...To reproduce:
- Enable the Credit Card dummy processor
- Enable a Direct Debit processor (such as CiviSepa? or iATS)
- Enable both on a Contribution Page
Depending on which Payment Processor is set as the default, that will influence if the "direct debit agreement" is displayed on the contribution page. It should only be shown if a Direct Debit payment method was selected.
Screenshots by @Andreas in #4189:
![screenshot1](/uploads/06edccccf03f105e07263906e06ed4a4/screenshot1.png)
![screenshot2](/uploads/97f048b7788ea9672fb4b2584e8d9962/screenshot2.png)
Initially reported by @romy5.61.0https://lab.civicrm.org/dev/core/-/issues/4160Convert html special chars to their ascii equivalent in ical file generation2023-03-07T07:26:05ZyashodhaConvert html special chars to their ascii equivalent in ical file generationWhen an event is set to public, the event registration receipt includes a link to download a .ics (ical) file of the event.
This ICS file is generated on the fly, and adds the description of the event to the description field in the .ics...When an event is set to public, the event registration receipt includes a link to download a .ics (ical) file of the event.
This ICS file is generated on the fly, and adds the description of the event to the description field in the .ics. All html tags are stripped from the text, however special chars that have been converted to their html code are not converted back to ASCII in the .ics.
We need to update the generation of the .ics file to include the conversion of html char code back to ASCII equivalent.
e.g.
- è ; > è
- " ; > "
- Â ; > Â
-   ; > [space]
(put the space before ; so that one can see the char code)
etc...yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4149User editable Message Templates, the Contact Action: Send an Email and the Co...2023-03-29T21:09:22Zjustinfreeman (Agileware)User editable Message Templates, the Contact Action: Send an Email and the Contact Action: Print Merge/Document cannot use any Smarty Tokens with the crmDate function because CKEditor 4 unnecessarily HTML encodes single quotes (') and double quotes (")User editable Message Templates, the Contact Action: Send an Email and the Contact Action: Print Merge/Document cannot use any Smarty Tokens with the crmDate function because CKEditor 4 unnecessarily HTML encodes single quotes (') and do...User editable Message Templates, the Contact Action: Send an Email and the Contact Action: Print Merge/Document cannot use any Smarty Tokens with the crmDate function because CKEditor 4 unnecessarily HTML encodes single quotes (') and double quotes (").
So if you use a Smarty Token like:
```{contribution.receive_date|crmDate:"%E%f %B %Y"}```
```{contribution.receive_date|crmDate:'%E%f %B %Y'}```
When CKEditor 4 parses the HTML it converts this into:
```{contribution.receive_date|crmDate:"%E%f %B %Y"}```
```{contribution.receive_date|crmDate:'%E%f %B %Y'}```
Effectively rendering the crmDate function unusable in these situations.
Using CKEditor 5 does solve this specific problem, however CKEditor 5 introduces new problems such as the inability for users to resize images, loss of some formatting controls and importantly prevents the ability to view/edit the source HTML.
Agileware Ref: CIVICRM-21035.61.0https://lab.civicrm.org/dev/core/-/issues/4141API4: When searching by date range, end of range is not included2023-04-22T17:05:33ZlarsssandergreenAPI4: When searching by date range, end of range is not includedWhen you use SearchKit to search by date range on a datetime field (i.e. between two dates), the end date is not included in the results because it interprets 12/31/2022 as 20221231000000 instead of the expected 20221231235959. The same ...When you use SearchKit to search by date range on a datetime field (i.e. between two dates), the end date is not included in the results because it interprets 12/31/2022 as 20221231000000 instead of the expected 20221231235959. The same happens in FormBuilder with a date filter and Choose date range. This comes from API4, where `->addWhere('receive_date', 'BETWEEN', ['2022-01-01', '2022-12-31'])` is interpreted as to 20221231000000 rather than to 20221231235959.
This is quite confusing for users, e.g. when last quarter doesn't give the same results as 10/01/2022 - 12/31/2022.
I think the fix is simply to use a default time of 23:59:59 if none is specified for an end date, but I'm not sure if that might cause unexpected behaviour elsewhere.https://lab.civicrm.org/dev/core/-/issues/4124Past campaigns are not to be assigned via batch update/update contributions2023-03-15T06:27:08ZyashodhaPast campaigns are not to be assigned via batch update/update contributionsSteps to replicate :
- Create a campaign with end date in past
![campaign](/uploads/cefd27e11afe0c929803e28f58f67bbb/campaign.png)
- Create a profile configured for contribution fields (including the campaign field)
- Find Contribution...Steps to replicate :
- Create a campaign with end date in past
![campaign](/uploads/cefd27e11afe0c929803e28f58f67bbb/campaign.png)
- Create a profile configured for contribution fields (including the campaign field)
- Find Contributions, and select a few and use the created profile to update the campaign
- The campaign is NOT available in the drop down
![batch_update](/uploads/cfa7bee25d1cb7baa5bd1664b39e00e5/batch_update.png)
- On new/edit contributions, you are able to choose the past campaigns as well (which is the correct behavior).
![new_contribution](/uploads/82d4ddaaf86af46cab608ef26b333ece/new_contribution.png)yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4110Can't edit Activity source, targets, assignees in FormBuilder2023-04-05T16:48:01ZnoahCan't edit Activity source, targets, assignees in FormBuilder[As reported](https://chat.civicrm.org/civicrm/pl/eprjkpg4cbrcbbj7u64qnbsohc) by @guyiac on MM:
I'm trying to use a form to edit existing activities. I can pass the existing activity id successfully with an URL, and all the information ...[As reported](https://chat.civicrm.org/civicrm/pl/eprjkpg4cbrcbbj7u64qnbsohc) by @guyiac on MM:
I'm trying to use a form to edit existing activities. I can pass the existing activity id successfully with an URL, and all the information for the activity will pre-fill into the form, ***except*** the contacts (targets, assigned to, and created by). Am I missing something? Civi 5.54.0.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/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/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/4081API v.3 Event.create used for update will change Event Template to ordinary E...2023-01-16T15:26:05Zniels_erik_andersenAPI v.3 Event.create used for update will change Event Template to ordinary EventWhen API v.3 Event.create is used for update event template, it will set is_template to false so that the template is changed to an ordinary event.
To reproduce:
cv api Event.create id=nnn template_title="New Title"
Where nnn is id for...When API v.3 Event.create is used for update event template, it will set is_template to false so that the template is changed to an ordinary event.
To reproduce:
cv api Event.create id=nnn template_title="New Title"
Where nnn is id for Event Template
To fix:
In
CRM_Event_BAO_Event::create(&$params) {
$transaction = new CRM_Core_Transaction();
if (empty($params['is_template'])) {
$params['is_template'] = 0;
}
Change
if (empty($params['is_template'])) {
to:
if (empty($params['id']) && empty($params['is_template'])) {5.59.0