Details
-
Type: Bug
-
Status: Done/Fixed
-
Priority: Trivial
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.4.4
-
Fix Version/s: 4.4.5
-
Component/s: Core CiviCRM
-
Labels:None
Description
This issue bears a family resemblance to CRM-11227.
When a default search profile is in use, and you access a list of contacts from the Manage Group page, the form id is set to the default search profile id. (If you don't have a default search profile set, it's not set).
When you add the contacts to a group, the participant_id is set to the form's id value (which was previously set to the default search profile id).
This causes an error if that participant id doesn't exist (I've demonstrated this on demo by setting the default search profile id).
CRM/Event/Form/Participant.php already has a check (thanks to CRM-5792) that avoids this problem when the path is civicrm/contact/search. I think we need to add a check for path being civicrm/group/search as well.