Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-07-18T17:56:58Zhttps://lab.civicrm.org/dev/core/-/issues/4436Contact prefix not shown in mailing labels2023-07-18T17:56:58ZschorschiiContact prefix not shown in mailing labels## Overview
I tried to insert the contact prefix into the mailing label format. So I selected the "Individual Prefix" from the right drop-down menu and it inserts `{contact.prefix_id:label}` into the mailing label format textbox. However...## Overview
I tried to insert the contact prefix into the mailing label format. So I selected the "Individual Prefix" from the right drop-down menu and it inserts `{contact.prefix_id:label}` into the mailing label format textbox. However, this placeholder is never filled, i.e. it is always empty when creating mailing labels.
## Reproduction steps
1. Administer -> Localization -> Address Settings -> insert "Individual Prefix"/`{contact.prefix_id:label}` into textbox
2. Search contacts, select some from the result list, choose "Mailing labels - print" from the actions menu
## Current behaviour
The contact prefix is never shown on the mailing labels.
## Expected behaviour
The contact prefix should be shown on the mailing label PDF.
## Environment information
CiviCRM version 5.63.1 under WordPress, German language packhttps://lab.civicrm.org/dev/core/-/issues/4435Undefined index: payment_type2023-07-24T02:33:18ZJoeMurrayUndefined index: payment_typeOn dmaster I changed default contribution page to purchase memberships so it allowed pay later, went to live page and did a pay later payment for a $100 membership and got (on https://dmaster.demo.civicrm.org/civicrm/contribute/transact?...On dmaster I changed default contribution page to purchase memberships so it allowed pay later, went to live page and did a pay later payment for a $100 membership and got (on https://dmaster.demo.civicrm.org/civicrm/contribute/transact?_qf_Confirm_display=true&qfKey=CRMContributeControllerContribution4dhfkffigym8c4c8k0kos0ko00440gkg8008wss00gowwc8ckw_9868):
Notice: Undefined index: payment_type in CRM_Core_Payment->validatePaymentInstrument() (line 511 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Payment.php).
Dummy Payment processor is only defined payment processor and it is enabled.
Changing Fall Fundraising default event to allow Pay Later, then using Live page to do so, also results in an error on the confirm but not Thank You page (https://dmaster.demo.civicrm.org/civicrm/event/register?_qf_Confirm_display=true&qfKey=CRMEventControllerRegistrationxabxsqxsysgg88scss808ksog0o4okko84cw4ok0s0ss8cgsk_1767):
Notice: Undefined index: payment_type in CRM_Core_Payment->validatePaymentInstrument() (line 511 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Payment.php).5.65.0https://lab.civicrm.org/dev/core/-/issues/4434Don't allow uploading attachments to bulk mailings if they exceed the size limit2023-07-21T09:57:50ZDaveDDon't allow uploading attachments to bulk mailings if they exceed the size limitThere's been a couple times on multiple sites where the mailing bounces and it's not clear to the average office staffer why, but it's because they've uploaded a 30MB pdf to the mailing.
It should just not allow doing that in the first ...There's been a couple times on multiple sites where the mailing bounces and it's not clear to the average office staffer why, but it's because they've uploaded a 30MB pdf to the mailing.
It should just not allow doing that in the first place if the config settings have a smaller limit.https://lab.civicrm.org/dev/core/-/issues/4433E2E_Core_PathUrlTest::testGetUrl_WpAdmin() fails because CiviCRM routing is c...2023-07-24T20:52:34ZtottenE2E_Core_PathUrlTest::testGetUrl_WpAdmin() fails because CiviCRM routing is confusingThe gist of the test: it calls `cv url civicrm/contribute?reset=1` and asserts that the URL will open in the WordPress backend UI (aka `/wp-admin/`).
([Full source](https://github.com/civicrm/civicrm-core/blob/8e0dabd20bebe55d5dd725f301...The gist of the test: it calls `cv url civicrm/contribute?reset=1` and asserts that the URL will open in the WordPress backend UI (aka `/wp-admin/`).
([Full source](https://github.com/civicrm/civicrm-core/blob/8e0dabd20bebe55d5dd725f3015c41019cb8dbed/tests/phpunit/E2E/Core/PathUrlTest.php#L94-L117))
The test is failing. There are currently two patches:
* [25476](https://github.com/civicrm/civicrm-core/pull/25476): Automatically choose frontend/backend based on the route metadata
* [26772](https://github.com/civicrm/civicrm-core/pull/26772): Change the test to specifically request backend
Both have issues. So here's a deep-dive into the context.
Background
----------
* CiviCRM runs on Drupal/Backdrop and WordPress/Joomla.
* On WordPress/Joomla, the "frontend" and "backend" are different sub-applications (e.g. `/` vs `/wp-admin/`). The applications have very different URL structures. To make a hyperlink, you first decide which sub-application to target -- and then pick a page within it.
* On Drupal/Backdrop, it's one application, and all URLs have similar structure. To make a hyperlink, you simply identify the page.
* (*Drupal/Backdrop UX can sometimes distinguish frontend/backend -- but it's a visual choice based on local configuration. It's not a structural part of the URL.*)
* CiviCRM's routing system integrates into every UF/CMS, but (internally) it is closer to Drupal's. There is one `civicrm_menu` with all frontend+backend pages.
* On Drupal/Backdrop, CiviCRM's routes pass directly to CMS routes.
* On WordPress/Joomla, CiviCRM's routing integrates with both subapplications (ie "frontend" and "backend").
* CiviCRM stores a flag `bool is_public` for each route.
* CiviCRM includes routes which can be classified as:
* Purely backend (ex: `civicrm/dashboard`)
* Purely frontend (ex: `civicrm/event/register`)
* Purely web-service (ex: `civicrm/payment/ipn`)
* Multi-homed
* Ex: `civicrm/profile/view` has use-cases for frontend and backend
* Ex: `civicrm/ajax/api4/%` has use-cases for frontend, backend, and web-service
* CiviCRM has a function `CRM_Utils_System::url()`
* At first glance, it resembles Drupal's `\url()`. You typically just give the page (e.g. `url('civicrm/foo/bar')`).
* Over time, several additional parameters were added -- notably, the 6th parameter `bool $frontend` and the 7th parameter `bool $forceBackend`.
Problems
--------
* The status-quo invites bugs between CMS's.
* A developer working on Drupal will have trouble recognizing the importance of the 6th and 7th parameters. (*Those params do nothing on Drupal - and they're buried at the end of method.*)
* The status-quo invites bugs between interactive and automatic processes.
* A developer defines a custom token and tests it interactively; then at runtime, the token is sent by an automatic process. But the interactive/automatic split is orthogonal to frontend/backend split. Sometimes, interactive/automatic agree with each other (*both frontend or both backend*), and sometimes they disagree (*one frontend, one backend*).
* Overall, what tends to happen is:
* Developer writes a call like `CRM_Utils_System::url('civicrm/foo/bar')`, and it looks pretty.
* They test, and it works beautifully on their system.
* They publish, and it fails on other systems.
* Someone writes a patch to add 5 more parameters (`url('civicrm/foo/bar', '', FALSE, NULL, TRUE, TRUE)`). And then it's OK.
* The DX is awkward and invites bugs (in core and contrib) -- but it becomes more annoying for `cv` UX.
* If you need a 5th/6th param in PHP code, then you'll eventually figure it out and commit the update to your codebase. Then you forget about it.
* `cv` has some commands to facilitate manual testing and E2E testing (ie `cv url`, `cv http`, `cv open`). These are things that you improvise. Mismatched URLs can be annoying anytime you use these subcommands.
What to do
----------
There are two PRs to fix the test, and honestly - I don't really like either.
* [26772](https://github.com/civicrm/civicrm-core/pull/26772) makes the red mark go away, but it leaves the underlying issue (poor DX for PHP and poor UX for cv).
* [25476](https://github.com/civicrm/civicrm-core/pull/25476) aims to fix the underlying issue, but it's probably too facile. The current metadata can distinguish "purely frontend" pages from "purely backend" pages, but it cannot recognize "purely web-service" or "multi-homed". It probably messes-up some scenarios for those.
* Fixing this probably requires some more aggressive transition in the contract.
* Ex: Improve the routing metadata so that we can distinguish web-service routes and multi-home routes.
* Ex: Define a different class or function for generating URLs (*with a more usable signature*).
* Another option is to leave `civicrm-core` as-is -- and only update `cv`.
* Ex: Give `cv` the mechanism to resolve a frontend/backend based on metadata.
* Ex: Change `cv` to complain if you don't a specify frontend/backend flag.
* Either way, it feels like a bit of a wasted opportunity to only patch `cv` when we know that other users of `CRM_Utils_System::url()` get confused about the frontend/backend flags.https://lab.civicrm.org/dev/core/-/issues/4432Permission system can be bypassed from the search results action menu2023-07-21T09:59:05ZschorschiiPermission system can be bypassed from the search results action menuOverview
----------------------------------------
I created a simple permission structure where a group of CiviCRM users ("Group A") has write access to a group of contacts ("Group B"). (Every logged in user can read all contacts in our ...Overview
----------------------------------------
I created a simple permission structure where a group of CiviCRM users ("Group A") has write access to a group of contacts ("Group B"). (Every logged in user can read all contacts in our system.)
When a contact is now added to "Group B", users of "Group A" see the edit button on the contact and can add/remove the contact to/from groups on the contact detail page. When removing the contact from "Group B", the edit button disappears. So far, everything as expected.
But when using the actions menu from the search results, users can add/remove group assignments of a contact which is not in "Group B".
Isn't this an inconsistency in the permission system? Or am I missing something? How to avoid group membership changes of contacts which are not in "Group B" by users which are in "Group A"?
Reproduction steps
----------------------------------------
1. Create a role, assign it to "Group A" and create ACL "edit" for "Group B".
2. Log in with a non-admin user which is member of "Group A".
3. Search a contact which is not member of "Group B". Select it in the search results and choose "Group - add contact" or "Group - remove contact".
Current behaviour
----------------------------------------
I can change the group membership of this contact from within the action menu of the search result list.
Expected behaviour
----------------------------------------
Group membership changes should be refused since the contact is not member of "Group B".
When opening the contact's detail view, it works as expected, which means I'm not able to change the group memberships there.
Environment information
----------------------------------------
CiviCRM version 5.63.1 under WordPress
[Corresponding question on StackExchange](https://civicrm.stackexchange.com/questions/45266/permission-system-not-working-as-expected)https://lab.civicrm.org/dev/core/-/issues/4431API4: "!=" has unexpected results on NULL fields2023-07-21T09:59:23ZJonGoldAPI4: "!=" has unexpected results on NULL fieldsOverview
----------------------------------------
Using the `!=` operator when some of the values are `NULL` does not return the `NULL` records.
Reproduction steps
----------------------------------------
1. On a demo site (which by def...Overview
----------------------------------------
Using the `!=` operator when some of the values are `NULL` does not return the `NULL` records.
Reproduction steps
----------------------------------------
1. On a demo site (which by default has no contacts with a subtype), search for contacts that are not of subtype "Parent".
E.g.:
```php
\Civi\Api4\Contact::get(TRUE)
->addWhere('contact_sub_type', '!=', 'Parent')
->execute();
```
Current behaviour
----------------------------------------
No results are returned.
Expected behaviour
----------------------------------------
All results are returned, since no record is a Parent.
Comments
----------------------------------------
I thought at some point, `!=` internally generated `!= and IS NOT NULL` but maybe that was somewhere else.
I just learned about the MySQL null-safe equals operator, which would also solve this problem: https://stackoverflow.com/a/44723097/2832108https://lab.civicrm.org/dev/core/-/issues/4430New validation of email not good very bad on the search screen2023-08-08T22:21:52ZeileenNew validation of email not good very bad on the search screen![image](/uploads/c0c27aa7091ebf30a316174f9b1dac23/image.png)
![image](/uploads/d8fb04672fe5e1c6a16857f2c5958769/image.png)![image](/uploads/c0c27aa7091ebf30a316174f9b1dac23/image.png)
![image](/uploads/d8fb04672fe5e1c6a16857f2c5958769/image.png)5.64.0https://lab.civicrm.org/dev/core/-/issues/4429Once you create a Membership price set, with membership options (ie Select) y...2023-08-08T22:21:53ZpetednzOnce you create a Membership price set, with membership options (ie Select) you cannot then add a new Option as the Membership fields are not displayingreplicated on WPMaster
- add price set for memberships
- add a SELECT field so you can set option 1 = Memb X and option 2 = Memb Y
- save
- try to add a new option to the above field, Memb Type and Number of Terms fields are not visiblereplicated on WPMaster
- add price set for memberships
- add a SELECT field so you can set option 1 = Memb X and option 2 = Memb Y
- save
- try to add a new option to the above field, Memb Type and Number of Terms fields are not visible5.64.0https://lab.civicrm.org/dev/core/-/issues/4428Membership Fee token error in automatic membership renewal messages2023-09-24T22:49:30ZbwheelerMembership Fee token error in automatic membership renewal messagesOverview
----------------------------------------
This is related to another issue, https://lab.civicrm.org/dev/core/-/issues/3805 which was posted in https://civicrm.stackexchange.com/questions/42438/error-on-membership-fee-token-when-u...Overview
----------------------------------------
This is related to another issue, https://lab.civicrm.org/dev/core/-/issues/3805 which was posted in https://civicrm.stackexchange.com/questions/42438/error-on-membership-fee-token-when-using-print-merge-document/42443#42443
Reproduction steps
----------------------------------------
The original ticket has these reproduction steps:
I did a short test on the demo sandbox.
Selected "Find Membership" and selected one record. I then choose Print/Merge Document and added 2 tokens, {membership.id} and {membership.fee} Then clicked "Preview" to see the pdf outcome.
If I use only the token {membership.id} I do not get any error message and the preview is created.
Adding {membership.fee} I get the following error message below.
You can also reproduce the issue by creating an automatic membership renewal message with {membership.fee} in it and trying to send the renewal message.
Current behaviour
----------------------------------------
In the current version of Civi, the code will run but it will show 0.00 for the membership fee instead of the actual membership fee.
Expected behaviour
----------------------------------------
It should show the correct membership fee.
We propose fixing this with the following code. This won't match exactly the latest version of Civi because we're working off 5.58.1 but if it looks good, we'll submit a review with the latest version of Civi.
```diff
+++ b/sites/all/modules/civicrm/CRM/Member/Tokens.php
@@ -61,8 +61,17 @@ class CRM_Member_Tokens extends CRM_Core_EntityTokens {
*/
public function evaluateToken(\Civi\Token\TokenRow $row, $entity, $field, $prefetch = NULL) {
if ($field === 'fee') {
- $membershipType = CRM_Member_BAO_MembershipType::getMembershipType($this->getFieldValue($row, 'membership_type_id'));
- $row->tokens($entity, $field, \CRM_Utils_Money::formatLocaleNumericRoundedForDefaultCurrency($membershipType['minimum_fee']));
+ $membershipTypeId = $this->getFieldValue($row, 'membership_type_id');
+ if (empty($membershipTypeId) && isset($row->context['membershipId'])) {
+ $membership = CRM_Member_BAO_Membership::findById($row->context['membershipId']);
+ $membershipTypeId = $membership->membership_type_id;
+ }
+ $membershipType = CRM_Member_BAO_MembershipType::getMembershipType($membershipTypeId);
+ $minimumFee = 0;
+ if ($membershipType) {
+ $minimumFee = $membershipType['minimum_fee'];
+ }
+ $row->tokens($entity, $field, \CRM_Utils_Money::formatLocaleNumericRoundedForDefaultCurrency($minimumFee));
}
```https://lab.civicrm.org/dev/core/-/issues/4427Deleted activities filter no longer working on manage case2023-08-08T22:21:52ZDaveDDeleted activities filter no longer working on manage case1. Delete a case activity.
2. On manage case expand the activity search filters and click the deleted checkbox.
3. Shows the same thing as when unchecked.
The ajax url in both cases has activity_deleted=0
Hmm, deja vu, but in reverse: ...1. Delete a case activity.
2. On manage case expand the activity search filters and click the deleted checkbox.
3. Shows the same thing as when unchecked.
The ajax url in both cases has activity_deleted=0
Hmm, deja vu, but in reverse: https://lab.civicrm.org/dev/core/-/issues/1022. This time the case_id is missing for this field.5.64.0https://lab.civicrm.org/dev/core/-/issues/4426Standalone: currentPath returns null2023-08-20T19:28:14ZbgmStandalone: currentPath returns nullThis is mostly visible when using the language-switcher extension. `CRM_Utils_System::currentPath()` returns NULL, so the extension cannot generate proper URLs. It's presumably going to cause problems elsewhere.
The function does this:...This is mostly visible when using the language-switcher extension. `CRM_Utils_System::currentPath()` returns NULL, so the extension cannot generate proper URLs. It's presumably going to cause problems elsewhere.
The function does this:
```
public static function currentPath() {
$config = CRM_Core_Config::singleton();
return isset($_GET[$config->userFrameworkURLVar]) ? trim($_GET[$config->userFrameworkURLVar], '/') : NULL;
}
```
and when using Standalone, `$config->userFrameworkURLVar` is set to `q` (default value), and `$_GET['q']` is not set.
For Drupal9, we still apply this patch: https://github.com/civicrm/civicrm-core/pull/15267/files (I didn't revive the PR, because apparently we're the only ones having the issue, so maybe it's related to our hosting).5.66.0https://lab.civicrm.org/dev/core/-/issues/4425Standalone: language change does not stick2023-12-02T12:21:46ZbgmStandalone: language change does not stickTo reproduce:
- Administer > System Settings > Extensions: Enable the [update language](https://civicrm.org/extensions/update-language-files) extension, saves time, if you haven't already downloaded the translation files
- Administer > ...To reproduce:
- Administer > System Settings > Extensions: Enable the [update language](https://civicrm.org/extensions/update-language-files) extension, saves time, if you haven't already downloaded the translation files
- Administer > Localization > Languages: Enable two languages (no need for multilingual, just enable a second language)
You should then be able to display pages in different languages, using the `lcMessages=xx_YY` parameter. Ex:
- https://crm.example.org/civicrm?lcMessages=en_US
- https://crm.example.org/civicrm?lcMessages=fr_CA (adapt to the locale you enabled)
This works for a single page. However, CiviCRM should normally save the language in the `$session` object. See `CRM_Core_BAO_ConfigSetting::applyLocale`. It does not seem to be happening.
(I'll try to circle back, just wanted to log my findings so far)5.69.0https://lab.civicrm.org/dev/core/-/issues/4424Breakage with 5.63 moving code to extensions2023-07-27T21:22:32ZeileenBreakage with 5.63 moving code to extensionsWe are hitting a fatal error `Error: Class 'Civi\Api4\FinancialAccount' not found in include()` when we upgrade from 5.61 to 5.64.
The error is happening when it tries to reconcile managed entities because our mgd.php file inc...We are hitting a fatal error `Error: Class 'Civi\Api4\FinancialAccount' not found in include()` when we upgrade from 5.61 to 5.64.
The error is happening when it tries to reconcile managed entities because our mgd.php file includes a call to this api.
The Managed.reconcile is called before `addExtensionTask` resulting in it failing on the former because the latter has not yet run. It then fails to do the latter because it crashed out, although the domain version is correctly udpdated5.64.0https://lab.civicrm.org/dev/core/-/issues/4423Slow contact lookup query in SearchKit2023-07-15T12:58:42ZeileenSlow contact lookup query in SearchKitI think we might be doing something weird when we query for an id in search kit / api4
It takes about 30 seconds to return here - that is what I might expect if I was waiting for it to search without an index (ie a pre-pended wildcard) ...I think we might be doing something weird when we query for an id in search kit / api4
It takes about 30 seconds to return here - that is what I might expect if I was waiting for it to search without an index (ie a pre-pended wildcard) but of course we turned that off using the site setting
![image](/uploads/acb69198d4abda193d10b5e2fd103252/image.png)https://lab.civicrm.org/dev/core/-/issues/4422Is there any reason to save both html and text versions of Inbound Emails?2023-07-13T17:33:27ZlarsssandergreenIs there any reason to save both html and text versions of Inbound Emails?For Email-to-Activity processing, when the email being processed has both html and text versions, both are saved to the details for the activity using the `-ALTERNATIVE ITEM 0-` ... `-ALTERNATIVE ITEM 1-` delimiters (depending on the det...For Email-to-Activity processing, when the email being processed has both html and text versions, both are saved to the details for the activity using the `-ALTERNATIVE ITEM 0-` ... `-ALTERNATIVE ITEM 1-` delimiters (depending on the details of the email, sometimes it seems to fail to recognize that both are present). This is handled while viewing activities (you only get the first version, which is not ideal as it is often the text version), but not in SearchKit.
I don't see any reason to keep two versions of the same email, so my proposal is just to keep the html version if both are present. Simple is better here unless there is some use case for having both.
If there is a need for the text version, perhaps we could add a setting for the mail account that would select text or html if both are present.https://lab.civicrm.org/dev/core/-/issues/4421Scheduled jobs stopped working after an update last week - error in MailingEv...2023-11-23T06:34:09ZTobias KrauseScheduled jobs stopped working after an update last week - error in MailingEventUnsubscribe.phpI realized this morning that the CiviCRM cron job for the scheduled jobs stopped working after we updated last week from CiviCRM 5.61.2 to 5.61.4. Today I updated to the most current version 5.63.1 but the error still exists.
The proble...I realized this morning that the CiviCRM cron job for the scheduled jobs stopped working after we updated last week from CiviCRM 5.61.2 to 5.61.4. Today I updated to the most current version 5.63.1 but the error still exists.
The problem became obvious as the message "Cron job not running" appeared when I logged in this morning (I did not so for the whole last week). When I checked the list of scheduled jobs I found out that the "Bounces fetcher" job run successfully but all the other jobs did not. So I run our cron job task
`/var/www/civi_live/vendor/civicrm/cv/bin/cv api job.execute --user=admin --cwd=/var/www/civi_live/httpdocs`
manually in CLI and got the following error:
```
In MailingEventUnsubscribe.php line 47:
count(): Argument #1 ($value) must be of type Countable|array, null given
```
The following file is the one: vendor/civicrm/civicrm-core/api/v3/MailingEventUnsubscribe.php
Here it is the following code part in the function civicrm_api3_mailing_event_unsubscribe_create:
```
$groups = CRM_Mailing_Event_BAO_MailingEventUnsubscribe::unsub_from_mailing($job, $queue, $hash);
if (count($groups)) {
CRM_Mailing_Event_BAO_MailingEventUnsubscribe::send_unsub_response($queue, $groups, FALSE, $job);
return civicrm_api3_create_success($params);
}
```
CRM_Mailing_Event_BAO_MailingEventUnsubscribe::unsub_from_mailing can return an array or NULL. I am not sure why this error appeared after the last update as neither CRM_Mailing_Event_BAO_MailingEventUnsubscribe::unsub_from_mailing nor civicrm_api3_mailing_event_unsubscribe_create() has changed but it may be related to some other changes somewhere.
When I change this code part to the following the scheduled jobs are finished:
```
$groups = CRM_Mailing_Event_BAO_MailingEventUnsubscribe::unsub_from_mailing($job, $queue, $hash);
if ($groups && count($groups)) {
CRM_Mailing_Event_BAO_MailingEventUnsubscribe::send_unsub_response($queue, $groups, FALSE, $job);
return civicrm_api3_create_success($params);
}
```https://lab.civicrm.org/dev/civicrm-asset-plugin/-/issues/23Scheduled jobs stopped working after an update last week - error in MailingEv...2023-07-10T09:24:27ZTobias KrauseScheduled jobs stopped working after an update last week - error in MailingEventUnsubscribe.phpI realized this morning that the CiviCRM cron job for the scheduled jobs stopped working after we updated last week from CiviCRM 5.61.2 to 5.61.4. Today I updated to the most current version 5.63.1 but the error still exists.
The proble...I realized this morning that the CiviCRM cron job for the scheduled jobs stopped working after we updated last week from CiviCRM 5.61.2 to 5.61.4. Today I updated to the most current version 5.63.1 but the error still exists.
The problem became obvious as the message "Cron job not running" appeared when I logged in this morning (I did not so for the whole last week). When I checked the list of scheduled jobs I found out that the "Bounces fetcher" job run successfully but all the other jobs did not. So I run our cron job task
`/var/www/civi_live/vendor/civicrm/cv/bin/cv api job.execute --user=admin --cwd=/var/www/civi_live/httpdocs`
manually in CLI and got the following error:
```
In MailingEventUnsubscribe.php line 47:
count(): Argument #1 ($value) must be of type Countable|array, null given
```
The following file is the one: vendor/civicrm/civicrm-core/api/v3/MailingEventUnsubscribe.php
Here it is the following code part in the function civicrm_api3_mailing_event_unsubscribe_create:
```
$groups = CRM_Mailing_Event_BAO_MailingEventUnsubscribe::unsub_from_mailing($job, $queue, $hash);
if (count($groups)) {
CRM_Mailing_Event_BAO_MailingEventUnsubscribe::send_unsub_response($queue, $groups, FALSE, $job);
return civicrm_api3_create_success($params);
}
```
CRM_Mailing_Event_BAO_MailingEventUnsubscribe::unsub_from_mailing can return an array or NULL. I am not sure why this error appeared after the last update as neither CRM_Mailing_Event_BAO_MailingEventUnsubscribe::unsub_from_mailing nor civicrm_api3_mailing_event_unsubscribe_create() has changed but it may be related to some other changes somewhere.
When I change this code part to the following the scheduled jobs are finished:
```
$groups = CRM_Mailing_Event_BAO_MailingEventUnsubscribe::unsub_from_mailing($job, $queue, $hash);
if ($groups && count($groups)) {
CRM_Mailing_Event_BAO_MailingEventUnsubscribe::send_unsub_response($queue, $groups, FALSE, $job);
return civicrm_api3_create_success($params);
}
```https://lab.civicrm.org/dev/core/-/issues/4420crmDate support for Date Preferences2023-07-10T06:21:42ZlarsssandergreencrmDate support for Date Preferences[crmDate](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Smarty/plugins/modifier.crmDate.php) only supports Date Formats, not the confusingly separate Date Preferences, which include creditCard format. It would be nice to b...[crmDate](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Smarty/plugins/modifier.crmDate.php) only supports Date Formats, not the confusingly separate Date Preferences, which include creditCard format. It would be nice to be able to use `crmDate:'creditCard'` on Contribution Page Review and Thank You pages, etc.
Or maybe we should use tokens for credit_card_expiration_date instead, @DaveD thinks they support the Preferences.https://lab.civicrm.org/dev/core/-/issues/4419Membership tab on contribution page config broken2023-08-08T22:21:51ZDaveDMembership tab on contribution page config brokenI'm not sure of the details yet but `TypeError: Cannot access offset of type string on string in include() (line 95 of .../templates_c/en_US/%%B4/B40/B407902D%%MembershipBlock.tpl.php)`I'm not sure of the details yet but `TypeError: Cannot access offset of type string on string in include() (line 95 of .../templates_c/en_US/%%B4/B40/B407902D%%MembershipBlock.tpl.php)`5.63.1https://lab.civicrm.org/dev/core/-/issues/4418Accepted credit cards not saved when creating or editing a payment processor2023-08-08T22:21:51ZlarsssandergreenAccepted credit cards not saved when creating or editing a payment processor[This change](https://github.com/civicrm/civicrm-core/pull/25873/commits/df3b3799337a18ef22e059681ca36784d66f0f1b) in 5.61 makes it so that if you create or save a payment processor, accepted_credit_cards is not saved correctly. The prob...[This change](https://github.com/civicrm/civicrm-core/pull/25873/commits/df3b3799337a18ef22e059681ca36784d66f0f1b) in 5.61 makes it so that if you create or save a payment processor, accepted_credit_cards is not saved correctly. The problem is that the save was changed to API 4, which doesn't [properly handle JSON](https://lab.civicrm.org/dev/core/-/issues/4417) and accepted_credit_cards is one of the few JSON fields we have.
I think for now, we should just go back to API 3 and then we can switch back to API 4 when the JSON issue is resolved.