maintenance portlet | Implement bulk delete contentlets API #35191

[hassandotcms]

Summary

Add 1 new REST endpoint to MaintenanceResource, replacing legacy DWR bulk contentlet deletion with a modern REST API for the Maintenance portlet Tools tab.

New endpoint:

• DELETE /api/v1/maintenance/_contentlets — Takes a JSON array of contentlet identifiers, resolves all language siblings for each, and permanently destroys them (bypasses trash). Each contentlet is destroyed independently — one failure does not block others. Returns deleted count and list of failed identifiers.

Implementation details:

• DeleteContentletsForm extends Validated with @JsonCreator, validates identifiers list is non-empty
• DeleteContentletsResultView (@Value.Immutable) with deleted count and errors list
• One-by-one destroy with error collection (matches legacy DWR behavior and BulkActionsResultView pattern)
• Uses respectFrontendRoles=false (modern REST convention, no effect for admin users)
• SecurityLogger entry logs user and identifier count
• Accepts JSON array instead of legacy comma-separated string

Test plan

• Integration tests pass: ./mvnw verify -pl :dotcms-integration -Dcoreit.test.skip=false -Dit.test=MaintenanceResourceIntegrationTest
• DELETE /_contentlets with valid identifier destroys contentlet and all siblings
• DELETE /_contentlets with multiple identifiers destroys all
• DELETE /_contentlets with non-existent identifier returns {deleted: 0, errors: []}
• DELETE /_contentlets with empty/null identifiers returns 400
• DELETE /_contentlets without request body returns 400
• Non-admin users get 403
• SecurityLogger entry appears with user and identifier count

Closes #35203

[claude]

Claude finished @hassandotcms's task in 2m 50s —— View job

---

PR Review

• Read changed files
• Analyze for bugs, risks, and design issues

---

1. Bug — getSiblings() failures are silently swallowed (not reported in errors)

MaintenanceResource.java:966-972 — when getSiblings() throws, the identifier is only logged; it is never added to errors and never counted as deleted. The caller receives {deleted: 0, errors: []} and has no way to know the identifier could not be resolved.

// current (line 966-972)
try {
    contentlets.addAll(conAPI.getSiblings(trimmedId));
} catch (final Exception e) {
    Logger.warn(this, ...);
    // ← trimmedId is silently dropped; should be: errors.add(trimmedId);
}

Fix: add errors.add(trimmedId) inside the catch block. Fix this →

---

2. API contract — errors field name is misleading

AbstractDeleteContentletsResultView.java:32 — the field is named errors but contains a list of identifiers that failed, not error messages. This is confusing to API consumers and conflicts with the field description ("Identifiers of contentlets that failed to be destroyed"). failedIdentifiers would be accurate and self-documenting. Changing this now is cheaper than after clients adopt it.

---

3. No upper bound on identifiers list

DeleteContentletsForm.java:39 — validation only rejects empty lists. A caller can send thousands of identifiers; each triggers a getSiblings() call that may itself return multiple contentlets, all of which are then destroy()-ed serially. This is an unbounded synchronous operation with no timeout, no size cap, and no feedback while running. Worth adding a configurable max (e.g., Config.getIntProperty("MAX_BULK_DELETE_CONTENTLETS", 1000)) and throwing 400 if exceeded.

---

4. Blank identifiers silently ignored

MaintenanceResource.java:965 — blank strings in the identifiers list (e.g., ["", " "]) pass form validation, are trimmed and skipped silently, and the caller gets {deleted: 0, errors: []} with no indication the input was unusable. Either validate in DeleteContentletsForm.checkValid() that no element is blank, or add those to errors.

---

5. AbstractSearchAndReplaceResultView — redundant dual fields

AbstractSearchAndReplaceResultView.java:25-33 — success() and hasErrors() are always logical inverses (set via success(!hasErrors) in MaintenanceResource.java:591). Dual fields risk desynchronization if the builder logic changes. One field should drive the other.

---

6. Misplaced ArrayList import (minor)

MaintenanceResource.java:72 — import java.util.ArrayList is in the middle of com.dot* imports, separated from java.util.List at line 81. Cosmetic but worth fixing.

---

No issues with: auth (assertBackendUser + admin check is correct), respectFrontendRoles=false (appropriate for admin-only endpoint), the Immutables pattern, @JsonCreator deserialization, SecurityLogger entries, or the test coverage (which is solid for the happy paths).

[claude]

Claude finished @hassandotcms's task in 1m 31s —— View job

---

I'll analyze this and get back to you.

[claude]

Rollback Safety Analysis

• Read rollback-unsafe categories reference
• Get full PR diff
• Analyze diff against all unsafe categories
• Apply label

---

Result: ✅ Safe To Rollback

This PR adds a new DELETE /api/v1/maintenance/_contentlets REST endpoint. The changes were checked against all rollback-unsafe categories:

Category	Verdict
C-1 Structural Data Model Change	✅ No runonce tasks, no core table changes
C-2 Elasticsearch Mapping Change	✅ No ES mapping changes
C-3 Content JSON Model Version Bump	✅ No CURRENT_MODEL_VERSION changes
C-4 DROP TABLE / DROP COLUMN	✅ No DDL drop statements
H-1 One-Way Data Migration	✅ No batch UPDATE/DELETE on business data
H-2 RENAME TABLE / RENAME COLUMN	✅ None
H-3 PK Restructuring	✅ None
H-4 New ContentType Field Type	✅ None
H-5 Storage Provider Change	✅ None
H-6 DROP PROCEDURE / DROP FUNCTION	✅ None
H-7 NOT NULL Column Without Default	✅ None
M-1 Non-Broadening Column Type Change	✅ None
M-2 Push Publishing Bundle Format Change	✅ None
M-3 REST/GraphQL API Contract Change	✅ Additive only — new endpoint, no existing contracts changed
M-4 OSGi Plugin API Breakage	✅ No interface changes

The PR is purely additive: new Java classes (DeleteContentletsForm, AbstractDeleteContentletsResultView, ResponseEntityDeleteContentletsResultView) and a new endpoint in MaintenanceResource. Rolling back to N-1 simply removes the new endpoint — no existing data, schema, mappings, or API contracts are affected.

Label "AI: Safe To Rollback" has been applied.

View job run