ulsklyc/yuvomi v2.41.2

on GitHub

Fixed

• An instalment on a loan the household had taken on could not be corrected (#859). Tick off an
  instalment on a borrowed loan, then open that booking in the budget and change the amount: saving
  failed with "Loan repayment entries must remain income." Nothing the dialog could send was
  accepted, because the dialog was right and the check was wrong. There was no way around it either

  • deleting the instalment and booking it again was the only remedy.

  The rule dates from a time when every loan was money lent out, where a repayment coming back
  really is income. Loan direction arrived in v1.77.0 (#638): an instalment on a loan you took on
  leaves the household and is booked as an expense, so it is negative by design. The loans routes
  learned that; the entry route kept the old rule and rejected exactly the sign it had itself
  written.

  The sign of a repayment booking now belongs to the loan rather than to the request, and it is
  derived from the same rule everywhere - booking an instalment, re-booking after a change of
  direction, and editing the booking afterwards. That rule lived inside the loans routes, which is
  why the entry route could contradict it; it is now shared between them.

  Two things the old check had been hiding come with it. The cap against paying off more than the
  loan still owes compared a signed amount against a positive remainder, so on a borrowed loan it
  was always satisfied and never stopped anything. And an amount of zero, previously caught by the
  income rule as a side effect, is now refused on its own terms rather than reaching a database
  constraint.

  In the budget dialog, the income/expense switch is now inert on a loan instalment and says so.
  Which of the two it is follows from the loan, is changed there, and any other answer was going to
  be silently overruled on save.

  Two further faults surfaced once this path could be walked at all, and both are fixed here. Opening
  an instalment for editing from the loan list filled the dialog from the instalment rather than from
  the budget entry it belongs to. On a foreign-currency loan that meant the loan-currency figure went
  in where the budget-currency one belongs, so saving converted it a second time - 100 USD at 0.50
  became a 200 USD instalment. And because that stand-in carries no account, the dialog offered "no
  account" and saving unlinked the instalment from the account it was charged to, moving that
  account's balance. Both happened even if all you touched was the title.

  Editing now loads the actual entry instead of assembling a second, partial copy of it. The
  assembled one still describes the row in the list, where the loan currency is the right figure to
  show - it was never an editing record, and now nothing treats it as one.

• A booked loan instalment was titled in English, whatever the household language (found while
  verifying #859). Ticking off an instalment writes a budget entry called Loan repayment: <name>,
  and that string was fixed in the source. In 23 of the 24 languages it has read as English ever
  since - in the entry list, in the CSV export, in search results and over the API.

  There is a translated title, and it has been there for a while, but it only ever applied when the
  stored title was empty. Regular instalments always have one, so it never got a turn. Where it did
  work was instalments backdated on an existing loan, which carry no budget entry at all - so the
  same list could show a translated title next to an English one, for two instalments of the same
  loan.

  The title is now written in the household's data language, the same way birthday events have been
  since v1.x (#524, #631, #632), and for the same reason: that row is what the REST API, the CSV
  export, the search index and MCP read, and none of those paths pass through the translation that
  happens in the browser. The translated fallback stays where it earns its keep - on backdated
  instalments.

  Existing entries keep their titles. The title of a budget entry is yours to edit, and rewriting
  one on a language change would overwrite a decision somebody may well have made on purpose.