The default permission_definitions seed for acc_supporttool used the
pattern (0, 1, 1, 1, 1, 0, 1) across rank_1..rank_7 — apparently
shifted by two columns:
* rank_2 (VIP) and rank_3 (X) had ALLOWED. With acc_supporttool=1
the SecureLoginEvent path sends ModeratorInitMessageEvent on
login, which makes the React client surface the ModTools toolbar
button and let the user open room/user info windows. The actual
sanction endpoints (ModToolSanctionBanEvent, ModToolWarnEvent,
…) still gate on ACC_SUPPORTTOOL so a VIP cannot actually take
moderator action — but they can request user info, room info
and chatlogs they have no business reading.
* rank_6 (Super Mod) was DISALLOWED, which is obviously not what
the name says.
Corrected pattern: (0, 0, 0, 1, 1, 1, 1) — Support (4), Moderator
(5), Super Mod (6), Administrator (7). Matches the convention used
by the other staff-only acc_modtool_* keys.
Two changes:
- Default Database/FullDatabase.sql: fix the seed for fresh
installs.
- Database Updates/004_fix_acc_supporttool_rank.sql: idempotent
UPDATE to realign existing deployments.
Found by user report: a rank-2 (VIP) account on the live retro had
the ModTools button visible in the toolbar after login.
simoleo89