Dojo to Angular: Publishing Queue Portlet

Context

The Publishing Queue portlet (push-publish workflow management: pending jobs, audit history, unsent bundles) currently ships as a Dojo + JSP portlet built around dijit.layout.TabContainer, dotcms.dojo.push.PushHandler, and dojox.form.Uploader. This epic migrates it to Angular + PrimeNG and reshapes the information architecture per the new design.

The migration is decomposed into a consolidated spike (current state + backend API + target UI mapping), a single FE + BE implementation task (Angular library + portlet.xml rewiring + rollback toggle), and a docs task.

Design reference: https://claude.ai/design/p/52e62c08-322d-4a8e-9900-95e5668c4d74?file=Publishing+Queue+Redesign.html&via=share (internal — auth required). Screenshots of the 8 key screens are attached below.

Current State (Dojo)

Target State (Angular)

Information architecture shift

Structure

• New Nx library: core-web/libs/portlets/dot-publishing-queue/ (shell + page + SignalStore + data-access service + models)
• Two PrimeNG tabs: Queue (two-column READY TO SEND + IN PROGRESS) and History
• New data-access service libs/data-access/src/lib/dot-publishing-queue/ covering /v1/publishing/*, /v1/bundles/*, /v1/publishqueue, and remaining legacy /bundle/* endpoints until consolidated
• Reuse existing services where possible: push-publish.service.ts, dot-push-publish-filters.service.ts, add-to-bundle.service.ts
• Reuse models from libs/dotcms-models: DotEnvironment, DotBundle, DotPushPublishData, DotPushPublishDialogData
• License + role gating preserved; any gap surfaced in the spike's API audit is filed as a separate security task and linked here

Backend Wiring

• dotCMS/src/main/webapp/WEB-INF/portlet.xml: publishing-queue points at the new Angular shell; a new publishing-queue-legacy entry points at the existing JSP for rollback
• Reuse existing PortletID.PUBLISHING_QUEUE enum entry and existing publishing-queue i18n key
• Live-toggle rollback so admins can revert to the JSP without redeploy
• Backend hardening discovered during the spike (OpenAPI gaps on legacy resources, consolidation of legacy /bundle/* endpoints into /v1/publishing/* and /v1/bundles/*) is tracked in separate [Task] issues filed by the spike and linked here

Acceptance Criteria

• Publishing Queue portlet loads at the existing publishing-queue route, served by the new Angular shell
• Queue tab renders the two-column layout (READY TO SEND + IN PROGRESS) with counts shown in each column header
• A READY TO SEND row exposes a primary Send action and a kebab with Configure & send, Generate / download, Remove from queue
• An IN PROGRESS row renders status chips (Scheduled, Retry, etc.) and a Retry action when applicable
• History tab renders sortable BUNDLE / STATUS columns with Sent / Failed chips, pagination, and bulk select
• Top-bar search filters bundles / content / environments across the active tab
• Upload Bundle action accepts a .tar.gz file and refreshes the active tab on success
• Configure & send modal exposes Push / Remove / Push+Remove cards, Send now / Schedule, environment dropdown, and filter dropdown
• Row click opens the Asset list modal (Name / Type / State) from both Queue and History
• Bundle details modal renders metadata + endpoints-by-environment table; Download is available for completed bundles
• License + role gating preserved (publishing-queue portlet, requireLicense(true) on uploads)
• Rollback toggle: switching publishing-queue ↔ publishing-queue-legacy in portlet.xml reverts to the JSP without redeploy

Sub-tasks

• #36039 — [Spike] consolidated audit (current state + backend API + target UI mapping + backend hardening backlog)
• #36040 — [Task] Angular implementation + backend wiring
• #36041 — [Docs] document UI/UX changes after Dojo → Angular migration