11 Commits

Include renames

Author	SHA1	Message	Date
LucaandPaul Nothaft	9431b9f094	feat(setup): configure the public address and SMTP in the wizard, not .env (#1104) ... * feat(setup): configure the public address and SMTP in the wizard, not .env A fresh install could not configure its own public address. `general_site_url` and the `email_configs` row already existed as admin settings, but nothing could reach them: - docker-compose.yml injected FRONTEND_URL=${FRONTEND_URL:-http://localhost:3000} and Dockerfile.aio baked in ENV FRONTEND_URL=http://localhost:3000, so getFrontendBaseUrl() returned on its first branch every time and the setting was never read. .env.example shipped the same value as an uncommented placeholder for FRONTEND_URL / ADMIN_URL / API_URL. - the wizard never asked for the address at all, and skipped its whole config step unless a CRM-ish feature was selected — so a gallery-only install was also never offered SMTP, despite gallery links, guest invites and expiry warnings all going out through email_configs. - eleven call sites read process.env.FRONTEND_URL directly rather than the resolver, three of them defaulting to placeholder hosts that reached real recipients: https://app.example.com in payment-reminder emails, localhost:3005 in admin invitation emails, https://app.example.com in dev template previews. Stop injecting a default anywhere, and resolve the origin instead: FRONTEND_URL -> general_site_url -> the origin the request arrived on -> whichever exists -> ''. A loopback candidate is treated as unconfigured so the installs that already have http://localhost:3000 baked into their environment self-heal; the same guard previously lived inline in routes/gallery.js for the slideshow QR (#848) and is now shared. The empty return is preserved because shareLinkService and the SSO redirects in routes/auth rely on it to emit relative urls — callers needing an absolute url use getAbsoluteFrontendUrl(), which still ends at http://localhost:3000. The wizard now persists window.location.origin right after the admin account is created, so an install that skips the rest still has a usable origin for background jobs that have no request to derive one from, and offers it as an editable "Public address" field. Settings -> General shows the field read-only when FRONTEND_URL pins it, instead of silently ignoring edits. Also drop the `|| 'mailhog'` fallback when seeding email_configs: that host only exists in the dev compose profile (which does not even start by default), so a fresh install came up with a live config pointing nowhere while the wizard showed empty SMTP fields. With no row, blank fields are the truth and emailProcessor logs "No email configuration found". Developers set SMTP_HOST=mailhog explicitly. backend/src/services/emailService.js is deleted: nothing in backend/ references it, and it was the only consumer of the SMTP_* variables, which misrepresented how mail is configured. Refs #705 * fix(setup): keep FRONTEND_URL ahead of ADMIN_URL/APP_URL when resolving links The previous commit routed two call sites through the resolver but put the site-specific variable FIRST, silently reversing precedence: userManagementService was: FRONTEND_URL || ADMIN_URL || localhost:3005 became: ADMIN_URL || resolver adminEvents/crud was: FRONTEND_URL || APP_URL || '' became: APP_URL || resolver An install with both variables set would have flipped which one won. Call the resolver first instead — it starts with FRONTEND_URL, so the original relative order is preserved and only the final fallback changes: localhost:3005 (not even the frontend's port) and '' (a relative link inside an email) both become the resolved origin. Refs #705 * fix(setup): unpin loopback FRONTEND_URL, keep ADMIN_URL/APP_URL reachable Review feedback on #1104. isEnvPinned() reported ANY FRONTEND_URL as authoritative, including the loopback values getFrontendBaseUrl() deliberately demotes. An install upgrading with the old compose default FRONTEND_URL=http://localhost:3000 therefore resolved its origin from general_site_url correctly, but got the Site URL field rendered read-only in Settings and skipped by the wizard's seeding - locking the exact operators this change exists to unblock out of configuring a public address anywhere. The predicate now mirrors the resolver, and the derived general_site_url_effective the General tab reads comes from the same helper instead of re-normalising process.env inline. APP_URL and ADMIN_URL had become dead code: getFrontendBaseUrl() only returns falsy when NOTHING is configured, so `|| process.env.ADMIN_URL` after it never ran once a site URL existed - which after this PR is the normal case. A split-origin install pointing ADMIN_URL at a separate admin host got invite links on the public gallery origin instead. They are now passed as an explicit `override` that resolves directly below FRONTEND_URL, preserving the historic FRONTEND_URL-before-ADMIN_URL order while beating the database- and request-derived fallbacks. general_site_url now feeds the CORS allowlist and the Access-Control-Allow-Origin header, not just email links, so a schemeless value is an allowlist entry no browser origin can match. Validate it server-side in PUT /general (isURL with require_protocol, require_tld off so LAN/NAS installs on http://nas:3000 still work) and client-side in both surfaces that write it - type="url" never fires in either, since neither input sits inside a form. Two more wizard fixes: the General tab no longer reposts general_site_url while it is env-pinned, because the field then holds the effective env value rather than the stored one and the round-trip read as a change to a protected key, 403ing a settings.edit-without-settings.domains admin on an unrelated save. And SetupConfigStep validates the From address before posting - /admin/email/config rejects a blank one, which used to surface as a generic warning while the wizard advanced from its finally block anyway, discarding every SMTP value the user had typed, password included. A failed save now keeps them on the step. * fix(setup): surface a rejected public address instead of swallowing it Review round 2 follow-up on #1104, pushed onto the branch. saveSiteUrl() caught and discarded every error. That was defensible before round 2 added a server-side URL check, but PUT /general can now answer 400 — and the two validators disagreed: http://my_nas.local client: accepted server: rejected http://foo_bar:3000 client: accepted server: rejected validate() let those through, the 400 was swallowed, `failed` stayed false and onDone() ran. The operator finished the wizard believing the public address was stored when nothing had been. That is the silent misconfiguration this whole change exists to remove, landing on the LAN and NAS installs it targets. Three parts: - saveSiteUrl() throws. finish() resolves it before anything else is posted and puts the message on the address field rather than the generic "some settings could not be saved" warning. Skip for now still always leaves, by contract, but warns instead of dropping the value in silence. - allow_underscores on the server check, for the same reason require_tld is off: browsers resolve http://my_nas.local and the client accepts it, so rejecting it server-side only produced the mismatch above. Both validators now agree across the LAN/NAS, IDN, bare-IP and scheme-less cases. - LOOPBACK_BASE_RE anchors its host token. Bare prefix matching also demoted https://localhost-nas.example.com, and now that this predicate gates the whole resolver rather than just the slideshow QR, being demoted means a configured address is silently ignored. 127. stays a bare prefix on purpose: all of 127.0.0.0/8 is loopback. Resolver suite 31 passing, up from 26. Mutation-checked: restoring the unanchored regex fails the three new host-boundary cases. * fix(settings): don't lock the General tab on a site URL nobody typed Review follow-up on #1104, pushed onto the branch. general_site_url was free-text until this PR added a server-side check, so an upgraded install can hold something schemeless that predates it. The tab flagged that on load, and `disabled={!!siteUrlError}` then killed Save for EVERY General setting. An admin holding settings.edit but not settings.domains could not clear it either: correcting the address is a change to a protected key and 403s. The tab has no permission gating, so that role was simply locked out of the tab with no self-service way back. That is the same role adminSettings.js:85-95 documents the no-op round-trip allowance for. The allowance only helps if the request is made, and this blocked it in the browser first. Validation now waits until the field is actually edited, and an unchanged value is dropped from the payload rather than reposted — matching what the env-pinned case already does one line above, and for the same reason. stored value invalid, untouched Save works, key not sent edited to something unusable Save blocked edited to a usable absolute url saved Four tests, first coverage for this feature. Mutation-checked: removing the dirty gate fails the untouched-value case. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-21 12:54:14 +02:00
Luca	415bffa04c	feat: zero-config first run — in-browser admin bootstrap + auto-generated secrets ... Fresh installs need nothing in .env. See PR description for the full feature.	2026-07-01 14:49:18 +02:00
Luca	3322a1d998	feat(restore): docker-logs visibility + ADMIN_CREDENTIALS.txt restore notice ... Two nice-to-haves from the PR #596 review. 1. Install-from-backup logging mirrors to stdout The winston logger writes to /app/logs/combined.log and may not tee to stdout. Operators tailing `docker logs picpeak-beta-backend` after a `compose up` saw the migration sweep + npm notice and nothing about the restore. Three key events now also fire through `console.log` with a `[install-from-backup] ` prefix: - "trigger file detected → <manifest>" - "starting restore from <manifest>" - "restore completed successfully" / "FAILED — <reason>" Plus the "skipping — existing data" branch. docker-logs surface now tells the restore story without requiring an `exec into the container` step. 2. ADMIN_CREDENTIALS.txt flags stale creds when restore is queued Migration 001 detects a pending `RESTORE_ON_INSTALL` file BEFORE writing the fresh-install credentials file. If a trigger will fire on the next boot, the file now opens with a clear warning: ⚠️ RESTORE_ON_INSTALL TRIGGER DETECTED ⚠️ These credentials are temporary. An install-from-backup run is queued to fire on the next server start, which will REPLACE this admin row with the one from the backup. After the restore completes, log in with your ORIGINAL pre-disaster credentials — not the ones below. If the restore fails for some reason, the credentials below remain valid as a fallback recovery path. Doesn't skip the file (so a failed restore still has the fallback credentials), just annotates it. Closes the maintainer's "stale junk credentials" observation.	2026-06-01 21:52:38 +02:00
Paul Nothaft	cd00bc13d4	fix: resolve issues #194, #195, #196, #197 ... - #194: Send full date format object instead of just format string to prevent JSON parse errors - #195: Remove non-functional forgot password link, fix README port 3005 -> 3000 - #196: Use ADMIN_PASSWORD env var in migration, update existing user in create-admin script instead of failing - #197: Convert camelCase filter keys to snake_case in photo export to match backend PhotoFilterBuilder	2026-02-22 22:27:21 +01:00
paulandClaude	1b4b497fdf	chore: clean up codebase for production readiness ... - Remove all console.log/debug statements from production code - Add NODE_ENV checks for development-only logging - Remove test scripts (test-feedback, test-image-security, test-backup-*, test-restore) - Remove one-time fix scripts (fix-temp-photos, fix-migration-state, mark-migration-applied) - Remove sensitive files (.env.backup, ADMIN_CREDENTIALS.txt) - Update package.json to remove references to deleted scripts - Replace console statements with logger utility in backend - Secure error boundaries to not expose stack traces in production This makes the codebase production-ready with no debug output or test scripts. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>	2025-08-24 23:19:30 +02:00
paulandClaude	ad495a92c4	fix: improve admin credentials display and configuration ... - Display email address instead of username in migration output - Use environment variables for admin email configuration - Update deployment guide with clear admin setup instructions - Add note that login requires email address, not username - Fix GitHub URL to correct repository - Remove obsolete version field from docker-compose.yml 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>	2025-07-25 16:28:32 +02:00
paul	8d85454ef6	Make credential file writing optional in migration ... - Wrapped file writing in try-catch to prevent migration failure - Credentials are always shown in console output - File writing is now optional - if it fails, migration continues - Added informative message when file cannot be written This prevents the migration from failing in environments where the data directory has permission issues, while still ensuring administrators can see and copy the credentials from console output.	2025-07-25 13:29:02 +02:00
paul	596bba2c1b	Fix permission error when writing admin credentials ... - Changed credential file location from /app/ to /app/data/ - Added directory creation with recursive flag - Updated console messages to show correct file location - The data/ directory is already owned by nodejs user in Dockerfile The error occurred because the nodejs user doesn't have write permission to /app/ directory, but does have permission to /app/data/ which is explicitly created and chowned in the Dockerfile.	2025-07-25 13:20:44 +02:00
paul	055de06315	Fix 001_init.js database column mismatch ... - Removed must_change_password field that doesn't exist in admin_users table - Changed from using db to knex parameter for database operations - Fixed require statement that was accidentally changed - Updated security message to reflect no forced password change - Removed debug logging after identifying the issue The error occurred because 001_init.js was trying to insert a column that doesn't exist in the admin_users table schema created by initializeDatabase().	2025-07-25 13:15:06 +02:00
paul	ccf59d1d4d	Fix 001_init.js to follow proper migration pattern ... - Changed from standalone script to proper migration with exports.up/down - Removed process.exit() calls that were terminating the migration runner - Removed immediate execution of runMigrations() - Now properly exports migration functions like other migrations This was the root cause - 001_init.js was executing immediately when required and calling process.exit(), preventing it from being run as a migration and causing 029 to run first on an empty database.	2025-07-25 13:00:03 +02:00
paul	519518ed6c	Fix migration order by renaming init.js to 001_init.js ... - Renamed core/init.js to core/001_init.js to ensure it runs first - Updated detectExistingSchema() to reference 001_init.js - This fixes the issue where backup migrations tried to access app_settings table before it was created - Migrations now run in correct order: init first, then numbered The error occurred because alphabetical sorting put 029 before init, causing migrations to fail on new deployments.	2025-07-25 11:37:52 +02:00