Page MenuHomePhabricator

Remove the hard-coded homepage, and other Dashboards improvements
Open, NormalPublic


Problems with Dashboards:

Minor stuff:

  • Moving panels is currently a jank-fest.
  • Picking up a panel causes it to visually offset in an incorrect way.
  • In Safari, dragging panels at certain browser widths feels sketchy (???)
  • Old edges and edge transactions could possibly use cleanup.
  • See PHI915, which would like dashboard documentation.

Need Followup:

Resolved Issues

  • "Favorites" should render a menu when rendering content.
  • The dropshadow effect on hover/pick is probably a bit too intense.
  • Deleting a panel redirects to the wrong place. I want to replace this menu, anyway.
  • Template menu on creation should be a modern "clickable" menu.
  • Panel type selection should be a modern "clickable" menu.
  • T12363 is a bug that may be a mess to fix.
  • T6444 can probably be wontfix'd.
  • T9903 is probably easy.
  • See PHI997. Editing and reordering tab panels is a weird, janky mess.
  • Dashboards should update to Ferret.
  • Panels should update to Ferret.
  • Dashboard NUX is probably wrong.
  • Remove obsolete PhabricatorDashboardInstall.
  • See PHI945. An install managed to add a panel to two different columns (how?). This made a lot of stuff not work great and made the panel not removable. This state should probably be formally supported and operations against dashboard should specify more than just a panel PHID, but at a minimum it shouldn't break.
  • See PHI727. Typeahead searches for panels don't use a real index.
  • We need a double-background migration for all this stuff?
  • The "add query to panel" flow needs a revisit.
  • When you're editing a tab panel, all the panels inside the tab panel can be dragged and reordered. Great!

Default Home Page: The default home page looks like a dashboard but is currently hard-coded. Instead, it should be composited from Dashboards.

The hard-coded nature of the page means that a lot of edge cases either don't work or would need to be implemented twice in order to work. Overheating, below, is one example.

  • This was resolved by D20333.

Overheating: Overheated queries recently began throwing exceptions by default. In some cases, this causes problems on the home page:

Panels should allow queries to overheat and handle this case gracefully.

  • This was resolved by D20335.

More Results / View All: Query panels currently give users very limited tools to determine:

  • Are there more results?
  • What do I click to see them?

See PHI854. See PHI1105.

Particularly, the header is linked but it isn't obvious that it's a link since it isn't colored. An unlabeled icon links to the results, but doesn't work on tab panels, doesn't look like a button, and doesn't convey any state information.

These actions should be obvious in the UI and work properly on tab panels.

  • This was resolved by D20336.


  • In T12745, Conpherence items being addable even with the application uninstalled.
  • In T12167, no mobile access to add items to a profile menu.

Revisions and Commits

rP Phabricator

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

The remaining bugs I want to fix here are:

T8033: Inform editor when panels have more restrictive policy than dashboard

I'm not really sure what's left here, but I believe the desired behavior is fairly straightforward:

  • When you can't see a panel, it should render "Restricted Panel", not fatal/hide the panel/whatever.
  • When you can't see a panel in a tab panel, it should render a "Restricted Panel Tab", not fatal/hide the panel/break/explode/whatever.
  • In the cases where we know policies are strictly stronger or weaker than other policies (which is non-exhaustive, but covers many common cases) we can can show a warning in edit/arrange mode.

T8033 floats some alternative behaviors like:

  • Remove policies on panels.
  • Give users who can view an object containing a panel automatic permission to view the panel.

Maybe we'll end up here eventually but I think these are generally trading away policy-safety for ease-of-use and I don't think that's the right tradeoff. If we do end up here, I'd probably do it by differentiating between "standalone" panels and "embedded" panels (part of a dashboard/other-panel only, bound to that container strictly). This may happen -- and may even happen here -- but I'm currently hoping to leave it for future changes.

T6018: Panels used by Tab panels appear as "This panel does not appear on any dashboards."

There's a long unrelated discussion on this one, but the basic "we should index panel usage properly" is fairly straightforward.

T12363: Configuration of "Tab Panel" is lost when 1st tab has no panel assigned

This is a simple bug but might overflow into a whole lot of rewriting. These are probably also related:

PHI945 - An install managed to add a panel to two different columns (how?). This made a lot of stuff not work great and made the panel not removable. This state should probably be formally supported and operations against dashboard should specify more than just a panel PHID, but at a minimum it shouldn't break.
PHI997 - Editing and reordering tab panels is a weird, janky mess.

The "reordering/layout" code and the "editing a tab panel" code aren't the same pathway, but all of this is largely just "the edit code is pretty old/sketchy".

T7216: Make it easier to update the ApplicationSearch saved query used by a dashboard panel

This one is fuzzy for now. There are currently a lot of workflow issues where updating things requires many more steps than it should.

T8033 - I'm not really sure what's left here...

This already seems mostly fixed. Here's the panel view:

Screen Shot 2019-04-01 at 8.13.11 AM.png (122×1 px, 12 KB)

Here's the tab view:

Screen Shot 2019-04-01 at 8.14.41 AM.png (139×1 px, 10 KB)

I'll tighten these up and add some more tailored warnings, but this is roughly what I think the desired behavior is.

Currently, Dashboards have a "View" mode, an "Arrange" mode, and a "Manage" mode.

I think we can get rid of these now that we have portals, assume that "View" is effectively always covered by installing the dashboard to some menu (Home, a Portal, a Project, etc), and combine "Manage" and "Arrange" into a single view to start simplifying behavior here.

Panel type selection should be a modern "clickable" menu.

Bad news: big mess.

Panel creation is currently handled by two controllers, an "Edit" controller and an "Editpro" controller. It also relies on custom fields. Transactions are nonmodular. The addition of panels to a dashboard is ad-hoc.

So this is going to be a whole series of changes, probably:

  • Modularize panel transactions.
  • Modularize dashboard transactions? Can I skip this for now?
  • Add an "add panel to dashboard" transaction to panels.
  • Replace the "Edit" controller with the "Editpro" controller.
  • Move all the custom field stuff to EditField stuff. This is going to go poorly with tab panels.

It may be possible to have this avoid spilling over into dashboards completely, although I'm not terribly hopeful.