Saved table views: user page and developer guide
Both pages are NEW - there was no wiki page for the shared table engine at all,
so nothing existed to extend.
The user page leads with the thing the request did not ask for and got anyway:
it works on four tables, not one, because Assets, Tasks, Calendar and Change
Management share a table engine. Then saving, who can see it, your default, the
library, editing, and two sections that answer questions before they are asked -
what happens when a table changes underneath a saved view, and why a shared view
cannot show you another company's rows.
Three points it is deliberate about, because each is a decision somebody could
otherwise read as a bug:
- The SEARCH BOX is not saved. A filter is how you like to look at things; a
search is a question you asked once.
- EDITING changes the name and who can see it, not what the view shows.
Renaming should not silently change what something does.
- YOUR DEFAULT is yours. Two people can have different defaults pointing at
the same shared view.
The developer guide records the visibility clause and why it is bracketed - it
is appended to a WHERE that already carries table_key, and an unbracketed set of
alternatives would bind that to the last branch only, putting tasks views on the
asset table. Also why analysts belonging to MANY teams forced sharing to name a
specific one, why the default lives on the reader and last-used on the view, and
the merge that lets a view survive a column being added or removed.
Ends with the traps: .dt-btn scoped to .dt-toolbar so the modal footer had no
padding, an English fallback that rendered {d} literally because it did not
interpolate, and Save view needing the team list before it opens.
Wired into the sidebar and pointed at from all four module pages. The Assets
pointer was moved out of where a generic anchor first put it - halfway down the
page under the right-click section - and into the Table View section where
somebody reading about the table will actually meet it.