Asset Picker: list panel should show content only, with folders navigated through the sidebar tree

[nicobytes]

Problem Statement

Split out of #37174 (finding 9), from the post-merge QA of #37207 — TC-001 Failed.

The Asset Picker's right-hand list panel shows folder rows with a selectable radio, mixed in with files and pages, and a folder can be returned as the picked value. QA expects the list to carry content only, with folders navigated through the sidebar tree.

This is not a defect in #37207's implementation. That issue's own acceptance criteria asked for exactly this behavior — "The picker can list and return folders when the caller asks for them" — and its post-merge plan covers folder selection as TC-003, which passed. TC-001 failed on QA disagreeing with the design, so what changes here is the decision, not a regression.

Decision taken during refinement: folders are not listed as rows; the sidebar tree is the only place folders appear. Whether picking a folder path survives as a capability at all is the one open question — it must be settled with UX/Product before implementation, because the shipped forwardTo template asks for it today.

Root cause notes

• The behavior is the shipped template's own request travelling end to end, not a picker default: file_browser_field_render_new.vtl:23 asks for kinds: ["file", "page", "folder"]; the browse-config builder in angular-form-bridge.ts:665 turns 'folder' into { showFolders: true }; with-asset-browse.feature.ts:130,169 forwards it as showFolders on every /api/v1/drive/search call, so folder rows come back in response.list and land in the store's items next to contentlets.
• DotAssetPickerConfig.browse keeps this opt-in, so no other entry point is affected — File, Image, video and audio never set showFolders (store/models.ts:18-32). The finding is scoped to openBrowserModal callers only.
• DotFolderListViewComponent has no notion of a navigational (non-selectable) row: items is one flat list — store/models.ts:301 widened it from DotCMSContentlet precisely so it could carry folders and links — and dot-folder-list-view.component.html:106-109 renders the single-select radio for every row it is given. So "list content only" has to be enforced upstream of the list, in what the picker requests, not by styling rows differently.
• Turning it off touches the published contract, not just the picker: DotBrowserItemKind (libs/edit-content-bridge/src/lib/interfaces/asset-browser.interface.ts:19) advertises 'folder', and the folder paging stream (folderCursor / hasMoreFolders, with-asset-browse.feature.ts:130,151,211-212 and the $hasMore union at line 85) exists to serve it.

Steps to Reproduce

1. Enable the new Edit Content experience and open a content item whose custom field renders file_browser_field_render_new.vtl (the forwardTo field on an HTML page is the shipped case).
2. Click click-here-to-browse to open the Asset Picker.
3. Look at the right-hand list: the current path's folders are listed as rows, each with a selectable radio, mixed in with files and pages.
4. Select a folder row and confirm — the folder's path is written into the field.

Expected per QA: the list panel carries content only; folders are reached through the sidebar tree.

🎥 Video on the TC-001 result.

Acceptance Criteria

• The picker's list panel shows content only — no folder rows — for every caller, including one that passes kinds: ['folder', …]
• Folders stay fully navigable through the sidebar tree, and the list keeps reflecting the selected folder's contents
• Settled with UX/Product and recorded here before any code: whether "pick a folder path" survives at all. Two viable shapes — (a) drop 'folder' from DotBrowserItemKind and from file_browser_field_render_new.vtl, making a folder unpickable: simplest, but removes a capability the legacy Browser Selector had; (b) keep the capability and move it out of the list — the picked value follows the tree's selected folder through an explicit affordance (e.g. a "Select this folder" action), so the list still shows content only
• The chosen shape is enforced where the request is built (the picker's browse config), not by hiding or disabling rows in dot-folder-list-view — the list stays a dumb renderer of whatever it is handed
• Both shipped templates are verified end to end after the change: file_browser_field_render_new.vtl (its kinds list changes under shape (a)) and redirect_custom_field_new.vtl
• If 'folder' is dropped, the folder paging stream (folderCursor, hasMoreFolders, and their contribution to $hasMore) is either removed or explicitly kept with a stated reason, so the paging model carries no dead stream
• The openBrowserModal contract docs state the resulting behavior, so a customer template cannot ask for a kind the picker silently refuses

Regression coverage

• Asset Picker store specs assert no folder row reaches items for a kinds: ['folder', …] caller
• angular-form-bridge.spec.ts's openBrowserModal suite is updated to the chosen shape
• Paging is covered with the folder stream in its final state (removed, or off), so Migrate openBrowserModal to the new AssetPicker and delete the legacy Browser Selector #37207's TC-007 — "the paginator stays reachable while any stream still has more" — does not regress

dotCMS Version

Latest from main.

Severity

Medium - Some functionality impacted

Links

• Split from: Content Drive toolbar control, shared filter chips and row selection in the list view #37174
• Parent epic: Create AssetPicker component reusing Content Drive (File/Image field asset selection) #36702
• Source issue: Migrate openBrowserModal to the new AssetPicker and delete the legacy Browser Selector #37207 (PR 37207 migrate openbrowsermodal to the new assetpicker and delete the legacy browser selector #37273)
• QA comment (TC-001 Failed): Migrate openBrowserModal to the new AssetPicker and delete the legacy Browser Selector #37207 (comment)
• Freshdesk ticket: NA

[github-actions]

PRs linked to this issue

• Withdraw asset picker folder selection so the list shows content only by @nicobytes