Feature request: “Child” Views inherit settings from “Parent” View? (filters / sorting / grouping / columns / etc.)

hi! i’d love the ability to create “child” views which inherit settings from a “parent” view.

tl;dr

the problem

as it is, when you create a view, it copies over all of the table’s existing settings. but this only happens at the time of creation. if you change anything on the table, it will not propagate any of those changes to the rest of the views.

for example, let’s say i had a table of Tasks, sorted alphabetically, and split into four identical views that filter by status: Active, Inactive, Completed, and Cancelled.

now, if i decided that i wanted to sort all tasks by date instead of alphabetically, i’d have to edit the Sort settings of all four of those views, one by one.

the solution

but what if i could set Active to be the parent of Inactive, Completed, and Cancelled views? then i’d only have to edit Active, and any changes i make to Active would cascade down to its three children. if i set Active to sort by date, the other three would also sort by date.

same with filters, grouping, showing / hiding columns, even column widths.

exceptions

naturally, any changes you make to a child view will override anything inherited from a parent view. and you can selectively disable inherited characteristics, like filters.

but anything untouched will get inherited or take priority. so if i have Active sorted by date, and Cancelled sorted alphabetically, then Cancelled will sort alphabetically first and then by date second.

it’s possible!

this functinoality already exists: in Conditional Formatting!

i just want this same functionality for every other setting, like Sorting, Grouping, Columns, etc.

Views currently inherit certain settings from the table at the time of creation. You can then overwrite the settings in the view, without affecting the table settings.

Have you tried that?

yes, but this only occurs time of creation. you’re essentially “forking” the table when you create a view. settings-wise, that view is completely independent of the table from that point forward.

i was hoping for it to be ongoing and dynamically update to match changes made to the original table. any changes made to the child table would take priority, but if there are no conflicts, then it’ll default to the parent table’s settings.

here’s an example.