fix(additional-privileges): return correct project membership ID

[varonix0]

Context

Currently there's an issue with old projects that doesn't have UUID ID's. You are unable to list, create, update, or delete additional privileges on identities in such projects because the return data was incorrectly returning the project ID as the project membership ID, but it should've been the actual project membership ID. This would cause a zod validation error when the project is an old project with a non-UUID ID.

I've kept the existing functionality as a fallback, so if we aren't able to get the project membership ID, it will fall back to the project ID being passed by the user.

Type

• Fix
• Feature
• Improvement
• Breaking
• Docs
• Chore

Checklist

• Title follows the conventional commit format: type(scope): short description (scope is optional, e.g., fix: prevent crash on sync or fix(api): handle null response).
• Tested locally
• Updated docs (if needed)
• Read the contributing guide

[maidul98]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[greptile-apps]

Greptile Overview

Greptile Summary

This PR fixes Zod validation errors that occurred when managing additional privileges for identities in old projects with non-UUID IDs. The fix properly retrieves the actual projectMembershipId from the membership table and includes it in service responses, with a fallback to projectId for backwards compatibility.

• Added projectMembershipId lookup logic in all service methods (createAdditionalPrivilege, updateAdditionalPrivilege, deleteAdditionalPrivilege, getAdditionalPrivilegeById, listAdditionalPrivileges)
• Updated router handlers to use the returned projectMembershipId with fallback to projectId for old projects
• Proper error handling with NotFoundError when project membership doesn't exist
• One endpoint (GET by slug) still uses old approach without fallback

Confidence Score: 4/5

• This PR is safe to merge with minimal risk after fixing the inconsistency in the GET by slug endpoint
• The implementation properly addresses the Zod validation issue by fetching the correct projectMembershipId from the membership table. The fallback mechanism maintains backwards compatibility. However, one endpoint was missed in the router updates, creating an inconsistency that could cause validation failures for old projects.
• Pay close attention to backend/src/ee/routes/v2/identity-project-additional-privilege-router.ts - the GET by slug endpoint needs the same fallback pattern applied

Important Files Changed

File Analysis

Filename	Score	Overview
backend/src/services/additional-privilege/additional-privilege-service.ts	4/5	Added projectMembershipId fetching and return logic to all service methods for project scope. Implementation properly queries membership table and includes NotFoundError handling.
backend/src/ee/routes/v2/identity-project-additional-privilege-router.ts	3/5	Updated router to use privilege.projectMembershipId with fallback to projectId. Missing update for GET by slug endpoint at line 342.

[greptile-apps]

Additional Comments (1)

1. backend/src/ee/routes/v2/identity-project-additional-privilege-router.ts, line 342 (link)

   logic: inconsistent with other endpoints - missing fallback to old project IDs

_{2 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}