Files
BanGUI/Docs/Tasks.md
Lukas 5b7d1a4360 Fix Failures tooltip wording; move Service Health to top of Server tab
Task 2: rename 'Failures:' label to 'Failed Attempts:' and update tooltip
to 'Total failed authentication attempts currently tracked by fail2ban
across all active jails' — more accurate than 'Currently failing IPs'.

Task 3: move <ServerHealthSection /> to the top of ServerTab so users
see connectivity status before scrolling through all settings fields.
2026-03-16 19:48:39 +01:00

5.0 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 Done

Implemented: In frontend/src/components/ServerStatusBar.tsx, changed the Failures: label to Failed Attempts: and updated the tooltip from "Currently failing IPs" to "Total failed authentication attempts currently tracked by fail2ban across all active jails". Updated ServerStatusBar.test.tsx to assert the new label text.

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 Done

Implemented: In frontend/src/components/config/ServerTab.tsx, moved <ServerHealthSection /> from the end of the JSX return to be the first element rendered inside the tab container, before all settings fields.

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.