Adding a field and overriding adds to all displays

Could you try to update to 7.x-dev and see whether this is still broken there?

If yes there are proabably other issues as well, which describe this problem.

Everything about overriding needs revisiting :/

#1176048: Remove button does not respect changing of the override select is probably a duplicate.

Feedback/review for this patch are highly welcomed, as on all patches in general.

It's true the overrides are currenty somehow horrible broken :(

Just tagging to catch them all.

Just ran into this issue when adding a sort field using 7.x-3.x-dev from Oct. 24th. The first sort field you add within a view always gets added to all displays even if you choose override. My situation was like this:

Display 1: sort on field_1
Display 2: sort on field_2
Display 3: no sort

To set this up in views I had to:

1. Add sort on field_1 and select override when saving
- bug now takes affect and adds sort on field_1 to all displays
2. Edit sort on field_1 in Display 2 and set to override and save
3. Remove sort on field_1 from Display 2
4. Add sort on field_2 in Display 2
5. Remove sort on field_1 on Master, which then removes the sort on Display 3

Hope this info helps.

Bumping this to a release blocker.

Hi

I've been testing this but with the http://drupal.org/node/1176048 patch included and I think that with the handler added in that patch it also corrected this one.

It would be definitive cool if some more people could test whether it's still a problem of 3.x-rc3

Tried in RC3 and not working so most likely not in dev either. Must been some caching. I do have an idea so hopefully i manage to get an patch done today

been debugging now and this is my conclusion:

When we make the submission it calls views_ui_standard_submit and there we call for the options_override.

In views_plugin_display.inc:

In options_override it calls the funtion set_override with argument section, in this case fields.
set_override do take two arguments, the section and a boolean $new_state with default value null.
So new_state gets a value fetched and will in this case always be true and what happends then for each options in the section is that it will be reverted to the defaults. So that is the error acording to me.

When looking around in the file I found this function: override_option($option,$value) that seems to actually do what we want in this case?

Maybe something like this, semicode

 function options_override($form, &$form_state) {
    //fetch options for the section
   $options = $this->defaultable_sections($form_state['section']);
   //for each option call for override_option
  foreach($options as $option){
     $this->override_option($option,$value);
  }

The problem for me is that I don't know what $value is, so therefor I can't really test it and see if this really is somewhat correct or if I'm totally wrong.

and just a thought, pehaps it would be better if we from the submit actually call directly to the options_overide function.

Hmm. It would make sense to me if the override dropdown was present on the add field/filter/sort form.

This issue would be definitive helpful for writing an issue summary. Just from reading #8 i assume the problem is the following:

* You can't override directly on the add item form
* Per default items aren't overridden

Is there anything additional which is a problem here? Please help and write a summary.

To clarify my last comment, the dropdown in the second image has no effect. But what Ankabout suggests in #15 is adding the dropdown to the first image.

There was an issue some time ago which would allow to only store new fields once submit is clicked, this maybe have helped it.

But yeah it's probably right that you have this select available.

Here is a first version which DOES NOT WORK!

Based on some problems i had to tackle on #1373174: Add ability to override entire grouping before adding settings i managed to implement this now...

There are some additional screenshots to show how it works.

This only works halfway.

If you choose to override before adding the field, it works great.

But if you don't choose to override before configuring, and then try to set it to override, it is still broken.

I misunderstood what was actually happening underneath, I think this is good to go solves the problem nicely.

One less issue