Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Major
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.6.6
-
Fix Version/s: 4.6.7
-
Component/s: None
-
Labels:
-
Documentation Required?:None
-
Funding Source:Contributed Code
Description
Smart groups created prior to 4.6.5 are broken with the membership_type_id & membership_status_id being silently ignored .
Here is the sql from a broken entry in the civicrm_saved_search table - full of custom values though 
INSERT INTO `civicrm_saved_search` (`id`, `form_values`, `mapping_id`, `search_custom_id`, `where_clause`, `select_tables`, `where_tables`) VALUES (119, 'a:42:{s:5:"qfKey";s:37:"3121d9f97cb8ddfbbdf9ebfe67bd224c_6896";s:12:"hidden_basic";s:1:"1";s:12:"contact_type";a:0:{}s:5:"group";a:0:{}s:12:"contact_tags";a:0:{}s:9:"sort_name";s:0:"";s:5:"email";s:0:"";s:14:"contact_source";s:0:"";s:9:"job_title";s:0:"";s:7:"uf_user";s:0:"";s:11:"uf_group_id";s:0:"";s:7:"privacy";a:6:
{s:12:"do_not_phone";s:0:"";s:12:"do_not_email";s:0:"";s:11:"do_not_mail";s:0:"";s:10:"do_not_sms";s:0:"";s:12:"do_not_trade";s:0:"";s:13:"do_not_toggle";s:0:"";}s:13:"email_on_hold";a:1:
{s:7:"on_hold";s:0:"";}s:30:"preferred_communication_method";a:5:
{i:1;s:0:"";i:2;s:0:"";i:3;s:0:"";i:4;s:0:"";i:5;s:0:"";}s:18:"preferred_language";s:0:"";s:17:"hidden_CiviMember";s:1:"1";s:25:"member_membership_type_id";a:5:
{i:10;s:1:"1";i:11;s:1:"1";i:12;s:1:"1";i:13;s:1:"1";i:14;s:1:"1";}s:17:"member_is_primary";s:1:"1";s:16:"member_status_id";a:3:
{i:2;s:1:"1";i:3;s:1:"1";i:7;s:1:"1";}s:13:"member_source";s:0:"";s:20:"member_join_date_low";s:0:"";s:21:"member_join_date_high";s:0:"";s:21:"member_start_date_low";s:0:"";s:22:"member_start_date_high";s:0:"";s:19:"member_end_date_low";s:0:"";s:20:"member_end_date_high";s:0:"";s:10:"custom_123";s:0:"";s:10:"custom_126";s:0:"";s:15:"custom_124_from";s:0:"";s:13:"custom_124_to";s:0:"";s:15:"custom_125_from";s:0:"";s:13:"custom_125_to";s:0:"";s:15:"custom_127_from";s:0:"";s:13:"custom_127_to";s:0:"";s:15:"custom_128_from";s:0:"";s:13:"custom_128_to";s:0:"";s:10:"custom_174";s:0:"";s:15:"custom_178_from";s:0:"";s:13:"custom_178_to";s:0:"";s:10:"custom_179";s:0:"";s:4:"task";s:2:"13";s:8:"radio_ts";s:6:"ts_all";}', NULL, NULL, ' ( civicrm_membership.membership_type_id IN (\'10\',\'11\',\'12\',\'13\',\'14\') AND civicrm_membership.status_id IN (\'2\',\'3\',\'7\') AND civicrm_membership.is_test = 0 ) ', 'a:12:
{s:15:"civicrm_contact";i:1;s:15:"civicrm_address";i:1;s:22:"civicrm_state_province";i:1;s:15:"civicrm_country";i:1;s:13:"civicrm_email";i:1;s:13:"civicrm_phone";i:1;s:10:"civicrm_im";i:1;s:19:"civicrm_worldregion";i:1;s:18:"civicrm_membership";i:1;s:6:"gender";i:1;s:17:"individual_prefix";i:1;s:17:"individual_suffix";i:1;}', 'a:2:
{s:15:"civicrm_contact";i:1;s:18:"civicrm_membership";i:1;}');
Attachments
Issue Links
Activity
So, the issue is smart groups created prior to 4.?x - probably 4.6.4 or similar - which have different storage in their formValues fields than those created after various changes.
I just hit another report and have replicated it so I will try to get more detail
Both the sites I'm trying are recent 4.4 upgrades so the smart groups would have been created in 4.4
SO in the civicrm_saved_search.form_values of the pre-existing smart group I see
"member_membership_type_id";a:3:
s:16:"member_status_id";a:4:
{i:1;s:1:"1";i:2;s:1:"1";i:3;s:1:"1";i:9;s:1:"1";}But if I create a new one I get
"membership_type_id";a:1:{s:2:"IN";a:1:
{i:0;s:1:"2";}}
I dug further into this & found that the sites in question have 'wierd' keys for membership_status_id & membership_type_id in their saved searches so this PR fixes
https://github.com/civicrm/civicrm-core/pull/6479
I haven't dug into the history of how this arose but:
1) all 3 sites are recently upgraded from 4.4. I don't know the past of one of them but the other 2 have been on CiviCRM for a long time.
2) new saved searches are not affected - only those that preceeded the upgrade.
3) nah - no 3 - I really don't know anything more about this 
Just putting a comment in here which I skyped to Eileen but useful for the rest of the community to know, Looks like the bad array keys are introduced here https://github.com/civicrm/civicrm-core/blob/4.4/CRM/Member/Form/Search.php#L376
Feedback I have received on results of the PR (above)
I have seen improvement in working out who is in these groups, but preliminary testing has found the following:
The "count" column in the Manage Groups page is still incorrect
On the "Edit Smart Groups Criteria" page, when opening the Edit Smart Groups Criteria tab, the relevant fields aren't populated (pressing search verifies that the fields get dropped at this stage)
As per the changes https://github.com/civicrm/civicrm-core/commit/0a74debbc6ccd6cbbb1304de8e9bfcebcc3f9c61#diff-2d294a711dee9bd582602b2c974a22a3L439 the form element membership_type/status in Search Form is being changed to "multi-Select2" from "checkbox" from 4.6.6 onward. So this is the formvalue comparison how both kind submit values in postprocess fn.
| CheckBox | Multi-select2 |
|---|---|
| array( 1=> 1 2 => 1 3 => 1) |
array(1,2,3) (later processed into array('IN' => array(1,2,3))) |
Now two remaining issues -
1) Search form aren't filling because of 'name' and 'checkbox values' mismatch, e.g. - 'member_membership_type_id' name should be membership_type_id instead and value should be processed to Multi-select2 format and need to be fixed in this spot https://github.com/civicrm/civicrm-core/pull/6342/files#diff-4709aadbb3a8fe3eafe15d2fdc83ecf8R435
2) Weird qill format because $QillName is changed now
Will submit a final fix in my new PR with your (cherry-picked commits) changes.
Submitted the PR https://github.com/civicrm/civicrm-core/pull/6484
Your extra fix is looking good I think. Seems to be working where I have applied it.
Closing issue as the PR is being merged and tested
Eileen, I was unable to replicate the issue although the serialized data under saved-search provided is too big but then I created a new smart group with multiple Membership types and statuses and via advance search and on 'Edit Smart Group Criteria' redirects to Advance Search with successful listing of chosen contact with filled criteria (checked against 4.6.7). Is there anything I missed ?