backup

Docs/Tasks.md

@@ -7,57 +7,3 @@ Reference: `Docs/Refactoring.md` for full analysis of each issue.
 ---
 
 ## Open Issues
-
-### History page filters and behavior (frontend)
-
-1. [x] 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. [x] 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. [x] 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. [x] 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.
-

backend/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "bangui-backend"
-version = "0.9.14"
+version = "0.9.15"
 description = "BanGUI backend — fail2ban web management interface"
 requires-python = ">=3.12"
 dependencies = [