[AmanGIT07]

Summary

Removing a member from an organization now also removes their access on disabled projects and groups. Stacked on #2048.

Changes

• cascadeRemovePrincipal lists the organization's projects and groups with IncludeDisabled: true. The member's policies on disabled projects and groups, their policies on custom resources in disabled projects, and their member relation on disabled groups are removed with the rest.
• The membership tests expect the new list filters.

Technical Details

• Enabling a project or group again does not give a removed member their access back.
• The deleter already lists projects and groups with IncludeDisabled: true.
• User delete does not change. It already ends by removing all of the user's policies and every relation they are in, and TestUserDeleteLeavesNoAccessAndNoLivePolicy already covers a disabled project and group.
• Service users do not reach this removal. The endpoint refuses them, and service user delete removes their policies and relations itself.

Test Plan

• go test ./core/membership/ passes. The removal and user delete tests expect IncludeDisabled: true on both lists. Without the flag, 18 cases fail.
• e2e TestOrgMemberRemovalLeavesNoAccessOnDisabledProjectsAndGroups: a member holds a role on a project, a group, and an order in that project, and the group holds viewer on a second project. The project and group are disabled, the member is removed, and both are enabled again. No live policy is left, the member has no get on any of them, and the group no longer gives access to the second project. Without the fix, all three checks fail.
• go test ./test/e2e/... passes.
• make test passes.
• golangci-lint run reports no issues.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
frontier	Ready	Preview	Nov 11, 2026 3:23pm UTC

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

Run configuration

• Source mode: Auto
• Repository: raystack/frontier
• Branch: fix/revoke-pats-on-member-removal
• File: .coderabbit.yaml
• Commit: ddfe0f4
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: 30ccffd5-e6fb-4977-9027-ad08ea6e3ef1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

• X
• Mastodon
• Reddit
• LinkedIn

[coveralls]

Coverage Report for CI Build 43047826767

Coverage remained the same at 56.097%

Details

• Coverage remained the same as the base build.
• Patch coverage: 2 of 2 lines across 1 file are fully covered (100%).
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	42232
Covered Lines:	23691
Line Coverage:	56.1%
Coverage Strength:	21.71 hits per line

---

💛 - Coveralls

[rohilsurana]

The fix looks right. Both list calls now include disabled projects and groups, and the postgres repos honor the flag. The project list also feeds the custom resource cleanup, so orders in a disabled project get cleaned up too.

I ran the new e2e test locally. It passes with the fix. With the old org.go all three sub tests fail. Unit tests and lint pass.

Two things for later, not for this PR:

• Removing someone straight from a disabled project or group still fails with "not found". RemoveProjectMember, SetGroupMemberRole and RemoveGroupMember call Get, and GetByID skips disabled rows. Worth a follow up issue.
• Members removed before this fix may still have live policies and group relations on disabled projects and groups. Do we want a one time cleanup, or is it fine to leave them?

[rohilsurana]

Nit: this covers the API removal for a user. The PR says user delete gets the same fix through RemoveOrganizationMemberOnDelete. A small case for that path, or for a PAT, would back that claim. Fine as a follow up.

[AmanGIT07]

User delete does not change in this PR. I reworded the description so it no longer reads that way. User delete already ends by removing all of the user's policies and every relation they are in (core/user/service.go:167), and TestUserDeleteLeavesNoAccessAndNoLivePolicy already covers a disabled project and group.

A PAT scoped to a disabled project is covered by #2048. Its revoke removes every policy the PAT holds: listing policies by principal does not look at the project's state (internal/store/postgres/policy_repository.go:104), and neither does deleting them (core/policy/service.go:81).

[AmanGIT07]

On the two things for later:

1. Removing someone straight from a disabled project or group: agreed. SetProjectMemberRole, RemoveProjectMember, SetGroupMemberRole and RemoveGroupMember all load the project or group first, and GetByID skips disabled rows. Follow-up issue: Removing a member from a disabled project or group fails with not found #2051.
2. Members removed before this fix: removing them again won't clean these up, because the member check stops before the cleanup runs. Whether a one-time cleanup is needed depends on live data, which has to be checked first. We will decide after that, not now.