Skip to content

[Dashboard] Plugin-registered table filter properties - #10618

Open
ishankaul1 wants to merge 5 commits into
masterfrom
ishan/slurm-jobs-account-qos
Open

[Dashboard] Plugin-registered table filter properties#10618
ishankaul1 wants to merge 5 commits into
masterfrom
ishan/slurm-jobs-account-qos

Conversation

@ishankaul1

@ishankaul1 ishankaul1 commented Aug 31, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Adds a generic filter-property registry to the dashboard plugin system, mirroring registerTableColumn: plugins call registerTableFilter({table, key, label, kind, order}) and pages read usePluginTableFilters(table). The jobs page appends registered properties to its filter schema — they appear in the filter dropdown, round-trip through the URL, and their values are forwarded verbatim to the data provider as pluginFilters: [{property, value}] (cache keys included).
  • Makes useUrlFilterState schema-reactive: registration is asynchronous (typically arriving with a plugin's first data response), so a deep-linked param that lands before registration passes through as an unowned key and decodes into a filter chip the moment the schema grows.
  • OSS ships no filter-specific UI of its own from this PR: concrete filters (e.g. Slurm Account/QOS) and any companion columns are registered by the data-provider plugin via this and the existing registerTableColumn mechanism. Deployments without such a plugin see zero change.

Test plan

  • Full dashboard jest suite (200 passed) and next lint clean; the jobs URL-filter suites cover schema round-tripping with the (mocked, stable) registry hook.
  • Manual, against a provider plugin registering two filters + a column on its first response: dropdown gains the properties after the first fetch; cold-load deep link with a registered param decodes into a chip and serves filtered rows; sort via the registered column's sortKey; deployments where the provider never registers show no trace.

🤖 Generated with Claude Code

@ishankaul1
ishankaul1 marked this pull request as ready for review September 1, 2026 01:06
…lurm rows

External Slurm rows merged into the jobs table can carry the Slurm
accounting fields (account, qos). Show them in a conditional
'Account / QOS' column (only once external rows have been seen, latched
so it doesn't flicker across pages) and offer Account/QOS filter
properties in the filter dropdown, forwarded to the pagination backend
as account_match/qos_match. Managed rows show an em-dash; the schema
keeps both properties unconditionally so shared URLs always decode.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ishankaul1
ishankaul1 force-pushed the ishan/slurm-jobs-account-qos branch from 0f94279 to 13f063f Compare September 1, 2026 01:07

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Devin Review found 2 potential issues.

Devin Review

Comment thread sky/dashboard/src/components/jobs.jsx Outdated
Comment thread sky/dashboard/src/components/jobs.jsx Outdated
ishankaul1 and others added 4 commits August 31, 2026 18:20
A cluster can stamp QOS without an account; the cell previously hid the
QOS in that case. A lone QOS renders as '— / <qos>' so it cannot read as
an account name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…bled flag

The row-scan latch was path-dependent: if the current page happened to
hold only managed rows while external rows sat on later pages (or the
user was on the my-jobs scope), the Account/QOS column and filter
options never appeared. Providers that serve external rows now send a
deployment-level externalJobsEnabled flag on every response; the page
latches on it from the first fetch, independent of page contents. The
row-scan stays as a fallback for providers without the flag.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The provider flag (externalJobsEnabled) is the single signal now.
Dashboards ship in the same image as the provider that sends it, so
the only case the row-scan covered was a dev-only version skew — not
worth keeping the path-dependent mechanism for.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… of OSS

Rework per review: instead of OSS carrying Slurm-specific Account/QOS
filter properties and a column, the plugin system gains a generic
registry — registerTableFilter({table, key, label, kind, order}) +
usePluginTableFilters(table) — mirroring registerTableColumn. The jobs
page appends registered properties to its filter schema (dropdown, URL
round-trip via a now schema-reactive useUrlFilterState — a deep-linked
param that arrives before registration decodes into a chip when the
schema grows) and forwards their values verbatim as
pluginFilters: [{property, value}] through the cache manager to the
data provider's fetch function.

OSS itself now ships no Account/QOS UI at all: the column moved to the
provider plugin via the existing registerTableColumn mechanism, and the
externalJobsEnabled response passthrough is gone (the provider consumes
its own flag to decide to register).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ishankaul1 ishankaul1 changed the title [Dashboard] Jobs table: Account/QOS column and filters for external Slurm rows [Dashboard] Plugin-registered table filter properties Sep 1, 2026
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