deploy-felhom-compose/TASK.md

0.12.1 Bug Fixes

Bug 1: Version displays "vv0.12.0"

Severity: Low (cosmetic) Location: Two templates with hardcoded v prefix

The sidebar and settings page templates both prepend v to {{.Version}}:

<span class="version">v{{.Version}}</span>          ← line 17845 (layout.html)
<span class="settings-value mono">v{{.Version}}</span>  ← line 19061 (settings.html)

build.sh takes VERSION as its first argument (VERSION="${1:-dev}"), and Viktor passes v0.12.0 → the template renders vv0.12.0.

Fix (template side — recommended): Replace v{{.Version}} with {{.Version}} in both locations. This way the version displayed matches the git tag exactly. The v prefix comes from the tag/build arg naturally.

Affected files:

• internal/web/templates/layout.html — sidebar footer
• internal/web/templates/settings.html — version info row

---

Bug 2: "Külső HDD" stats show same values as SSD

Severity: Medium (wrong data displayed) Location: Dashboard and Backup page storage bars; also metrics collector in main.go

Setup on demo-felhom.eu:

• Internal SSD (512G): system disk, mounted at /. /mnt/hdd_placeholder is a normal folder on this.
• External USB HDD (1TB): mounted at /mnt/hdd_1 (ext4, /host-dev/sdb1)
• Two storage paths registered (visible in Settings > Adattárolók):
  • /mnt/hdd_placeholder — "Rendszermeghajtón" badge, Aktív, 19.8 GB / 460.2 GB
  • /mnt/hdd_1 — "Alapértelmezett" + "Aktív" badge, 0.0 GB / 915.8 GB
• No hdd_path in controller.yaml, no HDD_PATH in any app.yaml
• The Settings page (Adattárolók section) shows correct values for both paths

Current behavior:

• Dashboard: "Külső HDD" shows 19.8 GB / 460 GB — same as SSD (wrong!)
• Backup page: Same duplicate in "Tárhely áttekintés"

Root cause: primaryHDDPath() (line 15164) returns paths[0].Path — the first element in the slice, which happens to be /mnt/hdd_placeholder (on the SSD). Then system.GetInfo("/mnt/hdd_placeholder", ...) calls syscall.Statfs on a directory that lives on the root filesystem → returns SSD stats.

// current — broken
func (s *Server) primaryHDDPath() string {
    if paths := s.settings.GetStoragePaths(); len(paths) > 0 {
        return paths[0].Path  // ← returns first element, NOT the default!
    }
    return s.cfg.Paths.HDDPath
}

But GetDefaultStoragePath() (line 8946) already exists and returns the path with IsDefault: true — which is /mnt/hdd_1 (the actual HDD).

Same bug in main.go (line 2403-2405) for the metrics collector:

metricsHDDPath := cfg.Paths.HDDPath
if paths := sett.GetStoragePaths(); len(paths) > 0 {
    metricsHDDPath = paths[0].Path  // ← same bug
}

Fix:

1. primaryHDDPath() → use s.settings.GetDefaultStoragePath() instead of paths[0].Path
2. main.go metrics collector → use sett.GetDefaultStoragePath() instead of paths[0].Path
3. Fallback: if no default is set, fall back to cfg.Paths.HDDPath (existing behavior)

// fixed
func (s *Server) primaryHDDPath() string {
    if p := s.settings.GetDefaultStoragePath(); p != "" {
        return p
    }
    return s.cfg.Paths.HDDPath
}

Affected files:

• internal/web/handlers.go — primaryHDDPath() function
• cmd/controller/main.go — metrics collector HDD path selection

---

Bug 3: Gokapi/Mealie show gray ("auto") status — should be green

Severity: Medium (misleading status) Location: buildAppBackupRows() in internal/web/handlers.go (line 14302-14367)

Apps without HDD data (like Gokapi, Mealie) always get status = "auto" (gray dot). From the user's perspective, these apps ARE fully backed up — their Docker volumes are included in the restic snapshot, and their configs are under /opt/docker/stacks/. The gray dot misleadingly suggests they're not backed up at all.

Current logic (line 14365-14368):

} else {
    // No HDD data — fully automatic
    row.Status = "auto"
    row.StatusText = "Automatikus mentés (nincs felhasználói adat)"
}

Desired behavior:

• Apps with no HDD data whose Docker volumes are successfully backed up → green dot with text "Mentés rendben"
• Apps with no HDD data where last volume backup failed → yellow dot
• Keep "auto" only if there's genuinely no backup info available (edge case)

Fix approach: Replace the else block (line 14365-14368):

} else {
    // No HDD data — everything backed up automatically via restic
    if volumeLastStatus == "ok" {
        row.Status = "green"
        row.StatusText = "Mentés rendben"
    } else if volumeLastStatus == "error" {
        row.Status = "yellow"
        row.StatusText = "Kötetek mentése sikertelen"
    } else {
        row.Status = "auto"
        row.StatusText = "Automatikus mentés"
    }
}

Additionally, if the app has a DB and the DB backup was successful, that should also contribute to green status. The existing DB error check at line 14372 already degrades to yellow, so this is covered.

Affected files:

• internal/web/handlers.go — buildAppBackupRows() status logic

---

Bug 4: Restore section ("Visszaállítás") UX rethink

Severity: Medium (UX complexity) Location: Backup page restore section in backups.html

Now that user data folders are also backed up via cross-drive (rsync), the restore section needs rethinking. Currently:

• DB backup is a separate snapshot tied to user data
• Multiple warnings accumulate, making the UI intimidating
• User must understand the difference between DB-only and full restore

Decision (from Viktor):

• If user data is backed up, the "Pillanatkép" selector should only show snapshots that include user data → restores everything together (most failsafe)
• Daily DB-only backups remain useful as intermediate recovery points, but DB-only restore is an advanced task → contact support
• This simplifies the UI: one dropdown, one action, one clear warning

Implementation plan:

1. Snapshot selector: Filter to show only snapshots containing user data paths when cross-drive is configured
2. Restore action: Restores both Docker volumes/configs AND user data in one operation
3. Simplify warnings: Single clear warning about data overwrite, remove redundant ones
4. DB-only restore: Not exposed in UI — support-level operation via CLI

Note: This is a design change, not a bugfix. Needs more detailed specification before implementation. Possibly v0.13.0 scope.

Affected files:

• internal/web/handlers.go — restore handler logic
• internal/web/templates/backups.html — restore section template
• internal/backup/restore.go — restore logic (if separate)

---

Bug 5: Restic key buttons barely readable

Severity: Low (cosmetic) Location: Backup page, "Titkosítási kulcs" section (line 16660-16661 in backups.html)

The "Megjelenítés" and "Másolás" buttons use class="btn btn-sm" without a color variant. The .btn base class sets color: #fff (white text) but has no background color. The browser default background (light gray) makes white text nearly invisible on the dark theme.

Current HTML:

<button type="button" class="btn btn-sm" onclick="toggleResticPw()">Megjelenítés</button>
<button type="button" class="btn btn-sm" onclick="copyResticPw()">Másolás</button>

Fix options: A. Add a default background to .btn base class — e.g. background: var(--card-bg); or background: rgba(255,255,255,0.1); — This fixes all unclassed buttons globally B. Add variant class to these specific buttons — e.g. class="btn btn-sm btn-secondary" with a defined .btn-secondary style

Recommended: Option A — add a sensible dark default to .btn:

.btn {
    /* existing properties... */
    background: rgba(255,255,255,0.1);  /* subtle dark default */
}

This ensures any btn without a specific variant is still readable on dark backgrounds.

Affected files:

• internal/web/templates/style.css (or wherever .btn is defined) — add default background

---

Priority / Implementation Order

1. Bug 1 (version vv) — trivial template fix, ~2 min
2. Bug 5 (button contrast) — trivial CSS fix, ~2 min
3. Bug 2 (HDD stats wrong path) — 2-line fix in primaryHDDPath() + main.go, ~5 min
4. Bug 3 (gray → green status) — small logic change, ~10 min
5. Bug 4 (restore rethink) — design decision needed, deferred to v0.13.0