Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-06-09T18:39:49Zhttps://lab.civicrm.org/dev/core/-/issues/4336Payment on Event Confirmation Page: Does not work when pay later is disabled2023-06-09T18:39:49ZlarsssandergreenPayment on Event Confirmation Page: Does not work when pay later is disabledGreat to have this functionality!
_This has been updated after the fixes in PR 26491._
_There are two cases: 1) with pay later or 2) without pay later._
**If pay later is enabled**, it seems to work as intended, but the pay later inst...Great to have this functionality!
_This has been updated after the fixes in PR 26491._
_There are two cases: 1) with pay later or 2) without pay later._
**If pay later is enabled**, it seems to work as intended, but the pay later instructions are displayed on the payment/confirmation page (they should never be as the user hasn't selected a payment method yet) and on the Thank You page even if they selected another payment method (see screenshots below).
Updated: After submitting, the contribution is created, but it is set to pending (pay later) and no payment is present.
With pay later enabled, it looks like $is_pay_later is always true.
On payment/confirmation:
![image](/uploads/1c406bf9b01bcaa4a430f3d720b5bf7f/image.png)
On Thank You after selecting a payment method that isn't pay later:
![image](/uploads/e2630c45369dbf975ad340c83339b7ec/image.png)
**Without pay later:**
On the payment/confirmation page, something isn't loading right because these billings fields should be filled in and there shouldn't be a card type select:
<img src="/uploads/546c468287908dc976a3e47a73192aed/image.png" width=400>
On submit, we get an error:
` [error] Payment processor exception: Error Unexpected Server Error, please see your logs `
```
[info] $iATS SOAP Response = stdClass Object
(
[ProcessCreditCardResult] => stdClass Object
(
[any] => FailureObject reference not set to an instance of an object.
)
)
```
Fixed:
~~On the first page, with pay later disabled, we get divs that shouldn't be there:~~
<img src="/uploads/cb6e5ac305cc947cb404206fecc5899d/image.png" width=400>https://lab.civicrm.org/dev/core/-/issues/4335Create User Record systematically create an account with just the e-mail address2023-06-26T13:28:47ZolivierCreate User Record systematically create an account with just the e-mail addressOverview
----------------------------------------
Create User Record (civicrm/contact/view/useradd?reset=1&action=add&cid=xxxx)
![image](/uploads/4ce580a31d1c0f9f3d30548e245e8a12/image.png)
don't find existing contact, and create a new ...Overview
----------------------------------------
Create User Record (civicrm/contact/view/useradd?reset=1&action=add&cid=xxxx)
![image](/uploads/4ce580a31d1c0f9f3d30548e245e8a12/image.png)
don't find existing contact, and create a new one with only email adress of the existing contact
Reproduction steps
----------------------------------------
1. On view contact, click **Actions** and **Create User Record**
2. Complete form with username and password, then validate
3. Search contact with the same email address than the existing contact
- You will find the existing contact, and a new one
- UFid is set on the new account
Expected behaviour
----------------------------------------
UFid should be set to existing account, and no new one should be created
Environment information
----------------------------------------
* __CiviCRM:__ 5.61.4 and the problem must have existed for quite a few previous versions
* __PHP:__ 8.1.15
* __CMS:__ Drupal 9.5.9
* __Database:__ MariaDB 10.5.16
* __Web Server:__ Apache/2.4.53
Comments
----------------------------------------
It seems to me that the problem lies in UFMatch.php, in the synchronizeUFMatch() function, which doesn't retrieve the contact_id if it exists.
As a workaround, I propose replacing lines 252 and 253
```
$contactID = civicrm_api3('Contact', 'create', $contactParameters)['id'];
$ufmatch->contact_id = $contactID;
```
with
```
// If contactID exist, user exist and use it
if (isset($dedupeParameters['contact_id'])) {
$ufmatch->contact_id = $dedupeParameters['contact_id'];
}
else {
// Conatct does not exist, so create a new one
$contactID = civicrm_api3('Contact', 'create', $contactParameters)['id'];
$ufmatch->contact_id = $contactID;
}
```5.63.0https://lab.civicrm.org/dev/core/-/issues/4334Remove Event Info link from Manage Event (and same from Manage Contribution P...2023-06-21T14:55:10ZlarsssandergreenRemove Event Info link from Manage Event (and same from Manage Contribution Page)![image](/uploads/dd822bae24450b2001a604f392198a89/image.png)
I'm not sure this is needed, since it just replicates the link available in the Event Links above, except less completely, as it doesn't include Online Registration, so users...![image](/uploads/dd822bae24450b2001a604f392198a89/image.png)
I'm not sure this is needed, since it just replicates the link available in the Event Links above, except less completely, as it doesn't include Online Registration, so users tend to think this is the only option (some organizations do not use Event Info, preferring to link straight to Registration).
There is a similar thing at the bottom of the first Manage Contribution Page tab that could also be removed, in my opinion. These look kind of weird and aren't really necessary, so I think they can go without losing anything, but am looking for further opinions on this.https://lab.civicrm.org/dev/core/-/issues/4333Attachment uploader information is missing in case attachments2023-06-04T15:14:55Zahed_compucorpAttachment uploader information is missing in case attachmentsOverview
----------------------------------------
The Case attachments don't have the uploader information. The `created_id` is not supposed to be empty regardless of how you uploaded the attachments i.e. when creating new cases or creat...Overview
----------------------------------------
The Case attachments don't have the uploader information. The `created_id` is not supposed to be empty regardless of how you uploaded the attachments i.e. when creating new cases or creating/editing the related activities.
For the records, the `created_id` field was added in the [#11739](https://github.com/civicrm/civicrm-core/pull/11739) PR / [#CRM-19948](https://issues.civicrm.org/jira/browse/CRM-19948) issue, but they didn't consider the case attachments scenario.
Reproduction steps
----------------------------------------
![attachment-uploader-issuee](/uploads/4e0b28319155ed0b34e477a1a7e793ac/uploader-issue.mp4)
1. Click on **Cases -> New Case**.
2. Under Attachments, upload a file and click **Save**.
3. In the case details page, click on any activity.
4. Under Attachments, upload a file and click **Save**.
Current behaviour
----------------------------------------
Files uploaded in steps two and four, don't have the uploader information i.e. the created_id value is empty.
Expected behaviour
----------------------------------------
Files uploaded in steps two and four should have the uploader information.
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.61.0/.../5.3.0 (since adding the [created_id field/feature](https://github.com/civicrm/civicrm-core/pull/11739/commits/ae2c7e000bf9548adbf8afd355d2127b0030e670))_
Proposed Solution
----------------------------------------
In the old [#11739](https://github.com/civicrm/civicrm-core/pull/11739) PR, it uses the current logged-in `$contact_id` for the created_id field when calling the method [create](https://github.com/civicrm/civicrm-core/blob/5.61.0/CRM/Core/BAO/File.php#L50):
```php
/**
* BAO object for crm_log table
*/
class CRM_Core_BAO_File extends CRM_Core_DAO_File {
...
public static function create($params) {
$fileDAO = new CRM_Core_DAO_File();
...
if (empty($params['id']) && empty($params['created_id'])) {
$fileDAO->created_id = CRM_Core_Session::getLoggedInContactID();
}
```
For case attachments, another method is called to create the File which is [filePostProcess](https://github.com/civicrm/civicrm-core/blob/5.61.0/CRM/Core/BAO/File.php#L100) :
```php
public static function filePostProcess(...) {
...
$fileDAO = new CRM_Core_DAO_File();
$op = 'create';
if (isset($dao->cfID) && $dao->cfID) {
$op = 'edit';
$fileDAO->id = $dao->cfID;
unlink($directoryName . DIRECTORY_SEPARATOR . $dao->uri);
}
if (!empty($fileParams)) {
$fileDAO->copyValues($fileParams);
}
```
The proposed solution is to set the `$created_id` inside the [filePostProcess](https://github.com/civicrm/civicrm-core/blob/5.61.0/CRM/Core/BAO/File.php#L100) method :
```diff
$fileDAO = new CRM_Core_DAO_File();
$op = 'create';
if (isset($dao->cfID) && $dao->cfID) {
$op = 'edit';
$fileDAO->id = $dao->cfID;
unlink($directoryName . DIRECTORY_SEPARATOR . $dao->uri);
}
+ else if (empty($fileParams['created_id'])) {
+ $fileDAO->created_id = CRM_Core_Session::getLoggedInContactID();
+ }
```
I've created the PR https://github.com/civicrm/civicrm-core/pull/26409 to check the proposed solution.5.63.0https://lab.civicrm.org/dev/core/-/issues/4332Error in membership status after a) changing membership type followed by b) p...2023-11-23T07:23:38ZJoeMurrayError in membership status after a) changing membership type followed by b) payment failure## Overview
Using a pay later payment when renewing a membership can lead to problems with the membership status, membership end date and membership type being changed at the time of the renewal being initiated ; these fields are update...## Overview
Using a pay later payment when renewing a membership can lead to problems with the membership status, membership end date and membership type being changed at the time of the renewal being initiated ; these fields are updated without a payment being recorded. It is possible that a payment will never be received, or its processing may fail. It is not easy to revert the data to its former state, or what it would have become through time from date of update to when the correction is attempted. For example, a renewal with a delayed payment might change the status from Grace to Current, the End Date from May 14, 2023 to May 14, 2024, and the Membership Type from General to Student.
These are very old problems dating to at least 2013 I believe.
The problem only occurs when both membership types have the same parent organization, and only for paid memberships. It occurs whether the membership period is Rolling or Fixed, and whether a membership type is being changed or not.
## Proposal
Refactor the current implementation so that a second, temporary membership is created that can store the new information without overwriting the old information until a payment is received for it. The new temporary membership would have a status of Pending. The Pending contribution would be related to the temporary rather than existing membership. When the payment is received (status=complete), the Pending membership's information is used to update the permanent membership, and the temporary membership record is deleted.
## Relevant code
In the Contribution Confirmation page postProcess call [legacyProcessMembership](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Confirm.php#L1623), various fields are updated before the doPayment call is processed [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Confirm.php#LL1702C42-L1702C51). As a result, the existing membership record is updated with selected membership type/end date/status after user submits a payment but before the code makes payment request, e.g. to a payment processor. This works if the payment went successfully.
In the case of a payment failure such as for IPN payment processors like Paypal Standard (occasionally when there is a delay on getting IPN callback or if the IPN response is not handled properly like https://lab.civicrm.org/dev/core/-/issues/1931) or for a manual Pay Later payment that isn't received, it leaves the selected membership in current/active state with a changed end date and possibly a different membership type. There is no fallback code written to revert the membership state or set it to Pending, and it isn't easy to reconstruct the data.
## New Behaviour
1. When initiating the Payment for Membership Renewal, create a new membership record and link the contribution in pending status to it. Add a new field, renewing_membership_id, to civicrm_membership to hold a reference from this 'temporary' pending membership to the existing membership that is being renewed. The existing membership record remains unchanged.
2. When the contribution status of the related contribution changes to Complete, update the original membership with the information from the temporary membership and delete the temporary membership.
Recommendation: delay the creation of activities for Membership Renewal (id=8), Change Membership Status (id=35) and Change Membership Type (id=36) until the contribution is completed.
Recommendation: create a new Activity Type, Membership Renewal Pending, to be created when the renewal request is received. In its body, provide: "ID of Membership being renewed: xx, Number of Periods: yy, Membership Type: [Label of Membership Type".
## Implementation:
1. Modify [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Confirm.php#L2900), CRM_Member_BAO_Membership::getContactMembership and [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Confirm.php#L2939).
2. Add / update new / existing unit tests on these new scenarios.EdselopezEdselopezhttps://lab.civicrm.org/dev/core/-/issues/4331SearchKit: Adjusting page size does not adjust number of rows2023-06-01T18:10:50ZlarsssandergreenSearchKit: Adjusting page size does not adjust number of rowsOverview
----------------------------------------
Adjust the page size for a Search Display doesn't change the number of rows shown.
Reproduction steps
----------------------------------------
1. Edit a Search Display.
2. Show Pager
3. ...Overview
----------------------------------------
Adjust the page size for a Search Display doesn't change the number of rows shown.
Reproduction steps
----------------------------------------
1. Edit a Search Display.
2. Show Pager
3. Change Pager to a number less than the number of rows
Current behaviour
----------------------------------------
Number of rows show is not changed. Pager itself is adjusted, but the actual table is not.
Expected behaviour
----------------------------------------
Number of rows shown should be changed.
Environment information
----------------------------------------
masterhttps://lab.civicrm.org/dev/core/-/issues/4330API4 error "Column in order clause is ambiguous"2023-06-07T00:21:50ZsamuelsovAPI4 error "Column in order clause is ambiguous"I have a specific query that used to work but seems to be broken since around CiviCRM 5.60.
I was able to reproduced in master.
This is the api4 call:
```php
$addresses = \Civi\Api4\Address::get()
->addJoin('Contact AS contact', 'LEF...I have a specific query that used to work but seems to be broken since around CiviCRM 5.60.
I was able to reproduced in master.
This is the api4 call:
```php
$addresses = \Civi\Api4\Address::get()
->addJoin('Contact AS contact', 'LEFT', ['master_id.contact_id', '=', 'contact.id'])
->addOrderBy('location_type_id:label', 'ASC')
->setLimit(25)
->execute();
```
`location_type_id` is in Address and as it it doing a join for another address to get the master_id address, it is ambiguous.
Looking at the generated query, we can see that the table prefix is not added in the order by :
```sql
SELECT `a`.`id` AS `id`, `contact`.`display_name` AS `contact.display_name`
FROM civicrm_address a
LEFT JOIN `civicrm_address` `master_id_1` ON `a`.`master_id` = `master_id_1`.`id`
LEFT JOIN `civicrm_contact` `contact` ON `master_id_1`.`contact_id` = `contact`.`id`
ORDER BY FIELD(`location_type_id`,'16','14','1','19','3','15','4','12','2','17','18','20','21','5','11') ASC;
```
Giving the error :
```
ERROR 1052 (23000): Column 'location_type_id' in order clause is ambiguous
```https://lab.civicrm.org/dev/core/-/issues/4329description is wrong for permission to view notes that are marked for author ...2023-06-05T05:06:28Ztpokorradescription is wrong for permission to view notes that are marked for author onlyOverview
----------------------------------------
I am wondering if the label in https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Permission.php#LL785C46-L785C46 is correct.
It is about the permission for viewing all notes. I...Overview
----------------------------------------
I am wondering if the label in https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Permission.php#LL785C46-L785C46 is correct.
It is about the permission for viewing all notes. It says: "even if they're marked admin only", but I would expect: "even if they're marked author only".
according to https://github.com/civicrm/civicrm-core/blob/master/sql/civicrm_data/civicrm_option_group/note_privacy.sqldata.php#L17
see https://chat.civicrm.org/civicrm/pl/ye4bu5w87b81mennu3at5ifcrr
Reproduction steps
----------------------------------------
1. Go to User Permissions in Drupal (/admin/people/permissions)
1. See the permission "CiviCRM: view all notes"
Current behaviour
----------------------------------------
The description says: View notes (for visible contacts) even if they're marked admin only
Expected behaviour
----------------------------------------
The description should say: View notes (for visible contacts) even if they're marked author only
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.60.0_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _8.1__
* __CMS:__ Drupal 9.8.5_
Comments
----------------------------------------
see the labels for the options for the notes: None or Author only.
https://github.com/civicrm/civicrm-core/blob/master/sql/civicrm_data/civicrm_option_group/note_privacy.sqldata.php#L17
There is nothing about "admin only"5.63.0https://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/4327GroupTest occasionally failing due to new test2023-06-12T22:23:38ZlarsssandergreenGroupTest occasionally failing due to new testI've noted a [test failure here](https://github.com/civicrm/civicrm-core/blob/40728fa72022780372b2728315e323a55cab76bf/tests/phpunit/api/v4/Entity/GroupTest.php#L234) a couple times over the last few days, e.g. [here](https://test.civicr...I've noted a [test failure here](https://github.com/civicrm/civicrm-core/blob/40728fa72022780372b2728315e323a55cab76bf/tests/phpunit/api/v4/Entity/GroupTest.php#L234) a couple times over the last few days, e.g. [here](https://test.civicrm.org/job/CiviCRM-Core-Matrix-PR/2442/) or [here](https://test.civicrm.org/job/CiviCRM-Core-Matrix-PR/2434/). It looks like the two child groups get flipped sometimes.
This was just added a [few days ago](https://github.com/civicrm/civicrm-core/commit/187159263745660bac548b5cf2b5d30e1b8b9412), so tagging @colemanw.https://lab.civicrm.org/dev/core/-/issues/4326Notice errors on backoffice event registration2023-06-09T23:38:52ZJoeMurrayNotice errors on backoffice event registrationOverview
----------------------------------------
_Register a participant in backoffice. See notice errors._
Reproduction steps
----------------------------------------
1. On dmaster, click on **Events -> Register Event Participant**.
1...Overview
----------------------------------------
_Register a participant in backoffice. See notice errors._
Reproduction steps
----------------------------------------
1. On dmaster, click on **Events -> Register Event Participant**.
1. Select a contact, event fall fundraiser dinner, click **Save**.
1. Get three copies for different line numbers of "Notice: Trying to get property '_id' of non-object in CRM_Event_Form_Participant::formRule()".
Current behaviour
----------------------------------------
![2023-05-31_12-59-37](/uploads/b2ec1cad1728b29ecc09742cd557d759/2023-05-31_12-59-37.png)
```
Notice: Trying to get property '_id' of non-object in CRM_Event_Form_Participant::formRule() (line 825 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Event/Form/Participant.php).
Notice: Trying to get property '_id' of non-object in CRM_Event_Form_Participant::formRule() (line 828 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Event/Form/Participant.php).
Notice: Trying to get property '_action' of non-object in CRM_Event_Form_Participant::formRule() (line 836 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Event/Form/Participant.php).
```
Note: happens when recording payment and when not recording payment.
Expected behaviour
----------------------------------------
_No notice errors_
Environment information
----------------------------------------
dmaster
Comments
----------------------------------------
_Anything else you would like the reviewer to note._5.63.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/4325Extra `<br>` tags inserted into rich text fields2023-06-01T13:38:11ZdtwExtra `<br>` tags inserted into rich text fieldsOverview
----------------------------------------
Extra `<br>` tags being inserted between HTML elements in rich-text fields, including between list items! And two being inserted between paragraphs. The html is clean in the editor, but t...Overview
----------------------------------------
Extra `<br>` tags being inserted between HTML elements in rich-text fields, including between list items! And two being inserted between paragraphs. The html is clean in the editor, but this is how it's being rendered on the front-end.
https://civicrm.stackexchange.com/questions/31535/br-tags-inserted-in-rich-text-fields-custom-fieldsets-when-displayed-as-tabs
Reproduction steps
----------------------------------------
"I added a custom field set to contacts, which I set to appear in a tab, then a 'note' type field and set it to be rich text. On a contact record, I added a couple of paragraphs (by hitting return between them) - looks good on the backend, but 2 x `<br>` tags between each `<p>` appearing on the front-end."
Current behaviour
----------------------------------------
Extra `<br>` tags are added
![CiviCRM_Screenshot_2023-05-31_152744](/uploads/7d62b59e050c00c5b9405a2268685eaf/CiviCRM_Screenshot_2023-05-31_152744.png)
![CiviCRM_Screenshot_2023-05-31_152938](/uploads/182e333899f70faa9405c5fe64e154e8/CiviCRM_Screenshot_2023-05-31_152938.png)
Maybe related to this change: https://issues.civicrm.org/jira/browse/CRM-11598
Expected behaviour
----------------------------------------
Extra `<br>` tags should not be added. Spacing should be handled with CSS.
Comments
----------------------------------------
_Anything else you would like the reviewer to note._5.63.0https://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/4323Date is incorrect when editing a contribution2023-11-09T19:36:12ZJDrueryDate is incorrect when editing a contributionWhen editing a contribution, Date Received is always set 05/30/2013 in the edit dialog. Under Payment Details, the date is correct (see first and second images below). When adding a new date in the Edit Contribution dialog, the popup cal...When editing a contribution, Date Received is always set 05/30/2013 in the edit dialog. Under Payment Details, the date is correct (see first and second images below). When adding a new date in the Edit Contribution dialog, the popup calendar always defaults to May of 2013. The year selector doesn't allow selecting anything after 2013 (third and fourth images).
A workaround is to change Date Preferences for activityDateTime. Changing the end offset from the default setting of 10 to 0 allows for dates up to the current year. I suspect this bug is caused by the end offset being interpreted as number of years before the current year, instead of number of years after the current year. Setting the end offset to -10 has the same effect as setting it to +10 (only dates 10 years before the current year are allowed).
![image](/uploads/68cdb261f247a35c092d34cab44e8f52/image.png)
![image](/uploads/501943aeba9f96ff61e9a0cd5c7449d5/image.png)
![image](/uploads/cba0d6b5a42f2b81ec28cd8e77890062/image.png)
![image](/uploads/d4d9340b4c377ef828a4a4cadf3a09ac/image.png)5.66.0https://lab.civicrm.org/dev/core/-/issues/4322Smart groups in group tab for contact too slow2023-05-31T08:18:14ZyashodhaSmart groups in group tab for contact too slowSmart groups in group tab for contact too slow. This should be optimized.Smart groups in group tab for contact too slow. This should be optimized.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4321Mailing Report link on Contact Mailings broken for A/B tests2023-05-30T22:22:24ZlarsssandergreenMailing Report link on Contact Mailings broken for A/B testsOverview
----------------------------------------
If you try to view a Mailing Report for an A/B Mailing from the Contact Mailings tab, you get unknown path instead of the mailing report. See [chat discussion here](https://chat.civicrm.o...Overview
----------------------------------------
If you try to view a Mailing Report for an A/B Mailing from the Contact Mailings tab, you get unknown path instead of the mailing report. See [chat discussion here](https://chat.civicrm.org/civicrm/pl/5rsi3a9y67dozbc8gzzmt71eic). The issue is that there is a [redirect](https://github.com/civicrm/civicrm-core/blob/cf6c1ffdcb96f45743752e451345140bdcfd7305/CRM/Mailing/Page/Report.php#L86) when the mailing report is an A/B test and that redirect does not work through [crmApp.js](https://github.com/civicrm/civicrm-core/blob/master/ang/crmApp.js) because it changes the $location, which does not work in a modal.
Reproduction steps
----------------------------------------
1. Enable Mailings for Viewing Contacts on Admin - Customize Data and Screens - Display Preferences.
1. Click Mailing Report beside an A/B test mailing on the Mailings tab on a Contact
1. Pop up says unknown path, no mailing report
Comments
----------------------------------------
Would be happy to do some work on fixing this, but I'm not sure what the approach would be.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/4319SearchKit + FormBuilder: In place edit using a list view2023-06-22T14:15:45Zsimon.hermannSearchKit + FormBuilder: In place edit using a list viewOverview
----------------------------------------
I was trying to embed a list view of a SearchKit in FormBuilder, where some of the entries have 'in-place edit' activated. When looking at the Afform I am able to click on those entries a...Overview
----------------------------------------
I was trying to embed a list view of a SearchKit in FormBuilder, where some of the entries have 'in-place edit' activated. When looking at the Afform I am able to click on those entries and the the green checkmark as well as the red X appear, however I am not able to edit the content of the entry.
Reproduction steps
----------------------------------------
1. Create a SearchKit with a list view
1. Activate the option 'in-place edit' for some of the entries.
1. Embed the list view in a Afform.
Current behaviour
----------------------------------------
The entries with 'in-place edit' are clickable and the green checkmark as well as the red X are showing. However, the input is shown but cannot be altered.
Expected behaviour
----------------------------------------
The input is shown and I can edit it.
Environment information
----------------------------------------
* __CiviCRM:__ 5.58.1 and 5.60
* __PHP:__ 7.4 and 8.1
* __CMS:__ WordPress 6.1.3https://lab.civicrm.org/dev/core/-/issues/4318Contributions sometimes lack line items, leads to fatal error upon "Download ...2023-06-21T00:11:44ZAllenShawContributions sometimes lack line items, leads to fatal error upon "Download Invoice"Originally reported at https://civicrm.stackexchange.com/questions/44907/contribution-has-no-line-items-shouldnt-that-be-impossible
**Problem and observation:**
On several sites I have found contributions which have no line items -- th...Originally reported at https://civicrm.stackexchange.com/questions/44907/contribution-has-no-line-items-shouldnt-that-be-impossible
**Problem and observation:**
On several sites I have found contributions which have no line items -- that is, rows in civicrm_contribution that have no corresponding rows in civicrm_line_item.
![no-line-items](/uploads/0f3958d00084586a43d7c04419a29ab7/no-line-items.png)
Responses at the above-linked SE question indicate that this is not normal.
This situation leads to a fatal error ("Return value of CRM_Financial_BAO_Order::getPriceSetID() must be of the type int, null returned") when attempting to generate a PDF invoice with "Download Invoice" for the given contribution, apparently on the assumption that this situation is not expected by core code.
**Detecting ffected sites:**
I've observed this on several sites (all currently running CiviCRM 5.58.1 but all having existed much longer), including one local dev site that sees relatively light usage.
This SQL query identifies contributions lacking line items:
```
SELECT count(*)
FROM
civicrm_contribution ctr
left join civicrm_line_item li on li.contribution_id = ctr.id
where li.id is null;
```
**Unable to repro:**
I'm unable to reproduce this situation at will, except by manually deleting rows in civicrm_line_item via API or SQL. It seems any contribution record will, by design, have at least one line_item, even if using a quick-config contribution instead of a visible price set, or if manually creating even a zero-dollar contribution in the back-end.
**Moving forward:**
Until we have a solid set of steps to repro, I'm not sure there's much we can do here. Hopefully this issue can serve as a place for others to share their findings (and hopefully we'll get to some repro steps at some point).https://lab.civicrm.org/dev/core/-/issues/4317Import contribution fails with custom fields2023-07-05T23:48:39ZPhilipp MichaelImport contribution fails with custom fieldsOverview
----------------------------------------
When importing contributions with field mappings to a custom field, the process fails after continuing from step 2 of 3.
Reproduction steps
----------------------------------------
1. Cl...Overview
----------------------------------------
When importing contributions with field mappings to a custom field, the process fails after continuing from step 2 of 3.
Reproduction steps
----------------------------------------
1. Click on **Contributions -> Import Contributions**.
1. Choose mandotory options and continue to step 2.
1. In "Matching CiviCRM Field" choose at least one custom field and try to continue to step 3
1. Got an error "**TypeError: CRM_Import_Parser::getFieldMetadata(): Return value must be of type array, null returned**".
Current behavior
----------------------------------------
Regardless of the provided CSV data, the process fails with:
```
TypeError: CRM_Import_Parser::getFieldMetadata(): Return value must be of type array, null returned in CRM_Import_Parser->getFieldMetadata() (line 1768 of /var/www/html/vendor/civicrm/civicrm-core/CRM/Import/Parser.php).
CRM_Import_Parser->getFieldMetadata('Zu_belastendes_Konto.nur_anstehende_Zuwendungen._IBAN') (Line: 165)
CRM_Contribute_Import_Parser_Contribution->getMappedRow(Array) (Line: 221)
CRM_Contribute_Import_Parser_Contribution->validateValues(Array) (Line: 2551)
CRM_Import_Parser->validateRow(Array) (Line: 1842)
CRM_Import_Parser->validate() (Line: 90)
CRM_Import_Form_MapField->postProcess() (Line: 612)
CRM_Core_Form->mainProcess() (Line: 144)
CRM_Core_StateMachine->perform(Object, 'next', 'Next') (Line: 43)
CRM_Core_QuickForm_Action_Next->perform(Object, 'next') (Line: 203)
HTML_QuickForm_Controller->handle(Object, 'next') (Line: 103)
HTML_QuickForm_Page->handle('next') (Line: 355)
CRM_Core_Controller->run(Array, NULL) (Line: 319)
CRM_Core_Invoke::runItem(Array) (Line: 69)
CRM_Core_Invoke::_invoke(Array) (Line: 36)
CRM_Core_Invoke::invoke(Array) (Line: 88)
Drupal\civicrm\Civicrm->invoke(Array) (Line: 83)
Drupal\civicrm\Controller\CivicrmController->main(Array, '')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 169)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
```
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.60/5.62/5.64_
* __PHP:__ _8.0_
* __CMS:__ _Drupal 9.5.9_
* __Database:__ _MariaDB 10.4.28_
Comments
----------------------------------------
I've tested latest versions and can reproduce it in 5.60 and later. It was probably caused with changes in [Update Contribution Import to use apiv4 field names, prior to adding hooks](https://github.com/civicrm/civicrm-core/pull/25886). The way of getting custom fields available for import has changed, which leads to different field keys respectively option values. Previously you got the short version "custom_xy", now you get a long database field name like one.
5.59:
![mapping-custom-fields-options-5.59](/uploads/e4f4adc83357fd0c3e7613b6f92d5bb2/mapping-custom-fields-options-5.59.png)
5.60 (and 5.62, 5.64):
![mapping-custom-fields-options-5.62](/uploads/d0f7573c8f279bc53c794949d3183ea9/mapping-custom-fields-options-5.62.png)
The import parser can't find related field meta data regarding to those keys.
I'm not sure, if those key names provided by the API are intended and therefor can't provide a PR.5.63.0