ulsklyc/yuvomi v2.14.3

on GitHub

Fixed

• Running the web installer a second time no longer downgrades a working installation. The simple path writes fixed values for host, port, SESSION_SECURE and TRUST_PROXY, and the re-run protection cannot catch them: it preserves whatever the client does not send, and these are sent. An instance set up behind a reverse proxy therefore lost its secure-only cookies, its proxy trust and its BASE_URL the moment someone picked "simple setup" again to change one small thing - with a blue banner that read like reassurance ("your current .env will be backed up") rather than a warning. When an existing .env is detected the simple path is now disabled, the recommendation moves to the advanced path, and a note says why. Three further values that were written on every run regardless of what the wizard showed are gone: SYNC_INTERVAL_MINUTES no longer resets a hand-tuned interval to 15, and DOCUMENT_STORAGE_LOCAL_ENABLED, DOCUMENT_STORAGE_WEBDAV_ENABLED and WEBDAV_BACKUP_ENABLED no longer write a literal false that silently switched off off-site backups and document storage while leaving their URL, username and password in place.
• The default answer to "how is Yuvomi exposed?" no longer produces an installation nobody can sign in to. "Behind a reverse proxy with HTTPS" was the pre-selected option, which sets SESSION_SECURE=true, while the fields right next to it still read localhost:3000. Anyone who left the defaults alone got an instance that only issues Secure cookies over plain HTTP, so the browser discards them and login fails without any message - and the hint text actively recommended that option in both reference languages. The choice now follows the host (localhost, 127.*, 10.*, 192.168.*, 172.16-31.*, *.local, .lan, .internal, home.arpa, IPv6 ULA and any name without a dot count as local), the hint states the consequence instead of a recommendation, and the combination of an http:// address with enforced secure cookies is blocked outright, naming the way out.
• The "download your .env" button no longer reports success when nothing arrived. It clicked a plain anchor, which cannot fail, and then unconditionally marked the keys as saved. Since the installer shuts itself down five minutes after the admin account is created, anyone who left the tab open and came back found a dead endpoint, no file, no error - and an interface claiming the keys were safe. This is the only backup of the DB_ENCRYPTION_KEY, for which there is deliberately no reset. The download now goes through fetch, checks the response, and only then reports success; a failure says so and shows where the file is on disk. The screen also states that the installer is about to shut down.
• Re-running the installer on an existing installation no longer ends on a raw "Not found." POST /api/v1/auth/setup answers with 404 when an account already exists and NODE_ENV=production - which every real deployment sets - while the wizard only accepted 201 or 403. The 403 branch existed in no production container, so the last screen of an eleven-step run showed an untranslated English server string with no explanation and no way forward. Both sides now treat 404 as the normal re-run case: the wizard continues to the final screen, which it needs anyway for the download and the follow-up links, and says that the account was already there.
• The public address is asked for instead of guessed, and it now follows what you type. BASE_URL was derived from scheme, host and port, which is never right behind a reverse proxy - the CLI installer asks for it explicitly for exactly that reason. Wrong values only ever fail silently: password-reset and invitation mails carry links nobody can open, and it surfaces weeks later. There is now a field for it, pre-filled from host, port and the exposure choice and updated as any of the three changes, and every derived redirect URI (Google Calendar, Google Drive, OIDC) comes from that one value instead of three separate constructions. The review screen lists it.
• Switching the interface language no longer disarms the confirmation step or mislabels a failed container start. Four labels change at runtime and still carried a static translation key, so applyTranslations wrote their base text back. On the review screen that meant the "click again to confirm" state reverted to "Save & start Docker" while the wizard still considered the action confirmed - one more click would have written the .env and started the container without the second confirmation. On the Docker screen a failed start was relabelled "Downloading image", next to a red cross and a visible error log, and announced that way in the live region.
• Placeholder text in the installer meets contrast requirements in dark mode. No ::placeholder rule existed, so Chrome's default #757575 applied, which does not follow the theme: measured 3.36:1 against the dark field background across all 25 fields that carry an example value. The app fixed the same class of problem in its own fields in July; the installer now uses the same element-level rule, and the value lands at 5.4:1.
• "Check again" after installing a container engine now unlocks the simple path. The lock could only ever be set, never lifted, so anyone who installed Docker mid-run watched the message disappear while the card marked "recommended" stayed dead - and kept the accent fill that marks it as the recommended choice. The lock now hangs on its two independent reasons (missing engine, existing .env) and the emphasis moves with it.
• Filipino is selectable again. It was supported, shipped and detected, but missing from the language dropdown - so a Filipino browser landed on an empty switcher, and anyone who changed the language once could not get back.
• Several controls in the installer are reachable and readable where they were not. The language switcher could only be reached backwards with Shift+Tab, because the focus moves to each step's heading and the switcher sat before it in the document; it also covered headings while scrolling on a phone. The exposure dropdown cut its longest option off without an ellipsis at 390px. The accordion headers and the language switcher fell below the 44px touch target on mobile, each for its own reason: a specificity conflict that a media query cannot resolve, and a button that carries no .btn class. Unchecked checkboxes rendered as white boxes in dark mode because no color-scheme was declared.

Changed

• The exposure choice and the public address moved to the first configuration step. They set SESSION_SECURE and TRUST_PROXY and decide whether login works at all, but they sat under a heading that reads "all optional - skipping is safe". They now belong to the step that asks how Yuvomi is reached, which is also what they answer. As a side effect the calendar step shows the final redirect URI rather than a provisional http://host:port, and the OIDC redirect field is pre-filled correctly for the first time.
• The installer ends with what to do next instead of a warning and a homework assignment. The final screen offered a download and a warning triangle; it now adds three concrete next steps - invite your family, choose your modules, install it on your phones - pointing at the real routes on the new instance. Setting up a family planner that has exactly one member is where the old ending left you.
• The review screen states what happens to the security keys instead of showing eight dots. Both key rows were masked bullets labelled SESSION_SECRET and DB_ENCRYPT_KEY - the latter not even the real variable name, so searching the .env for it found nothing. They now say whether a key was newly generated or carried over from the existing file. The data folder and the private-network switches were added, the latter because a review screen that omits exactly the security-relevant toggles is reviewing the wrong thing.
• A missing container engine is no longer a dead end. The message said "please install them and reload this page" with no link and no distinction between a missing engine and Podman without Compose, although the server knows the difference. It now links to the matching instructions and offers a "check again" button instead of asking for a page reload.
• The redirect URIs can be copied. They have to be transferred character by character into the Google Cloud Console and were the only values without a copy button, while the secrets two fields away had one.
• The installer looks like the rest of Yuvomi in the places where it did not. The wordmark used the accent colour, which the app's own stylesheet documents as forbidden for titles; the primary button used raw accent instead of the app's mix; the card carried a hairline border plus a wide shadow where the app's card has neither; hints were a size smaller than in the app. The inline fallback token block, which only takes effect when tokens.css cannot be loaded, had drifted from the real values in dark mode - in exactly the failure case it exists for.