Roadmap
The project's current maturity and planned work. Status: 2026-07-17.
Maturity summary
| Area | Status |
|---|---|
| Feature scope | 🟢 Ticket lifecycle, SLA, reports, tasks, vault, MFA |
| Multilingual | 🟢 TR/EN (UI + API messages + email/SMS templates) |
| Setup / deploy | 🟢 Docker Compose, Coolify, and Nginx documented |
| Migration | 🟢 Versioned; verifiable against a real PostgreSQL |
| Backend tests | 🟢 235 unit/route/worker tests |
| Frontend tests | 🟢 26 unit tests + 6 Playwright smoke/axe scenarios |
| Integration | 🟢 Real PostgreSQL + Redis testing |
| API documentation | 🟢 Request/response contracts on critical routes (OpenAPI) |
| Code quality | 🟢 Backend + frontend lint clean, typed |
Planned features
"My Tickets" — unified tracking for the requester
Today, access to a ticket is provided through a link specific to that ticket (or a ticket number + email); there is no flow for a user who has opened multiple tickets to see them all in one place.
Plan: The user enters their email; via a short-lived verification link sent to their
inbox, they see and track all tickets belonging to that email in a single list. No password —
email ownership is verified. It uses the existing infrastructure (short-lived tokens, Redis,
the BullMQ email queue, rate limiting) and requires no new table. A new bilingual notification
template (my_tickets_link) and a public page (MyTicketsPage) are added.
Docker Hub images and one-command setup
Today docker compose builds the images locally. The goal: publish the backend and
frontend images to Docker Hub via CI and provide a compose that can be docker pulled by
version tag (:1.0.0, :latest) and run without a build — so the system can be downloaded
and installed without cloning the source.
- Multi-architecture (amd64/arm64) image build + push on
main/tag push via GitHub Actions. - A
docker-compose.hub.ymlthat uses the published images (image:instead of build). - Version tagging:
:MAJOR.MINOR.PATCH,:MAJOR.MINOR,:latest.
Version tracking and automatic changelog
- SemVer git tags + GitHub Releases.
- Automatic CHANGELOG generation from conventional commits (instead of manual upkeep).
- Image tags kept in sync with the version.
S3-compatible storage (AWS S3 / MinIO)
Attachments and logos are currently written to the local disk (UPLOAD_DIR). The goal: put
the upload layer behind S3-compatible object storage (AWS S3, MinIO, R2) — for horizontal
scale, redundancy, and out-of-container persistence.
- A pluggable storage adapter behind
storage.service.ts(local disk | S3). - Selection via env (
STORAGE_DRIVER=local|s3,S3_ENDPOINT,S3_BUCKET, keys). - Download authorization stays in the backend (signed/proxied access); no directly public bucket.
Operations
- Alongside taking backups, run restore drills periodically as well.
- Monitor the retention job (
db:retention:check) and apply it during an approved maintenance window. - For internet-facing deployments, treat access control and
ENABLE_API_DOCS=falseas mandatory.
Product choices (deliberate)
- There is no persistent user account / password on the public portal; access is link-based.
- No separate component library is used; the UI is kept in-project with Tailwind.
- On-site support appointments are not assigned to staff; parallel appointments are not counted as conflicts.
- Staff passwords are at least 12 characters.
Contribution standard
For new routes and screens, maintain the same typed-contract, scope/RBAC, and regression-test standard. For reporting security vulnerabilities see Security, and for the contribution guide see Contributing.