Saved Views

A signed-in user can save a grid, calendar, timeline, map or Kanban board as they've arranged it — its filters, its columns and sort, the tables it shows, its layout — as a view of their own, offered in its view picker beside the page's views from then on. They choose which view it opens on, and hide the views they don't use. Saved views work the same way on MainGrid, SubGrid, Calendar, Timeline, Map and KanbanBoard, on Blazor and React, and are off until you turn them on with AllowSavedViews (React: allowSavedViews). AllowFiltering gives users something to save beyond what the control lets them change anyway.

Try them on the Grid Saved Views demo, the views of several tables on the Calendar page, and the Timeline page's first example.

What they need

Views are kept in Dataverse, in tables of the Power Portals Pro Core solution, so they follow a user from one browser and device to the next. The portal grants signed-in users their own rows of those tables without any table access of yours: each saved view and setting belongs to the contact who made it, and no user reads or changes another's. Registering table access for one of those tables yourself replaces that default for it. Without the solution's tables, the controls show only the page's views.

A visitor who hasn't signed in still sees the Filter menu's Views section; choosing anything in it explains that views are for signed-in users and offers to sign in, coming back to the page afterwards. SignInUrl (React: signInUrl) is where they go, the portal's own login page by default.

Saved views aren't offered on a calendar given its appointments in Appointments (React: appointments), which reads nothing from Dataverse. In React, a grid needs tableName, and isn't offered them when it is held to one view with viewId or reads a shared dataSource.

Saving a new view

The commands are in the toolbar's Filter menu, under Views. Once the user has changed what the control shows, the Filter button fills in, and Save as new view asks for a name, up to 200 characters, and saves the view. The control then shows the new view, and its picker lists it from then on; a grid's picker lists the user's views under My views, after the page's System views.

Save as new view is offered only for a changed view. A grid has changed when the user has filtered it, sorted it otherwise than its view does, or changed its columns, grouping, totals or layout — a page size alone doesn't count. A calendar has changed when the user has filtered it, switched a table on or off or picked another layout; a timeline, when they have filtered it or switched a table on or off; a board, when they have filtered or sorted it, or changed its cards' fields, its totals, the cards a lane loads or the lanes collapsed or hidden. Tables a control starts with switched off don't count while they stay off.

What a view keeps

A saved view keeps the query the control shows — the view's own filters with the user's, and their sort — and the way it lays it out:

• A grid keeps its page size, table or card layout, and grouping, and every column in order: whether it is hidden or pinned, its width — including widths the user dragged — its totals, and the title it shows. Columns the user added from the Columns dialog become part of the view.
• A calendar keeps the tables it shows, each with its filters, and its layout: day, work week, week, month or agenda. A view of appointments alone is saved as a grid's view of appointments is.
• A timeline keeps the tables it shows, each with its filters.
• A map of several tables keeps the tables it shows, each with its filters.
• A Kanban board keeps the fields its cards show and their titles, the lanes' totals, the cards each lane loads, and the lanes collapsed or hidden.

A view opened again is shown as far as the control lets the user change it: a grid that doesn't let users hide, pin or group columns shows a saved view's columns without those changes.

Changing a view

When the view shown is one of the user's own and they have changed it, Save in the Filter menu writes the change into it, straight away. To keep the view as it was, they save the change as a new view instead.

Managing views

Manage views in the Filter menu opens a panel listing every view the control offers — the page's and Dataverse's as well as the user's — marked Default, Hidden and Mine. A view's name opens it, and its … menu sets it as the user's default, hides it or shows it again, and, for their own views, offers more:

• Rename changes the view's name, leaving the view on screen and any unsaved change to it as they were.
• Copy saves a copy of any view, the page's included, under a new name — Copy of … to start with — layout and all.
• Change column titles, on a grid, gives the view's columns titles of the user's own. Emptying a box gives the column its own title back.
• Delete asks first, since a deleted view can't be brought back, and removes the view along with every default and hidden mark made of it. A control showing the deleted view moves to the user's default, else the page's DefaultViewId, else the first view that isn't hidden.

Choosing a default view

Set as my default in the Filter menu makes the view shown the one the control opens on for that user, and Manage views does the same for any view it lists, the page's included. A control has one default per user: setting another replaces it, and Stop using as my default in Manage views clears it. Making a hidden view the default shows it again.

A grid opens on the view its URL state names, when it keeps its state in the URL; else on the user's default; else the page's DefaultViewId; else the first view that isn't hidden. A calendar or timeline puts the user's default ahead of the page's DefaultViewId in the same way.

Hiding views

Hide from the view list in Manage views takes a view out of the picker for that user, and Show in the view list puts it back. Any view can be hidden, the page's and Dataverse's included, except the one on screen. A hidden view stops being the user's default. The view on screen is always listed, and a user who has hidden every other view still sees them all.

Where a view is offered

A view is saved for a table, and offered on every control of that table that has saved views on: a view saved on one grid of contacts is offered on every grid of contacts. A calendar's view of appointments alone is also offered on the grids of appointments, and a grid's on the calendars; each keeps its own layout of the view and takes the query from it. A view of several tables, saved on a calendar or a timeline, is offered on calendars and timelines alike. Give a control a SavedViewsKey (React: savedViewsKey) to keep the views saved on it to that control alone:

A key is letters, digits, -, _ and ., up to 100 characters, and compared regardless of case. A control with a key still offers the views saved on controls without one.

Defaults and hidden views are kept for each kind of control: a grid and a calendar share views but not the user's default or what they have hidden. A control without a key keeps them for every control of its kind and table; a control with a key keeps its own, and uses the kind's until it has one.

Dataverse

Install the Power Portals Pro Core solution: it holds the saved-view tables, and its Power Portals Pro Application User role already gives the portal's application user what it needs on them. Nothing else is set up for contacts.

Staff who sign in to the portal as themselves save views as their own Dataverse user, and each sees only the views they own. Give them the Power Portals Pro Saved Views security role from the same solution, which grants the saved-view tables at user depth.