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:

  1. Dashboard tables the bot already owns — prefix, aliases, fake_permissions, lockdown, warnings and embed_templates — are written directly. The bot's existing caches and commands pick them up unchanged.
  2. Every other module is stored as one JSONB document per guild and section in guild_config. After each save the dashboard sends a cheap pg_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 on LISTEN bore_config_change and reloads only the changed (guild, section) document through reload_dashboard_config().
  • refresh_dashboard_cache() — loads all of guild_config on 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