Improve usability of Filter + View + Grouping in list views

Description -

Store the selection of Filter/View and Grouping with the current objectID

Add the ability to combine Filter, View and/or Grouping into a "Scene"

Why is this feature important to you -

Often different personas use different combination of view/filter/grouping. 

The chosen view/filter/grouping depending on what a "project" or "task" or "issue" represents. 

Example: Take "issues" on a project.

1. In a creative execution project the issues might be change requests. So i need to see description, status, enteredBy, and group it by parent task. I might filter to open-only
2. In a planning project issues might be items on a ROAM board.  Here I what to see a mix of basic and custom fields grouped by status

Example: Take "tasks" on a project.

1. A project is a configuration project where a task represents a configuration entry. I have a specific set of custom fields to display
2. On project A I am a contributor so I want to see MY open tasks, grouped by week (plannedStartDate)
3. On project B I am the project owner so i need to see the standard task view

How would you like the feature to work -

Scenes can be created/named (save current scene) and edited (each of View/Filter/Grouping is a dropdown of available options).

Selecting a Scene sets the Filter/View and Grouping.

Allow setting a scene as default.

Store the selected view/filter/grouping (not the scenes) with the specific object ID (project ID, programID) instead of being global to the object type (all projects etc)

This allows me to have a set view for the examples above

• my config project scene
• my todos scene
• my PM scene
• my change-requests scene
• my ROAM scene

Current Behaviour -

The Filter/View/Grouping combination is stored for the objectType, meaning the filter/view/grouping I selected on project A follows me when I visit project B

For power users this is a nuisance

An every user has run into this issue: A brief moment of panic when we don't see the expected items, only to find that a filter (used on the project I was on previously) needed to be unset.

The current behavior (storing UI choices based on object type) adds no value at best, and can at times be a hindrance.