- Shipped
- 14 ஆகஸ்ட், 2026 அன்று 11:12 PM UTC
- Author
- Kamo
- Commit
- 30750e9
Ids 74/75/76 no longer resolve. RoleRightsSyncService would sweep them on some future SecurityService boot anyway — silently, at an unpredictable moment, with no record of how many rows or which orgs. Doing it here makes the removal deliberate, counted and logged in the run that ships the enum change. TWO ENCODINGS, and getting this wrong is silent. The four rights tables store the integer id via RoleRightTypeIdConverter; **************** stores the enum NAME (@Enumerated(EnumType.STRING), length 64). A single DELETE ... WHERE right_type IN (74,75,76) would match nothing on the template table and report success, leaving template rows for rights that no longer resolve being read into the force-rule map on every recalculation. Split accordingly. Non-fatal per table: these rows are inert by definition, so aborting the whole initializer — and skipping every runner after it — would be far worse than leaving three dead ids for one more deploy. No seeding and no verification gate, unlike the hierarchy backfill: this cannot remove access because nothing ever read these rights.