fix(ngx): keep unavailable resources inspectable in declarative tables - #254
fix(ngx): keep unavailable resources inspectable in declarative tables#254anastazya wants to merge 2 commits into
Conversation
A resource with isAvailable === false was locked out of every interaction path: the row got pointer-events: none, interactive was removed, onRowClick dropped the emit, and resource-field disabled every button including navigation. A resource that is not ready is exactly the one a user needs to open to see why - with a readyCondition configured, failing resources became completely uninspectable (observed live on the Platform Mesh portal: a never-reconciled resource could not be opened at all, while its warning icon offered no explanation). - keep the dimmed styling but drop pointer-events: none and keep rows interactive - emit tableRowClicked unconditionally - disable only mutating buttons (update/delete) on unavailable resources; navigation and custom actions keep working - flip the row-click spec to the new contract and cover navigation buttons on unavailable resources All 592 ngx tests pass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Theodor Ganescu <star.sg1@gmail.com>
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (7)
💤 Files with no reviewable changes (1)
Included review availability: Your plan includes up to 1 review per rolling hour; 0 remain after this review. 📝 WalkthroughWalkthroughUnavailable resources remain interactive for navigation and inspection. Update and delete actions remain blocked for unavailable resources. Resource field, table card, and table row tests reflect the updated behavior. ChangesUnavailable resource interactions
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to Unavailable resources remain inspectable while mutating actions stay disabled; no actionable merge-blocking risk remains after normal checks and review. Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Here, we have the possibility to add the status reay or read whatever to indicate the satus or issue 
if navigating to the resource would give us more info, would that not be a case as well in the table view, I don't see anything that can give us more navigating in that scenaro to the resource, maybe some example or a screenshot what I am missing here? |
|
Concrete case, from the Platform Mesh portal on our dev landscape this morning (Telekom OSC provider, which sets a readyCondition): a ShootClaim sat not-ready because no controller had reconciled it. The table showed the alert icon with accessible-name "Resource is not ready" and nothing else — and with the row locked there was no way into the detail page, which is where the conditions/messages render and where Edit/Delete live. Worse: when a resource is not-ready because its spec is wrong (bad region, bad version), the fix is Edit on the detail page — but the row is disabled precisely because the resource is broken, so the UI can never reach its own fix. The only escape was kubectl. A status/reason column in the table (your screenshot) definitely helps visibility, and we're adding one to our fragment once the status contract is settled. But it's per-fragment config and one line — multi-condition detail and the remediation actions still live behind navigation. That's the case for keeping not-ready rows clickable and only blocking the mutating buttons. |
|
Great thanks for the insightfull description, now I see the breader picture here, and I will think analyze the proposed solution and how differently we can handle that situation as well. |
|
the thing is that this change completly oboletes the idea of the the last point:
so I am thinking how to address this differently maybe with a flag in the contentconfiguration export interface ResourceDefinition {
apiGroup?: string;
version: string;
entityCollection: string;
entity: string;
name?: string;
scope?: KubernetesScope;
namespace?: string;
readyCondition?: PlatformMeshFieldDefinition;
ui?: UIDefinition;
permissionsDefinition?: PermissionsDefinition;
}avilableWhenNotReady?: boolean |
2 participants
Problem
A resource with
isAvailable === falseis locked out of every interaction path in the declarative table stack — four independent layers: the row getspointer-events: none,[interactive]is removed,onRowClickdrops the emit, andresource-fielddisables every button including navigation (with a matching guard in the table-card handler).A resource that is not ready is exactly the one a user needs to open to see why. Observed live on a Platform Mesh portal: with a
readyConditionconfigured, a never-reconciled resource could not be opened at all — its warning icon offered no explanation and every path to the detail view was dead, while healthy resources navigated fine.Fix
Keep the dimmed visual state, restore inspectability:
pointer-events: none; rows stay interactivetableRowClickedunconditionallyupdate/delete) on unavailable resources;navigateand custom actions keep workingSpecs: row-click contract flipped to the new behavior, new coverage for navigation buttons on unavailable resources. 592/592 ngx tests pass.
🤖 Generated with Claude Code
Summary by CodeRabbit