"Confirm Publish" Hierarchy Diagrams (Sidebar)

[edschema]

Designs:
confirm publish hierarchy diagram mid/hifi Figma link for all block levels

Section	Subsection	Unit	Component

Spec

1. Component and it's child and parent components are shown in a vertical stack as displayed.
2. If a component does not have parent objects, there will be no parent level shown.
3. If a component does not have child objects, there will be no child level shown.
4. If a component has multiple parents or children, the name will be replaced with "n Sections" or "n Components"
5. The names of blocks should be truncated at 18 characters
6. Components should show all ancestors

In scope

1. Publish review hierarchy shown here

Not in scope

1. Hierarchy view for the usage tab
2. Fully featured new structural block sidebars

Related Tickets

Publish section/subsection #1977

[pomegranited]

Hi @edschema @sdaitzman CC @jmakowski1123 @bradenmacdonald

Is it ok if these container hierarchies show only the immediate parents of the current container (which remain in Draft), and the immediate children (which will be published)?

Currently (as of openedx/openedx-platform#36806), we only index one level up to a library object's parents and one level down to its children. For example, when preparing to publish a Unit, I can easily show the Subsections that contain that Unit, and the Components contained by the Unit, but not the Sections that contain the Unit's Subsections.

We can update the index to store the entire hierarchy for every library object, but this will require some care to mitigate the potential performance impact of even a small change to an object's title or its container membership.

[bradenmacdonald]

@pomegranited Yeah, I want to avoid adding any more levels than that to the search index; I think it gets too complex. Even having both parents and children is questionable, so we have to see how it goes :p But for any situation like this where we're just looking at a single component, could we use the API to load the full hierarchy (not from the search index) if needed?

[sdaitzman]

Hi @pomegranited @bradenmacdonald, will discuss this and get back to you, but I think this level of visibility (showing the full hierarchy of parent/at least some child relations within a library) will be important for a few features going forward.

Is the performance implication about speed of being able to display this type of information? If it's on the order of a few extra seconds, would it be feasible to show a loader while the full diagram is prepared?