Problem: Sidebar tree can sometimes repeat the same sibling records, causing infinite scrolling

[PeteVox]

Current Behavior

Steps to reproduce the behavior
This behaviour isn't consistent, but can appear when expanding hierarchy branches containing more than 8 records. The sidebar tree shows initial 8 records with '{X} more...' link below. Clicking this link, or scrolling the tree downwards triggers a call to {atom url}/{slug}/informationobject/treeView?show=nextSiblings&resourceId={id}. This can return 7 records - the first 4 siblings, then a repeat of the first 3. This behaviour then repeats on subsequent requests to get 'nextSiblings'. This behaviour is only relevant in the sidebar tree. An affected collection displays records correctly in full-width tree, or when displayed as a 'list'.

Example returned set from a broken nextSiblings request:

• Item K/PP149/2/2/10 - Papers, 1959-1966, relating to Saunders' MD thesis, 'The control of pain in terminal cancer'
• Item K/PP149/2/2/11 - Transcripts, 1960-1963, of recorded conversations between Saunders and patients at St Joseph's Hospice, London
• Item K/PP149/2/2/12 - Transcripts of interviews, 1960-1963, with patients with surnames A-C, St Joseph's Hospice, London
• Item K/PP149/2/2/13 - Transcripts of interviews, 1960-1963, with patients with surnames D-F, St Joseph's Hospice, London
• Item K/PP149/2/2/10 - Papers, 1959-1966, relating to Saunders' MD thesis, 'The control of pain in terminal cancer'
• Item K/PP149/2/2/11 - Transcripts, 1960-1963, of recorded conversations between Saunders and patients at St Joseph's Hospice, London
• Item K/PP149/2/2/12 - Transcripts of interviews, 1960-1963, with patients with surnames A-C, St Joseph's Hospice, London

Expected Behavior

The request to {atom url}/{slug}/informationobject/treeView?show=nextSiblings&resourceId={id} should return the next 'N' sibling records without repeating.

Possible Solution

It looks like the helper method @

atom/lib/model/QubitInformationObject.php

Line 2309 in f7f5a63

public function getTreeViewChildren(array $options = [], &$childrenRemaining = null)

doesn't refer to any offset or 'start' parameters. The caller @

atom/apps/qubit/modules/informationobject/actions/treeViewComponent.class.php

Line 20 in f7f5a63

class InformationObjectTreeViewComponent extends sfComponent

seems to just pass the current resource into getTreeViewChildren(), which runs a fresh query that finds the very first child of that resource, then gets the 'next' siblings ... so each fetch starts from the same first child. No offset or 'current child' is passed in (?) - so pagination still anchors to the first record, and the 'next N' list repeats those earliest rows.

Context and Notes

No response

Version used

AtoM 2.9.1 and 2.9.2 (not tested in 2.10+)

Operating System and version

Ubuntu 22.04

Default installation culture

en

PHP version

No response

Contact details

No response

[fiver-watson]

Hi Pete!

For the devs, I can add a bit of historical context. From what I recall, this bug tends to appear when basically any treeview sort method OTHER THAN "Manual" is configured in Admin > Settings. When other settings are used (like Identifier, or Title - identfier, etc) then there are a couple complications that enter into the sort calculations, including a) the fact that no fields are required, so some records may not have a title OR identifier, and b) for titles, translations and culture fallback add further complexity.

I don't remember the more technical explanation I was given more than a decade ago (though I do remember it was back when PHP and MySQL had less functions to manage sorting properly), but I believe it had to do with trying to sort on NULL values and getting caught in a loop.

In any case, the workaround that has seemed to work for end users was:

1. Switch the Treeview sort settings back to manual
2. Clear cache, restart PHP-FPM, and rebuild the nested set.

Would love to see sorting improved, and also able to apply to the full-width treeview as well - hope this information might help with analysis.

[PeteVox]

Thanks Dan (and great to hear from you). To confirm that switching sidebar tree sorting to 'Manual' corrects the issue. Much appreciated.