Skip to content

fix(settings): a gated tab survives a refresh and the Retention tab shows backup status (#3453, #3454) - #3476

Merged
vybe merged 2 commits into
devfrom
feature/3453-settings-gated-tab-backup-status
Oct 9, 2026
Merged

vybe merged 2 commits into
devfrom
feature/3453-settings-gated-tab-backup-status

Conversation

@trinity-ability

Copy link
Copy Markdown
Contributor

Description

Part of the UI sweep epic #3471.

Related Issue

Fixes #3453
Fixes #3454

Journey Impact

Journey Impact: none: bug fix to existing behaviour found by the UI sweep; no journey promise is added or changed

Type of Change

  • Bug fix (non-breaking change that fixes an issue)

Testing

  • I have tested this locally
  • New tests added (if applicable)
  • All existing tests pass
  • Every new test executes the changed path

Mutation: queryTabRestore.spec.js — 1 red with the offered-set watcher removed, 1 red with the user-clicked guard removed. backupStatusPanel.spec.js — 5 red with the state forced to Healthy, 2 red with a missing block treated as normal, 1 red with the loading state removed. Restored byte-identical. settingsTabAndBackupWiring.spec.js is a declared source-text pin on the two Settings.vue call sites only (the view is too large to mount); behaviour is covered by the two mounted specs.

UI verification: on a preview frontend over a live local backend: all 12 Settings tabs keep their ?tab= across a hard reload, an unknown tab shows General; the Database backups card matches every field of the backup block of GET /api/settings/retention, in light and dark at 1440 and 768 (a caveat line truncated at 768 was found in that pass and fixed in the second commit).

Checklist

  • My code follows the project's style guidelines
  • I have updated the documentation (if applicable)
  • I have not committed any sensitive data (API keys, credentials, etc.)

🤖 Generated with Claude Code

trinity-ability and others added 2 commits October 9, 2026 18:09
…ckup status (#3453, #3454)

#3453 — Settings resolved `?tab=` once at setup against a tab list that
filters on entitlements, which load after setup; the only watcher followed
the URL, which had not changed. A refresh or deep link on an
entitlement-gated tab therefore showed the default tab under a URL that
still named the gated one. The resolution moves to `useQueryTab`, which
re-applies the URL's tab when the offered set changes. It does not do so
once the user has clicked a tab — including a click on the tab already
shown, which changes neither the tab nor the URL — and it never rewrites
the URL while the set is unknown. A tab that is still not offered after
the load leaves the default in place.

#3454 — `GET /api/settings/retention` has returned a `backup` block since
#2216 and nothing rendered it. `BackupStatusPanel` shows it on the
Retention tab from the response the tab already fetches: one state badge,
last successful backup (UTC-parsed, relative with absolute on hover),
recovery points, location with the same-disk boundary, schedule and
retention. A failed or skipped attempt outranks an older success; a
missing `backup` key and `{"error": "unavailable"}` each say what they
are; loading is "no response yet" with the rows reserved.

Tests red under mutation, restored byte-identical:
- queryTabRestore.spec.js "becomes active once the entitlement that
  reveals it arrives" — offered-set watcher removed (also red against the
  pre-fix logic extracted unchanged)
- queryTabRestore.spec.js "a click on the tab already shown counts as a
  choice too" — user-chose guard removed
- backupStatusPanel.spec.js failed / skipped / stale / never-run / off —
  state forced to Healthy
- backupStatusPanel.spec.js "no backup key" and "could not build" —
  both treated as a normal block
- backupStatusPanel.spec.js "before the response arrives it holds its
  footprint and claims nothing" — loading state removed

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ing at narrow widths (#3454)

Found in the UI pass at 768 px: the same-disk caveat was cut off with an ellipsis.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

@vybe vybe 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.

merge-train: batch validated on train/20261009-2301-a (#3500)

@vybe
vybe merged commit 6ce8256 into dev Oct 9, 2026
24 checks passed
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.

2 participants