Hierarchy display after search

[Chris Selwyn]

I am experiencing a curious symptom with the hierarchy display after doing a search.

When I do a search using the search box at the top and then select one of the results, I find that the hierarchy display does not synchronise on the item I have selected. The details of the item appear as expected including the path to the item. However, the hierarchy element only contains the root of the tree and it is not expanded down to the item itself.

I'm guessing that there is some data condition that is causing this to happen. It does not happen on every item in the repository but on those items where it happens, it always happens and becoming quite annoying. I cannot see any significant difference between those items where it works and those where it does not.

Is there something that I can do to make a searched item be always selected correctly in the hierarchy display?

Chris Selwyn

[Chris Selwyn]

I should add that if I navigate down the hierarchy tree then the display works just fine. The problems only happen when I select an item that I have searched for.

Chris

[Chris Selwyn]

OK... I have found what is going on. 

I noticed that the problem only occurs when I select something that is within a container that occurs at the end of the list of items in the treeview and I can only see the item if I click the 

That got me thinking that maybe the problem only occurs on those items that I can only see if I hit the "<n> more" button on the treeview. So I increased the "Settings→Treeview→Full Width→Items  Per Page" and (lo and behold) the item that I have searched for appears in the (now longer) TreeView display.

Since I am in a process of reorganising my entire repository, I temporarily have more items in the display than there will be when I have finished and that has pushed the list size to over the treeview "more" threshold and hence the problem.

So I can now see why this is happening. The question is ... Is this correct behaviour? 

Could I suggest that, if an item that is selected via a search occurs (or is in a container) that is over the "Items Per Page" limit then that item should be forced to be displayed anyway despite it being over the limit? 

Chris

[Dan Gillean]

Hi Chris, 

I'm glad you figured it out, and sorry that we weren't able to reply before you managed to sleuth the correct answer on your own. 

Could I suggest that, if an item that is selected via a search occurs (or is in a container) that is over the "Items Per Page" limit then that item should be forced to be displayed anyway despite it being over the limit?

That sounds great, but... if it were that easy, then we simply wouldn't include a pager setting at all! Note that we do ensure that the record itself displays (i.e. the view page of the description; the main part of the page) - however, the treeview is a hierarchical entity, meaning the entire thing must be loaded into memory to be able to determine the current position in the hierarchy. If the client browser does not have enough available resources, then the tree never loads at all - the user just gets an infinite loading icon that never resolves. 

The pager was our first attempt to chunk this out and be able to solve issues with large hierarchies displaying properly, while also balancing performance for all users. We have made a few incremental improvements since (such as increasing the available paging limit setting to 10,000 nodes), but the biggest next enhancement we could make (allowing for bi-directional paging) will require a lot of development and analysis to implement. 

If you would like to know more background: there is an old AtoM Wishlist ticket here that has a PDF attached, summarizing some of the background of the full-width treeview and paging: 

• https://projects.artefactual.com/issues/13293
  

We have since implemented all the recommendations explored in that analysis, except for the most expensive and complex option, the bi-directional paging support. We would love to be able to do this work in the future, but thus far no partner institution has prioritized its development and when the setting is configured correctly, we have generally not been having issues reported about treeview loading issues. As such, right now the Maintainers are focused on completing the last stages of the Bootstrap upgrade, as well as looking at upgrading some of AtoM's other core dependencies (like PHP, and the search index) for the next release. 

However: 

We initially set the default value of this setting to 50, out of an abundance of caution. In practice, I have noted that with the recommended technical requirements in place (i.e. at least 7GB RAM, per these suggestions in our documentation) that even the max value of 10,000 does not seem to cause issues. 

Consequently, I have filed a proposal issue ticket for us to increase the default value, so more people don't run into the same problem that you did. See: 

• https://github.com/artefactual/atom/issues/1748
  

Again, sorry for the confusion, glad you sorted it out, and thanks for the feedback! 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/01931cba-b913-4126-9d48-5fc16e3eafd6n%40googlegroups.com.

[Chris Selwyn]

Thanks for the explanation and I'm happy that this is a problem that you have already put some thought into. It certainly had me puzzled for a while.

I'm still not really sure why it can't simply display the path back to the root as part of the tree without having to display anything else but then, I'm not familiar with the internal working of the application.

Here's hoping you get something worked out so that future users don't have to go through the head-scratching that I did!

Chris

[Dan Gillean]

Hi Chris, 

In fact, it looks like the developers are already working on it, and will be increasing the default configuration limit significantly. Going forward, unless someone attempts to create a top-level record that has MORE than 8,000 immediate children (i.e. no intermediary levels like series, just 8,001 or more items right under the top level), then most folks won't need to adjust or even be aware of this setting. 

We originally set the paging limit quite low (at 50) out of an abundance of caution, but after several years of seeing how it behaves on a moderately resourced machine (such as our public demo site, etc) when set higher, we now feel more confident increasing this default. 

Thanks again for your feedback! Expect this default change to be included in the next major release. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/14c5761c-ee85-479d-a853-e20f4fc1e37bn%40googlegroups.com.