backend/src/ee/services/permission/project-permission.ts
Test actions committed to production backend

importSecret and duplicateSecret are added directly to the ProjectPermissionSecretActions enum and the ActionAllowedConditions map. The PR description acknowledges these are temporary test actions, but once merged to main, external API users — including Terraform/Crossplane providers or any SDK consumers — could start using these actions in their permission payloads. Removing them later would be a breaking API change that breaks those integrations.

These test actions must be removed from the backend before merging, or the feature needs to be hidden behind a feature flag.

frontend/src/pages/project/RoleDetailsBySlugPage/components/ProjectRoleModifySection.utils.tsx
computeAllowedConditions intersection bug with 3+ restricted actions

The reduce uses acc.length === 0 as an initializer sentinel. This breaks when there are 3+ restricted actions and one intermediate intersection produces an empty array — the empty acc in the next iteration is misinterpreted as "not yet initialized" and replaced with the next action's full allowed list instead of returning [].

Example: actions A allows [environment], B allows [secretPath] (intersection = []), C allows [environment, secretPath]. The result would incorrectly be [environment, secretPath] instead of [].

// Current (buggy):
return actionsWithRestrictions.reduce<string[]>((acc, action) => {
  const allowed = actionConditionsMap[action];
  if (!allowed) return acc;
  if (acc.length === 0) return allowed;  // ← incorrectly fires after an empty intersection too
  return acc.filter((cond) => allowed.includes(cond));
}, []);

// Fix: use a separate "initialized" flag or a null sentinel
let result: string[] | null = null;
for (const action of actionsWithRestrictions) {
  const allowed = actionConditionsMap[action];
  if (!allowed) continue;
  result = result === null ? allowed : result.filter((cond) => allowed.includes(cond));
}
return result ?? allConditions;

While only two test actions exist today, this function is designed to be general-purpose and will break as soon as a third restricted action is introduced.

frontend/src/pages/project/RoleDetailsBySlugPage/components/RolePermissionsSection.tsx
"Discard" button now resets to empty defaults instead of original data

The previous implementation used values: role ? { ...role, permissions: rolePermission2Form(role.permissions) } : undefined in useForm. In that mode, reset() without arguments restores to the currently tracked values — i.e., the role's loaded permissions.

The new implementation moves to defaultValues + a useEffect calling reset(roleData). In this pattern, reset() without arguments resets to the original defaultValues passed to useForm (which is undefined/empty since none were specified), not to the last reset(roleData) call.

The net effect is: clicking "Discard" wipes the entire form instead of restoring the saved permissions. This same regression exists in ProjectTemplateEditRoleForm.tsx and MembershipProjectAdditionalPrivilegeModifySection.tsx.

The fix is to reset to the loaded data explicitly:

onClick={() => {
  if (role) reset({ ...role, permissions: rolePermission2Form(role.permissions) });
}}

frontend/src/pages/project/RoleDetailsBySlugPage/components/GeneralPermissionPolicies.tsx
MultiValueWithTooltip renders TooltipContent unconditionally

The tooltip wrapper is rendered for every selected action chip even when data.description is empty/undefined. While TooltipContent is only visible when the tooltip triggers, mounting empty tooltip content for every chip is wasteful and may cause accessibility noise (empty tooltip text).

const MultiValueWithTooltip = <T extends ActionOption>(props: MultiValueProps<T>) => {
  const { data } = props;
  return (
    <Tooltip>
      <TooltipTrigger asChild>
        <div>
          <components.MultiValue {...props} />
        </div>
      </TooltipTrigger>
-     {data.description && <TooltipContent>{data.description}</TooltipContent>}
+     {data.description ? <TooltipContent>{data.description}</TooltipContent> : null}
    </Tooltip>
  );
};

Also note: If data.description is absent, the tooltip fires but has no content, which may produce a flickering empty popup on hover.

frontend/src/pages/organization/SettingsPage/components/ProjectTemplatesTab/components/EditProjectTemplateSection/components/ProjectTemplateEditRoleForm.tsx
"Cancel" / "Discard" now resets to empty defaults instead of navigating away

The old "Cancel" button called onClick={onGoBack} — it navigated the user back without touching the form. The new code calls onClick={() => reset()}. Because the form is initialized with explicit defaultValues (name: "", slug: "", permissions: {}), reset() clears the form back to empty values instead of the previously loaded role data.

This means clicking "Discard" on an existing role template completely wipes the displayed permissions rather than discarding the unsaved edits.

The fix should either restore onGoBack or reset to the currently loaded role values:

onClick={() => {
  if (role) reset({ ...role, permissions: rolePermission2Form(role.permissions) });
  else onGoBack();
}}

frontend/src/pages/project/MemberDetailsByIDPage/components/MemberProjectAdditionalPrivilegeSection/MembershipProjectAdditionalPrivilegeModifySection.tsx
"Discard" resets to empty defaults, not to loaded privilege data

Same pattern as the other forms. The form is initialized with:

defaultValues: {
  slug: "",
  temporaryAccess: { isTemporary: false },
  permissions: {}
}

Calling reset() on the "Discard" button click resets to these empty defaults, not to the loaded privilegeDetails. When editing an existing privilege, clicking "Discard" would appear to wipe all fields — the useEffect would re-fire only when privilegeDetails changes, not on discard.

Fix:

onClick={() => {
  if (privilegeDetails) {
    reset({
      ...privilegeDetails,
      permissions: rolePermission2Form(privilegeDetails.permissions),
      temporaryAccess: privilegeDetails.isTemporary ? { ... } : { isTemporary: false }
    });
  }
}}

backend/src/ee/services/permission/project-permission.ts
Test actions committed to production backend

importSecret and duplicateSecret are added directly to the ProjectPermissionSecretActions enum and the ActionAllowedConditions map. The PR description acknowledges these are temporary test actions, but once merged to main, external API users — including Terraform/Crossplane providers or any SDK consumers — could start using these actions in their permission payloads. Removing them later would be a breaking API change that breaks those integrations.

These test actions must be removed from the backend before merging, or the feature needs to be hidden behind a feature flag.

frontend/src/pages/project/RoleDetailsBySlugPage/components/ProjectRoleModifySection.utils.tsx
computeAllowedConditions intersection bug with 3+ restricted actions

The reduce uses acc.length === 0 as an initializer sentinel. This breaks when there are 3+ restricted actions and one intermediate intersection produces an empty array — the empty acc in the next iteration is misinterpreted as "not yet initialized" and replaced with the next action's full allowed list instead of returning [].

Example: actions A allows [environment], B allows [secretPath] (intersection = []), C allows [environment, secretPath]. The result would incorrectly be [environment, secretPath] instead of [].

// Current (buggy):
return actionsWithRestrictions.reduce<string[]>((acc, action) => {
  const allowed = actionConditionsMap[action];
  if (!allowed) return acc;
  if (acc.length === 0) return allowed;  // ← incorrectly fires after an empty intersection too
  return acc.filter((cond) => allowed.includes(cond));
}, []);

// Fix: use a separate "initialized" flag or a null sentinel
let result: string[] | null = null;
for (const action of actionsWithRestrictions) {
  const allowed = actionConditionsMap[action];
  if (!allowed) continue;
  result = result === null ? allowed : result.filter((cond) => allowed.includes(cond));
}
return result ?? allConditions;

While only two test actions exist today, this function is designed to be general-purpose and will break as soon as a third restricted action is introduced.

frontend/src/pages/project/RoleDetailsBySlugPage/components/RolePermissionsSection.tsx
"Discard" button now resets to empty defaults instead of original data

The previous implementation used values: role ? { ...role, permissions: rolePermission2Form(role.permissions) } : undefined in useForm. In that mode, reset() without arguments restores to the currently tracked values — i.e., the role's loaded permissions.

The new implementation moves to defaultValues + a useEffect calling reset(roleData). In this pattern, reset() without arguments resets to the original defaultValues passed to useForm (which is undefined/empty since none were specified), not to the last reset(roleData) call.

The net effect is: clicking "Discard" wipes the entire form instead of restoring the saved permissions. This same regression exists in ProjectTemplateEditRoleForm.tsx and MembershipProjectAdditionalPrivilegeModifySection.tsx.

The fix is to reset to the loaded data explicitly:

onClick={() => {
  if (role) reset({ ...role, permissions: rolePermission2Form(role.permissions) });
}}

frontend/src/pages/project/RoleDetailsBySlugPage/components/GeneralPermissionPolicies.tsx
MultiValueWithTooltip renders TooltipContent unconditionally

The tooltip wrapper is rendered for every selected action chip even when data.description is empty/undefined. While TooltipContent is only visible when the tooltip triggers, mounting empty tooltip content for every chip is wasteful and may cause accessibility noise (empty tooltip text).

const MultiValueWithTooltip = <T extends ActionOption>(props: MultiValueProps<T>) => {
  const { data } = props;
  return (
    <Tooltip>
      <TooltipTrigger asChild>
        <div>
          <components.MultiValue {...props} />
        </div>
      </TooltipTrigger>
-     {data.description && <TooltipContent>{data.description}</TooltipContent>}
+     {data.description ? <TooltipContent>{data.description}</TooltipContent> : null}
    </Tooltip>
  );
};

Also note: If data.description is absent, the tooltip fires but has no content, which may produce a flickering empty popup on hover.

frontend/src/pages/organization/SettingsPage/components/ProjectTemplatesTab/components/EditProjectTemplateSection/components/ProjectTemplateEditRoleForm.tsx
"Cancel" / "Discard" now resets to empty defaults instead of navigating away

The old "Cancel" button called onClick={onGoBack} — it navigated the user back without touching the form. The new code calls onClick={() => reset()}. Because the form is initialized with explicit defaultValues (name: "", slug: "", permissions: {}), reset() clears the form back to empty values instead of the previously loaded role data.

This means clicking "Discard" on an existing role template completely wipes the displayed permissions rather than discarding the unsaved edits.

The fix should either restore onGoBack or reset to the currently loaded role values:

onClick={() => {
  if (role) reset({ ...role, permissions: rolePermission2Form(role.permissions) });
  else onGoBack();
}}

frontend/src/pages/project/MemberDetailsByIDPage/components/MemberProjectAdditionalPrivilegeSection/MembershipProjectAdditionalPrivilegeModifySection.tsx
"Discard" resets to empty defaults, not to loaded privilege data

Same pattern as the other forms. The form is initialized with:

defaultValues: {
  slug: "",
  temporaryAccess: { isTemporary: false },
  permissions: {}
}

Calling reset() on the "Discard" button click resets to these empty defaults, not to the loaded privilegeDetails. When editing an existing privilege, clicking "Discard" would appear to wipe all fields — the useEffect would re-fire only when privilegeDetails changes, not on discard.

Fix:

onClick={() => {
  if (privilegeDetails) {
    reset({
      ...privilegeDetails,
      permissions: rolePermission2Form(privilegeDetails.permissions),
      temporaryAccess: privilegeDetails.isTemporary ? { ... } : { isTemporary: false }
    });
  }
}}