Clean up pre-existing direct user memberships on non-Group teams - #33116
Clean up pre-existing direct user memberships on non-Group teams#33116sonika-shah wants to merge 1 commit into
Conversation
Users may only be direct members of Group teams (API enforcement added in #32208; team dropdowns fixed in #32911). Memberships created before the rule leave users stuck on Department/Division/BusinessUnit teams whose team edits now fail. This 2.1.0 post-data migration removes those HAS relationships (both MySQL and Postgres) so the affected users fall back to Organization (the default). Group and the special Organization root are left untouched. Idempotent — re-runs match nothing.
❌ PR checklist incompleteThis PR cannot be merged until the following are addressed on its linked issue:
The fields live on the linked issue in the Shipping project (open the issue → right sidebar → Projects). After you set them, re-run this check (or push a commit) — issue/project changes do not re-trigger it automatically. Maintainers can bypass this check by adding the |
Code Review ✅ ApprovedOne-time data migration that removes pre-existing direct user memberships from non-Group teams ( OptionsDisplay: compact → Counting what did not apply, without listing it. Comment with these commands to change the behavior for this request:
Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source |
✅ Playwright Results — workflow succeededValidated commit ✅ 4487 passed · ❌ 0 failed · 🟡 7 flaky · ⏭️ 1 skipped · 🧰 0 lifecycle flaky PerformanceBlocking targets: ✅ met · Optimization targets: 🟡 in progress Shard-job maxima below are not the full workflow wall time; the linked run includes build, fixture, planning, and reporting. 🕒 Full workflow signal wall (to summary) 1h 6m 13s ⏱️ Max setup 4m 19s · max shard execution 20m 25s · max shard-job elapsed before upload 23m 22s · reporting 20s 🌐 218.34 requests/attempt · 2.31 app boots/UI scenario · 35.27% common-shard skew Optimization targets still in progress:
🟡 7 flaky test(s) (passed on retry)
How to debug locally# Download playwright-test-results-<shard> artifact and unzip
npx playwright show-trace path/to/trace.zip # view trace |
Data-cleanup follow-up to #32208 (API enforcement) and #32911 (team dropdowns).
Users may only be direct members of
Groupteams. That rule is now enforced on the API (#32208) and the UI team selector (#32911), but instances upgraded from before the rule can still have users attached directly toDepartment/Division/BusinessUnitteams. Those stale memberships are now invalid: the team's Add User action is hidden and editing such a user's teams fails validation, so there is no in-product way to remove them.This adds a one-time data migration that removes those pre-existing direct memberships so the affected users fall back to
Organization(the default team).Groupteams and the specialOrganizationroot are left untouched.Change
A 2.1.0 post-data migration (MySQL + Postgres) deletes the
HASrelationships (relation = 10) between a user and anyBusinessUnit/Division/Departmentteam:It is idempotent — a second run matches nothing.
Search index
Deleting the relationship updates the user's
teamson read immediately, but the user's search document still lists the old team until it is reindexed. A standard post-upgrade users reindex refreshes Explore; no inline reindex is included here.Testing
Validated on throwaway MySQL 8 and Postgres 15 against the real
team_entity(generatedteamType/idcolumns) andentity_relationshipschema, with a seeded mix of memberships:Department/Division/BusinessUnitGroupandOrganizationuser membershipsType of change
Checklist