Der Betrag wird gleichmäßig auf die ausgewählten Personen aufgeteilt.
Neues Ticket
Neue Gruppe
Art und Umgebung kommen aus den Metadaten (metadata.kind / metadata.environment). Die spezifischste Übereinstimmung gewinnt: Umgebung vor Art vor Kategorie – so fängt eine eigene Testphasen-Gruppe alle Staging-Tickets ab.
Einstellungen
Mein Konto
Zum Speichern ist das aktuelle Passwort erforderlich. Neues Passwort nur ausfüllen, wenn du es ändern möchtest.
Benutzerverwaltung
Beim Löschen eines Nutzers werden auch seine privaten Projekte und Aufgaben entfernt (die konnte nur er sehen). Gemeinsame Inhalte bleiben erhalten.
Einladungscode
Wer diesen Code kennt, kann sich ein Konto anlegen. Nach dem Ändern gilt sofort der neue Code.
Gruppen für das Ticketsystem
Gruppen steuern, bei welchem Team ein neues Ticket automatisch landet – je nach Kategorie (Anfrage, Problem, Störung, …). Eine Standardgruppe fängt alles Übrige auf.
API-Keys
Public-Keys (pbk_) geben Kunden-Websites den Ticketeingang frei:
POST /public/api/tickets mit Header
X-Api-Key.
Admin-Keys (pbs_) sind für Server-zu-Server-Integrationen mit Vollzugriff auf
/admin/api/… – am besten mit IP-Beschränkung.
Die vollständige API-Doku liefert /public/api/openapi.json.
Klick auf einen Key kopiert ihn. Rotation: zweiten Key anlegen, alten später löschen.
Webhooks (Projektboard → externes System)
Bei Ticket-Ereignissen (angelegt, Status geändert, neue Nachricht) ruft Projektboard die
hinterlegte URL per POST auf. Jede Zustellung ist mit HMAC-SHA256 signiert
(Header X-Projektboard-Signature,
Details in der README). Fehlgeschlagene Zustellungen werden automatisch mit wachsendem
Abstand erneut versucht (bis zu 7-mal). Eingehende Ereignisse (Dokumentfreigaben von docu9)
nimmt Projektboard unter POST /admin/api/webhooks/docu9
entgegen – authentifiziert mit einem Admin-API-Key.
Mail-Provisionierung (docu9)
docu9 ist die Quelle der Wahrheit für Ticket-SMTP, Posteingang und Branding. Das Board holt diese
Einstellungen periodisch ab (alle 10 Minuten) und verwendet bei einer Störung weiterhin die zuletzt
gültige Konfiguration. Die Zugangsdaten stammen aus docu9 Admin → Betrieb → Ticketsystem.
E-Mail-Versand über Relay (nur Notfallweg)
Seit der Umstellung versendet das Board direkt über den provisionierten Ticket-SMTP. Dieses Relay
wird nur noch verwendet, wenn der SMTP-Versand scheitert – als Auffangnetz.
Ist keine Provisionierung eingerichtet, bleibt das Relay der einzige Weg.
Automatisch versendet werden: Eingangsbestätigung, Statusänderungen und neue Team-Antworten an den Kunden
sowie Kundenantworten an das Team-Postfach. Den Absender bestimmt das Relay.
Links in Mails & Webhooks
Format je Zeile: Beschriftung|URL. Platzhalter in geschweiften Klammern werden aus den Ticket-Metadaten gefüllt ({space.id}, {user.email} …). Fehlt ein Wert, wird der Link einfach weggelassen.
Die Basis-URL macht Deep-Links („Im Projektboard öffnen“) vollständig. Die Kunden-Statusseite wird – falls gesetzt – in Kunden-Mails verlinkt; Platzhalter {number} und {token} werden ersetzt.
Anmeldung per SSO (Keycloak / OIDC)
Nutzer mit der geforderten Realm-Rolle können sich über den Identitätsanbieter anmelden und werden
beim ersten Login automatisch als Admin angelegt. Der lokale Login bleibt als Rückfallebene immer bestehen.
Redirect-URI für die Client-Konfiguration: <Basis-URL>/auth/oidc/callback
Zustellprotokoll
Die letzten Webhook- und E-Mail-Zustellungen. Fehlgeschlagene Einträge bleiben sichtbar und können erneut angestoßen werden.
Aktivitätsprotokoll
Wer hat wann welches Ticket bearbeitet – inkl. Änderungen über die Admin-API und Eingänge über die Website-Schnittstelle. Die letzten 1000 Einträge werden aufbewahrt.