- 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).
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: readspackage.json#versionat build time and injects it as the global__APP_VERSION__via Vitedefine.frontend/src/vite-env.d.ts: addsdeclare const __APP_VERSION__: stringso TypeScript knows about the global.frontend/src/layouts/MainLayout.tsx: rendersBanGUI 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 bumpingVERSION, also updatesfrontend/package.json#versionviasedto keep them in sync.frontend/package.json: version bumped from0.9.0to0.9.3to matchDocker/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:
- Inject the BanGUI app version at build time — add a
defineentry infrontend/vite.config.tsthat reads theversionfield fromfrontend/package.json(e.g.__APP_VERSION__). Keepfrontend/package.jsonandDocker/VERSIONin sync (update the release scriptDocker/release.shorMakefileto writepackage.json#versionfromVERSION). - 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. - Update the fail2ban version tooltip in
ServerStatusBar.tsxfrom 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.