Dashboard filter bar: clear actions, active count, impact hints, and overflow

[BorisTyshkevich]

Dashboard filter bar: clear actions, active count, impact hints, and overflow

Problem

The dashboard filter bar already renders shared parameter controls and reruns affected panels. With several filters, however, users cannot easily answer:

• Which filters are active?
• How do I clear one or all dashboard filters?
• Which panels does a filter affect?
• Is a hidden filter blocking a panel?
• How can the toolbar stay compact when many parameters exist?

These are presentation and usability problems over the existing parameter analysis. They do not require query-backed option sources, multiselect, or new execution semantics.

Goal

Improve the dashboard filter bar with four focused behaviors:

1. clear one filter;
2. clear all filters used by this dashboard;
3. show active count and per-filter impact;
4. collapse overflow behind More filters (N) without hiding errors.

Shared-state rule

Dashboard filters use the existing shared stores:

state.varValues
state.filterActive

Clear actions change activation only unless explicitly stated.

A cleared filter:

• becomes inactive;
• keeps its stored value dormant;
• persists activation;
• re-runs affected dashboard panels;
• does not delete recent-value history.

This matches optional-block semantics and allows reactivation without retyping.

Per-filter clear

Every active filter gets a clear affordance:

level: [Warning     ×]

Behavior:

• sets filterActive[name] = false;
• preserves varValues[name];
• persists activation;
• performs one affected-panel rerun wave;
• remains keyboard accessible;
• is absent or disabled when already inactive.

Clear dashboard filters

Add a toolbar action:

Clear filters

It deactivates only parameters referenced by the current dashboard snapshot.

It must not:

• remove unrelated globally stored values;
• clear recent history;
• affect parameters used only by saved queries outside the dashboard;
• trigger one rerun per field.

All activation changes coalesce into one preparation and rerun wave.

Disable or hide the action when no dashboard filter is active.

Active-filter count

Show a compact status near the filter bar:

3 active

Rules:

• count active dashboard parameters, not non-empty stored values;
• hidden/overflow filters still count;
• invalid required fields do not count as active;
• count updates immediately after clear or activation change.

Impact hints

Use existing multi-source parameter analysis.

Each field displays one concise hint:

used by 6 panels
3 panels waiting
used by 1 setup source

Rules:

• ordinary count is the number of displayed Panel sources referencing the parameter;
• waiting count is shown while the parameter is inactive/invalid and required by those Panels;
• Setup-source usage may be shown when Dashboard setup sources: run hidden setup queries before filters and panels #175 is present;
• Filter-source option queries are not counted as displayed Panels;
• hints are computed without additional SQL.

Keep exact source names in the tooltip when useful.

Overflow

When filters no longer fit the intended first toolbar row, keep a stable visible subset and place the rest under:

More filters (4)

Requirements:

• first row remains compact;
• disclosure is keyboard accessible;
• expanded overflow contains the same field controls, not clones with separate state;
• open/closed state survives local field repaint;
• layout wraps cleanly on narrower screens.

Initial ordering may remain parameter discovery order. MRU ordering is not required.

Never hide blocking states

A filter in any of these states must not be silently hidden:

• invalid;
• missing and required;
• type conflict;
• query-backed source error;
• setup-related configuration error.

Choose one consistent behavior:

• automatically open the overflow section; or
• show a clear error/waiting badge on More filters (N) and focus/open it when activated.

The user must be able to identify why a Panel is blocked without searching blindly.

Accessibility

• clear buttons have parameter-specific labels;
• active count is readable by assistive technology without announcing every repaint;
• disclosure uses aria-expanded and aria-controls;
• collapsed invalid/waiting state is exposed in the disclosure label/description;
• focus is preserved when filters rerender;
• clearing via keyboard produces the same single rerun wave as pointer use.

Files

Expected changes:

• src/core/dashboard.js
  • dashboard-scoped parameter set, active count, impact computation.
• src/ui/dashboard.js
  • clear actions, count, hints, overflow composition and coalesced wave.
• src/styles.css
  • compact clear controls, hints, disclosure and error badge.
• tests for core and UI behavior.

No new runtime dependency.

Tests

Clear behavior

• per-filter clear deactivates and preserves stored value;
• unrelated global parameters remain untouched;
• Clear filters affects only current dashboard parameters;
• bulk clear produces one rerun wave;
• recent values remain unchanged.

Count and impact

• active count follows activation, not string emptiness;
• hidden filters count;
• impact count matches per-source analysis;
• waiting count appears only for required blocked Panels;
• no extra network is issued to compute hints.

Overflow

• large filter sets collapse;
• controls retain one state instance;
• disclosure keyboard/ARIA behavior;
• invalid/required-hidden filters force visibility or badge;
• focus survives field and overflow repaint;
• responsive wrapping does not overflow horizontally.

Acceptance criteria

• Every active dashboard filter can be cleared individually.
• Clear filters deactivates only parameters used by the current dashboard and performs one rerun wave.
• Stored values and recent history are preserved.
• Active-filter count is accurate.
• Per-filter hints show affected/waiting Panel counts without network work.
• Excess filters collapse behind More filters (N).
• Blocking/invalid states are never silently hidden.
• Keyboard, focus, and ARIA behavior are covered.
• Coverage gates hold; no new runtime dependency.

Non-goals

• Query-backed option execution.
• Multiselect.
• Cascading filter dependencies.
• Saved filter presets/bookmarks.
• Reordering filters by MRU.
• A paired time-range picker.