In-Portal Issue Tracker

Welcome to the In-Portal Open Source CMS Issue Tracker! This is a central management / tracking tool for all types of tasks / issues / bugs for the In-Portal Project. Before reporting any issues, please make sure to read the Guide into Issue Tracker and How to Properly Test and Report Bugs!

Viewing Issue Simple Details [ Jump to Notes ] [ Wiki ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Type

Reproducibility

Date Submitted

Last Update

0001012

[In-Portal CMS] Admin Interfaces

feature request

N/A

2011-03-11 13:40

Reporter

alex

View Status

public

Project Name

In-Portal CMS

Assigned To

Developer

Priority

normal

Resolution

open

Fixed in Version

Status

active

Product Version

5.1.2-B2

Target Version

Icebox

Time Estimate

No estimate

Summary

0001012: Grid "View Presets" functionality

Description

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:
* default (without name as for now)
* sandbox (used for temporary data storage)
* user preset 1
* user preset 2
* ....
* user preset N

Sandbox preset won't be visible in menus, but 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
  -- user preset A - [update] - [x]
  -- user preset B - [update] - [x]
  -- create new preset...

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.

Additional Information

Maybe preset deletion won't be causing page refresh so I can quickly delete more then one of them.

Issue History
Date Modified	Username	Field	Change
2011-03-11 13:40	alex	New Issue
2011-03-11 13:40	alex	Reference	=> https://groups.google.com/d/topic/in-portal-dev/FfMfI-Faq6U/discussion
2011-03-11 13:40	alex	Change Log Message	=> Adding "View Presets" functionality to grids

Relationships [ Relation Graph ] [ Dependency Graph ]