73 lines
3.6 KiB
Markdown
73 lines
3.6 KiB
Markdown
# 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.
|