Skip to content

feat(candidate_profile): add pagination and sort to CV section list endpoints (#73) - #106

Merged
datvt243 merged 1 commit into
stagingfrom
feat/issue-73-pagination-filtering
Sep 2, 2026
Merged

feat(candidate_profile): add pagination and sort to CV section list endpoints (#73)#106
datvt243 merged 1 commit into
stagingfrom
feat/issue-73-pagination-filtering

Conversation

@datvt243

@datvt243 datvt243 commented Sep 2, 2026

Copy link
Copy Markdown
Owner

Summary

GET /api/v1/{education|experience|award|certificate|project|reference} now accept optional page, limit, sort query params.

generalInformation is intentionally excluded — its GET / returns a single per-candidate document (not a list via baseGetAll), so pagination doesn't apply there.

Backward compatibility

  • Omitting limit → response is identical to today: data is the full, unpaginated array.
  • Passing a valid limitdata becomes { items, pagination: { page, limit, total, totalPages } }.
  • limit is capped at 100 regardless of what's requested.
  • sort accepts a Mongoose sort expression (e.g. -createdAt for descending), validated against an allowlist regex (no $, can't smuggle an operator) — an invalid value is silently ignored rather than erroring.

Changes

  • services/index.ts: baseFindDocument gains page/limit/sort; applies .sort()/.skip()/.limit() plus a parallel countDocuments(), but only when a valid limit is given
  • candidate_profile/BaseController.ts: baseGetAll parses page/limit/sort from req.query, validates sort against an allowlist
  • swagger.config.ts: shared PageParam/LimitParam/SortParam + Pagination schema
  • 6 CV-section routers wired the new query params into their GET / Swagger docs
  • Tests: baseFindDocument.test.ts, BaseController.test.ts

Testing

  • npm test — 65/65 passing
  • npx tsc --noEmit — clean

Closes #73

🤖 Generated with Claude Code

https://claude.ai/code/session_01ACpXY4MGdQHFTmu3SZTPLG

…ndpoints (#73)

GET /api/v1/{education|experience|award|certificate|project|reference}
now accept optional `page`, `limit`, `sort` query params.

Backward compatible by design: omitting `limit` returns the exact same
response as before (`data` is the full, unpaginated array). Passing a
valid `limit` switches `data` to `{ items, pagination: { page, limit,
total, totalPages } }`. `limit` is capped at 100 regardless of what's
requested. `sort` accepts a Mongoose sort expression (e.g. `-createdAt`)
validated against an allowlist regex (no $, can't smuggle an operator);
an invalid value is silently ignored rather than erroring.

- services/index.ts: baseFindDocument gains page/limit/sort, applies
  .sort()/.skip()/.limit() + a parallel countDocuments() only when a
  valid limit is given
- candidate_profile/BaseController.ts: baseGetAll parses page/limit/sort
  from req.query, validates sort against an allowlist
- swagger.config.ts: shared PageParam/LimitParam/SortParam + Pagination
  schema
- 6 CV-section routers (education/experience/award/certificate/project/
  reference): wired the new query params into their GET / swagger docs.
  generalInformation excluded — its GET / returns a single per-candidate
  document, not a list, so pagination doesn't apply.
- tests: baseFindDocument.test.ts, BaseController.test.ts

Closes #73
@datvt243
datvt243 merged commit 33bade6 into staging Sep 2, 2026
3 checks passed
@datvt243
datvt243 deleted the feat/issue-73-pagination-filtering branch September 2, 2026 16:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant