Skip to content

feat(web): add GET /api/ee/user endpoint for owner user info#940

Merged
msukkari merged 7 commits intomainfrom
msukkari/ee-user-info-api-SOU-573
Feb 25, 2026
Merged

feat(web): add GET /api/ee/user endpoint for owner user info#940
msukkari merged 7 commits intomainfrom
msukkari/ee-user-info-api-SOU-573

Conversation

@msukkari
Copy link
Contributor

@msukkari msukkari commented Feb 25, 2026

Summary

  • Adds a GET /api/ee/user endpoint that returns the authenticated user's name, email, createdAt, and updatedAt
  • Restricted to org owners via withMinimumOrgRole(role, OrgRole.OWNER)
  • Follows existing patterns in the same route file (DELETE handler) and sibling /ee/users route

Test plan

  • Call GET /api/ee/user as an owner and verify it returns { name, email, createdAt, updatedAt }
  • Call GET /api/ee/user as a non-owner member and verify it returns a 403 forbidden response
  • Call GET /api/ee/user without authentication and verify it returns a 401 response

🤖 Generated with Claude Code

Summary by CodeRabbit

  • New Features

    • Added GET /api/ee/user endpoint returning the authenticated owner's profile (name, email, createdAt, updatedAt) with owner-restricted access.
    • Introduced a new "org-management" entitlement for enterprise plans to gate organization management APIs.
  • Documentation

    • Changelog updated to document the new endpoint and entitlement.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@github-actions

This comment has been minimized.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 25, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1994b23 and a27c563.

📒 Files selected for processing (1)
  • CHANGELOG.md
🚧 Files skipped from review as they are similar to previous changes (1)
  • CHANGELOG.md

Walkthrough

Adds a new GET /api/ee/user endpoint returning an authenticated owner's user info (name, email, createdAt, updatedAt). Introduces an "org-management" entitlement and enforces it in GET /api/ee/users and the new GET /api/ee/user handlers, returning 403 when missing.

Changes

Cohort / File(s) Summary
Documentation
CHANGELOG.md
Added Unreleased "Added" entry documenting the new GET /api/ee/user endpoint.
API — single user
packages/web/src/app/api/(server)/ee/user/route.ts
New GET handler: validates userId query, enforces owner auth and org-management entitlement, fetches user (name,email,createdAt,updatedAt), audits on success, maps service errors to HTTP responses. Existing DELETE unchanged.
API — users list
packages/web/src/app/api/(server)/ee/users/route.ts
Inserted entitlement guard for org-management at start of GET handler; returns 403 with structured service error if entitlement absent. Existing listing, logging, and error handling retained.
Entitlements
packages/shared/src/entitlements.ts
Added new entitlement org-management and included it in self-hosted:enterprise and self-hosted:enterprise-unlimited plan entitlements.

Sequence Diagram(s)

sequenceDiagram
    actor Client
    participant API as "GET /api/ee/user"
    participant Auth as "withAuthV2"
    participant AuthZ as "withMinimumOrgRole (OWNER)"
    participant Service as "User Service"
    participant DB as "Database"

    Client->>API: GET /api/ee/user?userId=...
    API->>Auth: authenticate request
    Auth-->>API: authenticated identity
    API->>AuthZ: verify OWNER role & org-management entitlement
    AuthZ-->>API: authorization granted / denied
    alt authorized
        API->>Service: fetch user by id (name,email,createdAt,updatedAt)
        Service->>DB: query user
        DB-->>Service: record / null
        Service-->>API: user data / null
        alt user found
            API-->>Client: 200 OK + user info
        else not found
            API-->>Client: 404 Not Found
        end
    else forbidden
        API-->>Client: 403 Forbidden (service error)
    end
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately and specifically describes the main change: adding a GET /api/ee/user endpoint for retrieving owner user information, which is the primary focus of the changeset.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch msukkari/ee-user-info-api-SOU-573

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
packages/web/src/app/api/(server)/ee/user/route.ts (1)

49-49: StatusCodes.OK is the default for Response.json — consider omitting.

-    return Response.json(result, { status: StatusCodes.OK });
+    return Response.json(result);

(The DELETE handler does the same at line 127 so keeping it for consistency is also a reasonable choice.)

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@packages/web/src/app/api/`(server)/ee/user/route.ts at line 49, The
Response.json calls currently pass an explicit status using StatusCodes.OK which
is unnecessary because Response.json defaults to 200; remove the redundant
status option and return Response.json(result) instead where
Response.json(result, { status: StatusCodes.OK }) is used (also update the
matching DELETE handler that does the same) so the code uses the default status
and stays concise.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/web/src/app/api/`(server)/ee/user/route.ts:
- Around line 17-50: The GET handler currently returns user data without
creating an audit record; inside the withAuthV2 -> withMinimumOrgRole block (the
GET handler function), after successfully fetching userData (i.e., where
prisma.user.findUnique returns a result and before returning it), call
auditService.createAudit(...) to record the read action (use a consistent action
string like "user.view" or "user.get"), include relevant context such as org.id,
the acting user.id, and the target user id (user.id or the fetched user's id),
and only create the audit on successful retrieval (not on notFound or thrown
errors) so the handler mirrors the existing audit pattern used by the user.list
and user.delete handlers.

---

Nitpick comments:
In `@packages/web/src/app/api/`(server)/ee/user/route.ts:
- Line 49: The Response.json calls currently pass an explicit status using
StatusCodes.OK which is unnecessary because Response.json defaults to 200;
remove the redundant status option and return Response.json(result) instead
where Response.json(result, { status: StatusCodes.OK }) is used (also update the
matching DELETE handler that does the same) so the code uses the default status
and stays concise.

ℹ️ Review info

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f9421ed and 6a86608.

📒 Files selected for processing (2)
  • CHANGELOG.md
  • packages/web/src/app/api/(server)/ee/user/route.ts

github-actions bot and others added 4 commits February 25, 2026 19:07
Co-authored-by: Michael Sukkarieh <msukkari@users.noreply.github.com>
Look up the specified user by ID instead of returning the
authenticated user's own info.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Adds a new "org-management" entitlement to both enterprise plan tiers
and gates the GET /api/ee/user and GET /api/ee/users endpoints behind it.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/web/src/app/api/`(server)/ee/user/route.ts:
- Around line 26-50: Both GET and DELETE handlers call withAuthV2 and
withMinimumOrgRole but use prisma.user.findUnique / prisma.user.delete directly
(these are not scoped by userScopedPrismaClientExtension), allowing OWNERs to
access or delete users across orgs; update both handlers to first verify org
membership via prisma.userToOrg (e.g., prisma.userToOrg.findFirst or findMany
with where: { userId, orgId: org.id }) and return notFound or a
forbidden/service error if no membership exists, then only call
prisma.user.findUnique or prisma.user.delete once membership is confirmed; keep
existing functions withAuthV2 and withMinimumOrgRole but add the explicit
org-membership check using the userToOrg relation before performing user
queries/deletes.

ℹ️ Review info

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d23eac2 and 1994b23.

📒 Files selected for processing (3)
  • packages/shared/src/entitlements.ts
  • packages/web/src/app/api/(server)/ee/user/route.ts
  • packages/web/src/app/api/(server)/ee/users/route.ts

@msukkari msukkari merged commit 8abde2d into main Feb 25, 2026
9 checks passed
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