Files
BanGUI/Docs/Tasks.md
Lukas e7834a888e Show BanGUI app version in sidebar, fix version tooltips
- Inject __APP_VERSION__ at build time via vite.config.ts define (reads
  frontend/package.json#version); declare the global in vite-env.d.ts.
- Render 'BanGUI v{__APP_VERSION__}' in the sidebar footer (MainLayout)
  when expanded; hidden when collapsed.
- Rename fail2ban version tooltip to 'fail2ban daemon version' in
  ServerStatusBar so it is visually distinct from the app version.
- Sync frontend/package.json version (0.9.0 → 0.9.3) to match
  Docker/VERSION; update release.sh to keep them in sync on every bump.
- Add vitest define stub for __APP_VERSION__ so tests compile cleanly.
- Add ServerStatusBar and MainLayout test suites (10 new test cases).
2026-03-16 19:45:55 +01:00

4.4 KiB

BanGUI — Task List

This document breaks the entire BanGUI project into development stages, ordered so that each stage builds on the previous one. Every task is described in prose with enough detail for a developer to begin work. References point to the relevant documentation.


Open Issues

1. Dashboard — Version Tag Mismatch Done

Implemented:

  • frontend/vite.config.ts: reads package.json#version at build time and injects it as the global __APP_VERSION__ via Vite define.
  • frontend/src/vite-env.d.ts: adds declare const __APP_VERSION__: string so TypeScript knows about the global.
  • frontend/src/layouts/MainLayout.tsx: renders BanGUI v{__APP_VERSION__} in the sidebar footer when expanded (hidden when collapsed).
  • frontend/src/components/ServerStatusBar.tsx: tooltip changed from "fail2ban version" to "fail2ban daemon version".
  • Docker/release.sh: after bumping VERSION, also updates frontend/package.json#version via sed to keep them in sync.
  • frontend/package.json: version bumped from 0.9.0 to 0.9.3 to match Docker/VERSION.
  • Tests added: src/components/__tests__/ServerStatusBar.test.tsx, src/layouts/__tests__/MainLayout.test.tsx.

Problem: The ServerStatusBar component on the Dashboard displays v{status.version}, which is the fail2ban daemon version (e.g. v1.1.0). The BanGUI application version lives in Docker/VERSION (e.g. v0.9.3) and is unrelated to the fail2ban version. Users see a version number they don't recognise and assume it reflects the BanGUI release.

Goal: Make the distinction clear and expose the BanGUI application version.

Suggested approach:

  1. Inject the BanGUI app version at build time — add a define entry in frontend/vite.config.ts that reads the version field from frontend/package.json (e.g. __APP_VERSION__). Keep frontend/package.json and Docker/VERSION in sync (update the release script Docker/release.sh or Makefile to write package.json#version from VERSION).
  2. Show the BanGUI version in the sidebar footer inside MainLayout.tsx (collapsed view: show only when expanded, or via tooltip). This is the natural place for an "about" version tag.
  3. Update the fail2ban version tooltip in ServerStatusBar.tsx from the generic "fail2ban version" to something like "fail2ban daemon version" so the two are no longer visually indistinguishable.

Files: frontend/vite.config.ts, frontend/package.json, Docker/VERSION, Docker/release.sh, frontend/src/layouts/MainLayout.tsx, frontend/src/components/ServerStatusBar.tsx.


2. Dashboard — Improve "Failures" Tooltip

Problem: The ServerStatusBar shows a "Failures: 42" counter with the tooltip "Currently failing IPs". In fail2ban terminology failures are individual failed authentication attempts tracked in the fail2ban DB, not the number of unique IPs that failed. The current wording is ambiguous and misleading — users may think it means broken connections or error states.

Goal: Replace the tooltip with accurate, self-explanatory wording.

Suggested fix: Change the Tooltip content for the Failures stat in ServerStatusBar.tsx from "Currently failing IPs" to something like "Total failed authentication attempts currently tracked by fail2ban across all active jails". Additionally, consider renaming the label from "Failures:" to "Failed Attempts:" to match the tooltip language.

Files: frontend/src/components/ServerStatusBar.tsx.


3. Config → Server Tab — Move "Service Health" to Top

Problem: In the Config page → Server tab, the Service Health panel (ServerHealthSection) is rendered at the bottom of the tab, after all settings sections (log level, log target, DB purge settings, map thresholds, reload/restart buttons). This means users must scroll past all editable fields to check service connectivity status, even though the health status is the most critical piece of context — it indicates whether the server is reachable at all.

Goal: Move the <ServerHealthSection /> block to the top of the ServerTab render output, before any settings fields.

Suggested fix: In frontend/src/components/config/ServerTab.tsx, move the {/* Service Health & Log Viewer section */} block (currently at the end of the JSX return around line 415) to be the first section rendered inside the tab container.

Files: frontend/src/components/config/ServerTab.tsx.