###

# Begin of the insertionProbem scopeEnd of the insertion Begin of the deletion Steps to reproduceEnd of the deletion

Begin of the insertion**Context**

End of the insertion 1. Have a project hierarchy like this:

* Parent A 

* Child A1

* many child projects

* Child A2

* many child projects

* Child A3

* The child projects of A1 and A2 need to be more than 300 in sum

2. Open the project selector


Begin of the insertion**Problem**End of the insertion Begin of the deletion <br>End of the deletion

Begin of the deletion # What is the buggy behavior?

End of the deletion * Begin of the insertionIn the top left project selector,End of the insertion Child A3 is not shown because the loading limit was reached before by the children of A1 and A2


<br>

# Begin of the insertionAcceptance criteriaEnd of the insertion Begin of the deletion What is the expected behavior?End of the deletion

* Change the loading strategy Begin of the insertionof the top left project selectorEnd of the insertion so that

* Root elements are loaded Begin of the insertionfirst (with a limit of 300)End of the insertion Begin of the deletion before the hierarchyEnd of the deletion

* Begin of the insertionOnly when expanding a node,End of the insertion Begin of the deletion OnEnd of the deletion the Begin of the insertionchildren are loaded (also with a limit of 300)

* When there is a project which has a parent which I am not allowedEnd of the insertion Begin of the deletion inital (non-filtered) state, it should be possibleEnd of the deletion to Begin of the insertionsee, it will appear as a child ofEnd of the insertion Begin of the deletion browserEnd of the deletion the Begin of the insertionnearest visible grand-parent

* The loading strategy for searched lists orEnd of the insertion Begin of the deletion whole hierarchy (andEnd of the deletion the Begin of the insertionfavourited list remains untouched

End of the insertion Begin of the deletion tree should load asynchronosuly if needed)

End of the deletion * **Technical note:** Begin of the insertion

End of the insertion Begin of the deletion

End of the deletion * Therefore the initial server response needs to be an async TreeView within the async FilterableTreeView Begin of the insertion


End of the insertion Begin of the deletion

* _Open: Do we still want to start loading children (if the limit allows) to avoid later calls or rather only the first level elements?_

* The loading strategy for searched lists or the favourited list remains untouched


<br>

End of the deletion ### **Behaviour specification (following the example from the steps to reproduce above)**

**Scenario 1: Initial state (user is not in a project):**

* Parent A is loaded but collapsed

* When A is expanded, all its direct children are loaded asynchronously (so A1, A2 &amp; A3)

* the loaded children are collapsed

* When I afterwards expand A1, all the direct children of A1 are loaded

* those loaded children of A1 are also collapsed

* In all these actions, the current limit of 300 remains


**Scenario 2: Initial state (user is on a project page of project A1):**

* Parent A is expanded and all its direct children loaded (so A1, A2 &amp; A3)

* General rule: If a node is expanded automatically, than this node, needs to contain **all** the data (not only partial hierarchies). That means, that when the user is on grand child A1.1, the selector loads the parent A1, the grandparent A and since the latter is automatically opened, also A2 and A3 need to be loaded. Those two can be collapsed Begin of the insertionthough.End of the insertion Begin of the deletion though. End of the deletion

* A1 is marked as selected but collapsed

* When a node is expanded, the direct children of that node are loaded (like above)

* In all these actions, the current limit of 300 remains


**Scenario 3: When searching/switching to favourited:**

* The first 300 matches and their ancestors are shown (all expanded). This is the current behavior

* The tree is not loading anything afterwards when collapsing/expanding


<br>

###

# Environment information

**Browser**

* [x] Chrome
* [ ] Firefox
* [ ] Safari
* [ ] Mobile Safari
* [ ] Other (please specify)

**Operating System**

* [ ] Windows
* [x] Mac OS X
* [ ] Mobile iOS
* [ ] Mobile Android
* [ ] Linux (please specify distro)
* [ ] Chrome OS
* [ ] Other (please specify)

<br>

# Original ticket

**What is the buggy behaviour?**

> Since OpenProject 17.6.0, projects in the project preview can be collapsed, which should improves clarity, but as a result, all subsequent projects are cut off. In addition, projects seem to be missing randomly in between. That alone creates chaos and makes it difficult to get a good overview. Combined with the long-standing bug where page breaks disrupt the sorting in the actual project list, it’s effectively impossible to keep track of projects right now. After the identifiers, this is the second major “Verschlimmbesserung”.

<br>

**What is the expected bebavior?**

> The project lists—whether in preview or full view—should always display all projects, without exception! That&#x27;s their only job!