feat: add user search and discovery endpoint - #26
Conversation
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR implements a complete public user search and discovery endpoint. The changes introduce query parameter validation via ChangesUser Search & Discovery
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@SEARCH_FEATURE.md`:
- Around line 24-42: The example response uses top-level keys "success", "data"
(array) and "meta" but must follow the documented interceptor envelope shape of
"success" plus "data" being an object with "data" (array) and "meta" (object);
update the example in SEARCH_FEATURE.md so the top-level "meta" is moved under
"data" and the existing "data" array becomes data.data (i.e., structure: success
+ data: { data: [...], meta: {...} }) to match the contract.
In `@src/modules/users/dto/search-query.dto.ts`:
- Around line 44-45: The Transform on the verified property currently coerces
any non-'true' value to false; change it to only convert explicit 'true' or
'false' string values to booleans and leave other inputs untouched so validation
fails. Update the `@Transform` on the verified property (in the SearchQueryDto) to
return true for value === 'true' (case-insensitive), false for value ===
'false', and otherwise return the original value (or undefined/null) so
`@IsBoolean`() will reject invalid strings like 'abc'.
In `@src/modules/users/users.controller.ts`:
- Around line 40-46: The Swagger docs show the search endpoint as protected
because the controller has class-level `@ApiBearerAuth`(); update the
search(`@Query`() dto: SearchQueryDto) method's `@ApiOperation` to include security:
[] (i.e., `@ApiOperation`({ summary: 'Search users by name', security: [] })) so
the OpenAPI docs mark it public while keeping the runtime `@Public`() decorator,
or alternatively remove/move the class-level `@ApiBearerAuth`() and apply it only
to protected methods to avoid documenting public routes as secured.
In `@src/modules/users/users.service.ts`:
- Around line 247-250: The search query using
this.userModelAction.createQueryBuilder('u') currently fetches all User columns
then maps to public fields; restrict the SELECT to only needed columns to avoid
overfetching sensitive data by adding a .select(...) on the query builder for
u.id, u.fullName, u.role, u.isVerified and u.createdAt (use the same column
identifiers used elsewhere in users.service.ts so subsequent getMany() and map
logic still work) and keep the existing .where/.andWhere/getMany() flow.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 6c596f28-d485-4876-a16b-b9fdd2ccd592
📒 Files selected for processing (5)
SEARCH_FEATURE.mdsrc/modules/users/actions/user.action.tssrc/modules/users/dto/search-query.dto.tssrc/modules/users/users.controller.tssrc/modules/users/users.service.ts
|
Fix your merge conflicts @clinztouch |
|
Okay
…On Sun, May 10, 2026 at 1:43 PM Victor Oluwayemi ***@***.***> wrote:
*amiabl-programr* left a comment (hngprojects/openprofile-be#26)
<#26 (comment)>
Fix your merge conflicts @clinztouch <https://github.com/clinztouch>
—
Reply to this email directly, view it on GitHub
<#26 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BRZA2YARUYPUJPZVHIVIUE342B2O7AVCNFSM6AAAAACYX7NEUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIMJVGMYTEMJQG4>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
- Add SearchQueryDto with validation (MinLength 2, MaxLength 100, type-safe trim) - Add search() method to UsersService with ILIKE, filters, sort, and pagination - Add GET /users/search to UsersController decorated with @public() - Expose createQueryBuilder via UserModelAction - Add SEARCH_FEATURE.md documenting the feature - Response matches TransformInterceptor envelope (success, data, meta)
…lic columns in query
e452fc8 to
08cc645
Compare
Summary
Adds a public user search and discovery endpoint to OpenProfile.
What changed and why
Add
SearchQueryDtowith validation and sanitization@MinLength(2)@MaxLength(100)@Transform()Add
search()method toUsersServiceILIKEcase-insensitive searchverifiedandroleAdd
GET /api/users/searchendpoint toUsersController@Public()Expose
createQueryBuilderthroughUserModelActionAdd
SEARCH_FEATURE.mdEnsure response matches existing
TransformInterceptorenvelope:{ "success": true, "data": { "data": [], "meta": {} } }Why:
This feature enables user discovery workflows across the platform and unblocks frontend search functionality while preserving secure public responses.
Related issues
Checklist
npm run lintpassesnpm run buildpassesNotes
Implementation followed RFC exactly.
No scope changes were introduced.
Search remains limited to
fullNameusing PostgreSQLILIKE, with optional filters, sorting, and pagination.Sensitive fields (
email,password,refreshTokenHash,otpHash,deletedAt) are excluded from responses.Summary by CodeRabbit
Release Notes