Allow external trigger of PaginatedResourceTable local-filter/api-filter fns

[richard-cox]

• PaginatedResourceTable will filter results sets via two optional functions
  • when SSP is not used it will run the result set via local-filter
  • when SSP is used it will provide filters for the api request used to fetch the result set
• Factors that affect the filters applied in both fns can change
• We need a way to re-trigger both processes given given those changes
• There might be something odd reactivity happening in some cases which would trigger this, see local-filter in PaginatedResourceTable does not work when switch the filter options which have the same amount of the record #15576 (comment)

[github-actions]

🎯 Agentic Issue Triage

Summary: Enhancement request to expose an external trigger mechanism on PaginatedResourceTable so that consumers can re-run local-filter and/or api-filter functions when the factors that determine those filters change independently of data changes. This is directly motivated by the bug reported in #15576.

📋 Issue Analysis

• Type: Enhancement / Feature Request
• Area: PaginatedResourceTable component — server-side pagination (SSP) and local filtering
• Milestone: v2.16.0
• Reporter: Team member (richard-cox), already assigned
• Related bug: local-filter in PaginatedResourceTable does not work when switch the filter options which have the same amount of the record #15576 — "local-filter in PaginatedResourceTable does not work when switching filter options with the same record count" — the root cause there is that the store's update mechanism doesn't re-trigger filtering when the data count hasn't changed. This enhancement is the proper fix/mechanism to resolve that class of problem.

Current behaviour:

• PaginatedResourceTable calls local-filter (non-SSP) or supplies filters to the API request (SSP) based on internally reactive state.
• External factors (e.g. a status dropdown, a tab change, a parent-component computed prop) that should influence those filters have no clean way to tell the table to re-evaluate.

Desired behaviour:

• A new API (e.g. a prop, an exposed method, or a watch-able reactive trigger) that consumers can call/set to force the table to re-run its filter logic.

🔧 Implementation Ideas

A few patterns to consider:

1. Expose a refresh / refilter method via defineExpose (Composition API) or ref-based call from the parent — simplest API, requires a template ref.
2. Accept a reactive filterKey / filterVersion prop — incrementing this prop triggers a watcher inside the table that re-runs both filter paths. Minimal API surface, easy to use.
3. Emit-based two-way binding — parent emits a signal via a shared event bus or provide/inject. Less idiomatic in Vue 3.
4. Watcher on the filter function references — if the local-filter/api-filter props are replaced with new function references (e.g. via computed) when the parent state changes, the table could watch for prop changes and re-run. This requires no new API if the table already watches those props.

Option 2 (filterKey prop) or Option 4 (watch the filter fn props) are likely the least invasive.

🐛 Debugging / Investigation Notes

• Reproduce the bug from local-filter in PaginatedResourceTable does not work when switch the filter options which have the same amount of the record #15576: have two items with the same status each, switch between statuses — the table doesn't re-render.
• Check PaginatedResourceTable's internal watchers: does it watch the local-filter prop reference? If not, replacing the function reference from the parent won't help.
• Check how local-filter is called — is it called only when the data array reference changes, or also when the prop changes?
• SSP path: trace where api-filter output is passed to the API request and whether there's a reactive dependency on the filter function itself.
• Look for uses of watchEffect vs watch — a watchEffect that only tracks data might miss filter-factor changes.

📁 Likely Files to Modify

• shell/components/PaginatedResourceTable.vue — primary file; add trigger mechanism and ensure watchers are correct.
• Any consumer components (e.g. in pkg/) that need updating to pass the new trigger prop/ref.
• Unit tests in shell/components/__tests__/ for the new behaviour.

✅ Suggested Sub-tasks

• Investigate current watcher/reactivity setup in PaginatedResourceTable for local-filter and api-filter props
• Decide on the trigger API (prop-based vs exposed method vs fn-ref watch)
• Implement the chosen mechanism
• Ensure both SSP and non-SSP filter paths are covered
• Update/add unit tests for the new trigger behaviour
• Update any consuming components (security-ext / other extensions) to use the new API
• Verify fix resolves the reproduction case from local-filter in PaginatedResourceTable does not work when switch the filter options which have the same amount of the record #15576

🔗 Resources

• Related bug: local-filter in PaginatedResourceTable does not work when switch the filter options which have the same amount of the record #15576
• Vue 3 defineExpose docs: (vuejs.org/redacted)
• Vue 3 Composition API watch / watchEffect: (vuejs.org/redacted)

Generated by Agentic Triage for issue #17678 · ● 154.7K · ◷