Upload via GUI (1 Datei)
This commit is contained in:
@@ -4,12 +4,17 @@
|
||||
|
||||

|
||||
|
||||
**Aktuelle Versionen:** Server **1.0.29** · Android-App **3.1.0** · Windows-Programm **2.7.0** · Minecraft-Plugin **1.0.0**
|
||||
|
||||
> Diese Anleitung ist auch für Einsteiger geeignet. Über das Inhaltsverzeichnis kommt ihr direkt zum gewünschten Thema. Die Abschnitte [Plugins entwickeln](#plugins-entwickeln) und [API und Webhooks](#api-und-webhooks-für-entwickler) richten sich an Entwickler.
|
||||
|
||||
## Funktionen
|
||||
|
||||
- **Kundenportal** mit Ticket-Erstellung, Ticketstatus, Wissensdatenbank und frei gestaltbaren Seiten
|
||||
- **Digitaler Assistent** im Kundenportal: beantwortet Fragen aus Wissensdatenbank und eigenen Antworten, erstellt auf Wunsch das Ticket, mit Fragen-Log, Rückmeldung 👍/👎 und eigenen Wortgruppen (ohne externen KI-Dienst)
|
||||
- **Mitarbeiterbereich** mit Ticketlisten, Filtern, gespeicherten Ansichten, Zuweisungen und internen Notizen
|
||||
- **Wiedervorlage** („auf später legen“), **Beobachter**, **ähnliche Tickets und Artikel** beim Bearbeiten und **Erinnerung an Kunden** vor dem automatischen Schließen
|
||||
- **Automatik**: Tickets beim Eingang oder Öffnen zuweisen, Status automatisch auf „Offline“, automatische Abmeldung, Ticket-Sperre gegen Doppelbearbeitung
|
||||
- **E-Mail**: Versand über SMTP (auch pro Absenderadresse), automatischer Ticketimport über IMAP
|
||||
- **Abteilungen, Teams und Rollen** mit Berechtigungen, die pro Abteilung unterschiedlich sein können
|
||||
- **SLA-Pläne**, Eskalations- und Ticketregeln, Geschäftszeiten und Feiertage
|
||||
@@ -19,10 +24,37 @@
|
||||
- **Plugins** zum Nachrüsten eigener Funktionen
|
||||
- **Update-Funktion** für Programmdateien und Datenbank, Backups und Datenschutz-Funktionen
|
||||
- **Import aus osTicket** inklusive Abteilungen, Nachrichten und Anhängen
|
||||
- **Windows-App und Android-App** mit hellem und dunklem Design, direkt aus dem Mitarbeiterbereich herunterladbar
|
||||
- **Windows-Programm und Android-App** mit hellem und dunklem Design, Push-Benachrichtigungen, Verwaltung nach Rechten und Android-**Widget** in drei Größen, direkt aus dem Mitarbeiterbereich herunterladbar
|
||||
- **Minecraft-Plugin** (Paper, Spigot, BungeeCord in einer Datei) zum Melden von Spielern und Problemen als Ticket
|
||||
|
||||
## Einblicke
|
||||
|
||||
### Demo-Video (mit Beispieldaten)
|
||||
|
||||
[](DeskHub-Webseite/docs/video/deskhub-demo.mp4)
|
||||
|
||||
Klick auf die Vorschau öffnet das Video ([deskhub-demo.mp4](DeskHub-Webseite/docs/video/deskhub-demo.mp4), etwa 75 Sekunden). Alle Namen, Tickets und Antworten darin sind erfunden. Es zeigt das Kundenportal mit dem digitalen Assistenten, die Übersicht, Ticketliste und Ticketansicht mit Wiedervorlage und Beobachtern, die Verwaltung des Assistenten mit Fragen-Log sowie das Windows-Programm.
|
||||
|
||||
### Digitaler Assistent im Kundenportal
|
||||
|
||||
[](DeskHub-Webseite/docs/images/demo-assistent-kunde.png)
|
||||
|
||||
### Übersicht im Mitarbeiterbereich
|
||||
|
||||
[](DeskHub-Webseite/docs/images/demo-uebersicht.png)
|
||||
|
||||
### Ticket mit Wiedervorlage, Beobachtern und passenden Artikeln
|
||||
|
||||
[](DeskHub-Webseite/docs/images/demo-ticket-wiedervorlage.png)
|
||||
|
||||
### Fragen-Log des Assistenten
|
||||
|
||||
[](DeskHub-Webseite/docs/images/demo-assistent-log.png)
|
||||
|
||||
### Windows-Programm
|
||||
|
||||
[](DeskHub-Webseite/docs/images/demo-windows-ticket.png)
|
||||
|
||||
### Neues Ticket erstellen
|
||||
|
||||
[](DeskHub-Webseite/docs/images/new-ticket.png)
|
||||
@@ -49,6 +81,10 @@
|
||||
- [E-Mails versenden (SMTP)](#e-mails-versenden-smtp)
|
||||
- [E-Mails automatisch abrufen (Postfächer)](#e-mails-automatisch-abrufen-postfächer)
|
||||
- [Automatisierung (Cronjobs)](#automatisierung-cronjobs)
|
||||
- [Status und automatisch Offline](#status-und-automatisch-offline)
|
||||
- [Digitaler Assistent](#digitaler-assistent)
|
||||
- [Wiedervorlage, Beobachter, ähnliche Tickets, Kundenerinnerung](#wiedervorlage-beobachter-ähnliche-tickets-kundenerinnerung)
|
||||
- [Ticket-Sperre und automatische Zuweisung](#ticket-sperre)
|
||||
- [SLA-Pläne](#sla-pläne)
|
||||
- [Gespeicherte Ansichten](#gespeicherte-ansichten)
|
||||
- [Berichte und Bericht-Baukasten](#berichte-und-bericht-baukasten)
|
||||
@@ -64,6 +100,7 @@
|
||||
- [API und Webhooks (für Entwickler)](#api-und-webhooks-für-entwickler)
|
||||
- [Sicherheit und Datenschutz](#sicherheit-und-datenschutz)
|
||||
- [Backup](#backup)
|
||||
- [Demo-Video neu erzeugen](#demo-video-neu-erzeugen)
|
||||
- [Hilfe, etwas funktioniert nicht](#hilfe-etwas-funktioniert-nicht)
|
||||
|
||||
---
|
||||
@@ -98,7 +135,9 @@ Ein Admin-Konto ist ein Mitarbeiter-Konto mit der Rolle „Admin“. Beim Anmeld
|
||||
3. Dem Assistenten folgen: Datenbank-Zugangsdaten, Website-Name, erstes Admin-Konto.
|
||||
4. Danach unter `eure-domain.de/staff/login.php` mit dem neuen Konto anmelden.
|
||||
|
||||
**Ganz wichtig:** Löscht anschließend den Ordner `install` vom Server (oder sperrt ihn). Sonst könnte jemand die Installation ein zweites Mal starten und eure Daten überschreiben.
|
||||
Der Assistent prüft zuerst die Voraussetzungen (PHP 8.2, Datenbanktreiber, `openssl`, beschreibbare Ordner; `curl`, `zip` und HTTPS sind empfohlen). Das Admin-Passwort braucht mindestens 10 Zeichen mit Groß- und Kleinbuchstaben, Ziffer und Sonderzeichen. Zum Schluss spielt er alle Datenbank-Änderungen ein, erzeugt den Verschlüsselungsschlüssel und sperrt sich selbst. Fehler bei der Datenbankverbindung werden verständlich erklärt (falsches Passwort, Server nicht erreichbar, Datenbank fehlt).
|
||||
|
||||
**Ganz wichtig:** Löscht anschließend den Ordner `install` vom Server (oder sperrt ihn). Der Assistent überschreibt eine bestehende Installation nie: Gibt es schon eine `config/config.php` mit Datenbank und Mitarbeiterkonten, zeigt er „Bereits installiert“. Wollt ihr bewusst neu anfangen, legt zuerst ein Backup an und entfernt dann `config/config.php`, `install/.installed` und die Datenbank (bei SQLite die Datei `database/deskhub.sqlite`).
|
||||
|
||||
---
|
||||
|
||||
@@ -147,8 +186,16 @@ Im Mitarbeiterbereich gibt es links im Menü:
|
||||
- **Sperrliste**: einzelne E-Mail-Adressen oder ganze Mail-Anbieter blockieren
|
||||
- **Verzeichnis**: Kontaktliste aller Kollegen
|
||||
|
||||
**Vorlagen (Textbausteine):** Im Antwortformular zeigt die Auswahl „Vorlage wählen“ nur Vorlagen, die der **Abteilung des Tickets** zugeordnet sind, dazu die Vorlagen für **alle Abteilungen** (ohne Abteilung angelegt). Beides ist in der Auswahl gruppiert. Zuordnen könnt ihr eine Vorlage unter Adminportal → Vorlagen.
|
||||
|
||||
**Mehrere Tickets in eine andere Abteilung verschieben:** In der Ticketliste die Tickets markieren, unten bei „Auswahl“ die Abteilung wählen und **„Abteilung ändern“** klicken. Die SLA-Fristen werden nach den Regeln der neuen Abteilung neu berechnet, die Verschiebung steht im Aktivitätsprotokoll jedes Tickets. Verschieben dürfen nur Mitarbeiter mit dem Recht „Tickets übertragen“ und nur in Abteilungen, auf die sie Zugriff haben. Tickets, die schon in der Zielabteilung liegen, oder bei denen das Recht fehlt, werden übersprungen und in der Meldung genannt.
|
||||
|
||||
In einem Ticket könnt ihr dem Kunden antworten, eine **interne Notiz** hinterlassen (nur das Team sieht sie), den Status ändern, das Ticket zuweisen, lösen oder schließen. Welche dieser Aktionen möglich sind, hängt von eurer Rolle in der Abteilung des Tickets ab.
|
||||
|
||||
**Signatur beim Antworten wählen:** Im Antwortformular eines Tickets steht unter dem Textfeld die Auswahl **Signatur**: **Meine Signatur**, **Abteilung „…“** (die Signatur der Abteilung des Tickets) oder **Keine Signatur**. Darunter zeigt eine Vorschau genau das, was angehängt wird. Voreingestellt ist wie bisher die eigene Signatur, ersatzweise die der Abteilung. Die Signatur wird nur an öffentliche Antworten angehängt, nicht an interne Notizen. Die Mobile-API nimmt beim Antworten (`POST /api/staff/v1/ticket_message.php`) optional das Feld `signature` mit `own`, `dept` oder `none`.
|
||||
|
||||
**E-Mail-Signatur:** Unter **Mein Profil → Signatur** stellt ihr den Text ein, der an eure Antworten angehängt wird (Fett, Kursiv, Liste, Link und Bilder). Bilder fügt ihr mit 🖼️ ein, die Größe ändert ihr, indem ihr das Bild anklickt: Mit dem runden Anfasser an der Ecke ziehen (auch mit dem Finger) oder 25 / 50 / 75 % / Original wählen. Das funktioniert in allen Texteditoren mit Bildern, auch bei Abteilungen und Mitarbeiter-Konten der Verwaltung. Bilder in Signaturen müssen über eine https-Adresse erreichbar sein (die Website-URL der Installation muss mit https:// beginnen), sonst blendet der Sicherheitsfilter sie aus.
|
||||
|
||||
---
|
||||
|
||||
## Für Admins: Das Adminportal
|
||||
@@ -202,6 +249,14 @@ Im Menü gibt es den Punkt **„Adminportal“**. Er ist für echte Admins immer
|
||||
| Backup | Manuelle und automatische Sicherungen |
|
||||
| System-Update | Programm und Datenbank aktualisieren |
|
||||
|
||||
### Firmenlogo
|
||||
|
||||
Unter **Einstellungen → Design → Firmenlogo** ladet ihr euer Logo hoch (PNG, JPG, GIF oder SVG, höchstens 2 MB). Es erscheint im Kundenportal, in den Anmeldeseiten und im Mitarbeiterbereich. Neben dem Logo steht standardmäßig der Name der Installation; mit **„Name neben dem Logo ausblenden“** zeigt DeskHub nur das Logo. Die Vorschau in den Einstellungen hat einen dunklen Hintergrund. Helle Logos sind auf den hellen Seiten des Kundenportals schwer zu erkennen, nehmt dafür lieber eine dunkle oder farbige Variante.
|
||||
|
||||
### Favicon
|
||||
|
||||
Das Symbol im Browser-Tab, in Lesezeichen und auf dem Startbildschirm stellt ihr unter **Einstellungen → Design → Favicon** ein. Erlaubt sind ICO, PNG, JPG, GIF, WebP und SVG (höchstens 1 MB, am besten quadratisch, z. B. 256×256 Pixel). DeskHub prüft den Inhalt, nicht nur die Endung; SVG-Dateien mit Skripten werden abgelehnt. Das Favicon gilt auf allen Seiten (Kundenportal, Mitarbeiterbereich, Anmeldeseiten, Druckansichten). Ohne Favicon verwendet DeskHub das Logo, ohne beides das Standardsymbol. Browser merken sich Symbole hartnäckig: Nach einer Änderung hilft Strg + F5 oder ein neuer Tab.
|
||||
|
||||
### Kundenportal-Design (Themes)
|
||||
|
||||
Unter **Einstellungen → Design** lassen sich mehrere Themes als ZIP-Datei hochladen, aktivieren und löschen. Ein aktiviertes Theme gilt für das ganze Kundenportal. Mit **„Standarddesign nutzen“** wird es wieder deaktiviert. Der Anzeigename wird aus dem Dateinamen der ZIP übernommen; lädt man ein Theme mit gleichem Namen erneut hoch, ersetzt es die vorhandene Version. Fertige Themes (darunter die Saison-Themes **Halloween Nacht** und **Weihnachten Winter**) liegen als ZIP im Ordner `theme/` des Projekts. Außerdem könnt ihr Themes direkt aus dem Katalog der Plugin-Webseite installieren: Auf derselben Seite erscheint unter **„Themes aus dem Katalog“** das Angebot automatisch. Prüfsumme und Signatur (mit dem unter Plugins hinterlegten Herausgeber-Schlüssel) werden vor der Installation geprüft; aktiviert wird das Theme erst, wenn ihr es selbst aktiviert.
|
||||
@@ -239,6 +294,10 @@ Damit eine Mail an z. B. `support@eure-domain.de` automatisch als Ticket erschei
|
||||
|
||||
Habt ihr getrennte Postfächer pro Abteilung (z. B. `technik@` und `vertrieb@`), legt ihr für jedes ein eigenes Postfach mit eigener Standardabteilung an. DeskHub ruft alle aktiven Postfächer nacheinander ab.
|
||||
|
||||
### Eigenes Ticket-Formular pro Abteilung
|
||||
|
||||
Unter **Abteilungen → Formular** (oder im Reiter „Ticket-Formular“ der Abteilung) kann jede Abteilung ein komplett eigenes Formular bekommen. Ist es aktiv, sieht ein Kunde, der diese Abteilung wählt (direkt oder über ein Hilfe-Thema), nur die dort festgelegten Felder: eigene Felder (Text, Mehrzeilig, Auswahl, Checkbox, Zahl, Datum, mit Pflicht und Reihenfolge), Überschrift, Einleitung, Bezeichnungen von Betreff und Beschreibung, Platzhaltertext und Text des Absende-Knopfs. Betreff und Anhang lassen sich ausblenden (ohne Betreff wird „Anfrage <Abteilung>“ verwendet). Die allgemeinen Ticket-Felder und die Felder der Hilfe-Themen gelten dann für diese Abteilung nicht. Name und E-Mail werden immer abgefragt. Abteilungen ohne eigenes Formular nutzen weiter das Standardformular.
|
||||
|
||||
### Eine Adresse einer Abteilung zuordnen
|
||||
|
||||
Läuft alles in einem Sammelpostfach zusammen (z. B. per Weiterleitung), muss DeskHub wissen, welche Empfängeradresse zu welcher Abteilung gehört:
|
||||
@@ -277,6 +336,63 @@ Nach der Installation müsst ihr nichts tun, Option A läuft von selbst.
|
||||
|
||||
---
|
||||
|
||||
## Status und automatisch Offline
|
||||
|
||||
Jeder Mitarbeiter stellt seinen Status ein (Verfügbar, Beschäftigt, Pause, Offline), im Browser unter **Verfügbarkeit & Schichten** und in der App unter Verwaltung → Mein Status. **Wer 30 Minuten lang nichts tut, geht automatisch auf Offline** und bekommt seinen vorherigen Status zurück, sobald er wieder aktiv ist. Als aktiv zählen echte Bedienung (Seitenaufrufe, Klicks und Tipps, Aktionen und Berührungen in der App); Abfragen im Hintergrund halten niemanden online. Ein von Hand gesetzter Status wird nicht von selbst zurückgesetzt. Die Zeit stellt ein Admin unter Verfügbarkeit & Schichten ein (0 = aus). Admins können dort (und in der App durch Antippen eines Teammitglieds) den Status jedes Mitarbeiters ändern; das steht im Aktivitätsprotokoll. Der Live-Chat auf der Kundenseite zeigt automatisch Offline-Mitarbeiter nicht mehr als erreichbar.
|
||||
|
||||
## Automatische Abmeldung
|
||||
|
||||
Im Browser wird ein Mitarbeiter nach der eingestellten Zeit ohne Bedienung abgemeldet (Einstellungen → Allgemein → Sitzungs-Timeout, Standard 30 Minuten; oben rechts zeigt ein Zähler die Restzeit). **Als Bedienung zählen** Klicks, Tastatureingaben und Mausbewegungen auf der Seite sowie jeder vom Nutzer selbst ausgelöste Seitenaufruf. **Nicht als Bedienung zählen** die Abfragen, die eine offene Seite im Hintergrund stellt (Ticketliste, Chat, Anwesenheit, „Seite aktualisieren“ bei neuen Antworten): Eine unbeachtet offene Seite hält die Sitzung also nicht am Leben. Mehrere Tabs teilen sich die Zeit; der Zähler gleicht sich alle 30 Sekunden mit dem Server ab. Windows-Programm und Android-App melden sich über ihr eigenes Anmelde-Token an und sind davon nicht betroffen.
|
||||
|
||||
## Digitaler Assistent
|
||||
|
||||
Der Assistent beantwortet Fragen im Kundenportal und ersetzt dabei das Live-Chat-Fenster, **solange der Live-Chat ausgeschaltet oder gerade niemand erreichbar ist**. Sobald ein Mitarbeiter als „Verfügbar“ gemeldet ist (und der Live-Chat läuft), sehen Kunden wieder den normalen Live-Chat. Im Wartungsmodus ist er nicht aktiv.
|
||||
|
||||
- **Antworten:** zuerst die im Backend hinterlegten **zusätzlichen Antworten** (Frage, Stichwörter, Text), dann die veröffentlichten Artikel der **Wissensdatenbank** (nur, wenn sie im Kundenportal eingeschaltet ist). Gesucht wird über die Wörter der Frage, ohne externen KI-Dienst: Kundenfragen verlassen den Server nicht.
|
||||
- **Keine Antwort:** Der Assistent fragt, ob er ein Ticket erstellen soll, und erfragt Thema (falls öffentliche Hilfethemen eingerichtet sind), Name, E-Mail-Adresse, Betreff und Beschreibung. Er zeigt eine Zusammenfassung und legt das Ticket nach Bestätigung an. Es durchläuft Ticket-Regeln und automatische Zuweisung, trägt den Tag „Assistent“ und der Kunde bekommt die übliche Eingangsbestätigung.
|
||||
- **Einrichten:** Adminportal → **Digitaler Assistent** (Menü „Verwalten“): ein-/ausschalten, Name, Begrüßung, Text ohne Antwort, Abteilung und Priorität der Tickets, zusätzliche Antworten pflegen und mit „Frage ausprobieren“ testen. Mit der Einstellung „Immer (zum Testen)“ siehst du den Assistenten auch bei besetztem Chat.
|
||||
- **Rückmeldung und Wörter:** „Das hat geholfen“ und „Ticket erstellen“ nach einer Antwort werden im Fragen-Log als 👍/👎 festgehalten (Filter „Hat geholfen“ / „Hat nicht geholfen“). Unter „Gleichbedeutende Wörter“ (Tab Einstellungen) pflegst du eigene Gruppen wie „Zugang, Einladung, beitreten“, die der Assistent gleich behandelt.
|
||||
- **Fragen-Log:** Auf derselben Seite unter „Fragen-Log“ siehst du jede Kundenfrage mit Ergebnis (eigene Antwort gefunden, Wissensdatenbank, keine Antwort, Ticket gewünscht/erstellt) und der gefundenen Antwort. Filter nach Ergebnis, Zeitraum und Text; „Häufige Fragen ohne Antwort“ fasst gleiche Fragen zusammen und legt mit einem Klick eine neue Antwort an. Gespeichert werden nur Frage und Ergebnis (kein Name, keine E-Mail); Aufbewahrung einstellbar (Standard 90 Tage, 0 = nichts speichern), „Log leeren“ löscht alles. Dafür einmal unter System-Update „Datenbank aktualisieren“ ausführen (Migration 0045).
|
||||
- **Recht für Mitarbeiter:** In einer Rolle das Recht **„Digitalen Assistenten verwalten“** vergeben (Admins haben es immer).
|
||||
- **Missbrauchsschutz:** höchstens 30 Fragen je 10 Minuten und Sitzung, höchstens 3 Tickets pro Stunde und Adresse, verstecktes Spam-Feld, gültiger Sitzungs-Token.
|
||||
|
||||
## Wiedervorlage, Beobachter, ähnliche Tickets, Kundenerinnerung
|
||||
|
||||
- **Wiedervorlage:** Auf der Ticketseite rechts „Auf später legen“ (in 1 oder 3 Stunden, morgen früh, in 3 Tagen, 1 Woche oder zu einem eigenen Zeitpunkt). Das Ticket verschwindet aus „Offen“ und „Alle“ und steht im Tab „💤 Wiedervorlage“. Zur gewählten Zeit kommt es zurück, der Mitarbeiter bekommt eine Benachrichtigung (Browser-Push und Android-App, Art „Wiedervorlage fällig“). Antwortet der Kunde früher, kommt es sofort zurück. Der Job „Wiedervorlagen“ läuft alle 2 Minuten über den eingebauten Cron oder per Crontab: `*/5 * * * * php cron/process_snoozes.php`.
|
||||
- **Beobachter:** „Ticket beobachten“ auf der Ticketseite. Beobachter bekommen eine Benachrichtigung bei Kundenantworten und Antworten anderer Mitarbeiter („Beobachtetes Ticket aktualisiert“, in den Push-Einstellungen abschaltbar), ohne dass ihnen das Ticket zugewiesen ist.
|
||||
- **Dazu passend:** Beim Öffnen eines Tickets zeigt die Karte passende Artikel der Wissensdatenbank (mit „Link kopieren“) und ähnliche bereits gelöste Tickets.
|
||||
- **Kunden erinnern:** Einstellungen → Allgemein → „Kunden erinnern“. Reagiert ein Kunde nach einer Antwort X Tage nicht, bekommt er einmalig eine freundliche Mail; ist das automatische Schließen an, nennt sie die Restzeit. Die Frist zum Schließen ändert sich dadurch nicht. Der Text lässt sich unter E-Mail-Vorlagen mit dem Schlüssel `customer_reminder` ersetzen (Platzhalter `{customer_name}`, `{ticket_number}`, `{subject}`, `{ticket_url}`, `{close_note}`). Crontab: `0 * * * * php cron/remind_customers.php`.
|
||||
- **App-Schnittstelle:** `PATCH /api/staff/v1/ticket_update.php` nimmt `snoozeUntil` (Datum/Uhrzeit oder `null`) und `following` (true/false) an; Ticketlisten liefern `snoozedUntil` und `following`, Wiedervorlagen mit `?snoozed=1`. Die Android-App (ab 2.7.0) und das Windows-Programm (ab 2.5.0) nutzen das: Knöpfe „Auf später“ und „Beobachten“ im Ticket, Reiter bzw. Filter „Wiedervorlage“ und „Beobachtet“ in der Liste und die Karte „Dazu passend“. Wiedervorlage und Beobachten funktionieren auch bei einem gerade bearbeiteten (gesperrten) Ticket.
|
||||
- Für alles: einmal unter System-Update „Datenbank aktualisieren“ (Migration 0046).
|
||||
## Digitaler Assistent in den Apps
|
||||
|
||||
Android-App (ab 2.9.0, aktuell 3.1.0) und Windows-Programm (ab 2.7.0) haben die Verwaltung des Assistenten fest eingebaut (Verwaltung → „Digitaler Assistent“) mit fünf Bereichen: Einstellungen, zusätzliche Antworten (anlegen, ändern, löschen), Fragen-Log (Kennzahlen, Filter, Suche, häufige Fragen ohne Antwort mit „Antwort anlegen“, Log leeren), Gleichbedeutende Wörter und „Frage ausprobieren". Der Bereich erscheint nur für Administratoren und Mitarbeiter mit dem Recht „Digitalen Assistenten verwalten“; die Schnittstelle `api/staff/v1/assistant.php` prüft das Recht bei jedem Aufruf und trägt jede Änderung ins Admin-Protokoll ein.
|
||||
|
||||
## Weboberfläche aus den Apps öffnen
|
||||
|
||||
Das Windows-Programm (ab 2.6.0) zeigt in der Verwaltung zusätzlich die Seiten, die sie nicht selbst nachbauen: Einstellungen, Digitaler Assistent, Wiederkehrende Tickets, Textbausteine, Ticket-Felder, benutzerdefinierte Listen, Seiten, Webhooks, API-Schlüssel, Plugins, Backup, System-Update, Sicherheitsprüfung, Postfächer, osTicket-Import sowie Erwähnungen und Mitarbeiterverzeichnis. Im Ticket öffnet „Im Browser“ die Ticketseite (zusammenführen, aufteilen, drucken).
|
||||
|
||||
- **Rechte:** Der Server (`api/staff/v1/web_pages.php`) liefert nur Seiten, die der Mitarbeiter öffnen darf (Administrator: alle; „Digitalen Assistenten verwalten“ und „E-Mail-Adressen verwalten“ als Einzelrechte; Erwähnungen und Verzeichnis für alle). Die Weboberfläche prüft die Rechte danach noch einmal selbst.
|
||||
- **Anmeldung:** Die App holt eine einmalige Adresse (`staff/app_login.php?t=…`), die 60 Sekunden gilt und nur einmal funktioniert; sie meldet im Browser an und leitet auf die Seite weiter. Jede Übergabe steht im Admin-Protokoll. Abgelaufene, benutzte oder erfundene Adressen führen zur Anmeldeseite. Dafür einmal „Datenbank aktualisieren“ (Migration 0047). Die Android-App 3.x enthält diese Browser-Übergabe nicht mehr; die Schnittstelle bleibt auf dem Server für das Windows-Programm.
|
||||
|
||||
## Ticket-Sperre
|
||||
|
||||
Wer ein Ticket öffnet, sperrt es für andere (5 Minuten, bei Inaktivität läuft die Sperre ab), damit nicht zwei Personen gleichzeitig daran arbeiten. Normale Mitarbeiter bekommen bei einem gesperrten Ticket einen Hinweis mit dem Namen des Bearbeiters. **Administratoren** können ein gesperrtes Ticket trotzdem **lesen und bearbeiten** (Antworten, Notizen, Status) und sehen oben den Hinweis „wird gerade von … bearbeitet“ mit dem Knopf **„Sperre aufheben und übernehmen“**. Das gibt es im Browser, im Windows-Programm und in der Android-App; das Aufheben steht im Ticket-Verlauf. Jeder darf seine eigene Sperre freigeben. Ein Live-Chat sperrt Administratoren nie aus.
|
||||
|
||||
## Beim Öffnen automatisch zuweisen
|
||||
|
||||
Öffnet ein Mitarbeiter ein Ticket, das noch niemandem zugewiesen ist, wird es ihm zugewiesen (Browser, Windows-Programm und Android-App). Das gilt nicht für geschlossene, gelöste, zusammengeführte oder als Spam markierte Tickets, nicht für Mitarbeiter ohne Recht zum Antworten und nicht, wenn ein Admin ein von jemand anderem bearbeitetes Ticket nur ansieht. Ein bereits zugewiesenes Ticket bleibt beim Bearbeiter. Ausschalten: Einstellungen → Allgemein → „Beim Öffnen automatisch zuweisen“.
|
||||
|
||||
## Neue Tickets automatisch zuweisen
|
||||
|
||||
Im Formular einer Abteilung (Adminportal → Abteilungen → Bearbeiten, auch in der Android-App und im Windows-Programm) steht **„Neue Tickets automatisch zuweisen“**:
|
||||
|
||||
- **Nicht automatisch zuweisen:** wie bisher.
|
||||
- **Immer an einen bestimmten Mitarbeiter:** z. B. alle Tickets von „First Support“ an Lukas. Ist er im Urlaub, bekommt seine Vertretung das Ticket, ohne Vertretung bleibt es unzugewiesen.
|
||||
- **Reihum:** der Reihe nach an die Mitarbeiter der Abteilung (Hauptabteilung oder zusätzlich zugewiesen). Mitarbeiter im Urlaub, offline oder außerhalb ihrer Schicht werden übersprungen; ist niemand erreichbar, bekommt trotzdem der Nächste in der Reihe das Ticket.
|
||||
|
||||
Das gilt für Tickets aus Formular, E-Mail, API (z. B. das Minecraft-Plugin) und Live-Chat. Reihenfolge: eine **Ticket-Regel** mit „Mitarbeiter zuweisen“ hat Vorrang, dann die Einstellung der Abteilung, dann der letzte Bearbeiter des Kunden. Von Mitarbeitern von Hand angelegte Tickets bleiben so, wie der Mitarbeiter sie zugewiesen hat. Im Ticket-Verlauf steht „Automatisch zugewiesen (Einstellung der Abteilung)“.
|
||||
|
||||
## SLA-Pläne
|
||||
|
||||
Ein SLA-Plan legt fest, wie schnell reagiert und gelöst werden soll. Unter Adminportal → **SLA-Pläne** legt ihr Pläne mit Reaktions- und Lösungszeit an und weist sie Abteilungen oder Hilfethemen zu.
|
||||
@@ -370,12 +486,31 @@ Beide Apps sind für Mitarbeiter und Admins gedacht und haben ein helles und ein
|
||||
|
||||
**Was die Apps können:**
|
||||
|
||||
- Tickets bearbeiten (antworten, Notizen, zuweisen, Status ändern, lösen, schließen), Übersicht, Kundenverzeichnis, internen Chat mit Kollegen
|
||||
- Tickets bearbeiten (antworten, Notizen, zuweisen, Status ändern, lösen, schließen), Übersicht, Kundenverzeichnis, internen Chat und Live-Chat
|
||||
- **Wiedervorlage** („Auf später“: 1 Stunde bis 1 Woche, im Windows-Programm auch eigener Zeitpunkt), **Beobachten**, Filter „Wiedervorlage“ und „Beobachtet“ und die Karte **„Dazu passend“** (Artikel und ähnliche gelöste Tickets)
|
||||
- **Digitalen Assistenten komplett verwalten**: Einstellungen, zusätzliche Antworten, Fragen-Log, Gleichbedeutende Wörter, „Frage ausprobieren“ (nur mit dem Recht „Digitalen Assistenten verwalten“)
|
||||
- Beim Antworten zeigen die Apps nur die Textbausteine der Abteilung des Tickets (plus die für alle Abteilungen) und bieten wie im Web die **Signatur-Auswahl** (meine, Abteilung, keine) mit Vorschau. Das setzt einen Server mit diesem Stand voraus; ältere Server liefern die Signaturen nicht, dann antworten die Apps wie bisher.
|
||||
- Gespeicherte Ansichten nutzen und Berichte aus dem Bericht-Baukasten ansehen
|
||||
- Störungs- und Verbindungsbanner
|
||||
- Admins und Co-Admins finden zusätzlich die **Verwaltung** mit fast allen Adminportal-Bereichen, je nach zugewiesenen Rechten: Abteilungen, Prioritäten, SLA-Pläne, Hilfethemen, E-Mail-Adressen (inkl. Test), Wissensdatenbank, E-Mail-Vorlagen, Organisationen, Mitarbeiter, Teams, Rollen, Admin-Protokoll, Eskalationsregeln, Zeiterfassung, Geschäftszeiten, Sperrliste, Aufgaben
|
||||
- Systemnahe Bereiche (Backup, System-Update, Plugins, API-Schlüssel, Webhooks, Postfächer, Ticket-Regeln, Ticket-Felder, Seiten, Einstellungen) gibt es bewusst nur in der Weboberfläche
|
||||
- Systemnahe Bereiche (Backup, System-Update, Plugins, API-Schlüssel, Webhooks, Postfächer, Ticket-Felder, Seiten, Einstellungen) gibt es in der **Android-App** bewusst nicht; das **Windows-Programm** öffnet sie auf Wunsch im Browser (siehe [Weboberfläche aus dem Windows-Programm öffnen](#weboberfläche-aus-den-apps-öffnen))
|
||||
|
||||
**Android-App 3.x:** komplett neues Design (helle, runde Karten, Blau/Türkis, Dunkelmodus), schwebende Navigation (Start, Tickets, Chat, Kunden, Mehr) und „Mehr“ mit Kacheln für Aufgaben, Status, Benachrichtigungen und die Verwaltung nach Rechten.
|
||||
|
||||
**Android-Widget (ab 3.1):** auf dem Startbildschirm in drei Größen. *Klein*: Meine offenen und Überfällige. *Mittel*: vier Kennzahlen und die drei wichtigsten Tickets als Nummern (Tipp öffnet das Ticket). *Groß*: zusätzlich „Neues Ticket“, „Alle Tickets“ und der eigene Status zum Umschalten. Überfälliges wird rot, im Dunkelmodus ist das Widget dunkel. Es zeigt bewusst keine Betreffs oder Kundennamen. Aktualisiert wird es nach Android-Vorgabe etwa alle 30 Minuten, beim Tippen auf ⟳, beim Öffnen der App und bei jeder Push-Nachricht. Die Statusknöpfe laufen über einen nicht exportierten Empfänger, andere Apps können den Status nicht ändern.
|
||||
|
||||
**Push-Benachrichtigungen (Android):** Die Android-App zeigt Popups bei neuen Tickets, Kundenantworten und Zuweisungen, auch wenn sie geschlossen ist. Das läuft über Firebase Cloud Messaging (Google).
|
||||
|
||||
- **Standard (nichts einzurichten):** Das DeskHub meldet sich beim ersten Senden automatisch beim **Push-Dienst des Herausgebers** an (`push.php` der Plugin-Webseite, die Adresse leitet sich aus `includes/catalog_defaults.php` ab) und schickt nur Geräte-Token und Ticketnummer dorthin. Der Firebase-Schlüssel liegt ausschließlich dort, nie in der App oder in diesem Paket. In der App anmelden und Benachrichtigungen erlauben (ab Android 13 fragt die App einmal danach); mit **„Testnachricht an meine Geräte“** unter **Einstellungen → Benachrichtigungen → „Android-App: Push-Benachrichtigungen“** prüfen.
|
||||
- **Eigenes Firebase-Projekt (für Fortgeschrittene):** Wer eine eigene App-Variante mit eigenem Firebase-Projekt betreibt, trägt in `config/config.php` `'fcm' => ['service_account_file' => '/pfad/ausserhalb/des/webordners/dienstkonto.json']` ein (Dienstkonto-Schlüssel aus Projekteinstellungen → Dienstkonten). Eine Oberfläche zum Hochladen gibt es bewusst nicht. Dann geht nichts mehr über den Push-Dienst. Die Datei `google-services.json` der eigenen App kommt beim Bauen in den Ordner `mobile/` (nicht ausgeliefert).
|
||||
|
||||
**Einstellbar pro Mitarbeiter:** Im Profil (Karte „Android-App: Welche Popups?“) und in der App unter Verwaltung → Benachrichtigungen wählt jeder, wofür er ein Popup bekommt (neues Ticket, Kundenantwort, Zuweisung, Live-Chat, SLA überschritten, Erwähnung) und legt stille Zeiten fest (Serverzeit, auch über Mitternacht). Testnachrichten kommen immer an. Auf Kundenantworten kann direkt in der Benachrichtigung geantwortet werden. Stürzt die App ab, meldet sie das beim nächsten Start an den eigenen Server (Aktivitätsprotokoll, „App-Absturz …“); es gehen keine Ticketinhalte und nichts an Dritte.
|
||||
|
||||
**Rechte beim Push:** Ein Popup bekommt nur, wer das Ticket auch sehen darf (Administrator oder Mitglied der Abteilung des Tickets). Für neue Tickets, Kundenantworten und Live-Chats braucht man zusätzlich das Recht „Antworten“ (Rolle). Eine **SLA-Überschreitung** melden die App nur dem zugewiesenen Mitarbeiter, Administratoren und Mitarbeitern mit dem Recht „Eskalationsregeln verwalten“, nicht der ganzen Abteilung. **Zuweisung** und **Erwähnung** erhält nur, wer Zugriff auf die Abteilung hat. In den Einstellungen („Welche Popups?“) erscheinen jedem nur die Arten, die für ihn überhaupt in Frage kommen; Live-Chat-Popups gibt es nur, wenn der Live-Chat eingeschaltet ist.
|
||||
|
||||
Wer bekommt was: ein **neues Ticket** bekommen alle Admins, Mitarbeiter der Abteilung und Mitarbeiter mit Benachrichtigung für diese Abteilung; eine **Kundenantwort** der zugewiesene Mitarbeiter (ohne Zuweisung die Abteilung); eine **Zuweisung** der neue Bearbeiter, aber nicht, wer sich selbst zuweist. Das gilt für Tickets aus Webformular, E-Mail, API und Live-Chat. Ein Tipp auf die Benachrichtigung öffnet das Ticket in der App.
|
||||
|
||||
**Datenschutz:** Standardmäßig steht nur „Neues Ticket #T-123“ in der Nachricht, Betreff und Kundenname verlassen euren Server nicht (auch der Push-Dienst sieht nur Ticketnummer und Geräte-Token). Wer mehr sehen will, schaltet „Betreff und Kundenname in der Benachrichtigung anzeigen“ ein. Jedes Gerät meldet sich beim Ausloggen ab. Pro Mitarbeiter sind bis zu 10 Geräte möglich; abgemeldete oder ungültige Geräte entfernt der Server selbst. Der Versand läuft nach dem Senden der Seite und bremst nichts.
|
||||
**Updates:** Die Android-App wird nur dann über die alte Version installiert, wenn sie mit demselben Signaturschlüssel erstellt wurde und eine höhere Versionsnummer hat. Nach einem Update die App einmal ganz schließen und neu öffnen.
|
||||
|
||||
---
|
||||
@@ -388,7 +523,7 @@ Adminportal → **System-Update** hat zwei Teile:
|
||||
|
||||
**Datenbank aktualisieren:** Die Karte „Datenbank“ zeigt, ob die Datenbank zum installierten Programm passt. Wenn nicht, erscheint dort und für Admins oben auf jeder Seite ein Hinweis. Der Knopf **„Datenbank aktualisieren“** erstellt zuerst ein Backup und spielt dann alle fehlenden Änderungen ein. Das ist der richtige Weg, wenn ihr Dateien per FTP hochgeladen habt. Scheitert das Backup, wird die Datenbank nicht angefasst.
|
||||
|
||||
**Signierte Updates:** Ist in DeskHub ein Herausgeber-Schlüssel eingebaut (`includes/catalog_defaults.php`), installiert das System-Update nur Releases, die mit diesem Schlüssel signiert sind. Ein manipuliertes Paket oder ein Release ohne Signatur wird abgelehnt und im Admin-Protokoll vermerkt. Ein manuell hochgeladenes ZIP wird nicht geprüft, ladet nur Pakete aus vertrauenswürdiger Quelle hoch. Es steckt kein Zugangstoken mehr im Programmcode: Die Releases werden öffentlich gelesen. Ist das Repository privat, tragt ihr in `config/config.php` ein Lese-Token ein: `'update' => ['token' => '…']` (nur Leserecht vergeben).
|
||||
**Signierte Updates:** Ist in DeskHub ein Herausgeber-Schlüssel eingebaut (`includes/catalog_defaults.php`), installiert das System-Update nur Releases, die mit diesem Schlüssel signiert sind. Ein manipuliertes Paket oder ein Release ohne Signatur wird abgelehnt und im Admin-Protokoll vermerkt. Ein manuell hochgeladenes ZIP wird nicht geprüft, ladet nur Pakete aus vertrauenswürdiger Quelle hoch. Es steckt kein Zugangstoken mehr im Programmcode: Die Releases werden öffentlich gelesen. Ist das Repository privat (Gitea meldet beim Laden der Versionen „404“), tragt ihr ein Lese-Token ein: am einfachsten im Adminportal unter **System-Update → Zugang zum Update-Server** (wird verschlüsselt gespeichert), oder in `config/config.php` im großen `return [ … ];` als `'update' => ['token' => '…'],`. In Gitea erzeugt ihr es unter Einstellungen → Anwendungen → Zugriffstoken mit der Berechtigung „repository: Lesen“ (nur Leserecht vergeben). Ein Eintrag in der `config.php` hat Vorrang.
|
||||
|
||||
**Release veröffentlichen (für den Herausgeber):**
|
||||
|
||||
@@ -415,7 +550,7 @@ Wer von osTicket auf DeskHub umzieht, kann den Bestand übernehmen: Kunden, Abte
|
||||
|
||||
Adminportal → **Einstellungen → „📥 osTicket Import“**.
|
||||
|
||||
1. **Hochladen:** Entweder den Dateinamen eintragen, wenn die SQL-Datei im DeskHub-Hauptordner liegt (**empfohlen**, vor allem bei großen Dateien), oder die Datei direkt hochladen (sie wird in 5-MB-Teilen übertragen).
|
||||
1. **Hochladen:** Entweder den Dateinamen eintragen, wenn die SQL-Datei im DeskHub-Hauptordner liegt (**empfohlen**, vor allem bei großen Dateien), oder die Datei direkt hochladen (sie wird in Teilen übertragen, deren Größe zum Upload-Limit des Servers passt).
|
||||
2. **Analysieren:** DeskHub liest die Datei und zeigt, was sie enthält (Kunden, Tickets, Nachrichten, Abteilungen, Hilfethemen, Anhänge). Der Fortschrittsbalken läuft von selbst, das Fenster muss offen bleiben.
|
||||
3. **Optionen:** Auswählen, was importiert werden soll. Die Reihenfolge ist fest: Kunden → Abteilungen und Hilfethemen → Tickets → Nachrichten → Anhänge. Anhänge setzen die Nachrichten voraus.
|
||||
4. **Import:** Läuft in kleinen Schritten, mit Fortschritt je Bereich. Am Ende steht eine Zusammenfassung mit Hinweisen.
|
||||
@@ -482,6 +617,31 @@ Unter `Plugins/plugins/tagesbericht-1.0.0.zip` (im Projektordner neben `DeskHub-
|
||||
|
||||
Nach Installation und Aktivierung findet ihr im Menü den Punkt **„Tagesbericht“**: Dort schaltet ihr den Versand ein, legt Uhrzeit, Werktage und Empfänger fest und könnt einen **Testbericht** an euch schicken. Voraussetzung ist der eingerichtete E-Mail-Versand.
|
||||
|
||||
### Mitgeliefertes Plugin: Synology NAS Backup (WebDAV)
|
||||
|
||||
Unter `Plugins/plugins/nas-backup-2.2.0.zip` liegt ein Plugin, das die Backups eures Servers automatisch auf eine Synology NAS (oder einen anderen WebDAV-Server) kopiert. Es ist aufgebaut wie das Plugin „Tagesbericht“: Es braucht nur die Standard-Berechtigungen **hooks.cron** und **ui.menu** und verändert nichts am Kern von DeskHub. Installation: Adminportal → Plugins → Zip hochladen → Berechtigungen bestätigen → aktivieren. Danach gibt es auf der Seite **Backup** den Reiter **„Synology NAS Backup“** (kein eigener Menüpunkt in der Seitenleiste; nur Administratoren sehen ihn). Dafür braucht das Plugin keine zusätzliche Berechtigung.
|
||||
|
||||
**Auf der Synology einrichten:**
|
||||
1. Paket **„WebDAV Server“** installieren und **HTTPS (Port 5006)** aktivieren.
|
||||
2. Einen eigenen Benutzer anlegen, der nur Zugriff auf einen freigegebenen Ordner (zum Beispiel `backup`) hat.
|
||||
3. Den Port im Router freigeben (oder einen Reverse-Proxy auf 443 nutzen) und die NAS über eine feste Adresse erreichbar machen (zum Beispiel Synology-DDNS `meine-nas.synology.me`) mit einem gültigen Zertifikat (Let’s Encrypt in der Synology-Systemsteuerung).
|
||||
|
||||
**So arbeitet es mit der Seite „Backup“ zusammen:** Das Plugin schaut alle paar Minuten in den Backup-Ordner des Servers. Jedes Backup, das dort neu liegt (Zeitplan der Seite „Backup“, „Backup jetzt erstellen“, Backups vor Updates), wird auf die NAS kopiert, sobald es geprüft ist (defekte Backups werden nie kopiert). Den Zeitplan stellt ihr also wie gewohnt auf der Seite „Backup“ ein; ist er dort ausgeschaltet, entstehen keine Backups und es gibt nichts zu kopieren. Alle Backups werden **automatisch auf Wiederherstellbarkeit geprüft** (siehe Abschnitt Backup), ohne dass jemand „Prüfen“ klicken muss.
|
||||
|
||||
**Auch die Liste „Vorhandene Backups“ auf der Seite „Backup“** zeigt die NAS: Jede Sicherung trägt die Marke „☁ auf NAS“ oder „nur hier“ (mit Knopf „Auf NAS“), und Sicherungen, die **nur auf der NAS** liegen, stehen ebenfalls in der Liste (mit „Auf Server holen“ und „Von NAS löschen“). Danach lassen sie sich wie jedes andere Backup wiederherstellen. Dafür braucht das Plugin keine zusätzliche Berechtigung (die Liste darf jedes Plugin ergänzen, das einen Reiter unter „Backup“ anbietet).
|
||||
|
||||
**Die Seite „Synology NAS Backup“** zeigt oben den Status, darunter die Liste der Backups (auf dem Server / auf der NAS, geprüft / defekt) und die Einstellungen:
|
||||
- **Verbindung:** IP-Adresse oder Domain, Port (Synology: 5005 HTTP / 5006 HTTPS, über Reverse-Proxy 443), Benutzer, Passwort, HTTPS, Zielverzeichnis auf der NAS (beginnt mit dem Namen des freigegebenen Ordners, zum Beispiel `/usbshare2/Geschichten/`). Die Server-URL wird als Vorschau angezeigt, **„Verbindung testen“** prüft alles.
|
||||
- **Aufbewahrung:** maximales Alter in Tagen **und** maximale Anzahl, beide Regeln gelten gleichzeitig (0 = aus); „Aktuell aktive Regeln“ zeigt, was gilt. Gelöscht werden nur Dateien, die das Plugin selbst angelegt hat (`backup_….zip`).
|
||||
- **Backups einzeln bewegen:** „Auf NAS“ für ein Backup, das noch nicht dort liegt, „Fehlende Backups jetzt kopieren“ für alle. Sicherungen, die **nur auf der NAS** liegen (zum Beispiel nach einem Serverumzug), holt ihr mit „Auf Server holen“; sie werden geprüft und lassen sich dann auf der Seite „Backup“ wiederherstellen.
|
||||
- **Eigene Backups des Plugins** (optional): Mit eigenem Zeitplan (stündlich bis monatlich, Uhrzeit), Inhalt (Datenbank und/oder Dateien, „wichtigste Dateien“ oder alles, Pfade ausschließen) erstellt das Plugin zusätzlich Backups, die nur auf der NAS liegen. „Eigenes Backup jetzt starten“ läuft im Hintergrund.
|
||||
|
||||
Gut zu wissen:
|
||||
- Jedes Backup wird nach dem Hochladen auf der NAS auf vollständige Größe kontrolliert; unvollständige Dateien werden wieder gelöscht.
|
||||
- Das Passwort wird verschlüsselt gespeichert. Zugangsdaten werden nie an Weiterleitungen geschickt. Ohne HTTPS sind nur Adressen im eigenen Netz erlaubt. Die Zertifikatsprüfung ist standardmäßig an und lässt sich für ein selbst erstelltes Zertifikat abschalten (dann weniger sicher).
|
||||
- Schlägt das Kopieren fehl, versucht das Plugin es frühestens nach einer Stunde erneut; die Admin-Adresse bekommt höchstens einmal am Tag eine E-Mail, und der Fehler steht mit Ursache auf der Seite des Plugins.
|
||||
- Das Plugin läuft über den eingebauten Cron (bei Aktivität im Adminportal) oder einen echten Cronjob, der DeskHub aufruft.
|
||||
|
||||
---
|
||||
|
||||
## Plugins entwickeln
|
||||
@@ -851,6 +1011,8 @@ ok = hmac.compare_digest(expected, request.headers.get("X-DeskHub-Signature", ""
|
||||
location ~* ^/uploads/.*\.(php\d?|phtml|phar|html?|xhtml|svgz?|xml|js)$ { return 403; }
|
||||
# Nach der Installation: Installationsassistent sperren
|
||||
location ^~ /install/ { return 404; }
|
||||
# In den PHP-Block (location ~ \.php$): Anmelde-Header der Apps an PHP weiterreichen
|
||||
# fastcgi_param HTTP_AUTHORIZATION $http_authorization;
|
||||
```
|
||||
|
||||
Diese Regeln müssen **vor** dem `location ~ \.php$`-Block stehen, weil nginx den ersten passenden Regex-Block nimmt. Danach in der **Sicherheitsprüfung** kontrollieren, dass alles gesperrt ist.
|
||||
@@ -867,7 +1029,7 @@ ok = hmac.compare_digest(expected, request.headers.get("X-DeskHub-Signature", ""
|
||||
4. **`app_key`** in `config/config.php` setzen (der Installer tut das) und nie ändern. Die Datei nach der Installation auf nur lesbar stellen (`chmod 640`).
|
||||
5. **Ordner `install/` löschen**, **PHP-Fehleranzeige abschalten** (`display_errors = Off`), **Zwei-Faktor-Anmeldung** für alle Administratoren aktivieren (Profil → Sicherheit).
|
||||
6. **Backups** einrichten und prüfen (siehe [Backup](#backup)), den Ordner `backups/` nie öffentlich machen.
|
||||
7. **Eigenes Repository:** `config/config.php`, die Datenbank, Backups und Uploads gehören nie in ein Git-Repository. Die mitgelieferte `.gitignore` schließt sie aus.
|
||||
7. **Eigenes Repository:** `config/config.php`, die Datenbank, Backups und Uploads gehören nie in ein Git-Repository. Die mitgelieferte `.gitignore` schließt sie aus. War eine `config/config.php` schon eingecheckt, entfernt sie aus dem Repository (`git rm --cached config/config.php`): Sonst landet eine fremde Konfiguration auf dem Server, und DeskHub arbeitet mit alten Daten statt mit denen aus dem Installer. Der Installer ersetzt eine vorhandene alte `config.php` zwar, prüft die geschriebene Datei und meldet, wenn PHP noch eine ältere Version aus dem Zwischenspeicher liefert, besser ist aber, sie gar nicht erst auszuliefern.
|
||||
8. Updates installieren: Sicherheitsverbesserungen kommen mit neuen Versionen.
|
||||
|
||||
---
|
||||
@@ -883,6 +1045,7 @@ Außerdem erstellt DeskHub automatisch ein Backup vor jedem System-Update, jedem
|
||||
|
||||
**Prüfen und Wiederherstellen:**
|
||||
|
||||
- **Automatische Prüfung:** Jedes neue Backup wird sofort nach dem Erstellen geprüft (manuell, per Zeitplan, vor Updates, vor Plugin-Aktivierungen). Noch nie geprüfte Backups und solche, deren letzte Prüfung über 7 Tage her ist, werden im Hintergrund nachgeprüft, damit auch spätere Beschädigungen auffallen. Das Ergebnis steht bei jeder Sicherung in der Liste („✔ geprüft“ / „✖ defekt“). Ein defektes Backup meldet DeskHub zusätzlich per E-Mail an die Admin-Adresse. Von Hand prüfen musst du nichts; „Prüfen“ gibt es weiter für den Fall, dass du sofort nachsehen willst.
|
||||
- Jedes Backup enthält einen konsistenten Datenbank-Schnappschuss (SQLite) bzw. einen SQL-Dump (MySQL) und eine Inhaltsliste mit Prüfsummen.
|
||||
- **✔️ Prüfen** kontrolliert ein Backup, ohne etwas zu verändern. Nach jedem manuellen und automatischen Backup passiert das von selbst; schlägt es fehl, erscheint im Adminportal eine Störungsmeldung („Backup defekt“).
|
||||
- **♻️ Wiederherstellen** spielt Datenbank und (wählbar) Uploads, Plugins und App-Downloads zurück. Davor wird automatisch ein Sicherheits-Backup des aktuellen Stands erstellt. Zur Bestätigung gebt ihr `WIEDERHERSTELLEN` ein. Programmcode und `config.php` werden nie überschrieben. Ein Backup einer anderen Datenbankart (SQLite ↔ MySQL) wird abgelehnt.
|
||||
@@ -895,6 +1058,23 @@ Im Ordner `DeskHub-Webseite/` führt `php tests/run_all.php` alle PHP-Tests nach
|
||||
|
||||
---
|
||||
|
||||
## Demo-Video neu erzeugen
|
||||
|
||||
Video und Bilder mit Beispieldaten entstehen aus einer eigenen Demo-Installation (SQLite, alles erfunden, keine Kundendaten). Nötig sind PHP 8.2, Node mit Electron (liegt in `desktop/node_modules`) und ffmpeg. Alle Befehle im Ordner `DeskHub-Webseite`:
|
||||
|
||||
```bash
|
||||
php tools/demo-video/seed_demo.php /pfad/zur/demo # Demo-Installation mit Beispieldaten anlegen
|
||||
php -S 127.0.0.1:8097 -t /pfad/zur/demo & # Demo starten (Zugang: lena@demo.example / Demo-Passwort-1234)
|
||||
../desktop/node_modules/.bin/electron tools/demo-video/capture.js /pfad/zu/bildern # Weboberfläche aufnehmen
|
||||
../desktop/node_modules/.bin/electron tools/demo-video/capture_app.js /pfad/zu/bildern 50 # Windows-Programm aufnehmen
|
||||
../desktop/node_modules/.bin/electron tools/demo-video/capture_titles.js /pfad/zu/bildern 1.0.28 # Titel- und Abspannbild
|
||||
bash tools/demo-video/build_video.sh /pfad/zu/bildern docs/video # Video (mp4) und GIF-Vorschau bauen
|
||||
```
|
||||
|
||||
Die Reihenfolge im Video ergibt sich aus den Dateinamen der Bilder. Die Bildunterschriften stehen in `capture.js` und `capture_app.js`.
|
||||
|
||||
---
|
||||
|
||||
## Hilfe, etwas funktioniert nicht
|
||||
|
||||
- **Admin-Protokoll** (Adminportal → Admin-Protokoll): Änderungen und fehlgeschlagene automatische E-Mails mit genauer Fehlermeldung.
|
||||
@@ -903,4 +1083,5 @@ Im Ordner `DeskHub-Webseite/` führt `php tests/run_all.php` alle PHP-Tests nach
|
||||
- **Rotes oder gelbes Banner oben:** Das ist eine Störungsmeldung der Überwachung, siehe [Überwachung und Störungsmeldungen](#überwachung-und-störungsmeldungen).
|
||||
- **„Datenbank veraltet“:** Unter System-Update auf „Datenbank aktualisieren“ klicken.
|
||||
- **Ein Plugin macht Probleme:** Unter Plugins deaktivieren. Lässt sich die Seite nicht mehr öffnen, hilft die Datei `plugins/.disabled`.
|
||||
- **Die App meldet „Ein gültiges Bearer-Token ist erforderlich“:** Der Webserver reicht den Anmelde-Header der App nicht an PHP weiter (typisch bei Apache mit PHP-FPM/FastCGI, z. B. Plesk). Anmelden funktioniert noch, jede weitere Anfrage scheitert. Die mitgelieferte `.htaccess` enthält die nötigen Regeln (neue Dateien hochladen). Auf **nginx** gehört in den PHP-Block `fastcgi_param HTTP_AUTHORIZATION $http_authorization;`. Zusätzlich senden die Apps (ab dieser Version) den Wert als `X-DeskHub-Authorization`, der auf jedem Hoster ankommt. Prüfen lässt sich das mit einem Unsinns-Token: Antwortet `/api/staff/v1/dashboard.php` mit „Die Anmeldung ist abgelaufen“, kommt der Header an; antwortet sie mit „Ein gültiges Bearer-Token ist erforderlich“, nicht.
|
||||
- **Die App zeigt „Keine Verbindung“:** Erreichbarkeit der Seite im Browser prüfen. Sobald der Server wieder antwortet, verschwindet das Banner von selbst.
|
||||
|
||||
Reference in New Issue
Block a user