Problem/Motivation
When trying to set part of an overridden display's configuration, the user ends up with broken configuration.
Steps to reproduce:
- Create a view with a display (A) with overridden filters
- Save
- Edit the view to make A's filters the default filters, e.g. via "Rearrange filters" dialog (ie on the Rearrange Filters dialog, select 'All Displays' in the For option.)
- Notice that A's filters have changed, instead of the default display's
Expected result:
Display A's filters are set as default. Display A no longer uses overridden filters.
Actual result:
Display A uses the filters of the default display. Display A no longer uses overridden filters.
This means, that upon saving the view, A's filters are lost irreversibly.
If both the default and the overridden display used filters of the same names, this will be hard to spot and lead to confusion and possibly errors later on, as filter values are changed behind the scenes. If A used additional filters, these will all be changed to "Broken handler".
The "Use as default" behavior effectively duplicates the "Revert to default" behavior, with the added bonus of unexpectedly altering the view. This broken behavior has been around for quite a while, and also happened in D7 (see
https://www.drupal.org/node/2313791 →
).
Proposed resolution
Upon closer inspection, it seems that views_ui never actually passes the display's configuration to the default display, even though the code comments state it does. So we have to properly implement this de-override behavior.
Remaining tasks
Write tests to reproduce, review suggested patch.