Title: File Management (Angular): opening a sub-folder from the list returns to the root when its tree node has not been loaded
@volo/abp.ng.file-management 10.3.0, @abp/ng.core 10.3.0)orders_exports) containing several dozen sub-folders — we have 77, one per order./file-management, so the directory tree holds only the root's children.orders_exports. It opens correctly — breadcrumb All files > orders_exports, 77 items.All files and the root content is listed.The module is used as-is: route created with createRoutes(), no custom wrapper, no replaced components.
A folder can only be opened if its node has already been loaded into the left-hand directory tree. Opening a sub-folder whose branch has never been expanded sends the user back to the root.
It works if orders_exports is first expanded with the + in the left tree, and then the same sub-folder is clicked. That is the only difference between the failing and the passing case.
It also happens through the filter box, which is how we first noticed it: filtering inside a folder shows the match, and clicking it returns to the root. The filter is not the cause — step 4 above reproduces it with no filter at all.
The problem only shows up with many sub-folders: with two or three the tree gets expanded easily and nothing looks wrong, which is probably why it has not been reported in this form.
before the click: GET /api/file-management/directory-descriptor?id=89ba7949-…&skipCount=0&maxResultCount=10
after the click: GET /api/file-management/directory-descriptor?skipCount=0&maxResultCount=10
No id on the second one, i.e. the root.
DirectoryTreeService.findFullPathOf(folder) rebuilds the path by walking this.treeHolder.getList(), which contains only the nodes already fetched into the tree. When the folder is not there, the while loop never runs and the method returns [ROOT_NODE].
NavigatorService.goToFolder() then undoes its own work:
goToFolder(folder) {
this.currentFolder$.next(folder); // correct folder
this.updateCurrentFolderPath(folder); // -> next([...findFullPathOf(folder)])
}
next(newValue) {
this.navigatedFolders = newValue; // [ROOT]
this.currentFolder$.next(this.getCurrentFolder()); // overwrites with ROOT
this.updateStream.patchStore({
currentDirectory: this.getCurrentFolderId(), // empty
});
}
currentDirectory ends up empty, so the list reloads the root.
As a minimum, when the path cannot be rebuilt, keep the folder itself rather than discarding it:
if (!retVal.length && folder?.id && folder.id !== ROOT_ID) {
retVal.push(folder);
}
That alone makes the folder open, but the intermediate breadcrumb entries stay missing, and goUpFolder() then returns to the root instead of the parent, because the path is only [root, folder].
We went one step further in our local patch: when the clicked folder is not in the tree, we rebuild the real path from the server, walking up with DirectoryDescriptorService.get(id), which also returns parentId — two requests for a folder one level below the root. The breadcrumb is then complete and goUpFolder() behaves correctly, with the tree still collapsed.
The filter box is not cleared when entering a folder. After filtering inside a folder and clicking a result, the newly opened folder is queried with the previous filter still applied, so it shows "No data available" even when it has contents. Clearing the box reveals them. We expect the filter to reset on folder change.
One detail if you fix it from outside FileManagementFolderFilterComponent: clearing list.filter from the content component re-queries correctly, but the input keeps showing the old text, because the filter component is OnPush and nothing marks it for check. We ended up clearing it inside the filter component itself.
Our operators reach every order's exported files through orders_exports. Until the patch, none of those folders could be opened from the list, so the files could not be downloaded.
