Clarin9/Make default search items-only, configurable via discovery.cfg

[Kasinhou]

What

Restrict the default Discovery search to items only (so /search no longer returns communities and collections — restoring CLARIN v7 behaviour), and make it configurable so admins can toggle it without touching Spring XML.

Changes

dspace/config/spring/api/discovery.xml — defaultConfiguration → defaultFilterQueries: replace the hardcoded type list with a property reference:

- <value>(search.resourcetype:Item AND latestVersion:true) OR search.resourcetype:Collection OR search.resourcetype:Community</value>
+ <value>${discovery.search.default.filterquery}</value>

dspace/config/modules/discovery.cfg — new property (items only by default, all-types alternative documented inline):

# Resource types returned by the default search (/search). Items only by default (CLARIN).
# To also return communities and collections, use:
#   discovery.search.default.filterquery = (search.resourcetype:Item AND latestVersion:true) OR search.resourcetype:Collection OR search.resourcetype:Community
discovery.search.default.filterquery = search.resourcetype:Item AND latestVersion:true

To include communities/collections again, override the property in local.cfg and restart — no XML edit, no reindex.

Why backend (and configurable) instead of frontend

• Single source of truth — applies to every API consumer (Angular UI, raw REST, OAI), and to facet counts, not just the UI search page.
• v7 CLARIN did this in the UI (clarin-search.component); the v9 upgrade dropped that component, causing the regression. Fixing it server-side and exposing a config key avoids per-client workarounds and lets each deployment decide.
• Supersedes FE PR Clarin9/Restrict main search page to items only dspace-angular#1487 (now closed as redundant).

Notes / scope

• Query-time filter — no reindex required. Takes effect on backend restart (Spring reloads discovery.xml / config).
• communityConfiguration and collectionConfiguration inherit from defaultConfiguration, so scoped search within a community/collection is also items-only (desired for CLARIN).

Verification (dockerized demo backend, default /search)

Config value	Total	Types present
...:Item ... (items only, default)	471	items only
... OR Collection OR Community (all types)	497	items + 20 collections + 6 communities

Toggling the single discovery.search.default.filterquery property and restarting flips the behaviour both ways — confirming the placeholder resolves from discovery.cfg and the feature is configurable end-to-end.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Restricts the default Discovery (Solr-backed) /search behavior to return items only, restoring CLARIN v7 behavior at the backend configuration layer so it applies consistently to all API consumers.

Changes:

• Updated the default Discovery defaultFilterQueries to remove Collection and Community resource types from the default search filter.
• Updated the inline XML comment to reflect the CLARIN-specific intent of the default filter.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Kasinhou]

CI fix — Discovery IT failures

The 10 failing integration tests (DiscoveryRestControllerIT, DiscoveryVersioningIT) were not code bugs — they are upstream tests that assert the default search returns communities and collections (e.g. discoverSearchObjectsTest seeds a community + collection + items and expects totalElements=7 plus community/collection objects in the results). Making the committed default items-only invalidated those expectations.

Fix (last commit): pin the original all-types filter query in the integration-test config (dspace-api/src/test/data/dspaceFolder/config/local.cfg), so the upstream Discovery ITs keep validating discovery features (pagination, facets, scope, versioning) against the environment they were written for — no test assertions touched, no upstream merge conflicts.

Net result: CLARIN default = items-only (config/modules/discovery.cfg), test env = all-types (restores upstream ITs), fully configurable via discovery.search.default.filterquery.

Policy note: this keeps items-only as the shipped fork default. The alternative is to leave the committed default as upstream (all-types) and enable items-only per-deployment in local.cfg — happy to switch if that's preferred.