Panels can currently appear on multiple dashboards, so we can't use the dashboard's policy for them directly. If we could, you could always see any panel by creating a new dashboard you have permission to see, adding every panel to it, and looking at the panel you wanted.

Unless you can define a different default dashboard for logged in and logged out users, yeah.
The problem I see:

• I run a phabricator instance where the main part is only accesible for logged in users, but logged out users can still see some tasks.
• My problem: I want to inform my users about different upcoming events etc, for example per text panel
• The logged out users should not be able to see these messages, so I restricted some panels
• The whole problem would be easy to solve, if admins can define: logged in users get dashboard a), logged out users get dashboard b) in my situation

Do we have a good reason for having separate polices for panels?

oh well

There's currently no way to query that, since the dashboardPHID is in a JSON blob in the PhabricatorProfileMenuItemConfiguration table.

One thing I'd like to bring back is "Install" in some fashion, which is easy to prompt and do the legwork on landing it on a home or project menu, but doesn't seem we can let you know where a dashboard is used and if you have it installed.

Nothing set in stone, It just popped into my head as a possible solution

I'd probably use it in Dashboard creation as well for finding Panels.

Generally makes sense to me.

@epriestley I think for Dashboards, and probably other applications, having some sort of compound typeahead/select would be helpful. I think maybe we can abstract this into using ApplicationSearch as the filter, and the tokenizer for the final results. Thoughts?

I plan to look into this stuff after new home settles

This picked up a few options through engine support and T11957 is adding some more. Particularly, default view is now "Authored" which I think resolves the original issue. I think the more-root problem is "Dashboards are kind of weird with all the panel copying", which is something we're aware of.

T11957 is the modern followup for this.

• Over time, we've drained the swamp to some degree on the default home page, by moving toward more useful defaults.
• We implemented Dashboards. Although we'd like to improve them, they've allowed ambitious users to fix this themselves for some time.
• See T11957 and M1473 for modern followups with a more concrete plan to lay this to rest.
• See also T11132 for discussion of NUX-oriented changes, specifically.

Same problem here. A way around this problem is to not re-use panels: Creating a completely new panel is adding it only once, however picking an existing panel is adding it twice.

Design atrocity incoming for T10747.

Having the same issue. Seems to only occur on certain panels. Adding the panel in question to a column now creates a duplicate in the opposite column. Removing the panel from one column removes it from both.

T10612: Editing a panel causes it to duplicate in dashboard may be the same root cause as this bug.

I'm also seeing this bug.

I was looking for similar functionality (publish the state of some external system on a panel) and instead of updating the entire panel I think it would be nice to use Phlux or Paste:

Just encountered the same problem :(

After D16226, panels no longer support tagging.

Turns out that CustomFields sort of just work properly with EditEngine out of the box, so D16226 provides a technically-functional dashboard.panel.edit, which allows you to edit text panels like this, for example:

Merging over into newer task.

im gonna do this task. im gonna do it up real nice.

T5317#64279

An E_PERM panel seems reasonable here, but I'd like to add a use case for hiding.

I accidentally stumbled across the root cause for this and I think the fix is a one-liner, so it should work better after D15391.

Note that those are the actual names of the tabs (not, say, some weird internal hash, as I thought at first glance), the list just isn't getting rendered properly:

I just ran into a fun issue that @avivey helped me figure out,