exclude system content types from the response

[dario-daza]

Proposed Changes

• change 1
• change 2

Checklist

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

Additional Info

** any additional useful context or info **

Screenshots

Original	Updated
** original screenshot **	** updated screenshot **

[claude]

Claude finished @dario-daza's task in 1m 2s —— View job

---

Rollback Safety Analysis

• Gather context (PR diff and rollback-unsafe categories)
• Analyze changes against unsafe categories
• Apply label

Result: ✅ Safe To Rollback

This PR contains no unsafe changes against any rollback-unsafe category. Here's the analysis:

Category	Verdict	Reason
C-1 Structural Data Model Change	✅ Safe	No database schema changes
C-2 Elasticsearch Mapping Change	✅ Safe	No ES mapping changes
C-3 Content JSON Model Version Bump	✅ Safe	No model version changes
C-4 DROP TABLE / DROP COLUMN	✅ Safe	No DDL drop statements
H-1 One-Way Data Migration	✅ Safe	No data transformation tasks
H-2 RENAME TABLE / RENAME COLUMN	✅ Safe	No renames
H-3 PK Restructuring	✅ Safe	No constraint changes
H-4 New Field Type	✅ Safe	No new field types
H-5 Binary Storage Provider Change	✅ Safe	No storage changes
H-6 DROP PROCEDURE / FUNCTION	✅ Safe	No procedure drops
M-1 Column Type Change	✅ Safe	No column changes
M-2 Push Publishing Bundle Format	✅ Safe	No bundle format changes
M-3 REST API Contract Change	✅ Safe	Filter-only change; rollback restores prior (broader) response
M-4 OSGi Plugin API Breakage	✅ Safe	No interface changes

Summary: The only production code change is a single .filter() call in ContentTypeResource.java (line ~1914) that excludes system content types from the getPagesContentTypes response. This is a pure in-memory filter — no database migrations, no ES mapping changes, no schema alterations. Rolling back to N-1 simply restores the previous behavior (system content types appear in the response again), with no data loss or permanent state change.