Filters Groups broken after export/import

This indeed seems to be a major issue. So i tryed to build a view like this, export the view and then import it again.
and "sadly" it worked how it should have worked.

Perhaps it could help if you provide a step by step reproduce of the issue. Thanks!

Update status, as it's currently impossible to reproduce.

I just had the same problem.
In the export all looks well, the filter groups operator and groups array is there, but if I import the view, all filters are there but no filter groups.

After some more testing it seem to happen when you have multiple displays and overriden filters.
When the filter groups are in the default filters, the import seems to work without a problem. But when the filter groups are with the overriden filters the import is not correct.

Not entirely sure but this could yet another override issue, so adding a tag.

Just wondering whether this issue still exists with the current dev version.

Many fixes to the override-problem got in there, maybe one resulted in an actual fix.

I'm cautiously optimistic. Have revisited one view where I was having this problem in 7.x-dev late last year and it now seems OK on 7.x-3.1. (Had to manually re-group filters and save view though.) Anybody else?

Great. Let's mark it as fixed.

Actually, may have spoken too soon. In my view I have one display with multiple filter groups and other displays with just one. On switching to the single-group displays in the Views UI, I get the following warning:

Notice: Undefined offset: 0 in views_ui_edit_form_get_bucket() (line 2343 of /path/to/drupal/site/modules/contrib/views/includes/admin.inc).

The rearrange filter dialog for these displays shows as many groups as on the multiple group display, all but the first one empty. Deleting these superfluous groups in any one display deletes them in all other displays, even when (as in my case) the filters and filter groups on all displays are marked as overridden in the UI.

A look at the exported view shows that the groups are defined in the default/master display thus:

  $handler->display->display_options['filter_groups']['operator'] = 'OR';
  $handler->display->display_options['filter_groups']['groups'] = array(
    1 => 'AND',
    2 => 'AND',
    3 => 'AND',
    4 => 'AND',
  );

The filters in my multi-group display are attached to the appropriate group ids. All other displays have no $handler->display->display_options['filter_groups']['groups']defined, and all filters are assigned to group 0, presumably the undefined offset in the warning message above.

Just bit me, bug still exists

I also ran into this issue. Using Drupal 7.12, Ctools 7.x-1.0, Views 7.x-3.3, Features 7.x-1.0-rc1

I have a view with two Page displays. The second one overrides the filters and uses filter groups. Using Features, exported my view and pushed to dev server. Groups were broken on dev server, even though the feature said it was in default state.

I tried to export the view manually and pasted into my feature, did a git diff, nothing had changed. I noticed that even though my feature was in the default state locally that from the Views list, it said the view had "Database overriding code", I reverted the view, which lost the groups. After recreating my group I was able to re-export my feature which looks like it just moved where the filter_groups were defined.

--- a/drupal/sites/all/modules/features/mysite_schedule/mysite_schedule.views_default.inc
+++ b/drupal/sites/all/modules/features/mysite_schedule/mysite_schedule.views_default.inc
@@ -1269,6 +1269,10 @@ function mysite_schedule_views_default_views() {
   $handler->display->display_options['arguments']['field_schedule_listing_type_value']['summary']['human'] = 0;
   $handler->display->display_options['arguments']['field_schedule_listing_type_value']['break_phrase'] = 0;
   $handler->display->display_options['arguments']['field_schedule_listing_type_value']['not'] = 0;
+  $handler->display->display_options['filter_groups']['groups'] = array(
+    1 => 'AND',
+    2 => 'OR',
+  );
   /* Filter criterion: Content: Published */
   $handler->display->display_options['filters']['status']['id'] = 'status';
   $handler->display->display_options['filters']['status']['table'] = 'node';
@@ -1417,10 +1421,6 @@ function mysite_schedule_views_default_views() {
   );
   $handler->display->display_options['fields']['field_ondemand_dates']['field_api_classes'] = 0;
   $handler->display->display_options['defaults']['arguments'] = FALSE;
-  $handler->display->display_options['filter_groups']['groups'] = array(
-    1 => 'AND',
-    2 => 'OR',
-  );
   $handler->display->display_options['defaults']['filters'] = FALSE;
   /* Filter criterion: Content: Published */
   $handler->display->display_options['filters']['status']['id'] = 'status';

Pushing the updated feature to the dev server and reverting the feature fixed the issue there.

Also, it looks like now when I edit my view that there are always 2 filter groups on every display, even if the second group is empty/not used. Hopefully something I mentioned here will help in debugging this issue.

It appears to me that the filter groups seem to follow the last display you edited in a multiple display view when editing.

I have a rather complex view (23 displays) which keeps breaking. Some of the displays just have an AND group and other displays have an AND group (AND) an OR group. It seems that if I edit one of the ones with just an AND group it deletes the OR group across the board.

So, I guess the underlying problem is the system deleting groups that are empty at the display level when the groups are actually global....

The problem appears to be is_default not working properly when working with an exported view, which is happening because the export is not containing

  $handler->display->display_options['defaults']['filter_groups'] = FALSE;

lines when appropriate.

filter_groups should be considered overridden whenever filters is overridden.

Attached is what I am pretty sure is the correct fix for this.

Can someone verify?

Test case of broken feature.

Added some automatic conversion code to be sure that overridden filter_groups are used.

After a discussion we figured out

* not break existing views!
* By not breaking existing views we have to use the value from the default display but force the value to be overridden.
* This is done by copy the value and mark it as overridden.
* As a result this will not change active views, but some intended filter_groups have to be rebuilt.

Adapted the if, as it was leftover from previous patches.

Some cleanup in the if to make it easier to understand

I tweaked some of the comments. No code changes.

I'm not really sure whether i want to look at the grammar changes, it was 2am :)

Here is a test which just contains a test for the update and the actual behavior.

Okay i did an experiment writing a test without running it locally, and basically i failed completly, but hey this showed something like a bug, see the documentation of set_override.

Here a a new issue, which does it right.

The init changes made it possible for me to relatively easily fix my corrupted views, so +1 on that!

So just committed it to 7.x-3.x

Maybe some parts of the patch are helpful for the backport.

Update version.

just fixed some grammar errors

The Drupal 6 branch is no longer supported, please check with the D6LTS project if you need further support. For more information as to why this issue was closed, please see issue #3030347: Plan to clean process issue queue