feat(permission): add AssignRole/AssignAdditionalPrivileges with conditions for Members, Identities, and Groups by victorvhs017 · Pull Request #5593 · Infisical/infisical

victorvhs017 · 2026-03-04T22:40:17Z

Context

This PR refactors project RBAC by introducing granular privilege actions and condition-based permission rules for Members, Identities, and Groups.

Before: Only GrantPrivileges existed, with no conditions or subject/action scoping.

After:

New actions: AssignRole (role assignment) and AssignAdditionalPrivileges (subject:action scoping)
Conditions: Member (email, role, subject, action), Identity (identityId, role, subject, action), Groups (groupName, role)
Legacy: GrantPrivileges is deprecated; it cannot be combined with AssignRole or AssignAdditionalPrivileges
Validation: Subject:action format ({subject}:{action}), forbidden subjects, and assignable subject allow-lists
Additional privileges: Validation that the actor can grant each subject/action in the requested permissions

Screenshots

In the video below, I show all the new Actions set in a role called "test". Then I switch to another browser where I have a user with this test role. Check how the conditions set for him change what he can and cannot do regarding roles and additional privileges of Users, Machine Identities, and Groups.

Screenshare.-.2026-03-05.8_23_54.PM.mp4

Steps to verify the change

UI – allow/forbid:
- Create/edit role with Member, Identity, and Group permissions.
- Add conditions (email, role, subject, action) and verify allow/forbid behavior.
- Confirm invalid combinations (e.g., Grant Privileges + Assign Role) are rejected.
Legacy actions:
- Create/edit role with GrantPrivileges only.
- Ensure existing roles that use GrantPrivileges still work.
- Confirm Grant Privileges + Assign Role / Assign Additional Privileges is blocked.
API – user:
- Create/update member/group memberships with AssignRole and AssignAdditionalPrivileges.
- Verify condition-based restrictions (e.g., subject:action scoping).
API – machine identity:
- Same flows for identities via AssignRole and AssignAdditionalPrivileges.
- Verify condition validation and subject/action scoping.

Type

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

…fields and conditions for member actions - Updated `validatePrivilegeChangeOperation` to accept optional `subjectFields` for more granular permission checks. - Introduced `MemberSubjectFields` type to define fields relevant to member permissions. - Enhanced `ActionAllowedConditions` to include conditions for granting privileges to members. - Implemented new validation logic for grant privilege actions in `project-additional-privilege-factory`. - Updated frontend components to utilize new grant privilege conditions for filtering roles and actions based on permissions.

maidul98 · 2026-03-04T22:40:59Z

✅ 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.

…nd subject matching - Introduced helper functions for action and subject matching to streamline permission validation logic. - Updated handling of rule subjects to support both single and multiple subject scenarios. - Added a NotFoundError for better error handling when a target user is not found during project membership updates.

…d privilege assignments - Introduced `AssignRole` and `AssignAdditionalPrivileges` actions to improve role management for project members. - Updated permission validation logic to prevent conflicts between legacy and new privilege actions. - Enhanced documentation to reflect new actions and their conditions for better clarity in permission management.

…in project permissions - Updated error messages for permission-related actions to improve clarity. - Added role slug to permission service factory for better role management. - Refined privilege validation logic in project additional privilege factory to reflect accurate action descriptions. - Improved condition checks for granting privileges in frontend components to ensure proper role modifications.

…s for project roles - Introduced new condition checks for granting privileges in the project additional privilege factory. - Updated frontend components to utilize new privilege conditions, improving role management and user feedback. - Enhanced tooltip functionality to provide clearer permission-related messages in UI elements. - Refined privilege handling logic to ensure accurate validation and user experience across project member actions.

…g in project components - Updated privilege validation logic in MemberProjectAdditionalPrivilegeSection to ensure accurate email checks. - Enhanced GeneralPermissionPolicies to conditionally hide legacy actions based on permission rules. - Revised action descriptions in ProjectRoleModifySection.utils for clarity on legacy actions and their usage.

…ion conditions - Changed label from "Target Email" to "User Email" for clarity in the MemberPermissionConditions component. This improves the user interface by providing a more accurate description of the field's purpose.

…ion for project permissions - Introduced `validateAssignableActionFormat` function to validate action format and subject assignments in both backend and frontend components. - Updated `extractConditionValues` to streamline condition value extraction for permission checks. - Enhanced `MemberConditionSchema` and `ConditionSchema` to incorporate new validation logic, improving error handling and user feedback for action-related conditions.

…missions - Updated `validateAssignableActionFormat` to accept a configuration object for improved subject validation, including allowed, forbidden, and glob pattern checks. - Refactored condition extraction in `MemberConditionSchema` and `ConditionSchema` to utilize the new validation logic, enhancing error handling and user feedback. - Integrated `picomatch` for glob pattern matching in subject validation across both backend and frontend components.

…schema - Updated the handling of forbidden subjects in `ConditionSchema` to ensure that only trimmed values are considered, improving validation accuracy for permission conditions. - Enhanced the logic for `$NEQ` operator to correctly manage subject values, contributing to better error handling and user feedback in permission-related actions.

…ilege validation - Added `AssignRole` and `AssignAdditionalPrivileges` actions to the permission system for improved identity role management. - Updated validation logic to prevent conflicts between legacy and new actions, ensuring clearer permission handling. - Enhanced condition schemas and frontend components to utilize new grant privilege conditions, improving role filtering and user feedback. - Refined error handling and messaging for identity-related permission actions to enhance clarity and user experience.

- Updated condition extraction to safely handle undefined values in `MemberConditions` and `IdentityConditions`, ensuring robust permission checks. - Enhanced the logic for processing rules to prevent potential errors when conditions are not defined, improving overall validation accuracy.

…ermission handling - Added `AssignRole` action to the permission system, replacing the legacy `GrantPrivileges` action for group management. - Updated validation logic to prevent conflicts between legacy and new actions, ensuring clearer permission handling. - Enhanced condition schemas and frontend components to utilize new grant privilege conditions for groups, improving role filtering and user feedback. - Refined error handling and messaging for group-related permission actions to enhance clarity and user experience.

…ssionPolicies - Introduced a separate state management for legacy actions to prevent unnecessary re-renders in the ActionsMultiSelect component. - Updated the logic to conditionally hide legacy actions based on the new state, improving performance and clarity in permission handling. - Enhanced the useMemo hooks to streamline dependency management for better efficiency in rendering.

greptile-apps · 2026-03-05T22:13:32Z

Greptile Summary

This PR introduces granular privilege actions (AssignRole and AssignAdditionalPrivileges) and condition-based permission rules for Members, Identities, and Groups, replacing the broad GrantPrivileges legacy action. The refactor is well-structured: conditions are schema-validated, backward-compatibility with GrantPrivileges is maintained, the permission-service.ts fix correctly populates role.name/slug for preset roles so downstream guards work, and the hasDetailedConditions path properly prevents empty-payload authorization bypasses.

Key items worth addressing before merge:

no-access role handling inconsistency — project-membership-user-factory.ts CREATE does not skip validation for the no-access role, while project-membership-identity-factory.ts and project-membership-group-factory.ts do. Now that the role.name fix makes those guards functional, assigning no-access to users incorrectly requires AssignRole/GrantPrivileges, while doing the same for identities and groups does not.
Misleading error messages — When both AssignRole and the GrantPrivileges fallback fail, the error message always reports assign-role (hardcoded in constructPermissionErrorMessage), even though the last-checked action and its missingPermissions details may reflect grant-privileges. This affects all three membership factories.
actorId naming in $validateAdditionalPrivilegesGuard — The parameter refers to the target entity (user/identity being modified), but the name actorId is conventionally reserved for the calling actor in this codebase, which can mislead future maintainers.
Unsafe permissions as TPermissionRule[] cast — The cast proceeds without confirming the value is actually an array, risking a confusing runtime error if upstream schema validation ever allows a non-array shape.

Confidence Score: 3/5

PR is mostly safe but has a behavioral inconsistency in no-access role handling for user memberships and misleading error messages that should be addressed before merge.
The core privilege-boundary logic is sound and backward-compatible. The main concerns are: (1) a logic inconsistency where assigning the no-access role to users incorrectly requires AssignRole/GrantPrivileges while identity/group paths correctly skip that check, (2) error messages that conflate AssignRole and GrantPrivileges action names, and (3) minor naming/safety issues in the shared validation helper. None of these are exploitable security vulnerabilities, but the no-access discrepancy is a real behavioral regression for existing users who only hold the Edit permission on Members.
Pay close attention to backend/src/services/membership-user/project/project-membership-user-factory.ts (missing no-access guard) and backend/src/services/additional-privilege/project/project-additional-privilege-factory.ts (actorId naming, unsafe cast).

Important Files Changed

Filename	Overview
backend/src/ee/services/permission/project-permission.ts	Adds AssignRole/AssignAdditionalPrivileges actions to Member, Identity, and Group enums; introduces MemberConditionSchema, updated IdentityManagementConditionSchema, and GroupConditionSchema with new subject/action condition fields; adds ActionAllowedConditions map scoping which conditions are permitted per action. Validation logic (refineSubjectActionConditions, validateAssignableActionFormat) is well-structured and reused via the shared refineSubjectActionConditions helper. Changes look correct.
backend/src/ee/services/permission/permission-fns.ts	Extends checkForInvalidPermissionCombination to block mixing GrantPrivileges with AssignRole/AssignAdditionalPrivileges. Adds optional subjectFields parameter to validatePrivilegeChangeOperation, enabling CASL subject-with-fields checks in the new privilege system. Logic is sound; the subject() call correctly falls back to the bare subject when no fields are provided.
backend/src/services/additional-privilege/project/project-additional-privilege-factory.ts	Major refactor: introduces checkPermissionConditions, hasUnrestrictedGrantPrivileges, validateGrantPrivilegeSubjectActionConditions, and the shared $validateAdditionalPrivilegesGuard helper for both CREATE and UPDATE paths. The actorId naming in $validateAdditionalPrivilegesGuard refers to the target entity (not the caller), which is confusing. The permissions parameter is cast to TPermissionRule[] without a runtime array check. Logic for the hasDetailedConditions branch correctly prevents empty-payload bypasses.
backend/src/services/membership-user/project/project-membership-user-factory.ts	CREATE guard gains an unconditional optimization (skip per-user loop if unrestricted), UPDATE guard now includes per-user subject fields. The user CREATE path is missing the no-access guard present in identity/group factories, which means assigning no-access requires AssignRole/GrantPrivileges for users but not identities or groups — likely unintentional inconsistency.
backend/src/services/membership-group/project/project-membership-group-factory.ts	Adds groupDAL dependency and fetches group details for condition-based role checks. Both CREATE and UPDATE guards follow the unconditional → conditional → legacy fallback pattern correctly. The error message always reports AssignRole even when the GrantPrivileges fallback was the last failing check, which can be confusing to callers.
backend/src/services/membership-identity/project/project-membership-identity-factory.ts	CREATE and UPDATE guards now check AssignRole with conditional identity fields (identityId, role slug) and fall back to GrantPrivileges. The NoAccess guard is correctly preserved in CREATE. Same error message inconsistency (always reports AssignRole) as in the group factory.
backend/src/ee/services/permission/permission-service.ts	Adds role: { name: el.name, slug: el.name } for preset roles in getProjectPermissionByRoles, fixing the broken role.name guard in downstream consumers and enabling slug-based condition checks for built-in roles.
backend/src/ee/services/permission/default-roles.ts	Additive only: adds AssignRole and AssignAdditionalPrivileges to the admin role for Member and Identity, and AssignRole to the admin role for Groups. No breaking changes; existing roles are unchanged.
docs/internals/permissions/project-permissions.mdx	Documents the new AssignRole and AssignAdditionalPrivileges actions for Members, Identities, and Groups, plus the deprecation notice for GrantPrivileges. Documentation is present and covers the new feature.
backend/src/server/routes/index.ts	Wires userDAL and identityDAL into the project additional privileges factory — straightforward dependency injection, no issues.

Comments Outside Diff (3)

backend/src/services/additional-privilege/project/project-additional-privilege-factory.ts, line 748 (link)

actorId refers to the target entity, not the calling actor

The parameter actorId (and the actorType alongside it) inside $validateAdditionalPrivilegesGuard refers to the target entity whose privileges are being created or updated — not the calling actor that is performing the operation. Throughout the rest of this codebase, actor consistently means the identity making the request (see OrgServiceActor, dto.permission). Reusing the same term for the target leads to immediate confusion, especially when both concepts appear in the same function body:
```
// actorId is the CALLING actor in dto.permission, but…
const membership = memberships.find(
  (el) => el[actorType === ActorType.IDENTITY ? "actorIdentityId" : "actorUserId"] === actorId
  //                                                                               ^^^^^^^^ this is the TARGET
);
```
Consider renaming the parameter to targetActorId / targetActorType so readers can immediately tell which side of the permission check they're looking at.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}
backend/src/services/membership-user/project/project-membership-user-factory.ts, line 88-97 (link)

no-access role included in privilege validation for user CREATE — inconsistent with identity/group factories

In project-membership-identity-factory.ts and project-membership-group-factory.ts, the CREATE guard wraps the entire validation block with:
```
if (permissionRole?.role?.name !== ProjectMembershipRole.NoAccess) {
  // validation ...
}
```
This guard is now functional because permission-service.ts was fixed to populate role: { name: el.name, slug: el.name } for preset roles.

In contrast, this user CREATE path has no such guard: when no-access is included in dto.data.roles, the code proceeds to check whether the calling actor has AssignRole/GrantPrivileges on Member for it — even though assigning the no-access role grants no privileges and should require no boundary check. An actor with only Edit on Member (but not AssignRole/GrantPrivileges) could assign no-access to identities and groups but not to users, which is confusing and likely unintentional.
backend/src/services/additional-privilege/project/project-additional-privilege-factory.ts, line 623 (link)

Unsafe as TPermissionRule[] cast without runtime type guard

permissions arrives as unknown (from dto.data.permissions) and is immediately cast:
```
const permissionRules = permissions as TPermissionRule[];
```
The for...of loop below assumes this is iterable and that each element has .subject, .action, and .conditions properties of the expected shapes. If permissions is ever an object (not an array) or contains entries with unexpected shapes, this will either throw a confusing runtime error or silently skip validation.

Since the value comes from user-supplied DTO data that has presumably been validated by a Zod schema upstream, this is low-risk in the happy path. However, adding a simple runtime guard (if (!Array.isArray(permissions))) before the cast and loop would make the failure mode explicit and predictable rather than a silent mismatch.

_{Last reviewed commit: ca2dd61}

backend/src/ee/services/permission/project-permission.ts

backend/src/ee/services/permission/permission-service.ts

- Modified the role structure in `permission-service-types.ts` to make `id`, `createdAt`, and `updatedAt` optional, enhancing flexibility in role definitions. - Updated the `permission-service.ts` to include the `name` property in the role object, improving clarity and consistency in role handling.

…on for roles - Added `AssignRole` and `AssignAdditionalPrivileges` actions to the admin permission rules, improving role management capabilities. - Introduced `extractNegatedConditionValues` function to streamline the extraction of forbidden values from conditions, enhancing validation accuracy. - Updated frontend components to utilize new grant privilege conditions, improving role filtering and user feedback in group management.

…ce role validation - Refactored the grant condition extraction logic to utilize a more flexible configuration-based approach, improving maintainability and clarity. - Introduced a new `ConditionMapping` type to enhance the handling of condition keys and their corresponding results. - Updated the `isGrantPrivilegesMemberRule` function to improve readability and maintainability. - Enhanced the GroupsTab component to ensure proper handling of inverted permission rules, improving role validation accuracy.

victorvhs017 · 2026-03-05T23:04:36Z

@greptileai re-review and update the summary

… conditions - Added `filterByGrantConditions` and `canModifyByGrantConditions` functions to streamline the handling of permission checks based on grant conditions. - Updated various components to utilize the new functions for improved role filtering and permission validation, enhancing code clarity and maintainability. - Refactored existing logic in components such as `GroupsTab`, `AddMemberModal`, and `IdentityProjectAdditionalPrivilegeSection` to leverage the new utility functions, improving overall permission handling.

victorvhs017 · 2026-03-05T23:16:21Z

@greptileai re-review and update the summary

backend/src/services/membership-user/project/project-membership-user-factory.ts

backend/src/ee/services/permission/project-permission.ts

backend/src/services/additional-privilege/project/project-additional-privilege-factory.ts

…ber actions - Added a new schema for member actions in the project permission structure, enhancing the flexibility of permission definitions. - Removed the previous member action schema to streamline the overall permission handling, ensuring clarity and maintainability. - Updated descriptions for better understanding of the new member permission conditions and actions.

…ship actions - Introduced unconditional checks for privilege validation in project membership group, identity, and user factories to streamline permission handling. - Updated validation logic to ensure that legacy actions are only invoked when necessary, improving clarity and maintainability. - Enhanced error handling for permission boundary checks, providing clearer feedback on missing permissions during project membership creation and updates.

… validation - Introduced a new `refineSubjectActionConditions` function to encapsulate the logic for validating subject and action conditions, improving code reusability and clarity. - Updated the `MemberConditionSchema` and `IdentityManagementConditionSchema` to utilize the new function, reducing redundancy in validation logic. - Enhanced error handling for action validation, ensuring clearer feedback on issues related to subject conditions.

victorvhs017 · 2026-03-06T00:23:54Z

@greptileai re-review and update summary

backend/src/services/additional-privilege/project/project-additional-privilege-factory.ts

backend/src/ee/services/permission/project-permission.ts

…n and introduce new guard logic - Updated the `newProjectAdditionalPrivilegesFactory` to improve permission validation by ensuring that unconditional allow rules take precedence over other conditions. - Introduced a new `$validateAdditionalPrivilegesGuard` function to encapsulate detailed privilege validation logic, enhancing clarity and maintainability. - Streamlined the handling of legacy actions and improved error handling for permission boundary checks, providing clearer feedback on missing permissions. - Refactored the `onCreateAdditionalPrivilegesGuard` to utilize the new guard logic, ensuring consistent permission checks across different actor types.

victorvhs017 · 2026-03-06T00:56:47Z

@greptileai re-review and update the summary

…entity creation - Refactored the error handling logic in the `newProjectMembershipIdentityFactory` to enhance clarity and maintainability. - Streamlined the construction of permission error messages, ensuring consistent feedback on missing permissions during identity project membership creation.

victorvhs017 · 2026-03-06T01:14:14Z

@greptileai re-review and update summary

backend/src/services/membership-group/project/project-membership-group-factory.ts

linear · 2026-03-06T01:24:30Z

SECRETS-23 Add role-based conditions to access control policy for actions

ENG-4662 Scope access for User Management “Assume Privilege” action

… for member management - Replaced `getGrantPrivilegeConditions` with `getMemberGrantPrivilegeConditions` across various components to improve clarity and specificity in member-related permission handling. - Updated related imports and usages in `AddMemberModal`, `MemberProjectAdditionalPrivilegeSection`, and `MemberRoleDetailsSection` to reflect the new function naming, enhancing code maintainability and readability.

akhilmhdh

Pending application testing

backend/src/ee/services/permission/project-permission.ts

backend/src/services/additional-privilege/project/project-additional-privilege-factory.ts

backend/src/services/membership-group/project/project-membership-group-factory.ts

backend/src/services/membership-identity/project/project-membership-identity-factory.ts

backend/src/services/membership-user/project/project-membership-user-factory.ts

akhilmhdh · 2026-03-06T18:58:56Z

...pages/project/AccessControlPage/components/GroupsTab/components/GroupsSection/GroupRoles.tsx

+      allowed: grantPrivilegeConditions.groupNames,
+      forbidden: grantPrivilegeConditions.forbiddenGroupNames
+    });
+  }, [permission, grantPrivilegeConditions, groupName]);


Instead of memoing permission each time - why not a single memo for the whole thing and return a object contains all the properties

Just to clarify, do you mean having all these 3 useMemos, for example:

In one big useMemo that returns 3 objects?

If that's the suggestion, I don't think it's a good optimization due to the dependency arrays being different.

akhilmhdh · 2026-03-06T18:59:28Z

...dentityProjectAdditionalPrivilegeSection/IdentityProjectAdditionalPrivilegeModifySection.tsx

    subject(ProjectPermissionSub.Identity, { identityId })
  );

+  const grantPrivilegeConditions = useMemo(


Same comment - instead of memoing permission each time, one single memo with various props as keys

akhilmhdh · 2026-03-06T19:00:21Z

...emberProjectAdditionalPrivilegeSection/MembershipProjectAdditionalPrivilegeModifySection.tsx

    ProjectPermissionSub.Member
  );

+  const grantPrivilegeConditions = useMemo(


Like wise everywhere we are doing memo

…ation logic - Updated permission-related schemas and validation functions to replace legacy field names with more descriptive ones, such as changing `email` to `userEmail` and `role` to `assignableRole`. - Enhanced the `validatePrivilegeChangeOperation` function to accept multiple actions, improving flexibility in permission checks. - Streamlined error handling in project membership factories to provide clearer feedback on permission issues, ensuring consistent validation across member, identity, and group actions. - Updated documentation to reflect the new permission field names and conditions, improving clarity for developers.

- Updated the button's disabled state in `IdentityRoleModify` to include a check for empty filtered roles, ensuring that users cannot attempt to modify roles when none are available. - Simplified the edit disabled condition in `MemberProjectAdditionalPrivilegeSection` by removing the check for ownership, enhancing clarity in permission handling.

…onent - Removed the unused import of `ProjectMembershipRole` in the `IdentityRoleModify` component to enhance code cleanliness and maintainability.

…eadability - Removed unused imports and simplified permission checks in the `newProjectAdditionalPrivilegesFactory` to improve clarity. - Reformatted condition mappings in `permission.ts` for better readability. - Updated action allowed conditions in `ProjectRoleModifySection.utils.tsx` to enhance consistency and maintainability.

…ition checks - Updated the `MemberRoleModify` component to include additional checks for role modification permissions, ensuring that buttons are only enabled when appropriate. - Refactored condition mappings in `ProjectRoleModifySection.utils.tsx` to replace legacy field names with more descriptive ones, improving clarity and maintainability.

…leModify component - Enhanced the readability of the disabled state condition for the role modification button in the `MemberRoleModify` component by formatting the logic across multiple lines. - This change improves clarity in understanding the conditions under which the button is enabled or disabled, aligning with recent refactoring efforts in permission handling.

akhilmhdh

Just some minor ux issues in application testing. Rest looks good @victorvhs017

One main one is error message for assign role. The additional privilege one has spot on error message. The assign role is a bit misleading

akhilmhdh · 2026-03-07T17:03:11Z

backend/src/ee/services/permission/permission-fns.ts

 import { OrgPermissionSet } from "./org-permission";
 import {
  ActionAllowedConditions,
+  ProjectPermissionGroupActions,


Application testing feedback

I feel like the message could cause confusion. Because i had assign role and just was condition only on those one. It works correctly, just the UI

I tried to make this more generic, including the conditions. What do you think?

Refactoring the error with a detailed message on which condition failed and why would be a big change.

backend/src/ee/services/permission/permission-fns.ts

akhilmhdh · 2026-03-07T17:15:09Z

backend/src/ee/services/permission/permission-fns.ts

+  ProjectPermissionIdentityActions,
+  ProjectPermissionMemberActions,
  ProjectPermissionSecretActions,
  ProjectPermissionSet,


Same in groups. I had permission for assignRole but the error said is not having it.

…ction descriptions - Improved the clarity of permission error messages in the `constructPermissionErrorMessage` function to provide more detailed feedback on permission denials. - Updated action descriptions in `IdentityManagementPermissionConditions` and `MemberPermissionConditions` components to reflect more specific examples, enhancing user understanding of assignable actions. - Removed unused imports in the `ConditionsFields` component to streamline the code and improve maintainability.

…dify and MemberRoleModify components - Updated the role selection logic in both `IdentityRoleModify` and `MemberRoleModify` components to utilize a new helper function for determining assignable roles, improving code clarity and maintainability. - Enhanced the rendering of role options to include permission checks, providing users with clearer feedback on assignable roles. - Streamlined the handling of role assignment conditions in the `ConditionsFields` component to improve user experience and messaging.

…ilege factory - Eliminated the unused import of `TIdentityDALFactory` in the `newProjectAdditionalPrivilegesFactory` to enhance code cleanliness and maintainability.

…rvice - Eliminated the unused import of `TIdentityDALFactory` in the `additionalPrivilegeServiceFactory` to enhance code cleanliness and maintainability.

- Eliminated the unused import of `identityDAL` in the route registration function to enhance code cleanliness and maintainability.

Victor Santos added 13 commits March 4, 2026 19:53

victorvhs017 changed the title ~~refactor(permission): enhance privilege management by adding subject …~~ feat(permission): add AssignRole/AssignAdditionalPrivileges with conditions for Members, Identities, and Groups Mar 5, 2026

victorvhs017 marked this pull request as ready for review March 5, 2026 22:06

greptile-apps bot reviewed Mar 5, 2026

View reviewed changes

backend/src/ee/services/permission/project-permission.ts Show resolved Hide resolved

backend/src/ee/services/permission/permission-service.ts Outdated Show resolved Hide resolved

Victor Santos added 3 commits March 5, 2026 19:25

greptile-apps bot reviewed Mar 5, 2026

View reviewed changes

Victor Santos added 3 commits March 5, 2026 20:41

greptile-apps bot reviewed Mar 6, 2026

View reviewed changes

backend/src/services/membership-group/project/project-membership-group-factory.ts Outdated Show resolved Hide resolved

victorvhs017 requested a review from akhilmhdh March 6, 2026 01:41

akhilmhdh reviewed Mar 6, 2026

View reviewed changes

Victor Santos added 6 commits March 6, 2026 19:27

refactor(permission): remove unused import in IdentityRoleModify comp…

e90d3c1

…onent - Removed the unused import of `ProjectMembershipRole` in the `IdentityRoleModify` component to enhance code cleanliness and maintainability.

akhilmhdh reviewed Mar 7, 2026

View reviewed changes

Victor Santos added 5 commits March 9, 2026 11:38

refactor(permission): remove unused import in project additional priv…

d2e8bf8

…ilege factory - Eliminated the unused import of `TIdentityDALFactory` in the `newProjectAdditionalPrivilegesFactory` to enhance code cleanliness and maintainability.

refactor(permission): remove unused import in additional privilege se…

9e547c8

…rvice - Eliminated the unused import of `TIdentityDALFactory` in the `additionalPrivilegeServiceFactory` to enhance code cleanliness and maintainability.

refactor(permission): remove unused import in route registration

bda6aec

- Eliminated the unused import of `identityDAL` in the route registration function to enhance code cleanliness and maintainability.

victorvhs017 requested a review from akhilmhdh March 9, 2026 16:18

Conversation

victorvhs017 commented Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Context

Screenshots

Steps to verify the change

Type

Checklist

Uh oh!

maidul98 commented Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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

Uh oh!

greptile-apps bot commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 3/5

Important Files Changed

Comments Outside Diff (3)

Uh oh!

Uh oh!

Uh oh!

victorvhs017 commented Mar 5, 2026

Uh oh!

victorvhs017 commented Mar 5, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

victorvhs017 commented Mar 6, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

victorvhs017 commented Mar 6, 2026

Uh oh!

victorvhs017 commented Mar 6, 2026

Uh oh!

Uh oh!

linear bot commented Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

akhilmhdh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

akhilmhdh Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

victorvhs017 Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

akhilmhdh Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

akhilmhdh Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

akhilmhdh left a comment

Choose a reason for hiding this comment

Uh oh!

akhilmhdh Mar 7, 2026

Choose a reason for hiding this comment

Uh oh!

victorvhs017 Mar 9, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

akhilmhdh Mar 7, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

victorvhs017 commented Mar 4, 2026 •

edited

Loading

maidul98 commented Mar 4, 2026 •

edited

Loading

greptile-apps bot commented Mar 5, 2026 •

edited

Loading

linear bot commented Mar 6, 2026 •

edited

Loading