Skip to main content

Tickessa 0.8.0

Published on 3 September 2026.

Version 0.8.0 adds safe quarantine, versioned knowledge, a separate help portal, form profiles and controlled AI foundations to ticket/email management. Public and paid AI features start disabled after updating.

Spam and quarantine

Provider spam headers, optional spam-folder retrieval, rules, sender checks and unsafe attachments are evaluated before AI. Held messages appear under Settings → Quarantine without AI calls or automatic replies. Only administrators may release them; original signals and decisions remain recorded. See Spam, quarantine and trash.

Separate help portal

Each project has a prepared stable /hilfe/{project} path. A separate frontend/API has no access to internal sessions, tickets or administration. Project portal, FAQ, contact, embeds, public AI and indexing have independent approvals and start disabled. See Help portal and forms.

Form profiles and topics

Administrators edit default forms, required fields, privacy links, origins and public topics. Public labels remain separate from internal category, priority and assignment. Stable versioned topic keys preserve historical selections.

Approved submissions create exactly one web ticket and incoming message. Short-lived tokens, minimum completion time, honeypots, rate/size limits and idempotency protect intake. Attachments and confirmation emails remain unapproved.

Direct links, isolated embeds, custom browser interfaces and server integrations share server configuration and ticket creation. Browsers receive no permanent key. Server secrets are issued once and belong only in the integrating application's protected configuration.

Versioned knowledge

Articles separate stable identity, current draft and published version. Every edit creates an unreviewed version. An administrator approves and then separately publishes; drafts do not replace online versions automatically.

Project, audience, origin, path, category, topic, product versions, validity, review date, order, featured placement, public text, internal notes, sources and internal references are documented separately. Publicly usable text must contain no confidential case data; internal notes are never served publicly. See the complete article guide.

Reviewed AI reply drafts can yield anonymised unpublished candidates. Conversion initially creates only an internal draft with pending review. Original articles and snippets remain in local MariaDB; search indexes and future embeddings can be rebuilt. See Candidates, snippets and search.

Public FAQ and article pages

Enabled portals show approved, published project articles through search, categories and stable pages. Internal notes, sources, tickets, AI runs and reviewer details are excluded. Unreviewed drafts do not change published versions.

Privacy-conscious self-help statistics

Separately approved project statistics count unsuccessful searches, form topics, article views, voluntary yes/no feedback and subsequent contacts without cookies, stored IPs/user agents or cross-project profiles. Raw events are aggregated into session-free daily values and deleted after short retention.

After confirmation, flagged articles can receive a budgeted internal AI revision suggestion using only the published article and aggregate counts. Results remain unpublished and follow normal human review. See Self-help statistics.

Public AI with mandatory sources

A separately approved page answers individual questions only from public article versions and links every factual source. Missing knowledge, low confidence, sensitive data or manipulation leads to safe refusal with personal contact still visible.

Only explicit visitor confirmation copies questions/results through short-lived local browser storage into an editable form. There is no automatic ticket or email creation. Provider/task/project/installation budgets and public rate limits bound costs and abuse. It remains disabled after updating. See Public AI help.

Your own AI connection

Administrators can store an encrypted OpenAI key and test it; the complete key is never returned to the browser. Other prepared provider profiles cannot be enabled without a validated adapter. Stored credentials activate neither processing nor sending.

Models, policies, budgets and fallback

Models are assigned per task. Installation, project and task have separate daily/monthly budgets and warnings. Timeouts, retries and per-ticket limits bound cost and errors; emergency stops leave manual work usable. Fallback starts disabled and needs an approved technical error class and explicit data-recipient approval. See Providers, tasks and budgets.

Tickessa Local AI

An installable versioned service offers local text models and embeddings through the common provider interface. Tickessa accepts private HTTPS only and validates certificates, pairing secret, protocol, service identity, LAN/VPN and direct/forwarded routing. Local only blocks cloud models/fallbacks; Hybrid requires explicit data-category approval.

Vector indexes contain IDs, checksums and rebuildable vectors; MariaDB articles remain authoritative. Tests cover authentication, offline fixtures, content-free indexes, installation, updates and removal. Model/hardware recommendations await reproducible real benchmarks. See Local AI.

Input and output protection

Fixed instructions, untrusted customer text and approved knowledge stay distinct. Input is cleaned and bounded; secrets and disallowed data categories block calls. Links are never opened and providers receive no tools. Only strictly validated structured output becomes a suggestion.

Ticket AI assistance

Classification, priority, summary, knowledge search and reply drafts are reviewable suggestions. Adoption and sending remain separate human actions. Confidence thresholds prevent direct application of weak category/priority suggestions. Provider, guard or budget failures preserve manual work. See Ticket AI assistance.

Reply profiles and salutations

Installation/project/category profiles control tone, formal/informal address, length, technical depth, greeting, closing, team identity, signature and wording. Safety and supported facts take precedence. Gendered salutations require explicit confirmed ticket data and are never guessed from names.

Grounded knowledge

The server filters sources by project, audience, publication, approval, validity and product version. Citing an unoffered source rejects output. Without relevant sources, a draft may ask questions but cannot assert an unsupported solution.

Origin and transparency

Each sent reply has an immutable human, reviewed-AI or automatic-AI origin record. Text/HTML email contains matching notices. Versioned project transparency changes never rewrite old records. See Origin and transparency.

Real AI quality cases

Administrators derive separate anonymised drafts from suitable resolved email/web tickets. They document permitted use, expected category/priority, response boundaries, required points, forbidden claims and risks. Only technical rechecking and three human confirmations admit a saved version into the protected dataset.

This neither changes source tickets, calls AI nor sends messages. Synthetic cases are technical fixtures only. The original 0.8.0 gate required real authorised anonymised cases from two projects; the current project-start transition rule is explained in Real quality cases.

Operation and validation

Schema through migration 026 was applied completely and repeatably to fresh MariaDB. Public AI/statistics were checked with isolated synthetic projects and approved/unapproved content. Local AI used a fully local synthetic runtime; real model, hardware, LAN, VPN and cluster benchmarks are not product approval.

Production builds, TypeScript, PHP unit/database tests, docs builds, secret scanning and architecture/security tests must pass before shipment. Production updates require file/database backups, migration, version/health checks and private/API path checks. Reference public AI and auto-send stay disabled pending separate approvals.

Still unapproved

Production AI on the reference installation, automatic AI sending, public project portal/FAQ/contact, public customer self-hosting, graphical browser installation and public registration.