Grid "View Presets" functionality

In-Portal has a "View Menu" almost on each of templates, that are used to display tabular data, e.g. grids/lists.

There was a lot of menu items in earlier versions of In-Portal, but right now there 3 menu items:

• Select Columns - opens dialog window for rearranging grid columns (show/hide/move left/move right)
• Auto-Refresh - will open submenu, where user can make grid auto-refresh periodically
• Per Page - will open submenu to change row count that are simultaniosly displayed in the list

Also when user changes filters, sorting or per-page, then they are stored into PersistantSessionData table to make sure that user will see current grid the same way he left it, when he logged-out from Admin Console.

I'm proposing to store various combinations of all of them as "View Presets", that can be used later.

In there database there will be 2+ presets:

• Current View" (used for temporary data storage)
• user preset 1
• user preset 2
• ....
• user preset N

Current View it will be used to temporarily store columns/filters/per-page until user decides to save them under preset of his choice OR create new preset. Sandbox preset will be used ONLY, when user has selected "user preset X". This will ensure, that "user preset X" isn't unintentionally changed by system until user decides to do that manually. When user is using "user preset X" and decides to create a new preset or update existing one, then all data from sandbox preset will be copied to the destination preset.

Switching to "user preset X" will overwrite sandbox preset contents with contents from selected preset. Then sandbox preset will be used to store any change user will made and to protect "user preset X" for unintended changes.

When default preset is selected, then changes will be saved directly to it without use of sandbox preset. This will ensure backwards compatibility and grid will work as before when presets are not used at all. When user is using default preset and decides to create a new preset or update existing one, then all data from default preset will be copied to destination preset.

Technically current preset name will be stored in session, but actual preset data read/write operations will happen on sandbox preset, when "user preset X" is being used.

Visually it will be a new "Presets" submenu (on top) of "View Menu":

Presets
– New Orders - [Save] - [x]
– International Addresses - [Save] - [x]
– Save As...

Maybe update and delete links will be more intuitive if replaced with nice small icons, maybe like our save/cancel toolbar buttons, but smaller.

We will ask user confirmation before actually deleting preset from database.