Files
Mattsson e996d70955 feat(settings): rename learned counterparty templates (#2454)
* feat(settings): rename learned counterparty templates

A user asked why a learned template under Inställningar > Mallar can be
deleted but not renamed. Nothing legal or ledger-shaped blocks a rename;
the one real obstacle was that the learn path keys templates by the
normalized bank description, so a renamed row would stop receiving
re-approvals and a duplicate would appear under the old key.

Why it occurred: counterparty_name doubles as display name and as the
learn/upsert key, and the only write path for it was the learner. There
was no rename because every later approval would have forked the row.

What was simplified instead of added: no display-label column, no new
table, no migration. The rename moves the old key into
counterparty_aliases, which the matcher already checks first, and the
learn lookup (findTemplateByKey) now resolves name-then-alias so
re-approvals and SIE re-imports land on the renamed row.

Why this over the proposed shape: a separate label would have kept the
key untouched but added a second name field for users to reason about;
renaming the key with an alias trail gives the user exactly what they
asked for with one fewer concept. Duplicate names are refused with 409
(active twin) or the invisible soft-deleted twin is removed (inactive).

Fixes #2453

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CgYn5GEp4N5Dxjc1S9Ljbq

* fix(bookkeeping): resolve the normalized-name match tier through aliases after a rename

Skeptic refutation on 819894559: the alias tier compares raw lowercased
bank descriptors, so the normalized key a rename pushes into aliases
("spotify") never matched there, and the name tier only knew the new
label ("musik"). A renamed template kept learning through
findTemplateByKey but was never proposed again for the merchant it was
learned from. nameMap now also resolves aliases, with a real
counterparty_name always winning over another row's alias.

Refs #2453

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CgYn5GEp4N5Dxjc1S9Ljbq

* fix(bookkeeping): canonical name beats a borrowed alias; unique-name race returns 409

Review findings on #2454:
- The alias tier ran before the name tier, so a bank line that is exactly
  another template's canonical name could resolve to a row holding that
  string as a rename alias. Aliases claimed by a different template's
  counterparty_name are now skipped when building the alias map.
- The PATCH twin check and the update are separate statements; a learn
  or a concurrent rename between them surfaced as 500. Postgres 23505 on
  the update now maps to the same 409 as the pre-check.

Refs #2453

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CgYn5GEp4N5Dxjc1S9Ljbq

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-09 12:32:29 +02:00
..
2026-07-13 22:54:33 +02:00