Tree picker in partial restore should use mini list view for nodes configured as list view

[bjarnef]

When doing a partial restore it is possible to select specific content to restore from remove environment. However the tree picker doesn't seem to respect list view nodes, where the tree picker should use mini list view. Instead I can expand tree nodes of a list view node, which cause the application to crash, e.g. with 10K child nodes.

Umbraco v10.4.0
Deploy v10.1.2

[bjarnef]

@AndyButland Not sure if it is related to this though? #146

[AndyButland]

Not related I think, but rather a separate, valid issue. Thanks.

[bjarnef]

In my use-case the application didn't like expanding 10K+ tree nodes... and others with several hundreds nodes did expand, but was quite slow.

[bjarnef]

@AndyButland does Deploy know if tree nodes are listview when the tree structure is shown at e.g. partial restore?

I would like to restore a specific content node in an listview archive with 10K+ nodes, but Deploy here expands all nodes unlike content picker / MNTP in Umbraco core, which I think repect this and show mini listview.

I think it is same issue for media and possible members too.

Umbraco v13.8.1
Deploy v13.4.0

It was able to show all tree nodes after a while and I could select the specific node, but the experience wasn't great.

It would be useful if it could respect the listview for specific nodes.

[bjarnef]

Furthermore I also noticed unpublished state isn't reflected in tree picker, but also protected content node.

[ronaldbarendse]

Hi @bjarnef,

Thanks for keeping this one alive and adding more context afterwards. Some background on why the picker behaves the way it does: the tree items Deploy requests from the remote environment only carry an identifier (the GUID plus the entity type), a name, an icon, whether the item has children, and a reference to its parent. That is the full contract between the environments, so the picker has nothing to base a published, protected or trashed indicator on. Those states also don't exist for several of the entity types this same picker serves (dictionary items, members and member groups, for example), so surfacing them would mean extending the cross-environment tree contract per entity type rather than only changing the UI.

On the mini list view itself: the picker doesn't switch to a list view for nodes configured with one, and that isn't something I'm planning to add right now. The changes coming for #321 (see also #330 (comment)) should take the sting out of the underlying problem though:

• Paging: children are fetched a page at a time with a "Load more" button, so opening a node with 10K children no longer pulls in the whole level at once.
• Search: the picker's search field now searches the remote environment, so you can find a node by name at any depth and pick it directly instead of expanding your way down to it.

Between those two, the scenarios that made a list view attractive here should be covered. This lands in an upcoming minor release.