task(content-drive): add push publish actions and delete to folders, gate creation on permissions #35161

[zJaaal]

Proposed Changes

Closes #35161. Adds the folder push publish family to Content Drive, across both the context menu and the Action Center, plus two fixes found on the way.

Context menu

• Push History for folders — new html/portlet/ext/folders/push_history.jsp (22 lines) resolving the folder from folderIdentifier, checking EDIT_PERMISSIONS server-side, and including the shared edit_publishing_status_inc.jsp. Hosted by DotJspIframeDialogComponent (see the review round below).
• Push Publish for folders and contentlets, spawning DotPushPublishDialogService — the app-wide dialog locales, plugins and experiments already drive for a single asset. No new dialog component.
• Add to Bundle for folders. No new plumbing: the shell already renders the bundle dialog off the context menu's own target keyed on identifier.
• Order: Folder Settings, Edit Permissions, Push Publish, Add to Bundle, Push History.

Action Center

• Folders are no longer dropped from the selection. Support is per action, from the registry: supportsFolders sits beside requiresEnvironments and is set on Add to Bundle and Push Publish only.
• Lock, Unlock and Refresh still see contentlets only. The Workflow Actions half is untouched — folders have neither a content type nor a scheme, so they never reach it.
• Actions that do not apply drop out of the list rather than showing a count of zero.

Delete

• Delete Folder in the context menu, gated on EDIT (what FolderAPIImpl.delete enforces at :438), confirming first through the app-wide DotAlertConfirmService. Uses the already-shipped POST /api/v1/assets/folders/_delete, so it needs no backend work and does not wait on the bulk endpoints on Async bulk folder copy and delete via the job queue #37062. Multi-select delete does, and stays on Content Drive: wire folder move, copy and bulk delete #37063.

Creation gating

• New, Upload and the drop zone are gated on CAN_ADD_CHILDREN, site root included. All three create something in the browsed folder, and the server enforces that permission on it (FolderAPIImpl:673-676 for a folder, ESContentletAPIImpl:605-609 for the contentlet an upload creates), so previously the user picked a file or filled in a dialog and only then got refused.
• One store computed feeds all three, so they cannot disagree about the same folder.

Shared

• withPushPublishEnvironments resolves the reachable environments once per portlet load, so both surfaces gate on one signal instead of each running its own lookup.

The push publish actions need no backend

PublisherAPIImpl.java:251-257 resolves an unrecognized identifier to PusheableAsset.FOLDER and enforces PermissionAPI.PERMISSION_PUBLISH, reporting a denial as a per-asset entry in errorMessages rather than throwing, which the existing error path already surfaces. Add to Bundle and Push Publish share that path, which is why folder ids already work for both.

The creation gate does need one field

Folders already carry their own CAN_ADD_CHILDREN with the tree. The site root did not: its parent is the host, not a folder, and nothing reported on it.

Three candidate sources looked like they could answer that from the frontend alone. All three are wrong, each differently, and two of them convincingly:

Source	Why it fails
GET /api/v1/permissions/user/{userId}	Reports only the user's individual role (PermissionSaveHelper:357). On the demo data Chris holds three roles, and Publisher / Legal carries its own grants on 5 assets this never returns. A grant held through a group role would read as no grant — hiding the buttons from users who can use them, the worst failure mode for a gate.
byPath's / entry	Carries addChildrenAllowed and matches expectations on the demo data, but resolves against the global SYSTEM_FOLDER singleton (FolderHelper#findSubfoldersUnderHost). That is one row per installation, host_inode = SYSTEM_HOST, zero permission rows — so it answers identically no matter which site is open, and a grant on the site would not move it. The demo match is a coincidence.
GET /api/v1/folder/search	Returns the root's children, never the root.

So the host needs its own answer. AssetPermissionHelper#getAssetMetadata already resolved canEditPermissions and canEdit for the calling user through permissionAPI, which honours every role the user holds; this adds canAddChildren beside them and maps it through both view builders. +26 lines across 4 files, plus 5 auto-generated lines of openapi.yaml.

No new endpoint and no new access path: GET /api/v1/permissions/{assetId} was already reachable by a non-admin for a host, verified with a limited user against the running instance.

Review round

Addressed 25 of the 27 threads from @oidacra and @rjvelazco. The substantive ones:

• The two iframe dialogs are now one. diff confirmed DotPushHistoryIframeDialogComponent and DotPermissionsIframeDialogComponent were identical apart from an interface name, a title, a test id and an empty-state key — the second existed because the first was named for one caller and so did not look reusable. Merged into DotJspIframeDialogComponent, taking titleKey / emptyKey / testIdPrefix through the dialog config. Renamed rather than kept as DotPermissions* on purpose: a component called Permissions that renders push history is the stale name that produces a fourth copy. Three call sites updated (edit-content, dot-categories, dot-content-drive); the merged spec is parameterised with describe.each over both. Incidentally fixes the permissions dialog's hardcoded, untranslated title="Permissions".
• Deleting a folder you are inside moves to the root. The sidebar tree serves the same menu, so the deleted folder can be an ancestor of the browsed one; reloading the current path fetched a path that no longer existed. #browsingInside compares with a trailing slash on both sides so /blog-archive/ is not read as inside /blog/.
• The folder invariant is now held by the compiler. eligibleWhen and warnWhen take DotContentDriveItem; the contentlet-only predicates narrow with isFolder. Adding supportsFolders to an action whose predicate reads locked or contentType fails to build instead of reading undefined off a folder. The cast at the call site is gone.
• A failed environments lookup is logged before the gate settles on false. UX unchanged — a broken endpoint just no longer reads as "no environment configured" to whoever is debugging it.
• Tests that were asserting less than they appeared to: the delete-failure cases asserted only what did not happen, so removing the handle(error) call kept them green; deleteFolder had no error-path test, so the consumer's negative assertions rested on nothing; the environments lookup was asserted toHaveBeenCalled() when consolidating it to once is the whole point of the feature; and Push Publish had no folder-in-payload coverage at all, so nothing proved a folder survived to executePushPublish.
• Plus: SUCCESS_MESSAGE_LIFE on the success toast, the folders-ignored test id renamed and the key it stranded deleted, rescaleToWidthBudget's percentage assumption documented, a duplicate grid test dropped whose comment asserted the belief this PR disproved, the contentlet menu order asserted as one ordered list, the per-row supportsFolders lookup hoisted, and the unused input-state constraint dropped from both store features.

Two threads deliberately left open: one asks @rjvelazco whether he wants a store-level partial-failure test that would differ from the existing one only by a string literal (by that layer a folder identifier is a contentlet identifier); the other waits on a browser check of the JSP's denied-path render, which I could not exercise over curl.

QA round

Two issues found testing on a build with the backend field, plus a correction.

• Dropping onto a folder in the sidebar tree bypassed the gate, for both of its outcomes — dropped files uploaded, dropped rows moved. Both now refuse with a toast naming the folder or the site. canAddChildrenTo extracts the rule so the New menu, Upload, the grid drop zone and the tree drop cannot disagree about one folder.
• A newly created folder's parent came back unexpandable. loadFolders() was firing; the bug was in buildTreeFolderNodes, where isLeaf read folderHierarchyLevels.length >= levelIndex + 1 — true for every on-path node, so a folder was marked a leaf in the same breath as its children were attached to it. PrimeNG hides the toggler for a leaf, so the new folder was in the model but unreachable, which read as the tree not reloading.

Correction to this description and to four code comments. Earlier revisions cited ESContentletAPIImpl:605-609 as the server enforcing CAN_ADD_CHILDREN on upload. That check is real but sits inside move, not the create path. What the server actually enforces on a folder is creating a folder (FolderAPIImpl:673) and moving a contentlet (ESContentletAPIImpl:607); the contentlet checkin path does not check it, so an upload is not refused server-side.

That makes the upload gate a consistency measure rather than a preview of a refusal — a weaker justification than the one originally given, and the comments now say so. It is still worth having: without it, uploading into a folder quietly allows what creating a folder in the same place forbids. The server-side gap is long-standing and deliberately not touched here; changing contentlet checkin permissions belongs in its own ticket with its own QA.

Copy drops the "Add Children" wording throughout — it is the internal permission name, not what the permissions UI calls it, and it means nothing to a customer.

Checklist

• Tests
• Translations
• Security Implications Contemplated (add notes if applicable)

Additional Info

Security notes

• The new JSP checks EDIT_PERMISSIONS server-side, not just at the menu level, so it does not render for someone who types the URL directly. This matters because the shared include exposes a Delete Push History button whose endpoint, BundleResource.deletePushHistory (:304), only requires a backend user with no per-asset check. That gap is pre-existing and shared by every push-history view; it is not introduced here, and it is the reason for the tighter gate. Worth its own ticket.
• The same-origin iframe guard is now a single shared predicate, isSameOriginRelativeUrl, and it fixes a real bypass. The previous string check only rejected a leading //, but browsers normalise backslashes into the authority position and strip tab, newline and carriage return before parsing, so /\evil.example.com, /\/evil.example.com and /<tab>/evil.example.com all resolve to an external host while passing it. The predicate delegates to the URL parser and compares the resolved origin. Not reachable through any current call site, since all three build their URL from a hardcoded /html/... prefix with only an id interpolated, so this is hardening rather than a live hole.
• Push Publish is offered disabled when no environment is reachable, and the reason sits in the label ("Push Publish (no environment)") rather than a tooltip. A disabled context menu item computes pointer-events: none, so no hover reaches it and no tooltip can fire; PrimeNG's ContextMenu also binds pTooltip from tooltipOptions alone, so a plain MenuItem.tooltip is accepted by the type and silently ignored on top of that. A label needs neither hover nor click. The command guards as well, since disabled only suppresses the click.

On the creation gate's defaults. Both unknowns resolve to allowed: a lookup still in flight, and an instance too old to report the field. Denying on either would strip the buttons from every user on an older instance and flicker them off-then-on for the common case, and the server refuses the write regardless — the gate softens an affordance, it does not protect anything. The push publish gate makes the opposite call (undefined reads as disabled) because offering a push with nowhere to send it fails later and far less legibly; the two are deliberately different and each says why in place.

The drop zone refuses the gesture rather than swallowing it. dot-upload-dropzone gained a disabled input that suppresses the overlay, the dragEnter output and the upload. The drag itself is left to the browser rather than cancelled, so the OS shows its own "cannot drop" cursor instead of the zone accepting a file and going quiet.

The New/Upload tooltip hangs off a wrapper, not the button. Same PrimeNG constraint as the Push Publish menu item: a disabled button computes pointer-events: none, so a tooltip bound to it can never fire. There is a test asserting the wrapper contains the button, so a later refactor that moves the binding back onto the button goes red.

Two bugs found while building this, both fixed here

1. A column subset handed the checkbox column the leftover width. Measured in Chrome on the Action Center preview's 586px table: the authored percentages for title, live, contentType total 53%, not the 96% the full set carries, and table-layout: fixed has to put the unclaimed 47% somewhere. Chrome gives it to the leading column — the 3rem checkbox one — which rendered 275px instead of 48, pushing the name far right of its heading and leaving Status 59px for a badge that does not fit, so it overflowed into Type. rescaleToWidthBudget scales a subset back to the full set's total, preserving proportions; the checkbox column then measures 42px and Status 103px. The comment there previously assumed the leftover lands on the title column — it does not.
2. Folder rows arrived with no inode. The drive-search view omits it, but the table keys rows on inode (language variants of a contentlet share an identifier, so it cannot key on that), leaving every folder row colliding on undefined. Backfilled at the service boundary; dotCMS keeps a folder's inode equal to its identifier, and a folder that already carries one is left alone.

On eligibleInodes. It keeps its meaning for the actions that fire on inodes, which is what pins the version and therefore the step, so one contentlet on two steps still contributes two entries. The two folder-capable actions put identifiers there instead, because that is what they fire on anyway — the same asymmetry executeAddToBundle already documents. Correction to an earlier version of this description, which claimed the switch removed a latent divergence where two versions of one contentlet would count 2 while the payload sent 1. It does not, and there was nothing to remove. map() preserves length, so the badge counts selected rows either way, and that is deliberate: the Add to Bundle registry entry reads "Coverage is the whole selection, minus the identifier collapse the configuration step explains", and $bundleCollapsedCount exists to disclose the absorbed rows on that step. De-duplicating the badge would zero that disclosure out. No behaviour change here, only the key the ids are drawn from.

Typechecked, not just tested. ts-jest runs with isolatedModules, so it transpiles without typechecking — a green suite is not proof the app builds. Two type errors slipped through that way (a missing DotContentDriveItem import and toDistinctIdentifiers not widened), and because nx serve kept serving the last good bundle they presented as an empty Add to Bundle preview rather than as a build failure. Every touched lib is now clean under tsc -p <lib>/tsconfig.lib.json --noEmit.

Strict-mode clean, per #35932: every strict error reported across the touched files sits on a pre-existing line, none on the new code.

Built test-first throughout. Each unit went red before green, and no test was edited to force a pass. Where an existing assertion had to change, it was because the correct behaviour changed — the contentlet menu's index-based order assertions shifted by the added item, the Action Center's folder-exclusion counts now include folders, and the grid's "no rescaling" assertion encoded an assumption the measurement disproved. Each is called out in its commit. Full runs: ui 1403, portlets-content-drive 1278, data-access 787, utils 108, plus content-drive/ui 53 and dot-publishing-queue 255 as the other consumers of the shared grid.

Verified against a running instance. The JSP returns HTTP 200 with the heading, all four columns, a correctly disabled Delete button and the publisher_status_no_push_history empty state. Without popup=true the body renders visibility:hidden (that parameter is load-bearing, since these adapters never include bottom_inc.jsp), and missing, empty or bogus identifiers render no table and no error page. The column-width and folder-inode findings above were both measured in the browser rather than reasoned about.

Known limitation, inherited not introduced. The push-history include calls the un-paginated getPushedAssets(assetId) then does three lookups per row, so a folder pushed hundreds of times renders every row with an N+1 — exactly how content types, templates and containers behave today. The paginated overload and PushedAssetHistory already exist if this should later move to the Angular timeline.

Separate pre-existing observation. SELECT_ASSETS_BY_ASSET_ID (PushedAssetsFactory.java:29) is ORDER BY push_date with no direction, so every push-history view, Site Browser's own tab included, is oldest-first, and ContentPushHistoryPaginator ignores its orderBy/direction so page 1 of /api/v1/content/{id}/push/history returns the oldest pushes. Left alone: changing it is a behaviour change to a public API contract that PushedAssetsFactoryTest pins (:245, :258), so it belongs in its own ticket. The reverse-chronological AC was dropped from #35161 for the same reason.

Screenshots

Action Center preview, before and after the column rescale — the before is the reported defect (name pushed right of its heading, Published badge overflowing into FileAsset).

🤖 Generated with Claude Code

[claude]

Claude finished @zJaaal's task in 3m 33s —— View job

---

Code Review — Folder push-publish actions, delete, and creation gating

I reviewed the diff on this branch against main, focusing on the two most recent commits (the tree drop-gating + isLeaf fix and the denied-folder test) alongside the full set of new folder-action, permission-plumbing, and gating changes.

✅ No new issues found

The changes are internally consistent and the logic holds up under review. Highlights I verified:

• tree-folder.utils.ts:138 — isLeaf fix. The old folderHierarchyLevels.length >= levelIndex + 1 was true for every on-path node, marking a folder a leaf as its children were attached and hiding the PrimeNG toggler. The new (folderHierarchyLevels[levelIndex + 1]?.length ?? 0) === 0 correctly reads the next level, so intermediate on-path nodes stay expandable and only a truly childless level marks a leaf. Correct.
• functions.ts canAddChildrenTo / withSitePermissions.ts / dot-permissions.service.ts. The three-state (undefined/true/false) gating is coherent, and the deliberately different failure defaults are sound and documented: site-root creation fails open (canAddChildren !== false, softening a server-guarded affordance) while Push Publish fails closed. The reset-to-undefined before each site lookup, plus filtering SYSTEM_HOST before the reset, correctly prevents a stale answer from gating a new site.
• push_history.jsp. Server-side EDIT_PERMISSIONS enforcement is real (not client-only); the try/catch collapses DotSecurityException→null so an unreadable folder and a missing id render the same single message, disclosing nothing about which denial applied. folderIdentifier is passed to the API, not concatenated into SQL, and is never echoed to the page. Correct.
• Backend permission plumbing (AssetPermissionHelper, AbstractAssetMetadata, AbstractAssetPermissionsView, PermissionResource). canAddChildren is resolved server-side via doesUserHavePermission(asset, PERMISSION_CAN_ADD_CHILDREN, user, false), threaded through the immutable builders, and the @Schema matches the return type. Conventions-compliant.
• action-center.ts getQuickActions. The flatMap + supportsFolders scoping is correct: folder-capable actions see the whole selection and emit identifiers, contentlet-only actions see filtered contentlets and emit inodes, and an action with an empty scope returns [] (dropped, not shown with a 0 count). eligibleWhen/warnWhen take the union type so the contentlet predicates narrow internally with no cast.
• #canDropInto drop gating in the shell component consistently gates both upload and move, with the site-root vs folder toast message chosen from the presence of permissions.

Previously-raised findings — resolved

All findings from earlier review rounds appear addressed in the current diff: the delete gate corrected to EDIT + EDIT_PERMISSIONS, rxMethod conversion, the iframe dialog merge, error logging in the environments lookup, the folders-limited-message test-id rename, orphaned-key deletion, and the isLeaf / drop-gate fixes in the latest commit.

[github-actions]

🐳 PR Docker test image

Latest build for commit 05f0884 pushed to dotcms/dotcms-test:

docker pull dotcms/dotcms-test:pr-37146-issue-35161-content-drive-folder-push-history
docker pull dotcms/dotcms-test:pr-37146-issue-35161-content-drive-folder-push-history_05f0884

[rjvelazco]

Four follow-ups from a second pass. None are blockers; the two test ones close AC clauses that are currently unverified.

[rjvelazco]

Minor / nit pass — everything still open from my earlier read that isn't already covered by a thread. None of these are blockers.

For the record, two things I checked and am not raising: the preview component's input types (fixed in 99f82da) and the environments lookup now firing on every portlet load rather than on dialog open — the docblock already justifies that trade explicitly.

[rjvelazco]

LGTM! Personal comments and Claude comments resolved

[claude]

test