Backend: BTC školovanje list

GitHub Issue: #242

Backend task for the BTC školovanje list (GET /btc-trainings) – check search, date range, brand and status filters, status sorting and pagination against the API spec and DB structure, implement, and verify against the spec.

Docs: BTC školovanje list Spec: GET /btc-trainings (getBtcTrainings), BtcTraining, BtcStatus, Page / PerPage in api-docs/openapi.yaml DB: BtcTrainings, BtcTrainingModules, BtcTrainingCandidates in api/database/create_schema.sql

1. Double check API spec and DB structure

• Each list column maps to a field: Naziv → name, Marka → brandCodes, Datum početka Modul 1 → module1StartDate, Status → status.

• Status without dates: the docs ask what status a školovanje without a Modul 1 start date has. The spec says upcoming, sorted last in its group (the docs recommendation). Confirm.

• Date range filter (decided): any overlap with Modul 1 start → Modul 4 end, partial overlap included (open-ended without a Modul 4 end; never matches without a Modul 1 start). Check the spec and docs say the same.

• Pagination: 10 per page, the same as the events list. The endpoint uses the shared Page / PerPage (default 20), so the frontend sends perPage=10.

  Please confirm 10 records per page. Neither the spec nor the events docs give a page size; 10 is what the events list uses in the app.

• Search matches the školovanje name and candidate names (search). The brand filter matches the školovanje’s BrandCodes, not the candidates’ Marka (kandidat). Confirm.

• Sorting: status (active → upcoming → past), then module1StartDate ascending, null last.

• Actions menu by status (Detalji / Uredi / Ukloni) is decided by the frontend from status. Check that status is all it needs.

• Roles and permissions: btc-trainings.access, Trainer only. No per-member filtering (unlike assessments). Brand restriction as decided in Backend: Adding new BTC školovanje.

• DB: status is not stored. It needs Modul 1 StartDate and Modul 4 EndDate from BtcTrainingModules. Deleted rows (DeletedAt not null) are excluded.

2. Implementation

• Roles and permissions: require btc-trainings.access → 403.
• DB: one query that joins Modul 1 and Modul 4 per školovanje and calculates the status in SQL (today’s Zagreb date passed as a parameter), so filtering by status, sorting and paging all happen in SQL. Exclude DeletedAt IS NOT NULL.
• Search: case-insensitive LIKE on Name and EXISTS on BtcTrainingCandidates FullName.
• brandCode: BrandCodes LIKE '%X%'. dateRange: parse start/end the same way as getAssessments. Invalid values → 400.
• candidatesCount in the same query (no N+1).
• Response: pagination + results of BtcTraining.

3. Verify implementation against spec

• Route, query parameters and response shape match getBtcTrainings.
• Sorting with a mix of statuses and a školovanje without dates (last among upcoming).
• Each status filter, brand filter, a search that matches only a candidate name, and a date range that overlaps only Modul 3.
• totalResults is correct with filters applied; page 2 returns the rest.
• A deleted školovanje doesn’t appear. Evaluator token → 403.

Done when

The BTC školovanje list page can be built from the API, with all filters, sorting and pages working.