Added
- New Inventory module (Stage 1 of a larger design aimed at upstream contribution): track owned belongings with hierarchical storage locations, a manageable category list, purchase price, warranty length, condition and status. Deliberately no current-value/resale-estimate field - see discussion #696: a manually maintained number nobody updates is worse than none. Budget/document/subscription linking, derived deadlines and calendar integration follow in later stages.
- Inventory items can now be linked to documents from the Documents module (receipts, warranty cards, manuals), reusing the same document-linking mechanism Budget entries already use (Stage 2 of the Inventory module design). Items stay household-visible as before; each linked document is still filtered per viewer.
- Inventory items can now be linked to Budget entries (a purchase, a refund, a repair, an accessory bought later), including creating a new item directly from a booking with its purchase price prefilled automatically (Stage 3 of the Inventory module design). Visibility follows Budget's own rules exactly - in personal budget mode, a private booking stays invisible to other members even when linked to a household-visible item.
- Inventory items now surface a derived warranty deadline (Stage 4 of the Inventory module design): a proactive in-app reminder 30 days before the warranty ends, and a dedicated, subscribable read-only ICS calendar feed for warranty end dates. Both are computed on the fly from the purchase date and warranty length, never stored.
- Inventory items can now track an arbitrary number of custom dates beyond the built-in warranty deadline - TÜV, service, insurance renewal, or anything else with a date - each with its own configurable reminder lead time. These join the same reminder system and the same ICS feed (renamed from "warranty deadlines" to "inventory deadlines" to reflect the broader scope) that Stage 4 introduced.
- Inventory ships disabled and each household switches it on - the first module with that default. Every module is a permanent line item in the navigation of every household, including the ones that will never track a bike, and Inventory is the first whose audience is visibly a subset. Enable it under Settings → Navigation; a household that does not want it never sees it, and existing installs do not find a new entry after an update they did not ask for.
- The Inventory deadlines ICS feed token is now per user instead of household-wide, matching the calendar feed. A household-wide token could not be withdrawn from one person: whoever had subscribed kept access until it was taken from everyone. Each member now mints, rotates and disables their own subscription, and doing so leaves everyone else's running. The feed's content is unchanged and still household-wide - inventory items belong to the household, not to a member.
- The Inventory list is a two-level browse: the landing page shows metric cards (item count, total purchase value, items needing attention) and a category overview, and tapping a category shows its items grouped by storage location with "All" / "Needs attention" filter chips scoped to that category. Items can carry a single photo, and tapping one opens a read-only detail view (with a colored accent stripe) before editing; the nav icon carries a badge for items with a soon-expiring or overdue warranty or tracked date. The "Needs attention" metric card on the landing page is itself a filter now - tapping it flattens the list across every category to just the items that need a look, the same view search results already use. The five seeded categories (Electronics, Vehicles, Household, Sports, Other) are localized instead of staying German regardless of the app's language, matching how Task Categories already handle their own seeded set.
Fixed
- Everyone can manage their own calendar and inventory feed subscription, not just the admin. Both feed tokens have always been personal - they sit on your own user row, and neither route asks whether you are an admin - but the only place to reach them was Settings → Sync → Calendar, and that leaf is admin-only. In a household of five, one person could subscribe their phone to the family calendar and the other four could not, with no error to explain it: the page simply did not exist for them. The two sections now have their own leaf under Settings → Personal → Feed subscriptions, reachable by every member. Only the two feed sections moved; CalDAV accounts, ICS subscriptions and the one-time calendar import stay where they are for now. This is the fourth time a per-user setting had been stranded on an admin-only leaf, after the calendar defaults, the task defaults (#695) and the navigation order; existing subscription URLs keep working and nobody has to re-subscribe.
docker-compose.ymlstarts on Synology, QNAP and other older Docker builds again. Since v2.2.1 the file passed its.envin the Compose long form (- path: .env/required: false), which exists only from Compose v2.24 onwards. Anything older refuses the whole manifest withservices.yuvomi.env_file.0 must be a string- not at startup, but while reading the file, so nothing runs and the message points at a line the user did not write (#765, reported by @Zaldans on DSM 7.3.2 with Docker 24.0.2). The entry is back to the short form- .env, which every Compose version understands and whichpodman-compose.ymlhas kept all along. Nothing is lost by it: the long form was there for Git/GitOps stacks that clone the repository without a.env(#698), and that path has had its own file since,docs/docker-compose.portainer.yml, which lists every variable explicitly because Portainer hands its variables to Compose for substitution rather than as an env file. Keeping the long form only moved the failure one step later for those stacks - without a.envthere is noSESSION_SECRET, and the container exits on startup - while breaking every NAS whose engine predates it. A guard now holds the short form across all Compose manifests in the repository rather than a list of known files.