[Dashboard] Plugin-registered table filter properties - #10618
Open
ishankaul1 wants to merge 5 commits into
Open
Conversation
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
force-pushed
the
ishan/slurm-jobs-account-qos
branch
from
September 1, 2026 01:07
0f94279 to
13f063f
Compare
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
registerTableColumn: plugins callregisterTableFilter({table, key, label, kind, order})and pages readusePluginTableFilters(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 aspluginFilters: [{property, value}](cache keys included).useUrlFilterStateschema-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.registerTableColumnmechanism. Deployments without such a plugin see zero change.Test plan
next lintclean; the jobs URL-filter suites cover schema round-tripping with the (mocked, stable) registry hook.sortKey; deployments where the provider never registers show no trace.🤖 Generated with Claude Code