dotCMS / dotCMS/core

[Task] Legacy /bundle/* endpoints: OpenAPI hardening + consolidation into v1 publishing

Open
#36,048 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Team : Modernization
Dominant language
Java
Stars
970
Forks
486
Avg merge
3d 33m
Merged PRs (30d)
170

Description

Context

Surfaced by the Publishing Queue migration spike (#36039).

com.dotcms.rest.BundleResource (/bundle/*) is the legacy bundle REST surface. The new Angular portlet (#36040) consumes a mix of v1 (/v1/publishing/*, /v1/bundles/*) and these legacy endpoints. Several of the legacy endpoints have known quality issues that should be retired into the v1 surface:

Legacy endpoint Issue Proposed v1 destination
GET /bundle/{bundleId}/assets (BundleResource:120) Ad-hoc List<Map> response, dual queue/audit lookup GET /v1/publishing/{bundleId}/assets returning a typed view
GET /bundle/getunsendbundles/{params:.*} (BundleResource:184) Legacy matrix path params, JSONArray envelope Owner-filtering variant of GET /v1/publishing?status=WAITING_FOR_PUBLISHING&owner=me
GET /bundle/updatebundle/{params:.*} (BundleResource:257) GET with side effect, "true"/"false" string response, no OpenAPI PUT /v1/publishing/{bundleId} body { name, filterKey }
GET /bundle/_download/{bundleId} (BundleResource:754) Legacy path; the v1 surface has no download equivalent GET /v1/publishing/{bundleId}/_download
POST /bundle/_generate (BundleResource:795) Mixed legacy form binding POST /v1/publishing/{bundleId}/_generate
POST /bundle/sync, POST /bundle (BundleResource:892, 951) Two near-identical multipart endpoints POST /v1/publishing/upload (with ?mode=sync|async query param)
GET /bundle/{bundleId}/manifest (BundleResource:1024) OK shape but tucked under the legacy resource GET /v1/publishing/{bundleId}/manifest

Also surfaced by the audit:

  • AuditPublishingResource (/auditPublishing/*, inter-server) has no OpenAPI annotations
  • PublishQueueResource.deleteAssetsByIdentifiers (PublishQueueResource:40) has @Tag but no @Operation content and the form lacks @Schema
  • PushPublishFilterResource POST/PUT/DELETE methods have implicit OpenAPI only (no @Operation / @ApiResponse)

Proposed change

Two-pass plan:

Pass 1 — OpenAPI hardening (no behavior change)

Add @Operation, @ApiResponse, and @Schema annotations to:

  • BundleResource — every endpoint with missing or incomplete OpenAPI metadata
  • AuditPublishingResource — full annotations
  • PublishQueueResource.deleteAssetsByIdentifiers + DeletePPQueueElementsByIdentifierForm
  • PushPublishFilterResource POST/PUT/DELETE

Regenerate dotCMS/src/main/webapp/WEB-INF/openapi/openapi.yaml and commit.

Pass 2 — Consolidation into v1

For each row in the table above, add the v1 equivalent and mark the legacy endpoint @Deprecated with @Operation(deprecated = true). Legacy endpoints keep working for one release cycle, then are removed.

Acceptance criteria

  • Pass 1: every endpoint listed has full OpenAPI annotations and a CI build that regenerates the yaml matches the committed file
  • Pass 2: each new v1 endpoint has parity with the legacy behavior and is covered by an integration test
  • The new Angular portlet (#36040) is updated to call the v1 endpoints where available
  • Deprecation notice in the openapi descriptions points to the v1 replacement

Source links

  • Spike audit: #36039
  • FE consumer: #36040
  • Epic: #34734

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading BundleResource, AuditPublishingResource, PublishQueueResource, and PushPublishFilterResource, then inspect the OpenAPI regeneration workflow and the existing v1 publishing endpoints. Done means the listed endpoints have complete metadata, the committed openapi.yaml regenerates cleanly, v1 replacements have integration-test parity, the Angular portlet uses them, and legacy routes document their deprecations.

Written by the indexing model from the issue text.

Assessment

Tech stack
angular, java, openapi
Domain
api, backend, frontend
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.