Skip to content

v5.1.1

Choose a tag to compare

@tempus2016 tempus2016 released this 13 Aug 12:00
38b28c0

A fix release for sibling chore swaps — the whole feature was unusable, and three of the four bugs below were invisible rather than noisy. Plus one small kid-facing addition: the child card now shows how close the next badge is.

No configuration changes — upgrade is drop-in.

New — cards

  • Progress toward the next badge on the child card — under the earned-badge strip there is now a compact Next up line: tier-coloured icon, badge name, a thin bar and an 845 / 1000 count for the closest unearned badge.

    The card only ever showed badges already won, so a child working toward 10 Perfect Weeks got no feedback until it popped — that progress existed only in the Badges card, which children rarely open. Tapping the line opens the panel's badges section, same as the earned strip. It hides itself when there is nothing left to earn or every remaining badge is still at 0%.

    Shown on all five designs. To turn it off, set show_next_badge: false on the card:

    type: custom:taskmate-child-card
    entity: sensor.taskmate_overview
    child_id: <child id>
    show_next_badge: false

    (#788, closes #780)

  • The Badges card's locked-tile progress bars now draw — found while building the above. Those bars read a closest_criterion field that nothing ever emitted, so they had never appeared on real data. The badges sensor now publishes it and the bars work — verified on a live instance: 0 bars before, 9 after. (#788)

Fixes

  • An approved sibling swap can now actually be completed — the swapped-to child saw the chore appear on their card, then tapping it did nothing at all: no completion, no points, no pending approval, and the chore reappeared within 30 seconds.

    Approval wrote only the cached assignee field, while every eligibility gate resolves the day's assignee through pure rotation date maths — so the completion service rejected the tap as "not assigned to you today", silently, at debug level. Approval now stamps a dated override that the resolver honours, which repairs completion, the per-chore button, the to-do list, streak and perfect-day accounting, calendar publishing, and the mid-day availability re-check that used to revert an approved swap. Skipping a chore or manually starting it clears the swap, since both are deliberate parent moves.

    Broken since v4.0.0, when sibling swaps were introduced. (#782, closes #781)

  • A deleted chore or child no longer leaves a stuck swap request in the approval queue — removing either cascaded to completions, transactions, task groups and much else, but never to swap requests, so a pending request outlived what it referred to. The panel cannot resolve a name that is gone, leaving the parent a permanent "? wants to swap ?" row that only rejecting could clear. Both ends of a request are now cascaded, and a chore's approved swap is cleared if it pointed at the deleted child. Existing installs are swept clean on upgrade. (#786, closes #785)

  • Deleting a child no longer hides their rotation chores from everyone else — the child was removed from the chore's pool but the chore kept pointing at them as today's assignee, and since a deleted id matches nobody, the chore vanished from every remaining child's card until midnight recomputed it. Confusingly the completion service and to-do list still accepted the survivor — only the card disagreed. Affected chores are now repointed at today's live pool immediately, and the pointer clears when the pool empties. (#789, closes #787)

  • Settled swap requests are no longer kept forever — approving a swap flipped the record's status and left it in storage. Nothing reads a request once it stops being pending, so those were write-only rows that accumulated for the life of the install. Approval now consumes the request, exactly as rejection always did, and existing stores are swept on load. Nothing is lost: the approval is still observable through the taskmate_swap_approved event and the chore's own dated override. (#784, closes #783)

  • Badge progress for "any of these" badges — the sensor reported the worst criterion for every badge, but a badge with an OR combinator is awarded on the best one, so such a badge could sit below 100% while already earned. It now takes the minimum for AND badges and the maximum for OR. (#788)

Internal

  • The documented minimum Home Assistant version was wrong: async_register_static_paths puts the real floor at 2024.7.0, not the 2024.1.0 previously claimed. (#776)
  • CI now tests both ends of the supported range — Python 3.12 on HA 2024.7.0 and Python 3.14 on current — so a change that breaks the floor is caught before release. (#775, #777, #778)
  • ruff format is enforced in CI, with the one-off reformat commit added to .git-blame-ignore-revs. (#774)
  • Added release guards that fail loudly rather than silently shipping a broken release: manifest-version-matches-tag, and a check that taskmate.zip is attached. Plus data-file checks, dependency review and a dev container. (#772)

Upgrading

HACS → TaskMateRedownloadv5.1.1, then restart Home Assistant. Hard-refresh the browser (Ctrl+Shift+R) so the updated cards load.

Full changelog: v5.1.0...v5.1.1