[FEATURE]: Move membership-fee status filtering to the database to support pagination + accurate total count #305

New issue

Open

opened 2025-12-22 14:17:20 +01:00 by moritz · 0 comments

moritz commented

2025-12-22 14:17:20 +01:00

Owner

Description

The member list currently derives the “current/last cycle status” by loading cycles and then filtering members in-memory. Once pagination is added, this will lead to incorrect page counts/total counts and inconsistent results because pagination would happen before the in-memory filter.

Proposal

Implement DB-level filtering/sorting for membership-fee status so the list can:

apply filters first,
paginate the filtered query,
return an accurate total_count for UI page count.

Possible implementation directions:

Add an Ash calculation/aggregate (or a dedicated read action) that exposes current_cycle_status and/or last_completed_cycle_status on Member, backed by the DB query.
Use Ash pagination with counting enabled so the UI can display total pages/records.
Hexdocs
Use aggregates where possible (filterable/sortable by Ash) to avoid N+1 and keep queries efficient.

Acceptance criteria

Member list filters (cycle status, current vs. last completed) are applied in the Ash query (no in-memory filtering for the main dataset).
Pagination works on the filtered dataset and UI shows correct total_count/page count.
“No cycle” members remain excluded from these filters (current behavior), but still appear in the unfiltered list.

## Description The member list currently derives the “current/last cycle status” by loading cycles and then filtering members in-memory. Once pagination is added, this will lead to incorrect page counts/total counts and inconsistent results because pagination would happen before the in-memory filter. ### Proposal Implement DB-level filtering/sorting for membership-fee status so the list can: 1. apply filters first, 2. paginate the filtered query, 3. return an accurate total_count for UI page count. Possible implementation directions: - Add an Ash calculation/aggregate (or a dedicated read action) that exposes current_cycle_status and/or last_completed_cycle_status on Member, backed by the DB query. - Use Ash pagination with counting enabled so the UI can display total pages/records. Hexdocs - Use aggregates where possible (filterable/sortable by Ash) to avoid N+1 and keep queries efficient. ## Acceptance criteria - [ ] Member list filters (cycle status, current vs. last completed) are applied in the Ash query (no in-memory filtering for the main dataset). - [ ] Pagination works on the filtered dataset and UI shows correct total_count/page count. - [ ] “No cycle” members remain excluded from these filters (current behavior), but still appear in the unfiltered list.