Running the published qbit-authentik 0.1.0-RC.8 with twoPersonApproval=true, the native Create Group action persisted a new group carrying authentik.users.read immediately, without queuing an authentik_approval_request. Edit Group already routed the same grant to a second person. Forge's live identity browser check now detects this, and Forge has been running a patched build to stay safe.
What the fix does
AuthentikAdmin.planCreateGroup now applies the existing identity-permission expansion and second-person condition (the same twoPersonApproval && !approved && addsIdentityPermission(...) gate and message as Edit Group). A creation whose permissions expand to any authentik.* permission becomes NEEDS_APPROVAL: nothing is written until a distinct operator holding authentik.approve approves it. Stored approvals keep the native requester/approver and live revalidation checks (approve re-plans against live data under the approver's own permissions). No pom version change; CHANGELOG [Unreleased] entry added.
Test evidence
New AuthentikAdminTest.creatingGroupWithIdentityPermissionsNeedsASecondPerson: queued result with no writes, exactly one approval request, self-approval refused (still no writes), second operator with approve + groups.manage succeeds, persisted group carries exactly authentik.users.read, request status APPROVED, repeat approval refused.
./mvnw verify -DskipITs on this branch: 464 unit tests, 0 failures/errors/skips, JaCoCo coverage checks met, BUILD SUCCESS (AuthentikAdminTest: 39 tests). Contract ITs not run locally.
Checkstyle (repository checkstyle/config.xml, run explicitly since the pom does not bind it): 176 violations, all pre-existing; none in the changed lines.
Forge's own evidence against RC.8: the regression fails on original RC.8 and passes patched; full patched unit suite and the 55-test Docker integration suite passed there.
Carried locally by GG Forge as qbit-authentik-rc8-create-approval.patch since RC.8; merging this lets Forge drop the patched build at the next RC.
## What GG Forge observed
Running the published `qbit-authentik` 0.1.0-RC.8 with `twoPersonApproval=true`, the native **Create Group** action persisted a new group carrying `authentik.users.read` immediately, without queuing an `authentik_approval_request`. **Edit Group** already routed the same grant to a second person. Forge's live identity browser check now detects this, and Forge has been running a patched build to stay safe.
## What the fix does
`AuthentikAdmin.planCreateGroup` now applies the existing identity-permission expansion and second-person condition (the same `twoPersonApproval && !approved && addsIdentityPermission(...)` gate and message as Edit Group). A creation whose permissions expand to any `authentik.*` permission becomes `NEEDS_APPROVAL`: nothing is written until a distinct operator holding `authentik.approve` approves it. Stored approvals keep the native requester/approver and live revalidation checks (`approve` re-plans against live data under the approver's own permissions). No pom version change; CHANGELOG `[Unreleased]` entry added.
## Test evidence
- New `AuthentikAdminTest.creatingGroupWithIdentityPermissionsNeedsASecondPerson`: queued result with no writes, exactly one approval request, self-approval refused (still no writes), second operator with `approve` + `groups.manage` succeeds, persisted group carries exactly `authentik.users.read`, request status `APPROVED`, repeat approval refused.
- `./mvnw verify -DskipITs` on this branch: 464 unit tests, 0 failures/errors/skips, JaCoCo coverage checks met, BUILD SUCCESS (AuthentikAdminTest: 39 tests). Contract ITs not run locally.
- Checkstyle (repository `checkstyle/config.xml`, run explicitly since the pom does not bind it): 176 violations, all pre-existing; none in the changed lines.
- Forge's own evidence against RC.8: the regression fails on original RC.8 and passes patched; full patched unit suite and the 55-test Docker integration suite passed there.
Carried locally by GG Forge as `qbit-authentik-rc8-create-approval.patch` since RC.8; merging this lets Forge drop the patched build at the next RC.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
With twoPersonApproval=true, the native Create Group action persisted a
new group carrying authentik.* permissions (for example
authentik.users.read) immediately, while Edit Group queued an
authentik_approval_request for a second person. Apply the same
identity-permission expansion and second-person condition at creation
time: the plan becomes NEEDS_APPROVAL and nothing is written until a
distinct operator holding authentik.approve approves it; the stored
request keeps the native requester/approver and live revalidation
checks.
Regression test: creating a group with authentik.users.read queues one
approval request and writes nothing, self-approval is refused, a second
operator with approve + groups.manage completes the creation, the
persisted group carries exactly the requested permission, the request is
APPROVED, and a repeat approval is refused.
Carried locally by GG Forge as qbit-authentik-rc8-create-approval.patch
since 0.1.0-RC.8.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: James Maes <james@kof22.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What GG Forge observed
Running the published
qbit-authentik0.1.0-RC.8 withtwoPersonApproval=true, the native Create Group action persisted a new group carryingauthentik.users.readimmediately, without queuing anauthentik_approval_request. Edit Group already routed the same grant to a second person. Forge's live identity browser check now detects this, and Forge has been running a patched build to stay safe.What the fix does
AuthentikAdmin.planCreateGroupnow applies the existing identity-permission expansion and second-person condition (the sametwoPersonApproval && !approved && addsIdentityPermission(...)gate and message as Edit Group). A creation whose permissions expand to anyauthentik.*permission becomesNEEDS_APPROVAL: nothing is written until a distinct operator holdingauthentik.approveapproves it. Stored approvals keep the native requester/approver and live revalidation checks (approvere-plans against live data under the approver's own permissions). No pom version change; CHANGELOG[Unreleased]entry added.Test evidence
AuthentikAdminTest.creatingGroupWithIdentityPermissionsNeedsASecondPerson: queued result with no writes, exactly one approval request, self-approval refused (still no writes), second operator withapprove+groups.managesucceeds, persisted group carries exactlyauthentik.users.read, request statusAPPROVED, repeat approval refused../mvnw verify -DskipITson this branch: 464 unit tests, 0 failures/errors/skips, JaCoCo coverage checks met, BUILD SUCCESS (AuthentikAdminTest: 39 tests). Contract ITs not run locally.checkstyle/config.xml, run explicitly since the pom does not bind it): 176 violations, all pre-existing; none in the changed lines.Carried locally by GG Forge as
qbit-authentik-rc8-create-approval.patchsince RC.8; merging this lets Forge drop the patched build at the next RC.🤖 Generated with Claude Code