Proposal: Consider raising the default installation value for the full-width treeview's "Items per page" setting

[fiver-watson]

Current Behavior

Context and background

The full-width treeview has a rather storied history. At some point pre-2.5, many users were reporting issues with the tree not loading at all for larger hierarchies. In Issue 12611 we adding paging for the full-width tree, starting at 50 nodes. However, any top-level description with more than 50 immediate descendants would have problems loading and correctly positioning the node view of the tree for any result outside of that initial limit.

This pre-history (and some of the subsequent steps considered) is captured in the attached PDF from 2020, which is also found on the Wishlist ticket linked below:

• AtoM treeview paging - issues and proposed solutions summary 2020-03.pdf
• https://projects.artefactual.com/issues/13293

We later increased the pager max setting value to 10,000, and added the ability to increase even further via configuration file. See:

• https://projects.artefactual.com/issues/13320
• (see also note-5 on that ticket for discussion of the config setting)

Current issues

Per the documentation, at installation the current max value for this pager is set by default to 50. See:

• https://www.accesstomemory.org/docs/2.8/user-manual/administer/settings/#items-per-page

However, the problem being:

• We are increasingly encountering users who have hierarchies that surpass this limit. Here is the most recent report from the user forum: https://groups.google.com/g/ica-atom-users/c/ARDljnpQwZE/m/VE2YLOJVAgAJ
• Without someone knowing the entire history of the full-width treeview's development, the purpose and intent of the "Items per page" setting is opaque, and not intuitive
• Most users do not know this is even a setting. Consequently we get bug reports about the treeview that turn out to be confguration issues when investigated, as shown above
• We originally set the value to 50 out of an abundance of caution. However, with our recommended installation guidelines of at least 7GB of RAM, we have not heard reports of issues with the setting being set to its max value of 10K, nor have I personally seen issues with it throughout several years of QA testing since the 2.5 release

Expected Behavior

• Except for EXTREMELY large hierarchies with more than 10K children under a single node, most users should be able to use the full-width treeview without needing to adjust the Items per page setting

Possible Solution

I propose that we consider increasing the default Items per page value for new installations to a very high value, such as 8,000. Analysts can set this and use it during testing for the entire pre-release period, while testing with large hierarchies, to confirm it should not be an issue. If not, then a schema migration for the default fixture value can be included in a release, and the new default value raised.

This should alleviate many reports of treeview issues that turn out to be configuration problems.

Given that there are also many other options between 50 and 10,000, a compromise would be to increase it but not to the max value - for example, setting the default to 1,000, or 2,000 would still likely avoid invalid reports for all but the largest hierarchies, without rendering the setting pointless

Context and Notes

No response

Version used

2.8, but the issue is also in 2.7 / 2.6

Operating System and version

Ubuntu 20.04

Default installation culture

en (but affects all)

PHP version

PHP 7.4

Contact details

No response

[fiver-watson]

Awesome! Do you have a method of tracking related docs changes that are required, or should i just open a separate docs issue? This change will need a quick update in the docs here, and probably a quick search to see if the default limit is mentioned anywhere else.

[anvit]

@fiver-watson Ah, thanks for the reminder. I just created a docs issue for this here! artefactual/atom-docs#266