-
Notifications
You must be signed in to change notification settings - Fork 1
Capacity drill-down pages show a generic error instead of 403-specific copy #33
Copy link
Copy link
Open
Labels
area/consoleIssues or PRs related to apps/console — routes, detail pages, marketplace, command paletteIssues or PRs related to apps/console — routes, detail pages, marketplace, command palettekind/cleanupCategorizes issue or PR as related to cleanup of code, process, or technical debtCategorizes issue or PR as related to cleanup of code, process, or technical debtpriority/backlogGeneral backlog priority. Lower than priority/important-longtermGeneral backlog priority. Lower than priority/important-longterm
Metadata
Metadata
Assignees
Labels
area/consoleIssues or PRs related to apps/console — routes, detail pages, marketplace, command paletteIssues or PRs related to apps/console — routes, detail pages, marketplace, command palettekind/cleanupCategorizes issue or PR as related to cleanup of code, process, or technical debtCategorizes issue or PR as related to cleanup of code, process, or technical debtpriority/backlogGeneral backlog priority. Lower than priority/important-longtermGeneral backlog priority. Lower than priority/important-longterm
Type
Fields
Give feedbackNo fields configured for issues without a type.
ClusterUsageResourcePageandStorageClassUsagePagerender a generic "Failed to load…" message on any list error.ClusterStorageSection, in the same Capacity area, distinguishes a 403 ("You do not have permission…") from other failures. For consistency the two drill-down pages should do the same.Both pages sit behind
CapacityAdminGuard(gated onnodes/list), so the realistic 403 case is a user who can list nodes but not the pods/PVCs the drill-down reads.Suggested fix: reuse the
K8sApiErrorstatus check fromClusterStorageSection, with a test for the 403 branch.