SRVKP-12524: Persist datasource filter selection for PipelineRuns

[ankrsinha]

Summary

Implements RFE SRVKP-12524: Persist the user's datasource filter selection (Cluster / Archived)
across sessions on the PipelineRuns list page.

The selection is stored in the Console's per-user ConfigMap via useUserPreference from the
dynamic plugin SDK. On the next visit, the previously selected datasource filter is automatically
applied. Default selection is Cluster.

Changes

• New hook useDatasourcePreference: Encapsulates useUserPreference for datasource filter
  persistence. Accepts a pageType (pipelineRun | taskRun) to allow reuse for TaskRuns
  in a follow-up.
• PipelineRunsList.tsx: Wraps onFilterChange to save datasource selection on change.
  Wraps onClearAll to reset preference to default.
• consts.ts: Adds USER_PREFERENCE_PREFIX for consistent preference key naming.

Behavior

Action	Result
User selects "Archived"	Preference saved, next visit shows "Archived"
User selects both	Preference saved, next visit shows both
Clear all filters	Chips removed, all data shown. Preference reset to "Cluster"
Next visit after clear	"Cluster" filter applied
Cross-device	Preference synced via ConfigMap
First-time user	Default "Cluster" applied (same as current behavior)

Test plan

• Verify datasource filter persists across page navigation
• Verify datasource filter persists across browser sessions
• Verify "Clear all filters" removes chips and resets preference
• Verify unit tests pass (yarn test)

Screen Recordings / Screenshot

Screencast.From.2026-07-03.11-44-56.mp4

[openshift-ci-robot]

@ankrsinha: This pull request references SRVKP-12524 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

Implements RFE SRVKP-12524: Persist the user's datasource filter selection (Cluster / Archived)
across sessions on the PipelineRuns list page.

The selection is stored in the Console's per-user ConfigMap via useUserPreference from the
dynamic plugin SDK. On the next visit, the previously selected datasource filter is automatically
applied. Default selection is Cluster.

Changes

• New hook useDatasourcePreference: Encapsulates useUserPreference for datasource filter
  persistence. Accepts a pageType (pipelineRun | taskRun) to allow reuse for TaskRuns
  in a follow-up.
• PipelineRunsList.tsx: Wraps onFilterChange to save datasource selection on change.
  Wraps onClearAll to reset preference to default.
• consts.ts: Adds USER_PREFERENCE_PREFIX for consistent preference key naming.

Behavior

Action	Result
User selects "Archived"	Preference saved, next visit shows "Archived"
User selects both	Preference saved, next visit shows both
Clear all filters	Chips removed, all data shown. Preference reset to "Cluster"
Next visit after clear	"Cluster" filter applied
Cross-device	Preference synced via ConfigMap
First-time user	Default "Cluster" applied (same as current behavior)

Test plan

• Verify datasource filter persists across page navigation
• Verify datasource filter persists across browser sessions
• Verify "Clear all filters" removes chips and resets preference
• Verify unit tests pass (yarn test)

Screen Recordings / Screenshot

Screencast.From.2026-07-03.11-44-56.mp4

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ankrsinha
Once this PR has been reviewed and has the lgtm label, please assign arvindk-softwaredev for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[qodo-code-review]

PR Reviewer Guide 🔍

Warning

/review is deprecated. Use /agentic_review instead (removal date not yet scheduled).

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Possible Issue The preference key uses dateSource in the constructed key string, which looks like a typo/inconsistency with the rest of the code that uses dataSource. This can cause persisted values to be stored under an unexpected key and not be read back correctly (or collide with other future keys). export const useDatasourcePreference = (pageType: PageType) => { const [preference, setPreference, loaded] = useUserPreference<string[]>( `${USER_PREFERENCE_PREFIX}.dateSource.${pageType}`, DEFAULT_DATASOURCE_VALUES, true, ); Type Safety The onFilterChange wrapper persists the dataSource value by casting value to string[], but the callback signature allows string | string[]. If the underlying filter ever passes a single string, this could store an incorrect type in user preferences and/or break consumers expecting an array. Consider normalizing to an array before persisting. const onFilterChange = useCallback( (key: string, value: string | string[]) => { baseOnFilterChange(key, value); if (key === 'dataSource') { setDatasourcePreference(value as string[]); } }, [baseOnFilterChange, setDatasourcePreference], ); Test Coverage Tests verify key contains pipelineRun/taskRun, but they don't assert the full key format/prefix or the dataSource segment. If the key has a typo, these tests would still pass. Consider tightening assertions to catch key naming regressions. it('should use a different preference key for taskRun', () => { testHook(() => useDatasourcePreference('taskRun')); expect(useUserPreferenceMock).toHaveBeenCalledWith( expect.stringContaining('taskRun'), DEFAULT_DATASOURCE_VALUES, true, ); }); it('should use a different preference key for pipelineRun', () => { testHook(() => useDatasourcePreference('pipelineRun')); expect(useUserPreferenceMock).toHaveBeenCalledWith( expect.stringContaining('pipelineRun'), DEFAULT_DATASOURCE_VALUES, true, ); });

[ankrsinha]

/agentic_review

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials

1. Preference load not applied ✗ Dismissed 🐞 Bug ≡ Correctness

Description

PipelineRunsList feeds datasourcePreference into useDataViewFilter as
defaultDataSourceValues, but useDataViewFilter only uses those defaults to initialize
filterState once. If useUserPreference resolves after the first render, the persisted datasource
selection is never applied (and the list may show the wrong datasource and loading behavior).

Code

src/components/pipelineRuns-list/PipelineRunsList.tsx[R52-73]

+  const {
+    preference: datasourcePreference,
+    setPreference: setDatasourcePreference,
+    resetPreference: resetDatasourcePreference,
+  } = useDatasourcePreference('pipelineRun');
+
  const [pipelineRuns, k8sLoaded, trLoaded, pipelineRunsLoadError] =
    useGetPipelineRuns(namespace, { name: PLRsForName, kind: PLRsForKind });

  const {
    filterValues,
-    onFilterChange,
-    onClearAll,
+    onFilterChange: baseOnFilterChange,
+    onClearAll: baseOnClearAll,
    filteredData,
    updatedCheckboxFilters,
  } = useDataViewFilter<PipelineRunKind>({
    data: pipelineRuns || [],
    options: {
      resourceType: 'PipelineRun',
-      defaultDataSourceValues: ['cluster-data'],
+      defaultDataSourceValues: datasourcePreference,
    },
  });

Evidence

The new code passes the preference into useDataViewFilter defaults, but the filter hook
initializes state from defaults only once and does not resync state when defaults change. Since the
preference hook explicitly exposes an async loaded flag, the preference can change after initial
render and be ignored by the active filter state.

src/components/pipelineRuns-list/PipelineRunsList.tsx[52-73]
src/components/hooks/useDatasourcePreference.ts[9-25]
src/components/hooks/useDataViewFilter.ts[153-236]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The datasource preference is loaded via `useUserPreference` (async) but the datasource filter state in `useDataViewFilter` is initialized only once. This can prevent the persisted datasource selection from being applied on page load.

### Issue Context
- `useDatasourcePreference` returns `loaded`, but `PipelineRunsList` doesn’t use it.
- `useDataViewFilter` computes `initialValues` from `checkboxFilters`, then does `useState(initialValues)` once; changes to `defaultDataSourceValues` later do not update `filterState`.

### Fix Focus Areas
- src/components/pipelineRuns-list/PipelineRunsList.tsx[52-99]
- src/components/hooks/useDatasourcePreference.ts[9-25]
- src/components/hooks/useDataViewFilter.ts[153-236]

### Implementation direction
In `PipelineRunsList`, apply the persisted datasource filter once when the preference finishes loading (and only if the user hasn’t already interacted):
- Destructure `loaded` from `useDatasourcePreference`.
- Add a `useEffect` that, when `loaded` becomes true, calls `baseOnFilterChange('dataSource', datasourcePreference)` (optionally guard with a `useRef` so it runs once and doesn’t override user input).

Alternative (broader) fix: update `useDataViewFilter` to reconcile `filterState` when `initialValues` changes due to updated defaults, but do so carefully to avoid wiping user-entered filters.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[anwesha-palit-redhat]

This needs to be moved inside /src/components/hooks/useDataViewFilter.ts.
What you are doing here is mutating methods that the hook exposes using baseOnFilterChange and baseOnClearAll which is not a practice that should be followed.