This is technically true in a very indirect sense, but not very user-friendly or helpful.

• We should probably write a new edge (PanelHasChildPanel or similar) and show "this panel is embedded in other panels: ..." rather than trying to write the dashboard edge to all children.
• Only the tab panel is affected for the moment.
• The "This panel does not appear on any dashboards." message should be tailored.

I don't think there is much value here in having "appears on", since panels work on dashboards, other panels, or any remarkup, anywhere. Does anyone have a good reason to keep this function? I could create an edge for panel -> panel if we want to keep something like this. But I'm concerned if the point is to "prune" panels, then we'd need to maybe build out mentions as well.

Oh I see above you mention using edges too.

If we make the permission changes discussed elsewhere (T8033, I think?), this might just become something like a containerPHID which points at a Dashboard for panels created from dashboards, another Panel for panels embedded in panels, and null for standalone panels.

The change I imagined there was:

• Remove the ability to "Add Existing Panel" (you can only create new panels).
• When you create a panel from a dashboard, its containerPHID becomes the dashboard, and its view policy is permanently locked to the dashboard's view policy.
• When you create a panel from another panel, its containerPHID becomes the other panel, and its view policy is permanently locked to the other panel's view policy.
• (Or maybe there are separate dashboardPHID and parentPanelPHIDs, that might make some loading stuff easier and keep us out of trouble if someone makes recursive tab panels full of tab panels full of tab panels.)
• When you create a panel as a standalone panel, its containerPHID is null and its view policy is not locked (you can freely edit it).

If I add "short name" as an optional Panel field, I could get rid of naming tabs. Then you just have to select a bunch of panels.

Or maybe icons... everyone loves icons.

As long as you're selecting existing panels in any interface, we're stuck with the problem in T8033. I think we can only fix that elegantly by removing all interfaces where you select panels, and replacing them with interfaces where you create panels.

frickin' tab panels make everything 10x harder.

ok - i'll work on unwinding policy stuff

Getting rid of all "Select Existing Panel" flows also makes simplifying the "Run a query -> turn it into a panel -> put it on a dashboard" workflow a bit more of a mess, especially if we want to try to do "run a query -> turn it into a panel -> add it to a tab panel". But I think in the long term making the T8033 problem impossible and then trying to do our best with the "query -> panel -> dashboard" flow is the best bet.

Like, in the worst case, the flow could go like this:

• Run the query.
• Choose "Add Query to Dashboard..."
• Get a dialog to pick a dashboard (with a typeahead) -- all sane so far.
• If that dashboard has tab panels (or, in the future, other container panels), get another dialog to choose between "Add to top-level dashboard as a new panel" and "add to panel X" and "add to panel Y". This is a little out there but probably still reasonable.
• (Keep getting more dialogs if we implement tab-in-tab-in-tab panels. This is loony but tabs-in-tabs are loony too.)

Yeah maybe I should optimize that workflow first, seems higher leveredged. T5307

I want it to work like like installing to home does basically, see query, click add, confirm, get take to arrange with the panel built and added.

Yeah, and the sane version (add to dashboard, not to tab panel) is probably not too awful and won't really make fixing T8033 any harder.

Yep, that's what I'm thinking too.

I imagine Facts will have similar workflows. The easier we can make it, the less worried I am about re-using panels.