- Shipped
- 15 Agosti 2026, 01:20 UTC
- Author
- Kamo
- Commit
- 5220a3f
MediaService now requires START_MEETING to create a meeting and VIEW_MEETINGS to resolve one. Measured on production before writing this: 42 security roles across 14 organizations, three per org, and only the single "Administrator (Full Access)" role in each holds them — the other 28 roles carry a row with setting NULL. 33 of 69 members had START_MEETING applied. Shipping the gate alone would have taken meeting creation away from the other 36. So both rights are granted to every existing role. Roles are the right level: every member has at least one, so the grant reaches all of them and keeps reaching members added later. Departments, job titles and member profiles hold a row only where somebody set one and hold none for these two, so there is nothing to seed there and inserting rows would invent overrides nobody asked for. Deliberately one-shot, unlike **************** That runner enforces an invariant the write paths maintain forever, so re-running it is a no-op. "Every role grants START_MEETING" is a cutover state instead — the whole point of the gate is that an organization can now revoke it — and re-running would silently re-grant what an administrator had deliberately taken away. A small platform_data_migrations ledger makes it fire exactly once; the clusters still ahead of this one need the same thing. The gate fails the run unless afterwards every role grants both rights, no department, job title or member denies either, and no security-model template FORCE_NUKEs either. That last check queries by enum NAME, because that table stores the name while the four rights tables store the integer id — an id-shaped predicate against it matches nothing and reports success. MANAGE_MEETINGS is not seeded. Nothing in the platform manages a meeting, so it stays decorative; granting it would hand every role a right that gates nothing.