[BUG] Content Drive: Sidebar folders don't open a right-click context menu like the table

[zJaaal]

Problem Statement

In the Content Drive portlet, right-clicking a folder in the left side-panel folder tree does nothing. On the main table, right-clicking a folder (or using its kebab menu) opens a context menu with folder actions (Edit folder, Edit permissions). Users reasonably expect the same right-click menu on the sidebar tree, but there is no equivalent wiring, so folder actions are unreachable from the tree.

Impact: Usability gap / inconsistency — folder actions are only reachable from the table, not from the sidebar tree where users spend most of their navigation time. Front-end (Angular admin UI).

Root cause / blocker

The two views are backed by different data:

View	Source	Folder object
Table (dot-folder-list-view)	POST /api/v1/drive/search	Full DotContentDriveFolder including permissions (+ title, sortOrder, filesMasks, defaultFileType, showOnMenu, …)
Sidebar tree (dot-tree-folder / dot-content-drive-sidebar)	POST /api/v1/folder/search	FolderSearchResultView — only id, inode, path, hostName, addChildrenAllowed — no permissions, none of the full folder fields

The shared context menu (dot-folder-list-context-menu) is driven by the store (patchContextMenu({ triggeredEvent, contentlet })) and gates its items on contentlet.permissions (EDIT → Edit folder, EDIT_PERMISSIONS → Edit permissions). The Edit folder dialog also needs the full folder fields as its payload.

So simply adding a (contextmenu) handler to the tree node is not enough — with the byPath data the menu would render empty (permission gate fails) and the edit dialog would be missing fields.

Proposed resolution options (team to decide)

1. Backend: add permissions (and the folder fields the edit dialog needs) to POST /api/v1/folder/byPath / FolderSearchResultView, giving the sidebar parity with the table.
2. Frontend: on right-click, fetch the full folder + permissions before opening the menu (extra request per right-click; needs an endpoint that returns permissions for a single folder).
3. Frontend: show the folder actions ungated in the sidebar and let the backend enforce permissions when the action runs (diverges from the table's permission-aware menu).

Steps to Reproduce

1. Open Content Drive.
2. In the left side-panel, expand the folder tree.
3. Right-click any folder in the tree.
4. Expected: a context menu appears with the same folder actions as the table (Edit folder, Edit permissions).
5. Actual: nothing happens — no context menu.

For comparison: right-clicking a folder row in the table opens the context menu as expected.

Acceptance Criteria

• Right-clicking a folder in the side-panel tree opens the folder context menu.
• The menu offers the same folder actions available from the table (Edit folder, Edit permissions), subject to the user's permissions on that folder.
• Menu items respect the user's permissions (an approach for sourcing folder permissions in the sidebar is chosen from the options above).
• Selecting Edit folder opens the folder dialog pre-populated with that folder's data.
• Behavior is consistent with the table's context menu (same items, same gating).

dotCMS Version

Latest from main branch.

Severity

Low - Minor issue or cosmetic

Notes

Split out from the same work as the "New button — create content in the current folder" fix (Content Drive). Relevant files:

• core-web/libs/portlets/dot-content-drive/ui/src/lib/dot-tree-folder/
• core-web/libs/portlets/dot-content-drive/portlet/src/lib/components/dot-content-drive-sidebar/
• core-web/libs/portlets/dot-content-drive/portlet/src/lib/components/dot-folder-list-context-menu/
• dotCMS/.../rest/api/v1/folder/FolderResource#byPath / FolderSearchResultView