Legacy edit content: Relationships search dialog still misses exact-name and mid-token terms (ContentletAjax catchall-only gate)

[ihoffmann-dot]

Problem Statement

The fix shipped in #36791 / PR #36793 corrected the exact-name and mid-token matching gap in GlobalSearchAttributeStrategy, which is the shared strategy used by the Content Search portlet, Content Drive's keyword search, and the new (Angular) edit content Relationships field dialog.

However, the legacy (Dojo/JSP) edit content screen does not go through that code path at all. Its "Relate" dialog is dotcms.dijit.form.ContentSelector, which dispatches over DWR to ContentletAjax.searchContentletsByUser — a separate, drifted copy of the same query-building logic that still uses a catchall-only prefix gate.

dotCMS/src/main/java/com/dotmarketing/portlets/contentlet/ajax/ContentletAjax.java:943-974:

luceneQuery.append("+" + fieldName + ":" + fieldValueStr + "* ");   // line 956 -> +catchall:img_0004.jpeg*
...
if ("catchall".equals(fieldName)) {
    luceneQuery.append(" title:'" + fieldValueStr + "'^15 ");
    ...
    luceneQuery.append(" title_dotraw:*" + fieldValueStr + "*^5 "); // line 968 -> optional BOOST only
}

The title_dotraw wildcard is present, but only as an optional boost clause. The mandatory +catchall:<term>* gate has already excluded the document, so it never rescues a mid-token or boundary-spanning term.

Impact: users on the legacy edit content screen cannot find related content by mid-token substring or by its exact full name — the same defect #36791 fixed everywhere else. Confirmed during QA of #36791.

Steps to Reproduce

1. Create a Content Type with a Relationships field pointing at another Content Type (e.g. Images).
2. Upload a File Asset named IMG_0004.jpeg, indexed.
3. Open a contentlet of the first Content Type in the legacy edit content screen and click "Relate".
4. Search 0004 (mid-token) -> Expected: IMG_0004.jpeg appears. Actual: 0 results.
5. Search IMG_0004.jpeg (exact full name) -> Expected: it appears. Actual: 0 results.
6. Search IMG or jpeg (genuine token prefixes) -> correctly found today.
7. Repeat steps 4-5 in the new edit content screen -> both work (fixed by fix(search): recover exact-name and mid-token matches in global search #36791 #36793).

Acceptance Criteria

• In the legacy edit content Relationships dialog, searching a mid-token substring (e.g. 0004 inside img_0004) finds the containing content.
• In the same dialog, searching the exact full name (e.g. IMG_0004.jpeg) finds the content.
• A term that exists in no field still returns 0 results — the broad, unscoped catchall:*term* from [BUG] Content Drive: keyword/title search returns inconsistent or incoherent results #36688 must NOT be reintroduced. Any broadened matching stays scoped to title_dotraw.
• No regression to the other ContentletAjax.searchContentletsByUser consumers (Content Search portlet's legacy screens, related-content filtering, date filtering). Existing ContentletAjaxTest stays green.
• Query-construction change only — no mapping/analyzer change, no reindex.

dotCMS Version

Latest from main.

Severity

Medium - Some functionality impacted

Links

• Follow-up to Global/Content search: exact-name and mid-token terms don't match (prefix-only catchall gate) #36791 / PR fix(search): recover exact-name and mid-token matches in global search #36791 #36793 — same defect, second code path not covered there.
• Legacy path: dotCMS/src/main/java/com/dotmarketing/portlets/contentlet/ajax/ContentletAjax.java:943-974
• Legacy UI: dotCMS/src/main/webapp/html/js/dotcms/dijit/form/ContentSelector.js:899-923
• Fixed reference implementation: dotCMS/src/main/java/com/dotcms/rest/api/v1/content/search/strategies/GlobalSearchAttributeStrategy.java:37-48
• NA (no Freshdesk ticket)

[github-actions]

PRs linked to this issue

• fix(search): recover exact-name and mid-token matches in the legacy relationship dialog (#37052) by @ihoffmann-dot