Skip to content

fix(ui): search the Applications and Services lists server side, with the Search and Columns sidebar - #1290

Open
WilcoLouwerse wants to merge 2 commits into
developmentfrom
fix/woo586-modules-search-sidebar
Open

WilcoLouwerse wants to merge 2 commits into
developmentfrom
fix/woo586-modules-search-sidebar

Conversation

@WilcoLouwerse

@WilcoLouwerse WilcoLouwerse commented Oct 12, 2026 •

Copy link
Copy Markdown

What

Findings from the WOO-586 walkthrough on the CMDB rig (Gemeente Rotterdam import, 1138 applications):

  • Search on Applications failed after a few searches. The faceted page narrowed the list by every id the facets response matched, sent as _ids[] in the query string. From about 170 matches the request line is too long: the rig's access log shows GET …/objects/20/module?…_ids%5B%5D=… answered with HTTP 414 (19 times), and the list showed an error. The facet cache (30 min) made earlier terms look fine for a while.
  • Applications had no Search and Columns sidebar, unlike Applications in use.

How

  • config.sidebar on the Modules and Services pages; FacetedCatalogIndexView forwards it to CnIndexPage. The sidebar's search is the page's free-text search: the list sends it as _search (server-side, paged), and @search hands the term to the facet counts, so the counts still follow the search.
  • The toolbar search box is gone (one search per page). Saved views keep working: applying one puts its term in the route's _search and remounts the list. An old link with _gf_search is carried over to _search. The list is not remounted when the facet counts change the narrowing ids (the self-fetch list watches its filter prop), so the sidebar search keeps its focus.
  • The e2e scenario and the gemma-faceted-search spec name the sidebar search; the unused strings "Search applications and services…" and "Clear search" are removed.
  • Only a GEMMA facet selection still narrows by _ids (new helper listNarrowingFilter). On this data set no module has GEMMA links, so the facets are empty. A facet that matches more than ~170 modules would still hit the 414; that needs a server-side narrowing in OpenRegister and is out of scope here.

Checks

npx jest 187 passed (3 new for listNarrowingFilter), hydra gates (local, diff scope) 58 of 58 applicable passed, node tests/validate-manifest.js PASS, eslint 0 errors on the changed files, npm run build OK. Rig check pending: the WOO-586 rig was stopped before the overlay could be tested.

Jira: WOO-586 — plan: https://github.com/ConductionNL/readonly-mirror-wilco-claude-plans/tree/dev-mirror/issues/jira/WOO-586/

🤖 Generated with Claude Code

WilcoLouwerse and others added 2 commits October 12, 2026 13:37
…ive them the Search and Columns sidebar

A free-text search on the faceted Applications page narrowed the list by
every id the facets matched, sent as _ids[] in the query string. From
about 170 matches the request line was too long, the server answered
HTTP 414 and the list showed an error on every search after that.

The page now has the Search and Columns sidebar the other index pages
have. Its search is the list's own _search, which OpenRegister pages
server side; the facet counts follow the same term. Only a GEMMA facet
selection still narrows the list by the matched ids. The Services page
uses the same view and gets the same sidebar, as its toolbar search box
is gone.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…, and update the e2e and spec

Review of #1290:

- created() carries an @SPEC tag (gate 16).
- The e2e scenario typed into the removed toolbar search box; it now
  opens the Search and columns sidebar and types there.
- The list is no longer remounted when the facet counts change the
  narrowing ids: the self-fetch list watches its filter prop and
  refetches (nextcloud-vue 2.65.0 and later), so typing in the sidebar
  search with a facet selected keeps the focus. Only a saved view or an
  old link still remounts it.
- A link from before this change carries the term as _gf_search; it
  moves to _search and the list reads it.
- gemma-faceted-search spec: the search is the sidebar's Search tab.
- The header docblock says the search and columns are CnIndexPage's
  own sidebar; the unused strings "Search applications and services…"
  and "Clear search" are gone from en and nl.

jest 187 pass, vitest facetStore/facetSchema 28 pass,
validate-manifest PASS, eslint clean on the changed files.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Comment thread src/views/FacetedCatalogIndexView.vue
Comment thread tests/e2e/spec-coverage/gemma-faceted-search.spec.ts

@WilcoLouwerse WilcoLouwerse left a comment

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verdict: APPROVE (self-review, posted as a comment)

Mode Standard. The approach holds in both library versions the PR can ship with (nextcloud-vue 2.65.0 from the lock, 2.73.1 from #1291): CnIndexPage takes sidebar, its hoisted sidebar's search reaches onSearchEvent → $emit('search'), and the list restores _search from the route on mount. The review found 2 🔴, 2 🟡 and 1 🟢; all were fixed on the branch before posting.

✅ Fixed before posting (5)

  • 🔴 gate-16: created() had no @spec tag — fixed in 71e684c0.
  • 🔴 The e2e scenario typed into the removed toolbar search box — fixed in 71e684c0.
  • 🟡 With a GEMMA facet selected, every facet-count refetch changed the remount key, so typing in the sidebar search lost focus — the key now changes only on listRemount (the self-fetch list watches its filter prop and refetches from 2.65.0 on) — 71e684c0.
  • 🟡 Old links carry the term as _gf_search and lost it; created() now moves it to _search and remounts the list. The gemma-faceted-search spec scenario names the sidebar search — 71e684c0.
  • 🟢 The header docblock described the search as not using CnIndexPage's sidebar; it now says it does. The unused strings "Search applications and services…" and "Clear search" are removed from en and nl — 71e684c0.

Gates: local run on 71e684c0 (run-hydra-gates.sh --scope-to-diff --base origin/development): exit 0, 58 of 58 applicable gates ran. The PR's own CI did not start for the first head (the pull_request event was lost during a GitHub API outage); it is expected on this push.
Tests: npx jest 187 passed, vitest facetStore/facetSchema 28 passed, node tests/validate-manifest.js PASS, eslint clean on the changed files.
Not verified: in a browser — the WOO-586 rig was stopped during the review.

@github-actions

Copy link
Copy Markdown
Contributor

Quality Report — ConductionNL/stackiq @ 5ae0877

Check PHP Vue Security License Tests
lint ✅
phpcs ✅
phpmd ✅
psalm ✅
phpstan ✅
phpmetrics ✅
eslint ✅
stylelint ✅
build ✅
check-manifest ✅
check-vue-demi ✅
test-l10n ✅
format ✅
check-schema-l10n ✅
check-l10n-js ✅
composer ✅ ✅ 133/133
npm ✅ ✅ 807/807
app:check-code ⏭️
info.xml ✅
REUSE ❌
lockfile sync ✅
PHPUnit ✅ 1223/1223 · 20 skipped
Newman ⏭️
Playwright ⏭️ deferred: E2E runs locally and on the promotion path only. This pull request targets development, so the suite is asked once per promotion into beta and main rather than once per push per open pull request. Run it locally with npx playwright test, or from the Actions tab on a branch with no open pull request into development.
Hydra gates ✅

Quality workflow — 2026-10-12 14:54 UTC

Download the full PDF report from the workflow artifacts.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant