35138 Defect content palette search bar disappears and system content types exposition

[dario-daza]

Proposed Changes

This PR solves two small issues in the content palette:

This PR fixes: #35138 Defect Search bar disappears

• Restore $shouldHideControls() signal, modified in the modernization deploy.

This PR fixes: #35140 Spike System Content Types exposition

• Hide system=true Content Types (e.g., 'Dot Favorite Page') from being exposed when a request to the .. resource is made.
• Add integration tests

This PR fixes: #35138
This PR fixes: #35140

[claude]

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

---

PR Review

• Read changed files
• Analyze changes

---

Backend — ContentTypeResource.java

Filter placement is correct. The .filter(contentType -> !contentType.system()) is applied in-memory after the DB fetch, before building typeVarNames. This is safe and minimal.

Scope concern: The filter is only applied in getPagesContentTypes. If there are other endpoints that call findPageContainersContentTypesVarNamesByPathOrIdAndFilter and are also exposed to the palette, those won't get this filtering. Worth confirming this is the only code path the palette uses.

---

Integration Test — ContentTypeResourceTest.java

Incomplete cleanup in finally block. Only regularContentType and systemContentType are removed. The container, template, folder, and page created mid-test are not cleaned up. This leaves artifacts in the shared test database.

// Finally block only does:
ContentTypeDataGen.remove(regularContentType);
ContentTypeDataGen.remove(systemContentType);
// container, template, folder, page are leaked

Fix this →

Also note: the @SuppressWarnings("unchecked") cast on the response entity is fine for a test, but if ContentTypesPaginator.VARIABLE is a constant you can reference, the cast chain could be verified at compile time.

---

Frontend — dot-uve-palette-list.component.ts

signalMethod type mismatch. The method is typed as signalMethod<() => void> but receives this.$currentView (a Signal<DotUVEPaletteListView>). The parameter _view in the callback is never used (correctly prefixed with _). The type parameter should match the signal's value type (DotUVEPaletteListView), not () => void. This works at runtime but the typing is misleading.

Multiple subscription accumulation. Each time $currentView changes, #updateControlsVisibility() is called, which:

1. Immediately sets $shouldHideControls to false
2. Subscribes to status$ with take(1) waiting for EMPTY or LOADED

If the view changes multiple times before status$ emits a terminal state, multiple concurrent subscriptions exist. take(1) on each means they each resolve independently, so the last one to fire wins — this can produce a race. In practice, rapid view changes during a page load could cause the controls to flicker or briefly show when they shouldn't.

Visual flash pattern. The previous linkedSignal was purely reactive (hide = contenttypes.length === 0). The replacement starts hidden (true), then immediately shows controls (set(false)), then waits for the status to re-hide them. This introduces a brief flash of controls showing before empty state is confirmed. This may be intentional as a loading UX, but it's worth being explicit about.

---

Deleted dot-uve.js

Clean removal. The 3-line file appears to have been vestigial.

---

models.ts

Comment-only change. No issues.

---

Summary: The backend fix is clean and correct. The test needs cleanup for leaked DB objects. The frontend fix resolves the regression but introduces a subtle subscription race condition and a type mismatch in signalMethod — neither is blocking but both are worth addressing.