Backend: BTC certificiranje list

Backend task for the BTC certificiranje list (GET /btc-certifications) – check search, date, brand and status filters, status sorting and 10-per-page pagination against the API spec and DB structure, implement, and verify against the spec.

Docs: BTC certificiranje list Spec: GET /btc-certifications (getBtcCertifications), BtcCertification, BtcStatus, Page / PerPage in api-docs/openapi.yaml DB: BtcCertifications, BtcCertificationCandidates in api/database/create_schema.sql

1. Double check API spec and DB structure

• Each list column maps to a field: Naziv → name, Marka → brandCode, Datum početka → startDate, Datum završetka → endDate, Status → status.
• Date filter: Figma shows a single-date picker; the docs recommend a date range, as on Assessments and BTC školovanje. The spec takes dateRange and matches any overlap with start → end (a single day = same start and end). Confirm.
• Pagination: 10 per page. The shared PerPage defaults to 20, so the frontend sends perPage=10. Confirm, or give this endpoint its own default.
• Search matches the name and candidate names. Sorting: status (active → upcoming → past), then startDate ascending.
• Actions menu by status is decided by the frontend from status. Edit / delete actions are only shown to users with btc-certifications.edit. The frontend reads this from GET /me/permissions. Confirm.
• Roles and permissions: btc-certifications.access. Trainers and BTC evaluators see all certificiranja (no per-member filtering, unlike assessments). Check against the docs.
• DB: status is not stored. Deleted rows (DeletedAt not null) are excluded. IX_BtcCertifications_StartDate supports the sort.

2. Implementation

• Roles and permissions: require btc-certifications.access → 403.
• DB: one query that calculates the status in SQL (today’s Zagreb date 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 BtcCertificationCandidates FullName. brandCode: equality. dateRange: overlap, parsed the same way as getAssessments. Invalid values → 400.
• candidatesCount in the same query.
• Response: pagination + results of BtcCertification.

3. Verify implementation against spec

• Route, query parameters and response shape match getBtcCertifications.
• Sorting with a mix of statuses. Each status filter, brand filter, a search that matches only a candidate name, and a single-day dateRange inside a 2-day certificiranje.
• perPage=10 with 14 records → 10 + 4, totalResults 14.
• A BTC evaluator who is not in any komisija still sees all certificiranja. A user without btc-certifications.access → 403. A deleted certificiranje doesn’t appear.

Done when

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