sorb/ThreadNet-Web
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 4 Wiki Activity

[MEDIUM] Default-Client-Einstellungen (Theme, Features) für Neuinstallationen provisionieren #1

New Issue
Closed
opened 2026-07-29 18:20:24 +00:00 by sorb · 2 comments
sorb commented 2026-07-29 18:20:24 +00:00
Owner
Copy Link
Copy Source

Neue Nutzer (egal ob Web-Client, installierte PWA oder Electron-Desktop) sollten mit
den für axion1337.chat gedachten Standardeinstellungen starten - nicht mit den generischen
Element-Defaults. Konkret betrifft das mindestens:

  • Theme: default_theme ist im Web-Deployment bereits gesetzt (aXion1337 Dark, via
    element-values.yaml) - muss für Electron-Builds ebenso gelten, ist dort aber nicht
    eigenständig provisioniert.
  • Custom Features (z.B. die Discord-Style-Raumliste): falls das ein Feature ist, das alle
    Nutzer standardmäßig sehen sollen, muss geprüft werden, ob es aktuell hinter einem
    Labs-Flag/einer manuellen Einstellung versteckt ist, die neue Nutzer nicht automatisch
    bekommen.
  • Sonstige sinnvolle Defaults (Benachrichtigungen, Video-Qualität, etc.) - einmal
    durchgehen, was aktuell nur "zufällig" beim Entwickeln richtig eingestellt ist, statt
    bewusst als Default für alle Nutzer konfiguriert.

Konkreter Fund, der das Problem sichtbar gemacht hat (beim manuellen Electron-Build,
siehe Release desktop-v1.12.17-clientscan): es gibt in apps/desktop keinen eigenen
Config-Variant-Ordner für unsere Instanz (wie element.io/release/element.io/nightly) -
das produktiv genutzte config.json musste manuell aus dem laufenden Pod kopiert werden, um
den generischen config.sample.json-Platzhalter zu ersetzen. Ohne eigenen Variant-Ordner
wiederholt sich das bei jedem zukünftigen Desktop-Build.

Vorschlag:

  1. Eigenen Config-Variant-Ordner anlegen (z.B. apps/desktop/element.io/axion1337/) mit
    config.json (Server-URL, Theme, gewünschte Default-Features) + build.json (Branding).
  2. Web-seitige element-values.yaml-Config und Desktop-Variant synchron halten, damit beide
    Clients dieselben Defaults haben.
  3. Bewusste Entscheidung pro Feature/Setting treffen: soll es Default sein oder optional
    bleiben - und das dokumentieren, statt es implizit zu lassen.
Neue Nutzer (egal ob Web-Client, installierte PWA oder Electron-Desktop) sollten mit den für axion1337.chat gedachten Standardeinstellungen starten - nicht mit den generischen Element-Defaults. Konkret betrifft das mindestens: - **Theme**: `default_theme` ist im Web-Deployment bereits gesetzt (`aXion1337 Dark`, via `element-values.yaml`) - muss für Electron-Builds ebenso gelten, ist dort aber nicht eigenständig provisioniert. - **Custom Features** (z.B. die Discord-Style-Raumliste): falls das ein Feature ist, das alle Nutzer standardmäßig sehen sollen, muss geprüft werden, ob es aktuell hinter einem Labs-Flag/einer manuellen Einstellung versteckt ist, die neue Nutzer nicht automatisch bekommen. - **Sonstige sinnvolle Defaults** (Benachrichtigungen, Video-Qualität, etc.) - einmal durchgehen, was aktuell nur "zufällig" beim Entwickeln richtig eingestellt ist, statt bewusst als Default für alle Nutzer konfiguriert. **Konkreter Fund, der das Problem sichtbar gemacht hat** (beim manuellen Electron-Build, siehe Release `desktop-v1.12.17-clientscan`): es gibt in `apps/desktop` keinen eigenen Config-Variant-Ordner für unsere Instanz (wie `element.io/release`/`element.io/nightly`) - das produktiv genutzte `config.json` musste manuell aus dem laufenden Pod kopiert werden, um den generischen `config.sample.json`-Platzhalter zu ersetzen. Ohne eigenen Variant-Ordner wiederholt sich das bei jedem zukünftigen Desktop-Build. **Vorschlag**: 1. Eigenen Config-Variant-Ordner anlegen (z.B. `apps/desktop/element.io/axion1337/`) mit `config.json` (Server-URL, Theme, gewünschte Default-Features) + `build.json` (Branding). 2. Web-seitige `element-values.yaml`-Config und Desktop-Variant synchron halten, damit beide Clients dieselben Defaults haben. 3. Bewusste Entscheidung pro Feature/Setting treffen: soll es Default sein oder optional bleiben - und das dokumentieren, statt es implizit zu lassen.
sorb commented 2026-08-01 02:49:10 +00:00
Author
Owner
Copy Link
Copy Source

Analyse + vorbereiteter Fix (2026-08-01 Nachtblock):

Guter Ist-Stand: Der eigene Desktop-Variant-Ordner existiert seit der CI-Migration (apps/desktop/axion1337/config.json, wird in desktop_linux/desktop_windows in die webapp kopiert) — Theme aXion1337 Dark, Brand, Features inkl. Discord-Raumliste (feature_new_room_list) sind dort provisioniert. Punkt 1 des Vorschlags ist damit faktisch erledigt.

Gefundener Drift (Web ⊊ Desktop, kein Widerspruch): Dem Web-Deploy (element-values.yaml im gitops-Repo) fehlen gegenüber dem Desktop: feature_video_rooms, feature_group_calls, feature_element_call_video_rooms, feature_new_room_decoration_ui und setting_defaults.feature_group_calls. Neue Web-Nutzer sehen Videoräume & Co. also nicht per Default, Desktop-Nutzer schon.

Fix liegt bereit, bewusst nicht deployt: gitops-Branch issue-1-client-defaults (lokal auf dem Mac, ein Commit) gleicht die Web-Config an — validiert (JSON/YAML). Ausrollen = git push gitlab issue-1-client-defaults + Merge, oder direkt auf main; Flux macht den Rest (Element-Web-Pod-Restart, nutzertransparent).

Entscheidung für sorb (nicht angefasst): bug_report_endpoint_url im Desktop zeigt auf rageshakes.element.io — Bug-Reports samt Logs gehen an Element statt an uns. Web-Deploy hat gar kein Rageshake. Vorschlag: Zeile im Desktop entfernen (kein Bug-Reporting) oder eigenes Ziel; sag an, dann setze ich es um.

**Analyse + vorbereiteter Fix (2026-08-01 Nachtblock):** **Guter Ist-Stand:** Der eigene Desktop-Variant-Ordner existiert seit der CI-Migration (`apps/desktop/axion1337/config.json`, wird in `desktop_linux`/`desktop_windows` in die webapp kopiert) — Theme `aXion1337 Dark`, Brand, Features inkl. Discord-Raumliste (`feature_new_room_list`) sind dort provisioniert. Punkt 1 des Vorschlags ist damit faktisch erledigt. **Gefundener Drift (Web ⊊ Desktop, kein Widerspruch):** Dem Web-Deploy (`element-values.yaml` im gitops-Repo) fehlen gegenüber dem Desktop: `feature_video_rooms`, `feature_group_calls`, `feature_element_call_video_rooms`, `feature_new_room_decoration_ui` und `setting_defaults.feature_group_calls`. Neue Web-Nutzer sehen Videoräume & Co. also nicht per Default, Desktop-Nutzer schon. **Fix liegt bereit, bewusst nicht deployt:** gitops-Branch `issue-1-client-defaults` (lokal auf dem Mac, ein Commit) gleicht die Web-Config an — validiert (JSON/YAML). Ausrollen = `git push gitlab issue-1-client-defaults` + Merge, oder direkt auf main; Flux macht den Rest (Element-Web-Pod-Restart, nutzertransparent). **Entscheidung für sorb (nicht angefasst):** `bug_report_endpoint_url` im Desktop zeigt auf `rageshakes.element.io` — Bug-Reports samt Logs gehen an Element statt an uns. Web-Deploy hat gar kein Rageshake. Vorschlag: Zeile im Desktop entfernen (kein Bug-Reporting) oder eigenes Ziel; sag an, dann setze ich es um.
sorb commented 2026-08-01 14:25:47 +00:00
Author
Owner
Copy Link
Copy Source

Migriert nach git.lab: axion1337.chat/ThreadNet-Web#1 (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.

**Migriert nach git.lab**: [axion1337.chat/ThreadNet-Web#1](https://git.lab/axion1337.chat/ThreadNet-Web/-/issues/1) (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.
sorb closed this issue 2026-08-01 14:25:47 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
sorb (ScrublordMcBad)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sorb/ThreadNet-Web#1