Broccolini Bot – Roadmap & Proposal

Short proposal and possible next steps for the Broccolini Bot ticketing system. Discord + Gmail + MongoDB remain the core; any extension is additive.

Current State

Email → Discord: Gmail poll creates ticket channels/threads; replies sync back to Gmail.
Discord-first: Panels, slash commands, buttons, modals, context menus for full ticket lifecycle (claim, close, escalate, tag, priority, transfer, move, saved responses).
MongoDB: Single data store for tickets, transcripts, tags, close requests, guild settings, and (optional) account info.
Automation: Auto-close, reminders, auto-unclaim, claim timeout; all configurable via .env.
Security: HTML escaping in outbound emails; test env workflow; optional healthcheck host binding.

No external ticketing API (e.g. Zammad) is used; the bot is self-contained.

Possible Next Steps

1. Read-only API layer

Expose ticket and metadata via a read-only HTTP API (e.g. alongside the bot or a small separate service).
Endpoints: list/filter tickets, ticket by ID, “my tickets” by Discord ID, tags, guild settings.
Enables dashboards, mobile tools, or a Support Cockpit (bOSScord-style overlay) without changing Discord or bot behavior.
Optional: use something like Directus on top of MongoDB for instant REST/GraphQL and admin UI.

2. Ticket routing & queues

Derive a queue (or routing bucket) per ticket from game detection (GAME_LIST), subject/body keywords, and existing tags.
Store queue on the ticket document; show it in Discord (e.g. in embeds or channel name) and in any future API/UI.
Enables “Network”, “Billing”, “Mod Help”, “Game X” views without changing how staff use Discord.

3. Incident & problem tracking

Incident: one-off “something broke” ticket.
Problem: recurring issue; link multiple incidents, track root cause, workaround, and fix status.
Optional new commands or buttons to “Link to problem” / “Create problem from ticket” and optional API fields.

4. Knowledge base & PM links

Internal KB (e.g. Wiki.js): link from problems/tickets to articles; optional /kb search in Discord.
PM tool (Plane, Focalboard, Taiga): “Create PM task from ticket” and link ticket ↔ task.
Broccolini Bot stays the source of truth for tickets; KB and PM are linked data.

5. bOSScord / Support Cockpit

Web (later desktop) client that reads from the API and MongoDB.
Richer views: queues, SLA-style status, “who’s viewing this ticket”, virtual display names, links to KB and PM.
All writes and communication remain in Discord; the client is view/routing only.

6. GitHub / GitLab (optional)

From a problem or PM task: create issue/PR with context.
Webhooks to update problem/task when issues close or PRs merge.

Principles

Discord + Broccolini Bot are canonical. New features augment, they don’t replace, the current flow.
API-first for new UIs. Any dashboard or cockpit consumes a read-only (or narrowly write) API; no direct DB access from frontends.
Config and secrets stay in .env. New services get their own env or reuse existing vars where it makes sense.
MongoDB remains the primary store. New collections or fields as needed; no second database unless justified.

No Deadlines

This document is a proposal and idea list. Work can proceed in small steps: e.g. add a read-only ticket API, then add queue derivation, then plug in a simple dashboard or bOSScord.

For a fuller platform vision (bOSScord, queues, incidents/problems, KB, PM), see the parent repo’s bOSScord proposal if present.

3.6 KiB Raw Blame History Unescape Escape