Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-06-11T15:47:08Zhttps://lab.civicrm.org/dev/core/-/issues/3485Installer - CiviGrant option no longer works2022-06-11T15:47:08ZtottenInstaller - CiviGrant option no longer worksOverview
----------------------------------------
When performing a web-based installation on Drupal or WordPress, it presents a list of components that you can toggle. One option no longer works correctly.
Reproduction steps
---------...Overview
----------------------------------------
When performing a web-based installation on Drupal or WordPress, it presents a list of components that you can toggle. One option no longer works correctly.
Reproduction steps
----------------------------------------
1. Create an empty D7/BD/WP site
2. Enable CiviCRM
3. In the status alert, click the link to `civicrm/setup`
4. Enable the CiviGrant option
5. Proceed with install
Current behaviour
----------------------------------------
CiviGrant is not activated
Expected behaviour
----------------------------------------
Activate CiviGrant extension
Or: Don't present the option
Environment information
----------------------------------------
Hydra site for WP: http://site-list.test-1.civicrm.org:8001/?filter=hydra-* (http://hydra-wp.test-1.civicrm.org:8002/)
Comments
----------------------------------------
I noticed this while trying the 5.50 installer, but it probably regressed circa 5.48.
The installer currently presents a list of components (https://github.com/civicrm/civicrm-core/blob/master/setup/plugins/blocks/components.civi-setup.php) and populates `$e->getModel()->components`.
To configurably toggle extensions during install, it needs to update `$e->getModel()->extensions`.
https://github.com/civicrm/civicrm-core/blob/master/setup/src/Setup/Model.php#L42-L455.51.0https://lab.civicrm.org/dev/core/-/issues/3465CiviCRM 5.49.1, Scheduled Reminder changing the "Limit or Add Recipients" opt...2022-05-19T14:14:50Zjustinfreeman (Agileware)CiviCRM 5.49.1, Scheduled Reminder changing the "Limit or Add Recipients" option to "-neither-" will instead save the "Also include" option because "-neither-" is a NULL value.CiviCRM 5.49.1, Scheduled Reminder changing the **Limit or Add Recipients** option to **-neither-** will instead save the **Also include** option because the **-neither-** option is a **NULL** value.
This can then cause Scheduled Remind...CiviCRM 5.49.1, Scheduled Reminder changing the **Limit or Add Recipients** option to **-neither-** will instead save the **Also include** option because the **-neither-** option is a **NULL** value.
This can then cause Scheduled Reminders to be sent to **unexpected contacts**, similar to https://lab.civicrm.org/dev/core/-/issues/3464 - if anyone edits the Scheduled Reminder.
![image](/uploads/d3b107ae3cd34af611efa6f3d1a840b0/image.png)
Agileware Ref: CIVICRM-19845.49.2https://lab.civicrm.org/dev/core/-/issues/3464CiviCRM 5.49.1, Emails are sent to EVERYONE if any Scheduled Reminder had a "...2022-05-19T22:28:13Zjustinfreeman (Agileware)CiviCRM 5.49.1, Emails are sent to EVERYONE if any Scheduled Reminder had a "Limit or Add Recipients" (limit_to) value of NULL, which is changed to "0" ("Also Include") during the database upgradeCiviCRM 5.49.1, Emails are sent to EVERYONE if any Scheduled Reminder had a **Limit or Add Recipients** (`limit_to`) value of `NULL`, which is changed to `0` (**Also Include**) during the database upgrade. This enables the **Also Include...CiviCRM 5.49.1, Emails are sent to EVERYONE if any Scheduled Reminder had a **Limit or Add Recipients** (`limit_to`) value of `NULL`, which is changed to `0` (**Also Include**) during the database upgrade. This enables the **Also Include** option which will then email ALL group(s) selected for the Group field.
The `limit_to` value should remain `NULL` post-upgrade. The use of `NULL`, `1` and `0` for the limit_to select field is not ideal and probably the root cause of this issue, using 1,2,3 would be better IMHO.
**Steps to reproduce**
1. Check the civicrm_action_schedule table, locate any records which have `NUL`L for the limit_to field, `SELECT id FROM `civicrm_action_schedule` where limit_to IS null`
2. Note the record ID for each civicrm_action_schedule
3. Execute the CiviCRM database upgrade for CiviCRM 5.49.1
4. Post upgrade, re-execute the query to check the limit_to field values, `SELECT id FROM `civicrm_action_schedule` where limit_to IS null`
5. Zero records are now returned.
6. Check the values of the limit_to in the civicrm_action_schedule for the records from step 1.
7. The limit_to value has now been changed to `0` which equates to the **Also Include** option
**The impact is that the affected Scheduled Reminders may unexpectedly send emails to groups of contacts.**
Agileware Ref: CIVICRM-1986
**Before CiviCRM database update**
Some records have `NULL` values.
![image](/uploads/375f7a3bf501348bdc27b13182a38a64/image.png)
**After CiviCRM database update**
Same records have been changed from `NULL` to `0` values.
![image](/uploads/2dec87392a2eaeb000afce6b29e4c0d5/image.png)
![image](/uploads/438a8433810c1502375a021d44d90588/image.png)5.49.2https://lab.civicrm.org/dev/core/-/issues/3459CiviEvent Search does not show all results2022-07-29T18:13:59ZMariaVCiviEvent Search does not show all resultsWhen registering a contact to an event, the search does not show all results:
![grafik](/uploads/44065d492a9573698423b2bd789cf0cb/grafik.png)
It has been working on earlier version when entering 3 digits.
When entering a number withou...When registering a contact to an event, the search does not show all results:
![grafik](/uploads/44065d492a9573698423b2bd789cf0cb/grafik.png)
It has been working on earlier version when entering 3 digits.
When entering a number without a leading zero it seems to work for all events:
![grafik](/uploads/91ce279b5efe45f0faaace21a142a6c3/grafik.png)
At first I have thought that it has something to do when the title starts with a zero but sometimes it also works:
![grafik](/uploads/976b961f2c87f6330e9c17d1f5a6fc22/grafik.png)
This issue has been noticed on CiviCRM v. 5.47.4.https://lab.civicrm.org/dev/core/-/issues/3447Import no longer giving errors properly2022-05-09T20:07:49ZDaveDImport no longer giving errors properlyI think the minimal file needed to reproduce this is just a one line csv file with
`a,b,c`
Then go Contacts - Import, don't check the header row box, and map it to First Name, Last Name, and Birth Date.
On the preview page there's no ...I think the minimal file needed to reproduce this is just a one line csv file with
`a,b,c`
Then go Contacts - Import, don't check the header row box, and map it to First Name, Last Name, and Birth Date.
On the preview page there's no errors and it says it will import one contact. On the next results page it says it imported 0 but there's no errors. The contact did not get imported.
@eileen5.51.0https://lab.civicrm.org/dev/core/-/issues/3436Multivalue custom field as "tab with table" does not show values2022-05-25T08:20:07ZjmargrafMultivalue custom field as "tab with table" does not show valuesMultivalue custom field as "tab with table" does not show the tab content
Create a custom field group and set it to be multivalue with style Tab with Table.
Add a field.
Visit a contact record and click on the new tab.
C...Multivalue custom field as "tab with table" does not show the tab content
Create a custom field group and set it to be multivalue with style Tab with Table.
Add a field.
Visit a contact record and click on the new tab.
Create a new entry. The entry will not be showed in the table
I can see the following error message in the browser console:
```
Uncaught SyntaxError: unexpected token: identifier
jQuery 7
globalEval
globalEval
Ga
append
html
X
html
refresh https://crmtest.sci-d.de/sites/all/modules/civicrm/js/crm.ajax.js?rb98g8:310
jQuery 4
jquery.min.js:3:67
jQuery 7
refresh https://crmtest.sci-d.de/sites/all/modules/civicrm/js/crm.ajax.js?rb98g8:310
jQuery 4
```
CiviCRM Version: 5.46.35.50.0https://lab.civicrm.org/dev/core/-/issues/3421Deduping link to 'merge and go to list' just reloads the pair of merged contacts2022-06-12T01:04:14ZpetednzDeduping link to 'merge and go to list' just reloads the pair of merged contactsafter pulling up a list of duplicates, on the merge contacts screen one is offered a button saying "Merge and Go To Listing", but it doesn't, it just reloads the same pair of contacts. (replicated on dmaster) (fuzion tracker r26378)after pulling up a list of duplicates, on the merge contacts screen one is offered a button saying "Merge and Go To Listing", but it doesn't, it just reloads the same pair of contacts. (replicated on dmaster) (fuzion tracker r26378)5.51.0https://lab.civicrm.org/dev/core/-/issues/3413setAmount requires a numeric amount value2022-05-05T06:27:07Zmagnolia61setAmount requires a numeric amount valueOverview
----------------------------------------
Since https://github.com/civicrm/civicrm-core/pull/21583 our installation has a problem with making contribution payments through the contribution checksum link fails if the Thousands Sep...Overview
----------------------------------------
Since https://github.com/civicrm/civicrm-core/pull/21583 our installation has a problem with making contribution payments through the contribution checksum link fails if the Thousands Separator and Decimal Delimiter are different than default.
Reproduction steps
----------------------------------------
1. create a pending contribution
2. set locale to the following:<br>
![Screenshot_2022-04-23_112132](/uploads/890f07b518c9102b2eb551b5de5311c3/Screenshot_2022-04-23_112132.png)<br>
(common in the Netherlands)
3. pay through a contribution link with checksum<br> (example: https://www.example.nl/civicrm/contribute/transact?reset=1&id=7&ccid=123&cid=456&cs=9982c0a392534059a7ae6b4f970f394c_1650623762_5648)
4. payment fails with:
setAmount requires a numeric amount value (reproduced on the sandbox)
![Screenshot_2022-04-23_112051](/uploads/db41c7e3c5c6544f4c91883dbcf43347/Screenshot_2022-04-23_112051.png)
Current behaviour
----------------------------------------
With Thousands Separator set to . and Decimal Delimiter set to , (as we do in the Netherlands) contribution checksum link payments fail
Expected behaviour
----------------------------------------
The payments should succeed :-)
Environment information
----------------------------------------
- CiviCRM: 5.48
- CMS: Drupal 7.89
- PHP: 7.4.29 (fpm-fcgi)
- Database: 10.5.15-MariaDB-0+deb11u1 engine: InnoDB 10 row format: Dynamic
- Webserver: Apache/2.4.53 (Debian)
- OS: Linux
Comments
----------------------------------------
First I thought this had to do with omnipaymultiprocessor but this morning I tested with some more different payment methods
We found https://github.com/civicrm/civicrm-core/pull/21583 to be the change that caused our problem.
Specifically in Civi/Payment/PropertyBag.php the line about 'total_amount'
```
protected static $propMap = [
'amount' => TRUE,
'total_amount' => 'amount',
```
When we remove the 'total_amount' line payments work fine, even with our decimal separator settings.
I am not sure if that would be the solution or only helps to find a real solution.
NOTE: integral payments with event registrations work fine. It is the payment links that are affected.
@mattwire would you be able to look into this?5.49.0https://lab.civicrm.org/dev/core/-/issues/3385Event cart hidden/enabled in buildkit 5.29 RC2022-04-22T16:22:30ZAndie HuntEvent cart hidden/enabled in buildkit 5.29 RCWhen viewing an event info page, there's a "Add to Cart" button. It looks like the eventcart extension is enabled (looking via the API) but it is not visible through the UI.
I don't know if this is for buildkit only or something that w...When viewing an event info page, there's a "Add to Cart" button. It looks like the eventcart extension is enabled (looking via the API) but it is not visible through the UI.
I don't know if this is for buildkit only or something that will take effect for everyone when they download the tarball, but it shouldn't be the default for buildkit to enable the event cart.5.29.0https://lab.civicrm.org/dev/core/-/issues/3382Data from custom fields is not stored in event but in event template2022-04-22T16:22:22ZoseidelData from custom fields is not stored in event but in event templateWhen creating a new event using an event template which includes custom fields, the data entered in the custom fields won't be stored in the event itself when clicking the 'Continue'-button, but are stored in the event template. After cl...When creating a new event using an event template which includes custom fields, the data entered in the custom fields won't be stored in the event itself when clicking the 'Continue'-button, but are stored in the event template. After clicking 'Continue' and then going back to the 'Info and Settings'-tab all data entered in the custom fields is gone. However, the data can be found in the used event template now. By going into edit mode the data is set in the template's custom fields and will be prefilled in the next event generated using this template.
This issue might be conneted to this one: [Core Issue 766](https://lab.civicrm.org/dev/core/-/issues/766)
See also a related post on [stackexchange](https://civicrm.stackexchange.com/questions/20709/new-event-from-template-does-not-copy-custom-fields)
Notice that custom field are 'only' lost in this cases, while it gets stored in the template in this one.
Steps to reproduce:
1. Set up fresh Joomla instance (V. 3.9.26 at the time of writing)
2. Install latest CiviCRM for Joomla (V. 5.37.2 at the time of writing)
3. Create a new set of custom fields (I've been using text, date and select inputs in my tests)
4. Create a new event template and fill out all necessary inputs (I've also entered something in the title, summary and description).
5. Create a new event using the newly created template. Enter something in all necessary fields as well as in the custom fields.
6. Click 'Continue'
7. Return to 'Info and Settings' - the data entered in the custom fields is gone :/
8. Open the template in edit mode. The custom data we previously entered in the event is here now
This issue can be reproduced in CiviCRM 5.37.0 and 5.37.2, but not in 5.36.1 used in the [Joomla Demo](https://cividemo.com/).
I've been using the following environments to test: AMPPS 3.9 and XAMPP (compile date 4-6-21) with PHP 7.3.
As I'm only using CiviCRM inside Joomla I haven't testet whether this issue also appears in other CMS- or the standalone-version.
A possible workaround for the problem is to skip entering something in the custom fields in Step 5 but doing so in Step 7. The contents of custom fields are saved correctly now. However, another strange behaviour occurs now: If there is any content of the custom fields already set in the template (e.g. if a field is set as required), this data is missing in the event using the template. Even in fields marked as required - the content set in the template is just gone.5.39.0https://lab.civicrm.org/dev/core/-/issues/3366Price option reaches max amount causes critical error.2022-04-22T16:21:52ZBruce ThompsonPrice option reaches max amount causes critical error.If a price field is setup with price options that have a max amount when that max amount of registrations is met the site throw a critical error in WordPress. First noticed this in CiviCRM v 5.35.1. I updated a site to 5.36 with the same...If a price field is setup with price options that have a max amount when that max amount of registrations is met the site throw a critical error in WordPress. First noticed this in CiviCRM v 5.35.1. I updated a site to 5.36 with the same result and then tested on https://wpmaster.demo.civicrm.org/ which is currently running 5.38.alpha1 and I received similar results xcept I didn't get the WP critical error message just a http 500 notice. Here is the error message sent via WordPress after the critical error page. There is nothing in the CiviCRM logs.
> An error of type E_ERROR was caused in line 209 of the file /home/account_name/public_html/wp-content/plugins/civicrm/civicrm/CRM/Price/BAO/PriceField.php. Error message: Uncaught Error: Call to a member function freeze() on string in /home/account_name/public_html/wp-content/plugins/civicrm/civicrm/CRM/Price/BAO/PriceField.php:209
Stack trace:
#0 /home/account_name/public_html/wp-content/plugins/civicrm/civicrm/CRM/Price/BAO/PriceField.php(439): CRM_Price_BAO_PriceField::freezeIfEnabled('
Happy to provide additional information.5.36.1https://lab.civicrm.org/dev/core/-/issues/3362registration via backend should expose price set fields regardless of active/...2022-04-22T16:21:40Zlcdwebregistration via backend should expose price set fields regardless of active/expire settingsWhen registering a contact through the backend, price fields should be exposed regardless of their active on/expire on dates. Those filters should only be implemented for the frontend form.When registering a contact through the backend, price fields should be exposed regardless of their active on/expire on dates. Those filters should only be implemented for the frontend form.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/3354Participant name overwritten with Billing Name2022-04-22T16:21:27ZADG CreativeParticipant name overwritten with Billing NameNoticed after update to Civi 5.20.2
On front-end Event Registration form, when the billing First/Last name is different than the event participant name, upon submitting the form, the Participant First/Last name is overwritten with the Bi...Noticed after update to Civi 5.20.2
On front-end Event Registration form, when the billing First/Last name is different than the event participant name, upon submitting the form, the Participant First/Last name is overwritten with the Billing First Last Name.
This causes the event registration to be attached to the Billing contact instead of the Participant contact.
![EventReg](/uploads/b052394df67c272cf04ae072d4d4d438/EventReg.jpg)
![EventConfirm](/uploads/081f712c33fba71e88b11a1153205d4b/EventConfirm.jpg)
![FindParticipants](/uploads/b3d3ae3ad5db1f2dc006ea0963e98f18/FindParticipants.jpg)5.21.0https://lab.civicrm.org/dev/core/-/issues/3352Event Confirmation Email causes fatal error if post-profiles are configured (...2022-04-22T16:21:22ZbgmEvent Confirmation Email causes fatal error if post-profiles are configured (5.18 regression)To reproduce:
* Setup an Event
* Enable email confirmations
* Configure a post-profile for the online registration
* Ensure that `civicrm_uf_group` with `id=1` does NOT exist.
Then register for the event.
Result: fatal error: "Expecte...To reproduce:
* Setup an Event
* Enable email confirmations
* Configure a post-profile for the online registration
* Ensure that `civicrm_uf_group` with `id=1` does NOT exist.
Then register for the event.
Result: fatal error: "Expected one UFGroup but found 0"
Backtrace:
```
[file] => CRM/Event/BAO/Event.php
[line] => 1155
[function] => getFrontEndTitle
[class] => CRM_Core_BAO_UFGroup
[type] => ::
[args] => Array
(
[0] => 1
)
```
In `sendEmail`, the code assumes that the postProfile is formatted the same as preProfile, but because we can have multiple postProfiles (and only one preProfile), the postProfile is an array.
https://github.com/civicrm/civicrm-core/blob/master/CRM/Event/BAO/Event.php#L1155
cc @eileenhttps://lab.civicrm.org/dev/core/-/issues/3336Membership status does not get updated during membership import when status o...2022-04-22T16:17:36ZandrewcormickdockeryMembership status does not get updated during membership import when status override is setMembership statuses are not updated during import to a non-rule based status even when status override is set.
To reproduce:
1. Use Memberships/Import Memberships to import a CSV file (example below)
2. Choose Contact Type individual, ...Membership statuses are not updated during import to a non-rule based status even when status override is set.
To reproduce:
1. Use Memberships/Import Memberships to import a CSV file (example below)
2. Choose Contact Type individual, Update existing memberships
3. When choosing a field mapping, make sure to match on Membership ID, Membership Type and Membership Start Date
4. Import file should contain columns for Membership Status and Membership Status Override (in the example below, I chose a non-rule based status "Deceased" plus Membership Status Override of 1)
5. Start import. Import indicates success on the screen.
6. Check records. Note that Membership Status Override is set correctly, however the Membership Status remains at the rule-based status and is not changed to the indicated non-rule status.
Example CSV:
```
Membership ID,Member Since,Membership Start Date,Membership Type,Membership Status,Status Override,First Name,Last Name
1,2016-09-11,2016-09-11,General,Deceased,1,Iris,Lee
3,2016-09-09,2016-09-09,General,Deceased,1,Lincoln,Zope
7,2016-09-05,2016-09-05,General,Deceased,1,Ray,Jones
9,2016-09-03,2016-09-03,General,Deceased,1,Nicole,Ivanov
```
We have noticed this regression in the following Civi versions 5.28.3, 5.29.1 and 5.31.beta1. It was working as expected in Civi version 5.24.3.5.31.0https://lab.civicrm.org/dev/core/-/issues/3330Updating Membership details fails if created via Relationship2022-04-22T16:17:20ZTony Maynard-SmithUpdating Membership details fails if created via RelationshipI have a configuration using Household Contacts, and Individuals who are linked to Households by 'Member of'/'Household of' Relationships. The Household holds a Membership which flows down to the Individuals. A Membership sign-up or re...I have a configuration using Household Contacts, and Individuals who are linked to Households by 'Member of'/'Household of' Relationships. The Household holds a Membership which flows down to the Individuals. A Membership sign-up or renewal is done by a logged-in Individual and generates a Contribution attached to this Individual, though the associated master Membership is attached to the Household. This is all set up using a Webform.
Since installing CiviCRM 5.20.0, whenever a Membership is updated one or other of the Memberships in this structure vanishes. Previously on CiviCRM 5.19.3 it worked correctly.
If one of the dates on the Household Membership is changed through the CiviCRM Administrative Interface then:
- The Household Membership vanishes.
- The associated Individual Membership IS updated with the new date, and appears now to be freestanding belonging to the Member.
If the Membership is renewed through the Webform:
- The Household Membership is updated correctly and remains.
- The Membership attached to the Individual Contact vanishes.
- The Contribution which created the Household's Membership remains.
This renders 5.20 unusable as far as we are concerned.
Tonyhttps://lab.civicrm.org/dev/core/-/issues/3316[regression] can't create recurring memberships from membership tab w/ credit...2022-04-22T16:16:57ZJonGold[regression] can't create recurring memberships from membership tab w/ credit card### To replicate
* Create a new recurring membership via the "Submit Credit Card Membership" button on the membership tab.
When you do so, the Contribution and ContributionRecur will be created, but the membership will fail to be create...### To replicate
* Create a new recurring membership via the "Submit Credit Card Membership" button on the membership tab.
When you do so, the Contribution and ContributionRecur will be created, but the membership will fail to be created.
This happens on 5.17.0 to 5.17.4. It does NOT happen on 5.16.4. It appears to be related to [PR 14887](https://github.com/civicrm/civicrm-core/pull/14887). I'm executing [this block of code](https://github.com/civicrm/civicrm-core/blob/82ce7f0bcf49d3ee47f158024c124cce0872beba/CRM/Member/BAO/Membership.php#L379-L396) which means that my `$ids['contribution']` is empty.
Backtrace:
```
Sep 19 15:43:13 [info] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[code] => -5
[message] => DB Error: already exists
[mode] => 16
[debug_info] => INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , price_field_id , label , qty , unit_price , line_total , price_field_value_id , financial_type_id ) VALUES ('civicrm_membership' , 49212 , 68001 , 2 , 'Under $5,000 (monthly recurring)' , 1 , 1 , 1 , 12 , 7 ) [nativecode=1062 ** Duplicate entry 'civicrm_membership-49212-68001-12-2' for key 'UI_line_item_value']
[type] => DB_Error
[user_info] => INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , price_field_id , label , qty , unit_price , line_total , price_field_value_id , financial_type_id ) VALUES ('civicrm_membership' , 49212 , 68001 , 2 , 'Under $5,000 (monthly recurring)' , 1 , 1 , 1 , 12 , 7 ) [nativecode=1062 ** Duplicate entry 'civicrm_membership-49212-68001-12-2' for key 'UI_line_item_value']
[to_string] => [db_error: message="DB Error: already exists" code=-5 mode=callback callback=CRM_Core_Error::handle prefix="" info="INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , price_field_id , label , qty , unit_price , line_total , price_field_value_id , financial_type_id ) VALUES ('civicrm_membership' , 49212 , 68001 , 2 , 'Under $5,000 (monthly recurring)' , 1 , 1 , 1 , 12 , 7 ) [nativecode=1062 ** Duplicate entry 'civicrm_membership-49212-68001-12-2' for key 'UI_line_item_value']"]
)
Sep 19 15:43:13 [info] $backTrace = #0 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(236): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/packages/PEAR.php(921): CRM_Core_Error::handle(Object(DB_Error))
#2 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/packages/DB.php(987): PEAR_Error->__construct("DB Error: already exists", -5, 16, (Array:2), "INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , p...")
#3 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/packages/PEAR.php(575): DB_Error->__construct(-5, 16, (Array:2), "INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , p...")
#4 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/packages/PEAR.php(223): PEAR->_raiseError(Object(DB_mysqli), NULL, -5, 16, (Array:2), "INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , p...", "DB_Error", TRUE)
#5 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/packages/DB/common.php(1920): PEAR->__call("raiseError", (Array:7))
#6 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/packages/DB/mysqli.php(933): DB_common->raiseError(-5, NULL, NULL, "INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , p...", "1062 ** Duplicate entry 'civicrm_membership-49212-68001-12-2' for key 'UI_lin...")
#7 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/packages/DB/mysqli.php(403): DB_mysqli->mysqliRaiseError()
#8 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/packages/DB/common.php(1229): DB_mysqli->simpleQuery("INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , p...")
#9 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/packages/DB/DataObject.php(2415): DB_common->query("INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , p...")
#10 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/packages/DB/DataObject.php(1040): DB_DataObject->_query("INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , p...")
#11 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php(572): DB_DataObject->insert()
#12 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Price/BAO/LineItem.php(86): CRM_Core_DAO->save()
#13 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Price/BAO/LineItem.php(471): CRM_Price_BAO_LineItem::create((Array:11))
#14 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Member/BAO/Membership.php(400): CRM_Price_BAO_LineItem::processPriceSet(49212, (Array:1), Object(CRM_Contribute_BAO_Contribution))
#15 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Member/Form/Membership.php(1526): CRM_Member_BAO_Membership::create((Array:43), (Array:1))
#16 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Member/Form/Membership.php(927): CRM_Member_Form_Membership->submit()
#17 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php(495): CRM_Member_Form_Membership->postProcess()
#18 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Upload.php(169): CRM_Core_Form->mainProcess()
#19 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Upload.php(136): CRM_Core_QuickForm_Action_Upload->realPerform(Object(CRM_Member_Form_Membership), "upload")
#20 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Upload->perform(Object(CRM_Member_Form_Membership), "upload")
#21 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Member_Form_Membership), "upload")
#22 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Core/Controller.php(351): HTML_QuickForm_Page->handle("upload")
#23 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Member/Page/Tab.php(301): CRM_Core_Controller->run()
#24 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Member/Page/Tab.php(374): CRM_Member_Page_Tab->edit()
#25 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(290): CRM_Member_Page_Tab->run((Array:4), NULL)
#26 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:14))
#27 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:4))
#28 /var/www/mysite.org/wp-content/plugins/civicrm/civicrm.php(1436): CRM_Core_Invoke::invoke((Array:4))
#29 /var/www/mysite.org/wp-includes/class-wp-hook.php(286): CiviCRM_For_WordPress->invoke("")
#30 /var/www/mysite.org/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters("", (Array:1))
#31 /var/www/mysite.org/wp-includes/plugin.php(465): WP_Hook->do_action((Array:1))
#32 /var/www/mysite.org/wp-admin/admin.php(253): do_action("toplevel_page_CiviCRM")
#33 {main}
```https://lab.civicrm.org/dev/core/-/issues/3285SearchKit: URLs to external sites no longer render2022-04-22T15:53:48ZJonGoldSearchKit: URLs to external sites no longer renderSearchKit displays that used to link to an external site now link to an invalid internal URL. This is a 5.44 regression.
### (Simplest) Steps to Replicate
* Create a new SearchKit search on Website entities. (Screenshot 1347)
* Create ...SearchKit displays that used to link to an external site now link to an invalid internal URL. This is a 5.44 regression.
### (Simplest) Steps to Replicate
* Create a new SearchKit search on Website entities. (Screenshot 1347)
* Create a new display, linking the website to itself. (Screenshot 1348).
* Click Preview.
### Expected Result
Link of "https://www.example.org" links to "https://www.example.org".
### Actual Result
Link of "https://www.example.org" links to "http://dmaster.localhost/https://www.example.org".
`git bisect` points to [PR #21820](https://github.com/civicrm/civicrm-core/pull/21820), specifically commit ID `8fd58f5640`.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3276Unreleased regression - fee levels incorrectly show sold out (in code that wi...2022-04-22T15:53:33ZeileenUnreleased regression - fee levels incorrectly show sold out (in code that will be 5.16)Fees are incorrectly showing as sold out, blocking change fee selection.
This is an unexpected consequence of
https://github.com/civicrm/civicrm-core/pull/14244
The path is that because $this->_id is now set it gets assigned to the fo...Fees are incorrectly showing as sold out, blocking change fee selection.
This is an unexpected consequence of
https://github.com/civicrm/civicrm-core/pull/14244
The path is that because $this->_id is now set it gets assigned to the form
https://github.com/civicrm/civicrm-core/blob/5774b54f47445de233daa85672ce4f793dff347a/CRM/Event/Form/Participant.php#L265
Which then gets passed to the call to load the fee block
https://github.com/civicrm/civicrm-core/blob/c4145dedecb1f3157ecf8fd85421f562e8128e73/templates/CRM/Event/Form/Participant.tpl#L411
which results in $_pid being set & as a result online being set
https://github.com/civicrm/civicrm-core/blob/90b461f1623e75e94e0f472a3c6bf23e01defbc1/CRM/Event/Form/EventFees.php#L350
which leads to the element being frozen
https://github.com/civicrm/civicrm-core/blob/90b461f1623e75e94e0f472a3c6bf23e01defbc1/CRM/Event/Form/EventFees.php#L393
which is interpretted as 'sold out'
https://github.com/civicrm/civicrm-core/blob/6b83d5bdd0f2ca546924feae6aa42aeddb1d40cf/templates/CRM/Price/Form/PriceSet.tpl#L93
This is an example of a code antipattern which is too prevalent in our codebase - ie. hanging various assumptions off a parameter.
I *think* the right answer is to assign a variable of online & then pass that through & make appropriate decisions based on that.
The first question is - do we revert https://github.com/civicrm/civicrm-core/pull/14244 out of the rc and then re-commit into master to give us more time given how awful this code path is5.16.0https://lab.civicrm.org/dev/core/-/issues/3271Regression: Can't use operators to filter contact subtypes other than "Is One...2022-04-22T15:53:19ZJonGoldRegression: Can't use operators to filter contact subtypes other than "Is One Of"This is introduced by core#544, which introduces a hard-coded `LIKE` where the code should allow for different operators.
[A commit based on 5.14 is here](https://github.com/MegaphoneJon/civicrm-core/commit/625b0b06e64d02883614e31bb4ef7...This is introduced by core#544, which introduces a hard-coded `LIKE` where the code should allow for different operators.
[A commit based on 5.14 is here](https://github.com/MegaphoneJon/civicrm-core/commit/625b0b06e64d02883614e31bb4ef79825a1b8ad2#diff-d355cdb00cea3915a3cf306c6c08f6a6L2131) and hopefully I (or someone) will have time to merge and add tests in the near future.5.16.0