Full width treeview autoload not working for descriptions outside the initial limit
|Target version:||Release 2.6.0|
|Google Code Legacy ID:||Tested version:||2.5, 2.6|
We recently added the possibility to load the treeview in batches with a "more" button. This limit is hard-coded to 50 descriptions (recursively) by default. When you visit a description outside that range the treeview doesn't expand automatically because the current node is not yet loaded.
If you have access to the code, the limit can be changed in here. Otherwise you will need to create an archival description with more than 50 children and visit the child number 51 or higher directly.
Even when the auto-load works (selecting a node inside the limit) the nodes are expanded but the selected one is not getting focus. If the node is bellow the initial treeview height, you need to scroll manually to get to it. I think this was working before too.
#1 Updated by Mike Cantelon about 1 year ago
For the main issue pointed out in this ticket, we likely need to have the full treeview JSON action (
apps/qubit/modules/default/actions/fullTreeViewAction.class.php) "page" through results until if gets to a page of results with the resource's ID in it... or, maybe better, do this on the client side with JS (
#5 Updated by Dan Gillean 11 months ago
I created a test CSV (attached) that has over 1,000 immediate children from the top-level record. I then tried modifying line 50 of js/fullWidthTreeView.js to increase the default load to 1,000.
The correct node was selected - but the issue is also that the treeview pane itself does not scroll to the correct position, so if your result is way down in the initial node, it's difficult to find it. Ideally, the tree would load in the pane with the selected node visible.
Vidcast of what I'm talking about: https://imgur.com/a/ubFXfgc (mp4 file also attached)
#8 Updated by Dan Gillean 11 months ago
- Status changed from QA/Review to Verified
- Target version set to Release 2.6.0
- Requires documentation set to Yes
The solution that Mike has added is 2-fold:
first, a bug fix for the JS in the treeview to make sure the window shows the selected node, and that the target node is selected / in focus. Second, a configurable setting (added to Admin > Settings > Treeview) that allows the user to adjust the default paging limit. The default value is still 50, but can be set to anything between 10 and 1,000.
I tested this primarily against three real hierarchies, provided by users who have encountered this issue. One file was a collection with nearly 900 immediate children; the other was a multi-level file, with at least 3 sub-fonds, each of which had many series, subseries, files, and items nested beneath; the last of which had only about 10 series, but each series had hundreds of item level children.
I set the pager to its maximum value (1,000), and then would search for lower-level records in the hierarchy, to navigate to them directly. In all cases, it never took longer than about 1.5 seconds for the tree to load correctly.
With this approach, the treeview behaved correctly on all the real-world sample data i had to work with - regardless of where a record was in the hierarchy, it was displayed correctly when navigated to directly.
HOWEVER: this fix does not address the original issue - which can be recreated by setting the pager back to the default value of 50. In that case, if you search for a record outside of the initial 50 record load and navigate to it directly from the search results, then the tree is collapsed, showing only the top-level record, and giving the user no context as to where to look to see it. If it is a descendant but the immediate parent is not in the initial load (for example, an item in Series 51, where the series is not in the initial load) then the result is the same.
So.... for the vast majority of users, this should solve the issue if the pager is set to its maximum value. But if we encounter enough real-world examples that are organized differently (for example, hundreds of thousands of immediate children), we may need to revisit this issue.
#9 Updated by Dan Gillean 7 months ago
- Requires documentation deleted (
Documentation updated in 2.6 docs branch: https://github.com/artefactual/atom-docs/commit/8a50a6666caa6d2d6f83ddbdebee87b7d30afd76