feat(edit-content): refactor the relationship field onto the shared search surface (#37192)

[adrianjm-dotCMS]

PR 2 of 2 — implementation. Spec approved in #37482; this branches off that branch, so its diff shrinks once PR 1 merges.

Closes #37192.

What changed

A — the "Add Relationships" picker. The bespoke dialog is replaced by the shared surface: dot-filter-bar chips over a picker-owned DOT_FILTER_FACADE, dot-folder-list-view in multiple-selection mode, the shared site/folder browser behind a filter chip, and api/v1/drive/search pinned to the relationship's target content type. No folder-tree sidebar — the folder scope is a chip, per the design.

B — the related-content list. Paging removed; 40 rows plus Load more, following the Key/Value field's precedent (#37191). Hover-only drag handle, right-aligned Status, single-column form max width.

The one design decision worth reading

The selection is an accumulated set keyed by identifier, seeded from the contentlets the field already holds — never rebuilt from a search response.

The dialog this replaces filtered its first search response to decide what was pre-checked, so an already-related item that response did not contain was never checked and was silently dropped on confirm. That was survivable only because the old dialog fetched once and paged in the browser. api/v1/drive/search pages on the server, so the accident would have become a reliable way to lose relationships. Per ADR-0018 the free-text filter is index-backed and lags, which is a second, independent reason the selection cannot be derived from search results.

Second consumer — please don't miss this

DotSelectExistingContentComponent was not only the relationship field's. Content Drive's shared field-filter chip opens the same dialog through DOT_RELATIONSHIP_PICKER. That provider is re-pointed here and its contract spec passes with only presentation assertions updated (which component and geometry it opens — C5 explicitly allows that). Contract: specs/37192-relationship-field-assetpicker/contracts/relationship-picker.contract.md.

Verified live: the chip opens the dialog with selectionMode: 'single' and the Apply label, and round-trips to us.rel:<identifier> in the URL with the result list filtered to match.

Its replacement footer is deleted: it reached the old store across PrimeNG's templates.footer boundary only because that store was providedIn: 'root'. The new store is per-dialog on purpose, so the two footers collapsed into one with a configurable label.

What a live backend found that the green suite did not

Three things only showed up once the flows were run against a rebuilt instance. They are the most useful part of this PR to review.

1. The cardinality refusal had no reader in the template. The store loaded the identifiers already claimed by another parent and toggleSelection refused them — and the row rendered like every other. The control toggled under the cursor, the editor confirmed, and the pick was dropped with nothing on screen explaining it. The store's own tests passed throughout, because they asserted $isConstrained rather than anything rendered.

Fixed with an unselectable input on dot-folder-list-view. Refused and allowed are separate template branches rather than one element with a bound [disabled]: PrimeNG's table controls drive their checkbox through [(ngModel)], whose setDisabledState latches on init, so a row that was refused and then allowed again keeps a dead control. The reset direction is what caught it.

2. The entire relationship E2E suite drove the deleted dialog. All six spec files imported the page object for "Select Existing Content", and the table spec drove the paginator FR-021 removed — this change was breaking CI and I had not noticed. Rewritten as add-relationships-dialog.ts. Two tests could not simply be ported: the confirm-disabled assertion is inverted per FR-013, and the two paging tests are now Load more.

3. A test I wrote contradicted FR-016. "Confirm an empty selection to unrelate the last item" was written against single cardinality, where FR-016 keeps the picker shut once the field holds its item. It only means anything on a multi-cardinality field. Running it is the only reason I know.

Open points — the reason this is a draft

1. Six libs/ui edits, against my own plan. The plan named touching that library the signal to stop and re-scope; I did not stop. All additive with defaults, ui green at 2031 tests:

• dot-chip-filter — optional icon; a titleless chip renders its value as its label
• dot-folder-list-view — configurable empty-state copy plus an optional action
• dot-folder-list-view — unselectable rows (finding 1 above; not optional, without it the cardinality guard is invisible)
• dot-asset-picker — full-screen behaviour extracted to the shared fullscreen-dialog module and now used by both (this one reduces duplication)

Either justify them here or tell me which to revert.

2. Columns are Content Drive's, not the design's. Shown: Name, Status, Locale, Type, Edited By, Last Edited. The artboard asks for Title, URL Title, Posting Date, Locale, Status, Last Modified. Changing them reaches into dot-folder-list-view — a scope decision, not a tweak.

3. New i18n keys need a backend rebuild. They are in Language.properties; a server serving the deployed copy shows raw keys.

Also worth a reviewer's eye

Site scoping changed. /drive/search resolves exactly one host and has no all-sites mode, so the picker now browses one site where the old dialog searched across all of them by default. The chip names the site being searched, so the UI no longer implies otherwise — but it is a behaviour change and belongs to product, not to me. Shared Assets is skipped without a request, since its hostname cannot be parsed as a URI authority (it used to surface as a 500).

The "Show Selected" toggle is restored, not new. The old dialog had it; the rewrite lost it and /speckit-converge reported the absence as a gap, which I initially read as a missing feature rather than as my own regression. Only the (N) counter is new — and FR-011 is what makes it necessary, since the selection accumulates across pages, searches and sites.

Store duplication left deliberately undone. withAssetBrowse already does this store's browse work. Generalising it means changing a shared feature with five shipped consumers (File field, Image field, three Story Block nodes, WYSIWYG, openBrowserModal) with no automated safety net for the behaviour that matters. Its two documented traps were fixed inside this store instead — per-page cursor bookmarks, and a row count that is not contentCount. De-duplication deserves its own issue.

One pre-existing bug recorded, not fixed. Routing between two contentlets whose relationship fields differ in cardinality opens the picker with the previous field's selection control. It self-corrects on reopen, and the read is the same one the deleted dialog made — out of scope here, noted so it is not mistaken for a regression from this change.

Verification

E2E (relationship-field)	51 passed, 1 skipped
edit-content	112 suites / 2274 tests
ui	123 suites / 2031 tests
portlets-content-drive	29 suites / 1366 tests
Lint, format, AOT build	clean

Verified server-side, not just on screen — each through GET /api/v1/content/{id}?depth=1: relate → save, unrelate → save, drag-reorder → save (order preserved), and the cardinality guard's positive path, a ONE_TO_ONE child already held by another parent, which no test had ever exercised against real data.

No Integration or Postman: frontend-only against unchanged contracts (SC-007, ADR-0013).

The pattern is the thing to review, not the individual fixes. Every bug in this PR that reached a human was a test asserting what I wrote rather than what the system needs — objectContaining on one field, a data-testid that survives on an unresolved element, a computed with no reader, a mocked call asserted instead of its effect. The fixes now assert the outgoing request or the rendered input. Where I rebuilt from the spec and the design, anything the spec did not name was lost in silence; the 252-line page object I deleted turned out to be the only inventory of what the old dialog actually did.

🤖 Generated with Claude Code