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.
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: 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 ✅ 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.