Dashboard sync
How the bore dashboard settings reach the bot — Postgres LISTEN/NOTIFY plus direct bot-table writes
The dashboard writes every module's settings into Postgres and two things happen:
- Dashboard tables the bot already owns —
prefix,aliases,fake_permissions,lockdown,warningsandembed_templates— are written directly. The bot's existing caches and commands pick them up unchanged. - Every other module is stored as one JSONB document per guild and
section in
guild_config. After each save the dashboard sends a cheappg_notify('bore_config_change', ...):
{ "table": "antinuke", "guild_id": "123456789012345678", "at": "2026-11-05T09:00:00Z" }Bot side (already installed)
bots/bore/base/bore.py ships the listener:
start_dashboard_listener()— holds one pooled connection onLISTEN bore_config_changeand reloads only the changed(guild, section)document throughreload_dashboard_config().refresh_dashboard_cache()— loads all ofguild_configon boot.bot.get_dashboard_config(guild_id, section)— returns the section's dict (or{}), for cogs to consult.
Cogs opt in one at a time: read bot.get_dashboard_config(ctx.guild.id, 'antinuke') instead of (or alongside) their own bot tables. If the
dashboard has never configured the section, the dict is empty — treat that
as "no override", never as all-off. If no listener is attached the notify
is a no-op and settings take effect on the bot's next restart, which also
re-reads guild_config via refresh_dashboard_cache().
Sections: antinuke, antiraid, automod, honeypot, logging, messages, autoroles, roles-panels, automatic-messages, booster-roles, ping-on-join, starboard, giveaways, levels, confessions, music, voicemaster, snipe, tags, fun, integrations.
Last updated October 20, 2018