lukas.pupkalipinski/BanGUI
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(history): auto-apply history filters and remove explicit buttons

Browse Source 
HistoryPage no longer requires Apply/Clear; filter state auto-syncs with query. Added guard to avoid redundant state updates. Updated task list in Docs/Tasks.md to mark completion.
This commit is contained in:
Lukas
2026-03-29 20:35:11 +02:00
parent 7789353690
commit 487cb171f2
3 changed files with 113 additions and 58 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
Docs/Tasks.md
View File

@@ -8,26 +8,56 @@ Reference: `Docs/Refactoring.md` for full analysis of each issue.
## Open Issues
### Worldmap list pagination (new)
### History page filters and behavior (frontend)
- Status: done
- Goal: Add paging controls to the WorldMap companion bans table (map page) so it matches Dashboard ban-list behavior and supports country drilldown without rendering / scrolling huge result sets.
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.
- Implement in `frontend/src/pages/MapPage.tsx` using the dashboard pattern from `frontend/src/components/BanTable.tsx`:
1. Add local state: `page` (start 1), `pageSize` (e.g., 100).
2. Derive `visibleBans` from `useMemo` + `selectedCountry`, then compute `pageBans` using `slice((page-1)*pageSize, page*pageSize)`.
3. Compute `totalPages = Math.max(1, Math.ceil(visibleBans.length / pageSize))`, `hasPrev`, `hasNext`.
4. Render a footer row below Table with total, page, prev/next buttons (use icons `ChevronLeftRegular`, `ChevronRightRegular`, or existing style).
5. Wire buttons to `setPage(page - 1)` / `setPage(page + 1)`, disabled by bounds.
6. Reset `page` to 1 whenever `visibleBans` filter changes: on `range`, `originFilter`, `selectedCountry`, or when data refreshes.
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.
- UX details:
- Keep existing “no bans found” row behavior.
- Keep summary info bar and total line consistent; show current slice counts in message as needed.
- Ensure paged data is used for `TableBody` mapping.
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.
- Optional follow-ups:
- Allow page-size selector if needed (25/50/100), updating `totalPages` and reset to page 1 on change.
- Add tests in `frontend/src/pages/__tests__/MapPage.test.tsx` for paging behavior (initial page, next/prev, filtering reset).
- Add documentation in `Docs/Web-Design.md` if there is a worldmap data table UI guideline.
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.