Page MenuHomePhabricator

Build Portals: a standalone menu page / dashboard of dashboards
Closed, ResolvedPublic

Description

See PHI374. An install would like dashboards of dashboards.

We currently have editable menus on the home page, the favorites menu, and on project pages. A reasonable extension of this is to allow users to create an object which is basically just a standalone menu. This supports building a collection of dashboards and other resources to serve as a home page for a team, or to give executives a more concise view of the world. This object is a "Portal".

  • Portals should support Ferret for the datasource on the "Install on Portal..." workflow.
  • Portals should support project tags.

Problems with ProfileMenuItem:

  • T12871 is really an infrastructure design issue.
  • T12949 is somewhat related.
  • More items in general could probably have custom icons (T12127).
  • T12098 is a hastily fixed bug.

Event Timeline

epriestley triaged this task as Normal priority.Mar 29 2019, 5:25 PM
epriestley created this task.

Just musing to myself:

I think that most of the issues here center around "MenuItem" not being a sufficiently strong / complete object.

  • In T12871, we have issues with menu items not properly interacting with policy/visibility stuff.
  • In T12949, we have issues with menu items sort of not having a sufficiently strong sense of identity and individuality.
  • Here, the first issue I'm running into is that ProfileMenuEngine just 404's if there aren't any valid items. This is lazy and wildly unhelpful.

I think my general approach here is going to focus on making "MenuItem" objects into more capable objects that are less of a flimsy shell around a little bit of display behavior. For example, they should have "inaccessible" states for policy stuff, should be uniquely addressable, and should have a more first-class relationship with the rendering pathway.

I think some of this is probably things being under-designed, and some of it is laziness in handling empty/error/policy states, particularly because they weren't a primary state in the original implementation on Project pages.

In T12949, we have issues with menu items sort of not having a sufficiently strong sense of identity and individuality.

Generally, the issue here is:

  • A menu is a list of PhabricatorProfileMenuItemConfiguration objects. These are a mix of stored objects from the database (things users have added) and runtime objects created by the engine (like the "Edit Menu" action).
  • These each generate zero or more PHUIListItemView objects to actually create items in the menu. A given Configuration is free to generate as many actual display menu entries as it wants. Today, they always generate zero or one, but I think this may not always be true (see D18346 and T12871 for examples, including "links to things tagged Y" or "all wiki children of document X"). These use cases seem pretty reasonable to me so I'd like to retain this capability.

However, a lot of the glue code gets kind of confused in the transition layer here. For example, we select a Configuration, even though that doesn't make sense if a Configuration may generate two or more items, since we could not select them individually given the current API.

I think I can fix this very narrowly for now and wait for it to become ripe later on (when we actually want something to emit multiple display items). It will very likely require API changes some day, but this API is not seeing a lot of churn and I think there's not much advantage to doing this work now versus making future-me do it.

These work now. If they see use, we can build them out in greater detail.