CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-03-15T06:27:08Zhttps://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/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/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/4078Mass SMS with many Contacts causes slow loading of Manage Case screen for ACL...2023-01-12T10:02:37ZjhungerfordMass SMS with many Contacts causes slow loading of Manage Case screen for ACL usersOverview
----------------------------------------
The combination of Mass SMS Activities with many recipients, and ACL access to Contacts for Users who do not have "view/edit all contacts", causes very long loading times for Manage Case ...Overview
----------------------------------------
The combination of Mass SMS Activities with many recipients, and ACL access to Contacts for Users who do not have "view/edit all contacts", causes very long loading times for Manage Case screens.
Mass SMS Activities apply to Contacts, not Cases. Due to the way the `$params` are converted to `$activityParams`, the `$case_id` is never passed to the final API call. This means that non-Case Activities go through permission checks when loading the Manage Case screen. These ACL checks can take quite a long time (e.g. 30 Mass SMS Activities with 2k recipients each means 60k ACL permission checks).
Bulk Email Activities are handled differently (possibly to avoid this type of issue). Changing the Activity Type from Mass SMS to Bulk Email with an SQL query provides a workaround, but not a great solution.
Reproduction steps
----------------------------------------
1. Set up ACL access to Contacts, so a User does not have "view all contacts" or "edit all contacts", but has ACL access to view and edit (at least some) Contacts
2. Enable CiviCase
3. Create a Case for a Contact who can be accessed by the ACL user
4. Create a few (dozen) Mass SMS Activities with thousands of Contacts including the Contact from step 3
5. Log in as the ACL user from step 1
6. Load the Manage Case screen for the Case from step 3
7. Observe that it takes longer than normal
8. Set is_deleted=1 or change the Activity Type to Bulk Email for all Activities created in step 4
9. Load the Manage Case screen again, and observe that it's much faster
Current behaviour
----------------------------------------
Most of the time is spent inside the `controller->run()` call here:
https://lab.civicrm.org/dev/core/-/blob/5.57.0/CRM/Case/Page/Tab.php#L98-112
That whole block can actually be removed, and superficially the page appears to work (without the speed issues), though I haven't tested much. Just noting that it doesn't have any immediately obvious effect on the page.
Looking into why it takes so long, I think it relates to the parameters prepared by this getActivites call:
https://lab.civicrm.org/dev/core/-/blob/5.57.0/CRM/Activity/BAO/Activity.php#L579-583
At that point, `$params["caseId"]` contains an integer. However, it doesn't make it into `$activityParams`. If you observe what happens here, I think `$activityParams["case_id"]` will always contain `['IS NULL' => 1]`.
https://lab.civicrm.org/dev/core/-/blob/5.57.0/CRM/Activity/BAO/Activity.php#L2287-2291
Since `self::activityComponents()` is called without arguments, it will never contain CiviCase:
https://lab.civicrm.org/dev/core/-/blob/5.57.0/CRM/Activity/BAO/Activity.php#L851-861
The comment "In practice this means should we include CiviCase in the results" seems to imply the reverse, but stepping through `activityComponents()` in the debugger, I see:
`$compInfo["CiviCase"]->info["showActivitiesInCore"] = (bool) 0`
Even if CiviCase were included in the results though, the case ID would not make its way from `$params` into `$activityParams`:
https://lab.civicrm.org/dev/core/-/blob/5.57.0/CRM/Activity/BAO/Activity.php#L2289-2291
The end result of all of this is that the controller is checking permissions for every Activity relating to this contact, not just the ones which will be displayed on the Case. When each Activity has thousands of Contacts (as with Mass SMS), these checks become very slow.
Also, the Activities section of the Manage Case screen seems to be populated by a subsequent process. Removing this controller has no obvious effect (except reducing the loading time), raising the question of whether it's needed at all.
Expected behaviour
----------------------------------------
Mass SMS Activities with many contacts should not slow down the loading of Manage Case screens (noting that a Mass SMS cannot be applied to a Case, only to a Contact).
Environment information
----------------------------------------
* __Browser:__ Chromium Version 108.0.5359.124 (Official Build) Arch Linux (64-bit)
* __CiviCRM:__ 5.57.0
* __PHP:__ 7.4
* __CMS:__ Drupal 7.92
* __Database:__ mysql Ver 15.1 Distrib 10.5.18-MariaDB
* __Web Server:__ Apache 2.4https://lab.civicrm.org/dev/core/-/issues/4075Profile used for search results: contact type field shows internal name inste...2023-01-12T10:01:14Zaydunsaidan.saunders@squiffle.ukProfile used for search results: contact type field shows internal name instead of labelOverview
----------------------------------------
If you create a profile to use for search results from simple or advanced search and include the contact subtype, the value shown is the internal name, not the label.
Reproduction steps...Overview
----------------------------------------
If you create a profile to use for search results from simple or advanced search and include the contact subtype, the value shown is the internal name, not the label.
Reproduction steps
----------------------------------------
1. At `Administer > Customise Data and Screens > Contact Types` create a type as 'My new type'
1. Edit the name to be 'My changed type'
1. Create/Update a contact to use the type just created
1. At `Administer > Customise Data and Screens > Profiles` create a profile, tick 'Search Views', add `Contact > Contact Subtype` as a field
1. Go to `Search > Advanced Search, set 'Views for Display Contacts' to the profile just created. Do a search that includes the contact you created/updated
Current behaviour
----------------------------------------
The type shows as `My_new_type`
Expected behaviour
----------------------------------------
The type should show as `My changed type`
Environment information
----------------------------------------
* __CiviCRM:__ _5.57.0_ ... but maybe much earlier too.
Comments
----------------------------------------
Note that renaming the type shows the problem more clearly, but even without that, if the subtype was created with a name including a space it will show with an underscore instead of the space.https://lab.civicrm.org/dev/core/-/issues/4071Multiple language support: translations are not available in "Contribution A...2023-11-23T07:47:00ZmasettoMultiple language support: translations are not available in "Contribution Amounts Label" (`amount_label` field) in the Contribution pageOverview
----------------------------------------
On tab "Amounts" of Contribution page there is no possibility to make translations of "Contribution Amounts Label".
Reproduction steps
----------------------------------------
1. Click ...Overview
----------------------------------------
On tab "Amounts" of Contribution page there is no possibility to make translations of "Contribution Amounts Label".
Reproduction steps
----------------------------------------
1. Click on **Administer -> Localisation -> Languages, Currency, Locations**.
1. Check on ****Enable Multiple Languages**.
1. Click on **Contribution -> New Contribution Page**.
1. On tab "Amounts", "Contribution Amounts Label" there is no possibility to make translations.
Environment information
----------------------------------------
* __CiviCRM:__ 5.54.0
* __PHP:__ _7.4
* __CMS:__ _WordPress 6.1_https://lab.civicrm.org/dev/core/-/issues/4067Contact dashboard - Pledges section always says "no pledges" when using checksum2023-01-10T09:30:32ZDaveDContact dashboard - Pledges section always says "no pledges" when using checksumIf a contact has pledges, then the contact dashboard (e.g. /civicrm/user?id=12) will show the pledges for the logged in user, or for logged in admins who have access. But when visiting as anonymous and using a checksum, the other section...If a contact has pledges, then the contact dashboard (e.g. /civicrm/user?id=12) will show the pledges for the logged in user, or for logged in admins who have access. But when visiting as anonymous and using a checksum, the other sections display the same but the pledges says "no pledges".
I can reproduce on master (note dmaster.demo does not set permissions for anonymous access to contact dashboard even with checksum so can't do it there), and it goes back to at least 5.35 so I don't know how old it is.https://lab.civicrm.org/dev/core/-/issues/4064Off-line Contribution receipts are sent to on hold emails2023-04-22T16:38:36ZlarsssandergreenOff-line Contribution receipts are sent to on hold emailsIf you record an off-line contribution for a contact with an email on hold, the option to send them a receipt at their on-hold email address is shown (with no indication that the email is on hold).
I would think the expected behaviour w...If you record an off-line contribution for a contact with an email on hold, the option to send them a receipt at their on-hold email address is shown (with no indication that the email is on hold).
I would think the expected behaviour would be to not show the receipt option if the contributor's email is on hold.https://lab.civicrm.org/dev/core/-/issues/4061Send letter in bulk to pledgers2023-01-10T09:34:22ZyashodhaSend letter in bulk to pledgersFunctional specifications:
- We are replicating the existing feature for contributions “Thank you letters - print or email” for the pledges.
- In menu Pledges, Find Pledges, make the Pledge statuses Pending, In progress and Overdue sele...Functional specifications:
- We are replicating the existing feature for contributions “Thank you letters - print or email” for the pledges.
- In menu Pledges, Find Pledges, make the Pledge statuses Pending, In progress and Overdue selected by default
- In menu Actions, add “Pledge Letters - print or email”
- When we select “Pledge Letters - print or email”, we land on a screen (replicate of the one for contributions)
- Replace Thank-you Letter for Contributions (PDF) by Pledge Letter
- Replace Update thank-you dates for these contributions by Update pledge letter dates for these pledges
- Remove Update receipt dates for these contributions
- Replace MAKE THANK-YOU LETTERS by MAKE PLEDGE LETTERS
The following tokens need to be available in the drop down Tokens so they can be included in a message template and resolved when included in the letter:
- Total pledge amount
- Total pledge payments
- Pledge balance
- Upcoming pledge payment amount
- Upcoming pledge payment due datehttps://lab.civicrm.org/dev/core/-/issues/4058Search Tasks limited by certain ACLs when they should not be2023-01-10T09:35:37ZRichSearch Tasks limited by certain ACLs when they should not beSometimes an incomplete list of search tasks are shown to a user whose access is ACL limited.
I think this problem is caused by this line:
https://lab.civicrm.org/dev/core/-/blob/5.56/CRM/ACL/BAO/ACL.php#L503
I think the loop `break`s...Sometimes an incomplete list of search tasks are shown to a user whose access is ACL limited.
I think this problem is caused by this line:
https://lab.civicrm.org/dev/core/-/blob/5.56/CRM/ACL/BAO/ACL.php#L503
I think the loop `break`s when it shouldn't. I think what's intended is to simply shift that `break` up within the `if {}` that ends on the line above it.
I think the intention of the code is:
- loop through the DAO results that lists permissions
- if the object_id is empty (typically, zero) then the permission applies to all "objects of that type" by which I think it means groups.
- there's an allowance that this record might be for a different permission type (e.g. View instead of Edit) which we would want to ignore
- if the type does match, then all groups are permissioned and we merge those onto our `$ids` array
However where it fails is if there are, say, 2 rows returned. The first says View all, the 2nd says Edit all, and we're asking about edit permission. Because of the `break` where it is, once the first row is looked at and discarded, we break and don't loko at the 2nd row!
Shifting the `break` up seems to fix this and seems to me to be probably what was intended.
Because this bug is highly sensitive to a load of stuff, it's likely that this shows up in weird situations and could be hard to reproduce.
If this makes sense to anyone I'll submit a PR.
In case it's helpful, my proposal is
```diff
diff --git a/sites/all/modules/civicrm/CRM/ACL/BAO/ACL.php b/sites/all/modules/civicrm/CRM/ACL/BAO/ACL.php
index 58b388b73..3d036a3a3 100644
--- a/CRM/ACL/BAO/ACL.php
+++ b/CRM/ACL/BAO/ACL.php
@@ -499,8 +499,8 @@ ORDER BY a.object_id
foreach ($allGroups as $id => $dontCare) {
$ids[] = $id;
}
+ break;
}
- break;
}
}
return $ids;
```https://lab.civicrm.org/dev/core/-/issues/4057Cannot remove contact from group from Groups tab UI within ACL environment2023-01-10T09:36:07ZRichCannot remove contact from group from Groups tab UI within ACL environmentHave a staff user, *Pebbles*, in an ACL, with access to a contact, *Wilma*.
When Pebbles views the Groups tab of Wilma's record, they are able to add Wilma to a group via the UI, but should they click **remove** or **delete** next to a ...Have a staff user, *Pebbles*, in an ACL, with access to a contact, *Wilma*.
When Pebbles views the Groups tab of Wilma's record, they are able to add Wilma to a group via the UI, but should they click **remove** or **delete** next to a group, an error shows:
> API permission check failed for GroupContact/delete call; insufficient permission: require access CiviCRM and edit all contacts
I don't think this is a security/permissions thing.
Pebbles is able to remove Wilma from the group by simply clicking Edit to get to the hideous edit-flippin-everything form, and then removing the group from the select2 element in the Groups accordion.
## Suggested fix (v1)
I think it's useful for ACL-ed staffers to be able to use groups; it's such a core feature of Civi. And it's fairly weird that they can add a contact to a group, but not remove one - or not by the main UI.
I implemented this as follows in a custom extension, but I'm sure there's a better way to do it upstream.
```
/**
* @see https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_alterAPIPermissions/
*/
function myextension_civicrm_alterAPIPermissions($entity, $action, &$params, &$permissions) {
if ($entity === 'group_contact' && $action == 'delete' && !empty($params['id'])) {
$gc = \Civi\Api4\GroupContact::get(FALSE)
->addWhere('id', '=', $params['id'])
->addSelect('contact_id', 'group_id.group_type:name')
->execute()->single();
$mayEditContact = \Civi\Api4\Contact::checkAccess()
->setAction('update')
->addValue('id', $gc['contact_id'])
->execute()->first()['access'] ?? FALSE;
$groupIsNotAcl = !in_array('Access Control', $gc['group_id.group_type:name'] ?? []);
if ($mayEditContact && $groupIsNotAcl) {
// Reduce the access permissions for this call.
$permissions['group_contact']['delete'] = 'access CiviCRM';
}
}
}
```https://lab.civicrm.org/dev/core/-/issues/4054Redis cache of Extensions persists between builds2023-01-05T21:57:54ZeileenRedis cache of Extensions persists between buildsI'm hitting an issue where if I run civibuild to rebuild a site shortly after enabling afform it fails - the reason is the Redis cache is used to retrieve enabled extensions, including afform so the afform alterMenu hook is called when i...I'm hitting an issue where if I run civibuild to rebuild a site shortly after enabling afform it fails - the reason is the Redis cache is used to retrieve enabled extensions, including afform so the afform alterMenu hook is called when installing CiviCRM - but the extension is not yet installed & hence the function fatals as it fails to find the Afform class it calls
When determining which hook is called we see
```
/**
* @param $moduleList
*/
public function requireCiviModules(&$moduleList) {
$civiModules = CRM_Core_PseudoConstant::getModuleExtensions();
```
This winds up at
![image](/uploads/e0a82bcf50371e56217b8a0d5c048e2a/image.png)
And it gets the previous build's module list here
![image](/uploads/69f06caeb86421b3923c41e152028f23/image.png)
The cache name is a bit convoluted - but it should be flushed on install to avoid this between-install leakage.
I'm not quite sure where though ... @tottenhttps://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/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/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.https://lab.civicrm.org/dev/core/-/issues/4025Import Memberships: activity date set to date of import instead of Membership...2023-11-08T00:50:05ZcomposerjkImport Memberships: activity date set to date of import instead of Membership Start DateOverview
----------------------------------------
For _Memberships > Import Memberships_, I would expect that the _Activity Date_ for _Membership Signup_ would be the required _Membership Start Date_. Instead, when one views Activities,...Overview
----------------------------------------
For _Memberships > Import Memberships_, I would expect that the _Activity Date_ for _Membership Signup_ would be the required _Membership Start Date_. Instead, when one views Activities, the _Membership Signup_ activity date is the date/time of the import.
Query on chat.civicrm.org (no replies, yet): https://chat.civicrm.org/civicrm/pl/jgrmtpxr878w3fbtrm6iia4rsw
It looks like @petednz also mentioned this issue back in 2017: https://chat.civicrm.org/civicrm/pl/sbj5yeuccfr65yy9wwmam3mxte
Reproduction steps
----------------------------------------
1. _Memberships > Import Memberships_ for an existing contact with a Membership Start Date set to some date in the past.
1. View the Membership Signup activity, perhaps via _Search > Find Activities_.
Current behaviour
----------------------------------------
The listed Activity Date is the date of the import.
Expected behaviour
----------------------------------------
I would expect that the _Activity Date_ would be the _Membership Start Date_, similar to how the _Activity Date_ for a _Contribution_ is set to the _Payment Received Date_.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
- __CiviCRM:__ 5.56.0, 5.55.2, 5.55.0, 5.54.0
- __CMS:__ WordPress 6.1.1
- __PHP:__ 8.1.13 (fpm-fcgi)
- __Database:__ 10.3.31-MariaDB engine: InnoDB 10 row format: Dynamic
- __Webserver:__ nginx/1.20.2
- __OS:__ Linux
Comments
----------------------------------------
In my case, part of this is maintaining history. At some point, I hope to import data for membership archives going back 80 years. From @petednz's mention, it sounds like the _Membership Dashboard_ will also look wrong.https://lab.civicrm.org/dev/core/-/issues/4024progress output on stdout when emails are processed as activities2022-12-08T09:43:19Zsebalisprogress output on stdout when emails are processed as activitiesOn a CiviCRM instance I administrate, the Civi cron job is run via “cv api job.execute” with appropriate user and cwd parameters. The output is normally in JSON, so I decided to parse the output to see if there have been any problems. If...On a CiviCRM instance I administrate, the Civi cron job is run via “cv api job.execute” with appropriate user and cwd parameters. The output is normally in JSON, so I decided to parse the output to see if there have been any problems. If there are no problems, I suppress the output completely, to prevent Linux cron (which triggers the whole thing) from sending an automatic email to the admins. This has worked well so far.
For a short while we have defined two new email accounts that we use for “email to activity”. When there are new emails, we now get output on stdout that makes it impossible to parse the output as JSON. This prevents making the automatic decision on whether there has been a problem, so I revert to sending an email and I keep the output.
I looked into the cause and found that CRM/Utils/Mail/EmailProcessor.php contains several lines that write to stdout. To me these outputs should better go to the CiviCRM log or to stderr. But I don’t know what standards you follow for this or other components, so at this point I am not able to submit a pull request.
You can find the output I am referring to by searching CRM/Utils/Mail/EmailProcessor.php for the string “echo”. I quote them here, together with my opinion of what I would do with them (biased because of my current problem of course):
```
212 catch (Exception $e) {
213 echo $e->getMessage();
214 $store->markIgnored($key);
215 continue;
216 }
```
This seems better placed on stderr or as an error entry in the Civi log.
```
229 echo "Failed Processing: {$mail->subject}. Reason: {$result['error_message']}\n";
```
Same as above.
```
234 echo "Processed as Activity: {$mail->subject}\n";
```
This is the line I regularly get. I think a Civi log entry with an appropriate level below warning should be enough, or it should go to stderr.
```
391 echo "Failed Processing: {$mail->subject}, Action: $action, Job ID: $job, Queue ID: $queue, Hash: $hash. Reason: {$r esult['error_message']}\n";
```
Same as earlier, error entry in the Civi log or stderr
These lines have been around for many years (I checked), and there might be similar examples in several other places. Again, I don’t know what your conventions are.https://lab.civicrm.org/dev/core/-/issues/4023Check Clean URLs check: Frequent error noise when no contribution pages and p...2022-12-08T09:42:33ZJonGoldCheck Clean URLs check: Frequent error noise when no contribution pages and public can't access events#### Replication Steps
* Be on WordPress.
* Have no contribution pages.
* Have at least 1 active event.
* Remove "CiviEvent: register for events" permission from anonymous user.
Get a bunch of these errors:
```
[error]
$Fatal Error De...#### Replication Steps
* Be on WordPress.
* Have no contribution pages.
* Have at least 1 active event.
* Remove "CiviEvent: register for events" permission from anonymous user.
Get a bunch of these errors:
```
[error]
$Fatal Error Details = array:3 [
"message" => "You do not have permission to access this page."
"code" => null
"exception" => CRM_Core_Exception {#8688
#message: "You do not have permission to access this page."
#code: 0
#file: "/home/jon/local/nmysite/web/wp-content/plugins/civicrm/civicrm/CRM/Utils/System/WordPress.php"
#line: 615
#cause: null
-_trace: null
-errorData: array:1 [
"error_code" => 0
]
trace: {
/home/jon/local/nmysite/web/wp-content/plugins/civicrm/civicrm/CRM/Utils/System/WordPress.php:615 {
› $civicrm_wp_title = ts('You do not have permission to access this page.');
› throw new CRM_Core_Exception(ts('You do not have permission to access this page.'));
› }
}
/home/jon/local/nmysite/web/wp-content/plugins/civicrm/civicrm/CRM/Utils/System.php:62 { …}
/home/jon/local/nmysite/web/wp-content/plugins/civicrm/civicrm/CRM/Event/Page/EventInfo.php:42 { …}
/home/jon/local/nmysite/web/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:319 { …}
/home/jon/local/nmysite/web/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:69 { …}
/home/jon/local/nmysite/web/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:36 { …}
/home/jon/local/nmysite/web/wp-content/plugins/civicrm/civicrm.php:1199 { …}
/home/jon/local/nmysite/web/wp-content/plugins/civicrm/includes/civicrm.basepage.php:380 { …}
/home/jon/local/nmysite/web/wp-includes/class-wp-hook.php:308 { …}
/home/jon/local/nmysite/web/wp-includes/class-wp-hook.php:332 { …}
/home/jon/local/nmysite/web/wp-includes/plugin.php:565 { …}
/home/jon/local/nmysite/web/wp-includes/class-wp.php:797 { …}
/home/jon/local/nmysite/web/wp-includes/functions.php:1332 { …}
/home/jon/local/nmysite/web/wp-blog-header.php:16 { …}
/home/jon/local/nmysite/web/index.php:17 { …}
}
}
]
```
I want to ping Eli Lisseck but I don't think they're pingable?