BanGUI/Docs/Tasks.md

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.

Reference: Docs/Refactoring.md for full analysis of each issue.

---

Open Issues

History page filters and behavior (frontend)

1. Time range filter currently not working

   • Scope: frontend history page state/logic (likely in frontend/src route or component for history table)
   • Expected behavior: selecting start/end timestamps (or presets) should filter history rows by event timestamp in the backend query or local data, then rerender filtered results immediately.
   • Investigation:
     • check component(s) handling time range input, change handlers, and query construction.
     • confirm backend API supports startTime/endTime parameters for history endpoint (/api/history or similar).
     • confirm values are passed as ISO strings/epoch and matched in backend.
   • Fix should include:
     • wiring the time range inputs to the filtering state.
     • constructing API query with time range params.
     • verifying with unit/integration tests plus manual through UI.

2. Global filter (All | Blocklist | Selfblock) not working

   • Scope: frontend history page filter chips or select control.
   • Expected behavior: choosing All, Blocklist, Selfblock should apply corresponding filter in same history query (no results for unmatched types).
   • Tasks:
     • locate filter control component and event handlers.
     • validate value mapping semantics (all=>no filter, blocklist=>source=blocklist, selfblock=>source=selfblock or equivalent).
     • ensure filter value is merged with time range + jail/ip filters in API call.
     • add tests for each filter option to confirm behavior.

3. Jail and IP address filters UX alignment with time range

   • Scope: frontend history page layout/CSS component; likely HistoryFilters container.
   • Expected behavior:
     • Jail filter and IP address filter should be same look (input/select style and spacing) as time range widget.
     • Place Jail/IP filters next to time range controls in same row.
     • Should be responsive and consistent.
   • Tasks:
     • modify the history filter container markup so time range, jail, ip filter are co-located.
     • apply matching CSS classes/styles to Jail/IP as existing time range control.
     • verify cross-browser/responsive display with storybook/test if exists.

4. Remove “Apply” and “Clear” buttons; auto-apply on field change

   • Scope: frontend history filter form behavior.
   • Expected behavior:
     • Any filter field change (time range, type, jail, IP) triggers immediate query update (debounced 150-300 ms if needed).
     • Remove explicit “Apply” and “Clear” buttons from UI.
     • Clear can be replaced by resetting fields automatically or via a small “reset” icon if needed.
   • Implementation steps:
     • remove button UI elements and event bindings from history page component.
     • make each filter input onChange call the shared applyFilters logic with current state.
     • add debounce to avoid 100% rapid API churn.
     • for clear semantics, ensure default/empty state on filter input binds to default query (All).
     • add tests to verify no apply/clear buttons present and updates via input change.

Acceptance criteria

• On history page, time range selection + filter chips + jail/ip are functional and produce filtered results.
• Time range, jail/IP inputs are styled consistently and in same filter row.
• No apply/clear buttons are visible and filter updates occur on value change (with optional debounce).
• Relevant tests added/updated in frontend test suite.