update_settings() merged the admin's changes without touching timezone_configured. So a timezone-only PATCH /api/v1/admin/settings {"timezone": "America/New_York"} left the marker false, and a later panel request could replace the admin's chosen zone with the zone Home Assistant reports.
Fix
In core/settings_store.py::update_settings: when the changes include timezone but not timezone_configured, the same write also stores timezone_configured = True. If the caller supplies timezone_configured explicitly, it is kept as given. The automatic adoption path (adopt_reported_timezone → _write_merged) is unchanged and still leaves the marker false.
No schema change, no migration, no admin PWA or panel change, and no datetime.now() added.
Tests (tests/test_api_household_clock.py)
test_timezone_only_admin_update_is_an_explicit_choice[America/Los_Angeles | ""]: a timezone-only PATCH sets the marker true. A later panel report of a different zone does not change the stored zone, and an empty zone stays empty.
test_explicit_timezone_configured_false_is_respected: an explicit false is kept, and adoption still follows Home Assistant.
Existing tests still cover the automatic adoption path leaving the marker false (test_unset_zone_adopts_reported_zone_for_overdue, _adopt_new_york) and the admin path that sends timezone plus timezone_configured: true (test_admin_chosen_zone_wins_over_reported_zone).
On base 40d0e5d, in a throwaway worktree: 2 failed, 42 passed. Both parametrizations of the new timezone-only test fail.
At head: 44 passed.
Full suite TZ=UTC uv run pytest -q: 2171 passed, 1 skipped.
Done-condition
A timezone-only admin update persists timezone_configured = true, so the zone the panel reports cannot overwrite it.
Maestro task `45243478-d697-459b-bdb1-58b48a14b789`: release review finding RR-001.
## Problem
`update_settings()` merged the admin's changes without touching `timezone_configured`. So a timezone-only `PATCH /api/v1/admin/settings {"timezone": "America/New_York"}` left the marker false, and a later panel request could replace the admin's chosen zone with the zone Home Assistant reports.
## Fix
In `core/settings_store.py::update_settings`: when the changes include `timezone` but not `timezone_configured`, the same write also stores `timezone_configured = True`. If the caller supplies `timezone_configured` explicitly, it is kept as given. The automatic adoption path (`adopt_reported_timezone` → `_write_merged`) is unchanged and still leaves the marker false.
No schema change, no migration, no admin PWA or panel change, and no `datetime.now()` added.
## Tests (`tests/test_api_household_clock.py`)
- `test_timezone_only_admin_update_is_an_explicit_choice[America/Los_Angeles | ""]`: a timezone-only PATCH sets the marker true. A later panel report of a different zone does not change the stored zone, and an empty zone stays empty.
- `test_explicit_timezone_configured_false_is_respected`: an explicit `false` is kept, and adoption still follows Home Assistant.
- Existing tests still cover the automatic adoption path leaving the marker false (`test_unset_zone_adopts_reported_zone_for_overdue`, `_adopt_new_york`) and the admin path that sends `timezone` plus `timezone_configured: true` (`test_admin_chosen_zone_wins_over_reported_zone`).
On base `40d0e5d`, in a throwaway worktree: **2 failed, 42 passed**. Both parametrizations of the new timezone-only test fail.
At head: 44 passed.
Full suite `TZ=UTC uv run pytest -q`: **2171 passed, 1 skipped**.
## Done-condition
A timezone-only admin update persists `timezone_configured = true`, so the zone the panel reports cannot overwrite it.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
update_settings() now persists timezone_configured=True when the changes
supply timezone without timezone_configured, so Home Assistant's reported
zone can no longer replace an admin-chosen zone (release review RR-001).
An explicit timezone_configured is kept as supplied; the automatic
adoption path is unchanged and still leaves the marker false.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Maestro task
45243478-d697-459b-bdb1-58b48a14b789: release review finding RR-001.Problem
update_settings()merged the admin's changes without touchingtimezone_configured. So a timezone-onlyPATCH /api/v1/admin/settings {"timezone": "America/New_York"}left the marker false, and a later panel request could replace the admin's chosen zone with the zone Home Assistant reports.Fix
In
core/settings_store.py::update_settings: when the changes includetimezonebut nottimezone_configured, the same write also storestimezone_configured = True. If the caller suppliestimezone_configuredexplicitly, it is kept as given. The automatic adoption path (adopt_reported_timezone→_write_merged) is unchanged and still leaves the marker false.No schema change, no migration, no admin PWA or panel change, and no
datetime.now()added.Tests (
tests/test_api_household_clock.py)test_timezone_only_admin_update_is_an_explicit_choice[America/Los_Angeles | ""]: a timezone-only PATCH sets the marker true. A later panel report of a different zone does not change the stored zone, and an empty zone stays empty.test_explicit_timezone_configured_false_is_respected: an explicitfalseis kept, and adoption still follows Home Assistant.test_unset_zone_adopts_reported_zone_for_overdue,_adopt_new_york) and the admin path that sendstimezoneplustimezone_configured: true(test_admin_chosen_zone_wins_over_reported_zone).On base
40d0e5d, in a throwaway worktree: 2 failed, 42 passed. Both parametrizations of the new timezone-only test fail.At head: 44 passed.
Full suite
TZ=UTC uv run pytest -q: 2171 passed, 1 skipped.Done-condition
A timezone-only admin update persists
timezone_configured = true, so the zone the panel reports cannot overwrite it.🤖 Generated with Claude Code
Independent Codex gpt-5.6-terra review completed for this exact commit.