Compare commits
4 Commits
v1.0.0
...
5f50c5faa0
| Author | SHA1 | Date | |
|---|---|---|---|
| 5f50c5faa0 | |||
| 18170d690b | |||
| 7d201a82ab | |||
| db2e2c83fe |
@@ -7,8 +7,18 @@ DATABASE_URL=postgresql://tessera:change-me-strong-password@db:5432/tessera
|
||||
|
||||
# App
|
||||
APP_URL=https://tessera.deine-domain.de
|
||||
# Generate with: openssl rand -hex 32
|
||||
JWT_SECRET=change-me-64-char-random-string
|
||||
|
||||
# Auslieferungskanal (siehe Betriebshandbuch, Kapitel 9):
|
||||
# beta = alle Neuerungen sofort (Teststellung)
|
||||
# live = nur freigegebene Versionen mit Nummer (Produktivbetrieb)
|
||||
# Fehlt die Zeile, nimmt die Compose-Datei "beta".
|
||||
IMAGE_TAG=live
|
||||
# Damit auf dem Server ein schlichtes "docker compose ..." genuegt,
|
||||
# ohne jedes Mal "-f docker-compose.prod.yml" anzugeben.
|
||||
COMPOSE_FILE=docker-compose.prod.yml
|
||||
|
||||
# Admin account (created on first start)
|
||||
TESSERA_ADMIN_USER=admin
|
||||
TESSERA_ADMIN_EMAIL=admin@deine-domain.de
|
||||
@@ -29,3 +39,8 @@ TESSERA_ENCRYPTION_KEY=
|
||||
# TESSERA_SMTP_USER=
|
||||
# TESSERA_SMTP_PASSWORD=
|
||||
# TESSERA_SMTP_FROM=Tessera <noreply@deine-domain.de>
|
||||
|
||||
# Fehlermeldungen (optional): Rueckfall-Postfach fuer den Knopf "Fehler melden",
|
||||
# falls unter Administrator > SMTP kein Feld "Fehlermeldungen an" gesetzt ist.
|
||||
# Leer = nur die Einstellung in der Oberflaeche gilt.
|
||||
# TESSERA_BUGREPORT_TO=
|
||||
|
||||
+8
-5
@@ -4,8 +4,8 @@ milestone: v1.2
|
||||
current_phase: 17
|
||||
current_phase_name: eigene-ausschreibungs-quellen-je-nutzer
|
||||
status: verified
|
||||
stopped_at: "2026-09-14: Quick 260914-m97 Fehler-melden-Knopf ausgefuehrt (4 Commits 54121c1/60b0ee8/b41be21/77117de gepusht, CI-Lauf 299 nach Rerun success, :beta-Abbilder mit 77117de beta); offen: Browser-Check mit mailhog durch den Verifizierer, danach Erstfreigabe v1.0.0"
|
||||
last_updated: "2026-09-14T15:08:28.980Z"
|
||||
stopped_at: "2026-09-15: v1.0.0 live auf tessera.ctl.de (neuer Server, IMAGE_TAG=live), alpha = beta; kein Feedback bisher; nichts offen; Mandantenfaehigkeit ruht; Schalter AUS"
|
||||
last_updated: "2026-09-15T14:25:42.000Z"
|
||||
last_activity: 2026-09-14
|
||||
last_activity_desc: Quick 260910-jab — drei zu kurz greifende RLS-Regeln geschlossen (GroupMembership beide Seiten, ModuleGrant beide Ziele, TenderRssFeedSource Lese-/Schreibsplit), listForUser gebunden, Aktenstand kohaerent
|
||||
state_head: 77117de3d0f1bb82df7b659f46fe26244ca6f164
|
||||
@@ -344,7 +344,10 @@ Gerettet aus `.continue-here.md`. Relevant fuer die noch offenen Live-Tests.
|
||||
|
||||
### Pending Todos
|
||||
|
||||
None yet.
|
||||
- [2026-08-11] [module-registry] Jeder Mandanten-Admin kann sich jedes Modul selbst freischalten — Aktivierung ohne Lizenzpruefung — [todo file](.planning/todos/pending/2026-08-11-modulaktivierung-ohne-lizenzpruefung.md)
|
||||
- [2026-09-07] [web/branding] Administrator kann das Aussehen branden — eigenes Logo und eigene Farben je Mandant — [todo file](.planning/todos/pending/2026-09-07-mandanten-branding-logo-und-farben.md)
|
||||
- [2026-09-14] [module-registry] Lizenzmodell — Betreiber gibt Modul je Server mit Lizenzanzahl frei, Firmenadmin lizenziert an bis zu N … — [todo file](.planning/todos/pending/2026-09-14-lizenzmodell-freigabe-je-server-mit-lizenzanzahl.md)
|
||||
- [2026-09-15] [desktop] Desktop-Client auslieferungsreif machen — Versions-Check, Windows-Installer, Abnahme, CI-Bau — [todo file](.planning/todos/pending/2026-09-15-desktop-client-auslieferungsreif-machen.md)
|
||||
|
||||
### Blockers/Concerns
|
||||
|
||||
@@ -445,8 +448,8 @@ sind. Kein Anlass, sie vorher erneut vorzulegen.
|
||||
|
||||
## Session Continuity
|
||||
|
||||
Last session: 2026-09-14T15:08:28.744Z
|
||||
Last session: 2026-09-15T14:25:42.000Z
|
||||
Resumed: 2026-09-14 — Sitzung ueber /gsd-resume-work fortgesetzt; #29 und 3c als /gsd-quick --validate mit voller Kette durchgefuehrt.
|
||||
Stopped at: 2026-09-14: Quick 260914-m97 Fehler-melden-Knopf ausgefuehrt (4 Commits 54121c1/60b0ee8/b41be21/77117de gepusht, CI-Lauf 299 nach Rerun success, :beta-Abbilder mit 77117de beta); offen: Browser-Check mit mailhog durch den Verifizierer, danach Erstfreigabe v1.0.0
|
||||
Stopped at: **v1.0.0 IST LIVE — 2026-09-15.** Der User hat den neuen Live-Server (tessera.ctl.de, IMAGE_TAG=live) selbst eingerichtet; alpha.tessera.ctl.de bleibt Beta. Bisher kein Feedback von Anwendern. Nichts offen. Kanalmodell: main = beta, Zweig live + Tag = live; Freigabe/Hotfix-Rezept in docs/anleitung-betrieb.md Kapitel 9. Vorlage .env.prod.example traegt IMAGE_TAG/COMPOSE_FILE/TESSERA_BUGREPORT_TO (7d201a8). DER SCHALTER IST AUS. Mandantenfaehigkeit RUHT (User 2026-09-14). Restposten ohne Dringlichkeit: Ship von Phase 17 (windows_enforce, open_count 15), Ledger #35 (Biome), #36 (stilles 403), #37 (DKV Single-Flight), Exchange-Alarm-Mail nie live getestet (kein Postfach). Naechster Einstieg: `/gsd-resume-work`, dann das, was der User aus dem Betrieb mitbringt (Fehlermeldungen kommen per Knopf ins eingestellte Postfach; Korrekturen auf Live laufen als Hotfix v1.0.x).
|
||||
Resume file: None
|
||||
Last activity: 2026-09-14 - Completed quick task 260914-m97: Fehler-melden-Knopf mit Bildschirmfoto per E-Mail, Empfaenger unter Administrator -> SMTP
|
||||
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
created: 2026-09-15T19:39:37.195Z
|
||||
title: Desktop-Client auslieferungsreif machen — Versions-Check, Windows-Installer, Abnahme, CI-Bau
|
||||
area: desktop
|
||||
severity: minor
|
||||
trigger: Sobald der User eine Bau- und Testmoeglichkeit fuer Windows organisiert hat (User 2026-09-15: "Da finden wir was. Evtl. sogar so, dass du im Browser selbst testen kannst"). Reiner Komfort — der Betrieb im Browser braucht den Client nicht. Nicht von uns aus draengen.
|
||||
files:
|
||||
- apps/desktop/src-tauri/src/lib.rs:82-100
|
||||
- apps/desktop/src-tauri/tauri.conf.json:4
|
||||
- apps/desktop/src-tauri/tauri.conf.json:29
|
||||
- apps/desktop/src/setup.html
|
||||
- .gitea/workflows/ci.yml
|
||||
- .planning/phases/06-desktop-client-ci-cd/06-02-SUMMARY.md
|
||||
---
|
||||
|
||||
## Problem
|
||||
|
||||
Phase 6 (Juni 2026) hat den Tauri-Rahmen um die Web-Oberflaeche gebaut
|
||||
(`apps/desktop`): Server-Adresse beim ersten Start, WebView auf die Installation,
|
||||
Tray mit Schliessen-in-den-Tray, Fensterzustand, Autostart, Benachrichtigungen,
|
||||
Versions-Check, Tessera-Symbol, Ziele AppImage + NSIS. Seit dem 2026-06-25 nicht
|
||||
mehr angefasst. Vier Dinge stehen zwischen dem Stand und einer Auslieferung:
|
||||
|
||||
1. **Versions-Check ist seit 260914-ku1 falsch.** `lib.rs` vergleicht
|
||||
`info.version` aus `GET /health/version` (jetzt z. B. `v1.0.0`, Stempel des
|
||||
Server-Abbilds) mit `CARGO_PKG_VERSION` des Clients (`0.0.1`) und meldet bei
|
||||
Ungleichheit "Eine neue Version ist verfuegbar" — also bei JEDEM Start.
|
||||
Client- und Server-Version sind zwei verschiedene Dinge; der Check braucht
|
||||
eine eigene Quelle fuer die Client-Version (z. B. ein Feld
|
||||
`desktopVersion` in `/health/version` oder eine eigene Datei im Web-Abbild).
|
||||
2. **Windows-Installer nie gebaut.** NSIS ist in `tauri.conf.json` konfiguriert,
|
||||
gebaut wurde nur das Linux-AppImage (`Tessera_0.0.1_amd64.AppImage`), weil
|
||||
auf dem Linux-Host keine Windows-Werkzeugkette existiert (06-02-SUMMARY).
|
||||
Braucht einen Windows-Rechner, eine Windows-VM oder einen Windows-Runner.
|
||||
3. **Keine Abnahme.** Phase 6 hat keine VERIFICATION.md; der Client wurde seit
|
||||
Juni nicht gestartet, die Web-Oberflaeche hat sich seitdem stark veraendert
|
||||
(Berechtigungen, Module, Kopfzeile mit Fehler-melden-Knopf, Versionsabzeichen).
|
||||
Vollstaendig gegen `https://tessera.ctl.de` durchklicken: Erststart-Dialog,
|
||||
Anmeldung, Tray, Schliessen, Benachrichtigung, Fehler-melden-Knopf (funktioniert
|
||||
`html-to-image` in der Tauri-WebView?).
|
||||
4. **Kein automatischer Bau.** `.gitea/workflows/ci.yml` baut nur die
|
||||
Container. Desktop-Pakete muessten je Freigabe von Hand oder ueber einen
|
||||
zusaetzlichen Runner gebaut und irgendwo abgelegt werden (Gitea-Release?).
|
||||
|
||||
## Solution
|
||||
|
||||
Eigene kleine Etappe als `/gsd-quick --validate`, sobald die Baumoeglichkeit
|
||||
steht. Reihenfolge: (1) Versions-Check richtigstellen und `tauri.conf.json`
|
||||
auf eine echte Client-Version bringen; (2) Bau auf Windows, Installer testen;
|
||||
(3) Abnahme gegen tessera.ctl.de mit Protokoll; (4) entscheiden, ob der Bau in
|
||||
die Pipeline kommt oder als dokumentierter Handgriff je Freigabe bleibt. Die
|
||||
eine Produktfrage an den User: Wo wird gebaut und getestet (Windows-Rechner,
|
||||
VM, Runner)? Wenn "im Browser testbar" eine per Browser erreichbare Windows-VM
|
||||
meint, kann die Abnahme von Claude ueber Playwright MCP / Bildschirm laufen.
|
||||
@@ -421,9 +421,11 @@ docker compose -f docker-compose.prod.yml pull
|
||||
docker compose -f docker-compose.prod.yml up -d --force-recreate api web
|
||||
```
|
||||
|
||||
Hinweis: Die Vorlage `.env.prod.example` im Repository enthält die Zeile
|
||||
`IMAGE_TAG` noch nicht. Wer eine neue `.env` aus der Vorlage anlegt, ergänzt die
|
||||
Zeile von Hand.
|
||||
Hinweis: Die Vorlage `.env.prod.example` im Repository enthält die Zeilen
|
||||
`IMAGE_TAG=live` und `COMPOSE_FILE=docker-compose.prod.yml` bereits. Wer eine neue
|
||||
`.env` aus der Vorlage anlegt, setzt `IMAGE_TAG` nur noch auf den gewünschten
|
||||
Kanal; auf einer älteren, von Hand gepflegten `.env` (wie auf alpha) werden die
|
||||
Zeilen einmal ergänzt.
|
||||
|
||||
### Eine Version freigeben
|
||||
|
||||
|
||||
Reference in New Issue
Block a user