Yuvomi
Self-hosted family planner for tasks, calendar, shopping, meals, and budget
Alternative to: cozi, familywall, skylight

v2.33.0
2026-08-23Added
POST /api/v1/documentstakes afolder_key. It names the system folder a module files its receipts in (budget,tasks,splitExpenses,inventory,housekeeping,calendarItems) and is what identifies that folder;folder_nameis now only the label used if the folder still has to be created. Sendingfolder_namealone keeps working and matches on the name, so an older client files exactly as before.
Fixed
-
The changelog no longer needs GitHub to show anything (#838). The view was a plain proxy to
api.github.com: if that call failed you got a 502 and “could not be loaded right now”, with no reason and no content. For a self-hosted app, needing someone else’s network to read your own history is the wrong dependency, and the ways there are ordinary - a container without outbound network, a timeout, or GitHub’s limit of 60 unauthenticated requests per hour and IP. TheCHANGELOG.mdthat ships with the app now goes into the image and carries the view when GitHub does not answer, with the same thirty releases and the same parser.It says which one you are looking at, and it reports the latest version as unknown rather than claiming you are up to date - the bundled file cannot know about anything newer than itself. The client does not record the check as done either, so the update question is not treated as settled for six hours when GitHub never answered.
A second problem sat underneath: only successes were cached, so once GitHub started failing, every request went out again. A household could push itself into the rate limit and keep the failure alive. Failures are now backed off for five minutes.
-
A module’s document folder is found by a stable key, not by its translated name (migration v157). Six modules file receipts in a folder of their own, and the identity of that folder was its display name - which the client sent, in its own language. Three faults followed from that one decision. Two members with different language settings created two folders, each holding half the receipts, which is the normal case in a multilingual household rather than an edge case. Every correction to a translation split the folder again; migration v146 had to clean that up once, and PR #837 was about to trigger it a second time. And a folder someone renamed came back under its old name with the next receipt, so the rename looked like a move it never was.
module_keycarries the identity now and the name is a label that may change freely, so a migration like v146 will never be needed again. Existing folders are bound to their key by written- out name lists, the same way v146 worked and for the same reason. Where a household holds the same folder in two languages, the older one takes the key and nothing is merged - that would be a decision about someone else’s documents.The lookup also existed in two copies, in the documents route and in the calendar helper, and now lives in
services/document-folders.js. -
The housekeeping folder is named after the module whose receipts it holds. It differed in twelve of twenty-four languages, and two of those -
HouseKeeping(en) andHázTartás(hu) - were simply typos. Before v157 that was a data fault rather than a cosmetic one. -
Filipino reads more like Filipino (PR #837, thanks @anobongjimwel). 214 values across the navigation, dashboard, tasks, shopping, meals, calendar, contacts, budget and settings. The follow- up carried the two renames through:
Imbentaryonow stands in all four places the module name appears, and seven strings that still saiddespensafollow the module’sPaminggalan.