- Sort imports and fix pyproject ruff config (per-file ignores for
intentional Qt/core exceptions)
- Mark Heirs.validate_* helpers as @staticmethod
- Clean up dead code, rename shadowing vars, use raise ... from
- Add AGENTS.md with env/lint/test/release guidance
When deleting old transactions and clicking Check, task_phase1 would fail
with 'NoneType object has no attribute get' error in WillItem.normalize_locktime.
Root cause: In Will.normalize_will (will.py:150), the parameter others_inputs
defaults to None. At line 151, a local variable 'others_input' is created with
a safe default value (empty dict). However, lines 179 and 184 still used the
original 'others_inputs' parameter instead of the safe local variable, causing
the error when calling .get() on None.
Fix: Use the safe 'others_input' variable instead of the raw parameter in
lines 179 and 184.
Also added:
- Traceback logging to on_error_phase1 so future errors include full call stack
- Debug logging in update_all to log willitems state before processing
- Comprehensive test (test_e5_build_with_real_wallet_heirs_and_utxos) that
reproduces the exact scenario from the user's karen7 wallet
Owner-approved changes after testing v0.4.6, plus accumulated v0.4.x work,
task-tracking notes, and an updated project HANDOFF document.
The four v0.4.7 changes:
1. Report area (BalBuildWillDialog) opens 500px tall (min) up to 700px (max),
then the scrollbar takes over. Previously it opened ~140px (too short).
2. Heirs are listed ONE per line again (green, bold) in _build_success_report,
reverting the v0.4.6 single-line form. Heir names can be long and the report
now scrolls, so compression is no longer needed.
3. Two wizard texts get an explicit line break: after "(or backup)" in the date
hint and after "miner fees" in the fee note (widgets.py).
4. ALL-DUST guard: when EVERY heir's share is below the Bitcoin dust limit, the
inheritance would pay nobody. Heirs.prepare_lists now raises
HeirAmountIsDustException at the end (where all heirs across all locktimes
are known with their final dust state), and dialogs.task_phase1 shows a clear
RED message and stops without building/signing/checking. A mix of dust +
valid heirs keeps building normally. The guard is intentionally in
prepare_lists, NOT prepare_transactions (which only sees the lowest locktime
and would false-positive). HeirAmountIsDustException is imported in common.py.
Tests: 3 new tests in test_core_heirs_extra.py pin the dust behaviour (all-dust
raises; mixed continues; multi-locktime continues). Full suite: 258 passed.
ruff: no new errors. Version bumped 0.4.6 -> 0.4.7 (4 files). CHANGELOG #23.
Also adds/updates HANDOFF.md so any future AI (Claude or another model) can
resume the project with full context (rules, layout, build/test/lint, dust
logic, git flow), and records the task-tracking notes in
.agent_memory_tasks.md.
UI batch (TASK A/B/C/D):
- (A) Clearer 'Will expired' message: shortened will id (8+8 chars) and
readable UTC date instead of raw UNIX timestamp; shown in WARNING colour
(orange) instead of ERROR (red) in the wizard, as it is an expected step.
- (A2) Split the orange message onto two lines via <br> (rendered as HTML by
msg_warning) to avoid an overly long single line.
- (B) History tab labels (text only): inheritance txs -> 'BAL Inheritance
transaction'; invalidate tx -> 'BAL Invalidate transaction'. Colours left
to Electrum defaults.
- (C) New 'No will-executor TX' checkbox in plugin settings, bound to the
existing NO_WILLEXECUTOR config (default ON, kept in sync with the wizard),
with help text, and included in the settings reset action.
- (D) Wizard button label 'Create your will' -> 'Build Your Will'.
Regression fix (A3):
- When an heir was added to an already-expired will via the wizard, the
automatic invalidation no longer triggered. Root cause: the inner
check_will() after build_will() raised WillExpiredException and the handler
returned (False, None), which never invalidated.
- Auto-opening the invalidation tx window from the closing wizard proved
unreliable (the window ended up behind the main wallet on some window
managers; a re-check loop could ask to invalidate repeatedly before the tx
reached the mempool). The robust fix: close the wizard and show a clear
instruction popup guiding the user to run 'Tools -> Invalidate' and then
press 'Check' to finish the will. Reasoning documented in the code.
Version bumped to 0.3.9 (manifest.json, __init__.py, plugin_base.py, VERSION).
CHANGELOG entry #15 updated. Verified: py_compile OK, ruff clean (no new
errors), full test suite 239 passed.
Bump plugin version to 0.3.4 (manifest, __init__, plugin_base, VERSION).
GROUP A
- A1: remove block-height locktimes; the plugin now uses UNIX timestamps
only. The NLOCKTIME_BLOCKHEIGHT_MAX guard is kept on purpose (it forces
every locktime to be a timestamp). chk_locktime is now 2-arg; int_locktime
and anticipate_locktime no longer accept blocks; RAW input only accepts d/y.
Two now-dormant configs (LOCKTIME_BLOCKS, LOCKTIMEDELTA_BLOCKS) are kept with
comments to avoid touching persisted keys.
- A2: rename PENDING -> MEMPOOL everywhere (label 'Mempool', yellow #ffce30);
add new UPDATED status; ANTICIPATED & UPDATED keep VALID; documented
set_status rules; backward-compat migration (old PENDING -> MEMPOOL).
- A3: clarify that anticipating to a future date only rebuilds (never
invalidates), while only a past locktime invalidates (WillExpired). Code was
already correct; only the comment and docs were fixed.
Colour follow-up: UPDATED lightened from #800080 to #b266b2 (more readable),
updated in theme.py, docs and the theme test.
GROUP B
- B1: verified the 'Create your will' button already opens the guided wizard
(no code change needed).
- B2: new persisted AUTO_SIGN setting (default ON) with an 'Auto-sign on Check'
checkbox in the settings dialog. When enabled, Check signs and broadcasts
automatically; the wallet password is requested only for encrypted wallets.
B2 follow-up (fixes reported after testing):
- Remove the duplicate sign/broadcast cycle in lists.check(); build_will_task()
already signs and broadcasts.
- Suppress the manual 'press Sign/Broadcast' hint and its popup when AUTO_SIGN
is ON (kept when OFF).
- Make broadcast one-shot: removed the retry flag and the Exception('retry');
failed will-executors stay PUSH_FAIL and are skipped (no endless retry).
PUSHED transactions are already excluded from re-collection.
Docs: inheritance-options.md/.html and inheritance-flow.svg updated to v0.3.4.
Tests: 206 passing (new test_anticipate_manual_locktime, test_anticipate_past_locktime,
test_group_b_auto_sign; updated core/util, core/will_extra, gui/theme, gui/widgets).
CHANGELOG.md added with one numbered entry per task.
Fix and refine the BAL plugin GUI without changing business logic:
core/will.py: restore the PUSHED requirement in needs_server_check so a
signed-but-not-broadcast will is no longer server-queried and therefore
stays blue (COMPLETE) instead of turning red (CHECK_FAIL). This matches the
original Gitea check() condition.
gui/qt/widgets.py: WillSettingsWidget vertical layout now caps every row to
the widest date-row width and left-aligns them; the leading icons keep their
original HelpButton width.
gui/qt/lists.py + gui/qt/common.py: the wizard toolbar button now shows a
28x28 icon plus a bold 'Create your will' caption (QSize imported).
gui/qt/dialogs.py (BalBuildWillDialog):
- closing summary row labelled 'All done: Ok' with a blank separator above it;
- 'checking variables' capitalised to 'Checking variables' (redundant trailing
colon dropped);
- final auto-closing countdown replaced by an explicit right-aligned 'Close'
button; intermediate technical pauses kept; next-steps popup preserved.
gui/qt/window.py + core/plugin_base.py: guide show_message on build, and
sync_hide_filters() in update_all so hide flags refresh immediately.
tests: test_needs_server_check updated; added offscreen preview helpers.
Version bumped to 0.3.3. 186 tests pass; ruff clean (baseline only).
Revert the v0.3.1 double-invalidation change (it caused an inheritance-list
regression: stale/invalidated wills lingered and heir/date updates became
incoherent) and add several targeted missed-update fixes plus a UI refinement.
Revert (v0.3.1 -> v0.3.2):
- Remove Will.mark_invalidated_by_tx() and its call in
loop_broadcast_invalidating. core/will.py and gui/qt/dialogs.py are restored
to the working v0.3.0 behaviour. The postpone double-invalidation issue is
intentionally left open, to be addressed without touching the shared
broadcast path.
FIX 1 - detect heir removal on Check / Electrum close:
- core/will.py (check_willexecutors_and_heirs): the else-branch now raises
HeirNotFoundException when a will still carries an heir that is no longer in
the current heirs set (heir removed), mirroring the existing 'heir added'
path. Rebuild therefore triggers on Check and on_close (same build_will_task
path), as decided by the user (manual update only, no auto-rebuild).
FIX 2 - Check queries servers for already-sent wills:
- core/will.py: new Will.needs_server_check(w) returns True for any VALID will
with a will-executor that is not yet CHECKED (no longer limited to PUSHED).
- gui/qt/lists.py (PreviewList.check): use needs_server_check so wills stuck on
'New / Not sent' are re-checked instead of reporting 'nothing to do'.
FIX 3 - Settings-dialog hide toggles refresh the list:
- core/plugin_base.py: new sync_hide_filters() re-reads the cached
_hide_invalidated / _hide_replaced flags from the persisted config.
- gui/qt/window.py (update_all): call sync_hide_filters() before refreshing, so
toggling 'Hide Invalidated' / 'Hide Replaced' in the Settings dialog (which
writes the config directly) updates the transaction list immediately instead
of requiring an Electrum restart.
UI - bold results in the Building Will dialog:
- gui/qt/dialogs.py (BalBuildWillDialog): render the right-side results in bold
(Ok, Ko, Nothing to do, Skipped, Wait, Timeout, ...) keeping the left-side
state labels in normal weight. Centralised in msg_ok/msg_error/msg_warning/
msg_set_status, plus the will-executor push/check rows now show Ok/Ko and
True/False in bold + colour (green/red).
Tests/tooling:
- tests/test_core_will.py: add test_check_heirs_unchanged_is_coherent,
test_check_heir_removed_triggers_rebuild, test_check_heir_added_triggers_rebuild,
test_needs_server_check.
- tests/sim_update_flows.py: real-world update-scenario simulation.
- tests/preview_build_will_dialog.py, tests/preview_we_rows.py: GUI-only
before/after previews of the bold formatting.
- Bump version to 0.3.2 (VERSION, manifest.json, __init__.py, plugin_base.py).
186 tests pass; smoke test, external-zip test and update-flow simulation OK;
ruff reports only pre-existing star-import false positives.
When postponing the delivery time of an already signed/sent will, the user
was asked to sign the on-chain invalidation transaction twice before the new
(postponed) will could be built.
Root cause: after the invalidation tx was broadcast, on_success_invalidate
restarted task_phase1 to rebuild the will, but the old will items were still
marked COMPLETE/PUSHED with their original tx.locktime (the on-chain
invalidation did not update the in-memory status). The postpone check therefore
fired WillPostponedException a second time, requesting another invalidation.
Fix:
- Add Will.mark_invalidated_by_tx(will, tx): marks INVALIDATED every valid will
item that spends a prevout consumed by the just-broadcast invalidation tx.
Setting INVALIDATED clears the VALID flag, removing those items from
only_valid_list so the postpone/expire check no longer fires.
- Call it from loop_broadcast_invalidating after a successful broadcast (txid
obtained) and persist via save_willitems. On the phase-1 restart the old will
is no longer VALID, so the will is rebuilt directly: a single invalidation
signature followed by the new will.
Tests: add test_will_mark_invalidated_by_tx and
test_will_mark_invalidated_by_tx_no_match plus the WillPostponedException
hierarchy assertion. 184 tests pass; smoke and external-zip OK; ruff clean.
Bump version to 0.3.1.
Postpone safety (Strategy B):
- A signed/sent will carries an immutable locktime; postponing the delivery
time previously did nothing, so a will-executor could still broadcast the
old (earlier-locktime) transaction and execute the inheritance too early.
- core/will.py: add WillPostponedException and detect postpone by comparing
the requested locktime against w.tx.locktime (the locktime frozen in the
signed transaction) instead of the in-memory heir entry, which is updated
together with the new value and would always compare equal.
- gui/qt/dialogs.py (BalBuildWillDialog.task_phase1, the real path used by
Tools -> Prepare): handle WillPostponedException before NotCompleteWill;
return (None, tx) to trigger sign + broadcast of the invalidation, then the
user presses Prepare again to rebuild/re-sign/re-send (two explicit steps).
- gui/qt/window.py: mirror the branch in build_inheritance_transaction with an
explanatory message; wording aligned to the 'Prepare' button.
- gui/qt/common.py: export WillPostponedException.
- A postpone on a will that was never signed/sent just rebuilds (no on-chain
fee).
Server status column:
- gui/qt/lists.py: add a dedicated 'Server' column to PreviewList with an
always-readable label and a tooltip (will-executor URL + state).
- gui/qt/theme.py: add server_status_text() and server_status_tooltip(),
reusing the existing status flags.
- gui/qt/common.py: export the new theme helpers.
Docs: update README.md, bal/README.md and CHANGELOG_REFACTOR.md.
Tests: 182 passed; smoke + external-zip OK; ruff has no new real findings.
