Repository navigation
Conversation
…P sync MemberService::synchronizeGroups skipped IGroup::Sponsors on the full IDP sync, so removing the group at the IDP never removed it locally and the member's Sponsor_Users access stayed too. The IDP payload is the source of truth: when sponsors or sponsors-external-users is missing from it, the local group is removed and that slug is stripped from the member's Sponsor_Users.Permissions on every sponsor. Rows left without any permission lose the membership; rows that still hold another slug are kept. The additive per-request sync is unchanged.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to Absent sponsor groups are removed during the designated authoritative IDP update; other sync paths remain additive. No actionable merge-blocking issue is established. Pre-merge checks |
|
|
📘 OpenAPI / Swagger preview ➡️ https://OpenStackweb.github.io/summit-api/openapi/pr-627/ This page is automatically updated on each push to this PR. |
There was a problem hiding this comment.
🟡 Changes recommended
The cleanup has a concurrent-grant consistency race and can hydrate entire sponsor membership collections.
2 open findings
What changed in this PR
Updates authoritative IDP synchronization to remove stale sponsor groups and permissions.
Changes:
- Removes missing sponsor groups during full synchronization.
- Cleans corresponding
Sponsor_Users.Permissionsentries and empty memberships. - Adds tests for full and additive synchronization behavior.
| File | Description |
|---|---|
app/Services/Model/Imp/MemberService.php |
Triggers sponsor-permission cleanup during full sync. |
app/Models/Foundation/Main/Member.php |
Removes permissions across sponsor memberships. |
tests/Unit/Services/MemberServiceSponsorGroupSyncTest.php |
Tests sponsor-group synchronization scenarios. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| SELECT SponsorID FROM Sponsor_Users | ||
| WHERE MemberID = :member_id | ||
| AND JSON_CONTAINS(COALESCE(Permissions, '[]'), JSON_QUOTE(:group_slug)) | ||
| FOR UPDATE |
| foreach ($this->sponsor_memberships->toArray() as $sponsor) { | ||
| if (in_array(intval($sponsor->getId()), $to_remove, true)) { | ||
| $sponsor->removeUser($this); |
…nsor_Users rows Reuse Member::removeSponsorPermission per sponsor membership, the same primitive the sponsor-users-api removal event uses, instead of a new raw SQL method that also deleted the memberships left without permissions. Group absence does not mean the access right is gone: the Sponsor_Users row lifecycle belongs to the access right events (AUTH_USER_REMOVED_FROM_SPONSOR_AND_SUMMIT). Stripping the slug is enough to hide the summits, since the sponsor summit strategy reads Permissions.
|
📘 OpenAPI / Swagger preview ➡️ https://OpenStackweb.github.io/summit-api/openapi/pr-627/ This page is automatically updated on each push to this PR. |
1 similar comment
|
📘 OpenAPI / Swagger preview ➡️ https://OpenStackweb.github.io/summit-api/openapi/pr-627/ This page is automatically updated on each push to this PR. |


ref: https://app.clickup.com/t/9014802374/86bcgcfre
Summary
Stale
sponsorsgroups were never removed in summit-api.MemberService::synchronizeGroupsskippedIGroup::Sponsorson the full IDP sync ("managed by SS side"), so removing the group at the IDP never removed it locally, and the member'sSponsor_Usersaccess stayed too. A leftover localsponsorsgroup sends the member throughSponsorMemberSummitStrategy, which hides the summits they get from admin access groups.The IDP payload is the source of truth: on the full sync (
allow_removals = true), whensponsorsorsponsors-external-usersis not in the payload, summit-api now removes the local group and strips that slug from the member'sSponsor_Users.Permissions. The summits then disappear fromSponsorMemberSummitStrategy, which readsPermissions.Changes
MemberService::synchronizeGroups:sponsorsis no longer in the removal skip list. When a sponsor group is removed,Member::removeSponsorPermission()runs for each of the member's sponsor memberships, the same primitive the sponsor-users-api removal event uses (SponsorUserSyncService::removeSponsorUserFromGroup).Sponsor_Usersrows are NOT deleted: their lifecycle belongs to the sponsor-users-api access right events (AUTH_USER_REMOVED_FROM_SPONSOR_AND_SUMMIT). A group missing at the IDP does not mean the access right is gone.ResourceServerContext::checkGroups) andSponsorUserSyncService::ensureSponsorGroupMembershipstay additive-only (allow_removals = false).Risk
A sponsor whose IDP profile does not carry the group yet (the MQ grant arrived first) loses the group and the permission slug on the next full sync, until the next sponsor-users-api event or additive sync re-adds it.
One-off cleanup of existing stale data
Report-only, run it and share the result before deleting anything:
Tests
New
tests/Unit/Services/MemberServiceSponsorGroupSyncTest.php(5 tests): full sync without the group removes the group and strips the slug (row stays); with the group keeps both; additive sync keeps both; a row with another slug keeps it; same forsponsors-external-users.tests/Unit/Services/SponsorUserPermissionTrackingTest.phpalready fails 2 tests (testRemoveSponsorUserFromGroupStillCleansUpWhenSponsorWasDeleted,testRemoveSponsorUserFromGroupRemovesGlobalGroupWhenLastSponsor) onmainwithout this change; they coverremoveSponsorUserFromGroup, which this PR does not touch.Summary by CodeRabbit