Berichte-Referenz

Der Bereich „Berichte“ erstellt eigene PDF-Berichte aus einer Bibliothek von Widgets. Diese Seite dokumentiert die Verhaltensweisen, Berechtigungen, das Layout-Raster und den Widget-Katalog, die das Schema allein nicht ausdrücken kann.

Die vollständige, stets aktuelle Liste der Endpoints, Parameter und Antwortfelder für die Version, die du betreibst, findest du in der interaktiven OpenAPI-Oberfläche (Swagger) unter https://<deine-octoja-instanz>/openapi/index.html.

Für eine durchgängige Anleitung zum Erstellen einer Vorlage und zum Erzeugen eines PDFs siehe Berichtsvorlage erstellen.

REST-Endpunkte

Alle Berichts-Endpunkte liegen unter /api/reports/. Die Spalte Hinweise nennt die benötigte Berechtigung (octoja nutzt eigene Berechtigungs-Policies, die nicht alle in Swagger abgebildet sind) sowie das nicht offensichtliche Verhalten.

Wichtige Verhaltensweisen

• Klonen beim Erstellen: cloneFromTemplateId muss, wenn angegeben, eine GUID-formatierte Zeichenkette sein; die neue Vorlage ist eine tiefe Kopie der rows + widgets der Quelle, einschließlich ihres deviceRules-Gerätefilters.
• UpdateValue-Wrapper: der Update-Body kapselt jedes Feld, z. B. { name?: { hasValue: true, value }, rows?: { hasValue: true, value }, orientation?: { hasValue: true, value }, deviceRules?: { hasValue: true, value } }. Die Aktualisierung ist partiell — Felder, die im Body weggelassen werden (oder ohne hasValue: true gesendet werden), bleiben in der gespeicherten Vorlage unverändert und werden nicht gelöscht.
• Erzeugungs-Zeitraum: die optionalen rangeStart / rangeEnd (ISO-Daten) beschränken zeitfensterbezogene Widgets auf einen Berichtszeitraum — gib beide oder keinen an; lass sie weg für einen Gesamtbericht.

Schema und Felder

Die vollständige Feldliste und die Typen für ReportTemplate, ReportRow und ReportWidget findest du in Swagger. Die folgenden Felder tragen Verhalten, das das Schema nicht vermitteln kann.

• name — bei eingebauten Vorlagen ist dies ein i18n-Schlüssel (z. B. pages.reports.builtIns.executiveSnapshot.name), bei Anzeige lokalisiert; bei eigenen Vorlagen ist es die wörtliche Benutzereingabe.
• isBuiltIn — nur Antwort / abgeleitet. Wird serverseitig aus einer Allowlist eingebauter IDs berechnet und nicht auf der Entität gespeichert; true für Vorlagen, die mit octoja ausgeliefert werden, false für mandanteneigene Vorlagen.
• slug — Basis für den PDF-Download-Dateinamen. Nur eingebaut — executive-snapshot erzeugt executive-snapshot-2026-04-20.pdf; eigene Vorlagen fallen auf einen slugifizierten name zurück (Standard null).
• iconName — Lucide-Icon-Komponentenname auf der Vorlagenkarte. Nur eingebaut (Standard null).
• orientation — Portrait (Standard) oder Landscape. Landscape passt breite Tabellen wie das Hardware-Inventar; ein ungültiger Wert liefert 400 Bad Request.
• deviceRules — der berichtsweite Gerätefilter, gespeichert auf der Vorlage (Schaltfläche Gerätefilter auf der Vorlagenseite). Eine Liste von Regelgruppen, die mit ODER verknüpft sind; jede Gruppe trägt einen match-Modus (All oder Any) und eine Liste von Regel-Elementen — dieselbe Satzbaukasten-Form wie bei Tag-Regeln. Standardmäßig leer, was jedes Gerät im Geltungsbereich bedeutet. Siehe Geltungsbereich-Semantik.
• columnSpan (Widget) — Anzahl belegter Raster-Spalten (Standard 1). Pro Widget begrenzt; jeder Widget-Typ deklariert seinen eigenen minColumnSpan, maxColumnSpan und defaultColumnSpan, die der Editor durchsetzt.
• rowSpan (Widget) — Höhe in Editor-Zeilen; 0 (Standard) bedeutet „Standardhöhe des Widgets verwenden“.
• config (Widget) — widget-spezifische Einstellungen, deren Form vom Widget-type abhängt; die verfügbaren Optionen findest du im Eigenschaften-Panel des Editors.
• backgroundColor (Widget) — einer aus einem festen Satz von Färbungen (Indigo, Emerald, Amber, Sky, Rose, Slate); die Hinweisbox verwendet denselben Satz.
• autoStatusColor (Widget) — bei true färben sich datengetriebene Widgets (KPI-Karten, Tachos) selbst nach Schweregrad des Wertes ein (grün OK, orange Warnung, rot Kritisch). Hat keine Wirkung auf Widgets, die keine Auto-Status-Schwellen deklarieren.

Eine ReportRow hat keine eigenen konfigurierbaren Eigenschaften — sie gruppiert Widgets horizontal und löst einen natürlichen Seitenumbruch aus, wenn das Raster keinen Platz mehr hat.

Das Vier-Spalten-Raster

Die Berichts-Leinwand ist ein festes Vier-Spalten-Raster. Der columnSpan eines Widgets gibt an, wie viele der vier Spalten es belegt. Eine Zeile kann jede Kombination von Widgets enthalten, deren columnSpan-Werte in Summe höchstens vier ergeben. Fügst du ein fünftes Widget zu einer Zeile hinzu, deren Summe bereits vier ist, platziert octoja es in einer neuen Zeile.

Typische Spans: 1 = viertelbreit (KPI-Karten, kleine Tachos); 2 = halbbreit (Info-Karten, Diagramme); 3 = drei Viertel (breite Tabelle neben einer schmalen Karte); 4 = vollbreit (Hero-Diagramme, Tabellen, die jede Spalte brauchen).

Widget-Katalog

Widgets sind in sechs Kategorien gruppiert — KPI-Karten, Diagramme, Tabellen, Info-Karten, Layout und Checks. Die Hinweise unten erfassen die Geltungsbereich-Sensitivität jedes Widgets und nicht offensichtliches Verhalten; GET /api/reports/widgets/available liefert den verbindlichen Live-Katalog für den aktuellen Build. Sofern nicht anders vermerkt, ist jedes Daten-Widget geltungsbereich-sensitiv (es berücksichtigt die Kunde-/Standort-Filter des Berichts).

KPI-Karten (Kpi)

Einzelwert-Indikatoren mit farbiger Kopfzeile und optionaler Auto-Status-Färbung. Der Katalog ist umfangreich und wächst mit dem Produkt — Beispiele sind Geräte gesamt, Online-Geräte, Offene Meldungen (Anzahl nicht geschlossener Meldungen — jeder Status außer Closed), Health Score, Geräte mit wenig Speicher, Patch-Compliance, Zertifikate ≤30 Tage, sowie KPIs für Aktivität, Backup, Monitoring, Lywand, Software-Inventar und Vorfälle. Alle KPI-Karten sind geltungsbereich-sensitiv. Patch-Compliance, Endpunktschutz und die entsprechenden Säulen der Management-Scorecard schließen Netzwerkgeräte aus; Patch-Compliance wertet nur Server und Workstations aus, Endpunktschutz nur die in seiner Konfiguration unterstützten Geräteklassen. Gibt es für eine Säule kein berechtigtes Gerät, bleibt sie unbekannt und fließt nicht als null Punkte in die Gesamtbewertung ein.

Mehrere KPI-Karten beziehen ihren Wert aus einem bestimmten Monitoring-Check statt aus dem Geräte-Inventar und zeigen deshalb einen Platzhalter —, solange dieser Check keinen Geräten im Geltungsbereich des Berichts zugewiesen ist:

• Verfügbarkeit — durchschnittliche Online-Verfügbarkeit über den Berichtszeitraum, berechnet aus dem gespeicherten Verlauf des Checks Gerät online (der Anteil der aufgezeichneten Messungen, die Ok zurückgeliefert haben). Ausgewertet werden nur Geräte, denen dieser Check zugewiesen ist; die Karte lässt sich zusätzlich auf bestimmte Geräte einschränken (Standard Alle Geräte) oder über einen eigenen Gerätefilter. Ist kein Berichtszeitraum gesetzt, fällt das Zeitfenster auf die letzten 30 Tage zurück. Auto-Status-Schwellen: 95 % oder mehr Ok, 80 % oder mehr Warnung, darunter Kritisch.
• Sophos-Schutz aktiv — die Anzahl der Geräte, deren Check Sophos Antivirus zuletzt Ok zurückgeliefert hat, bezogen auf die Geräte im Geltungsbereich, denen dieser Check zugewiesen ist. Dieselben Auto-Status-Schwellen: Sind 95 % oder mehr dieser Geräte geschützt, ist das Ok, 80 % oder mehr Warnung, darunter Kritisch.
• SLA-Incidents — wie viele Incidents (ununterbrochene Folgen von Warnung- oder Kritisch-Ergebnissen) der ausgewählte Check im Berichtszeitraum verzeichnet hat.
• Mittlere Behebungszeit — durchschnittliche Dauer in Stunden, die diese Incidents bis zur Behebung gebraucht haben. Incidents, die am Ende des Zeitfensters noch offen sind, bleiben außen vor, weil ihre Dauer noch nicht feststeht. Auto-Status-Schwellen: 4 Stunden oder weniger Ok, 24 Stunden oder weniger Warnung, alles darüber Kritisch.
• Service-Verfügbarkeit (zeitgewichtet) — der Anteil der überwachten Zeit im Zeitraum, in dem kein Incident offen war. Auto-Status-Schwellen: 99 % oder mehr Ok, 95 % oder mehr Warnung, darunter Kritisch.

Die drei SLA-Karten erwarten einen Check und optional eine Geräteliste; sie ergänzen die Tabelle SLA-Incidents in der eingebauten Vorlage SLA-Bericht.

Diagramme (Chart)

• Gerätealter (Balkendiagramm) — Histogramm der Geräte nach Altersband (z. B. < 1 J, 1–3 J, 3–5 J, > 5 J).
• Betriebssystemverteilung (Balkendiagramm) — Geräte gruppiert nach Betriebssystem-Familie.
• Gerätetypen (Donut) — Geräte gruppiert nach Typ (Workstation, Server usw.).
• Festplattennutzung (Donut) — Geräte gruppiert nach Gesamt-Festplattennutzungs-Bucket.
• Meldungen nach Priorität (Donut) — nicht geschlossene Meldungen gruppiert nach Priorität. Geschlossene Meldungen sind ausgeschlossen, passend zur KPI „Offene Meldungen“.
• Aktivität nach Quelle (Donut) — Aktivitätsereignisse gruppiert nach Quelle.

Tabellen (Table)

• Alle Geräte — Geräte mit Name, OS, Zuletzt gesehen und Zustand.
• Neueste Meldungen — neueste Meldungen mit Titel, Status, Priorität, Kunde und Datum.
• Zertifikate-Ablaufliste — Zertifikate, die bald ablaufen, gruppiert nach verbleibenden Tagen.
• Festplattenbelegung — Geräte sortiert nach geringstem freien Speicher.
• Top-Hersteller — Geräte gruppiert nach Hardware-Hersteller.
• Incident-Zeitleiste — chronologische Liste der Vorfälle innerhalb des Geltungsbereichs.
• Backup-Status — Läufe von Backup-Jobs mit Ziel, Status und letztem Erfolg.
• Lokale Benutzer — lokale Konten auf den Geräten des Geltungsbereichs.
• Schwachstellen — Schwachstellen-Funde, die über die Lywand-Integration eingespielt werden.
• Monitoring-Übersicht — Monitoring-Check-Status über die Geräte. Einzelne Checks lassen sich über die Einstellung Checks ausblenden aus der Tabelle heraushalten.
• Checks ohne Alarmierung (Tabelle) — Checks, die Geräten im Geltungsbereich zugewiesen sind, für die aber keine Alarmierung eingerichtet ist, mit Gerät, Check und dem Konfigurationspaket, aus dem die Zuweisung stammt. Berücksichtigt ebenfalls Checks ausblenden.
• Remote-Zeiten (Tabelle) — Remote-Support-Zeiten auf den Geräten des Geltungsbereichs im Berichtszeitraum, mit Startzeit, Techniker, Gerät und Dauer. Über Gruppierung wechselst du zwischen einer Zeile pro Sitzung, pro Gerät und pro Techniker; das Widget hat zudem einen eigenen Gerätefilter. Nur die ungruppierte Ansicht pro Sitzung zeigt zusätzlich die Notiz zur Remote-Sitzung; bei Gruppierung nach Gerät oder Techniker wird sie ausgeblendet. Ist kein Berichtszeitraum gesetzt, fällt das Zeitfenster auf die letzten 30 Tage zurück. Es ist das Kernstück der eingebauten Vorlage Remote-Zeiten.
• Meistinstallierte Software — die am häufigsten installierten Software-Titel über die Geräte des Geltungsbereichs.
• Softwareänderungen (Tabelle) (table-software-changes) — installierte, aktualisierte und deinstallierte Software, neueste Änderung zuerst. Eine Aktualisierung ist ein entferntes und hinzugefügtes gleichnamiges Produkt innerhalb derselben Inventaränderung; sie zeigt vorherige und neue Version. Initialinventare (baseHash fehlt) werden ausgeschlossen. Das Widget berücksichtigt Zeitraum, Kunde, Standort, Gerätefilter und Benutzerumfang. config.limit ist standardmäßig 500; das gemeinsame Eigenschaften-Panel akzeptiert 1 bis 1.000.
• Hardware-Inventar — eine Zeile pro Gerät mit einer konfigurierbaren Auswahl an Hardware-Feldern, gruppiert in System, Identität, CPU, Speicher, Datenträger und Netzwerk. Das optionale Systemfeld Registriert am (enrolledAt) gibt das Einbindungsdatum als Datum aus und gehört nicht zum Standardsatz.
• Patch-Verlauf — installierte Updates pro Gerät, mit KB-Nummer und Installationsdatum.
• Offene Patches — pro Gerät noch ausstehende Updates. Hat einen eigenen Gerätefilter, der zusätzlich zum berichtsweiten greift.

Patch-Leistungsnachweis und aktueller Status

Die Vorlage Patch-Leistungsnachweis dokumentiert abgeschlossene Arbeit: Die Aktivitätstabelle zeigt pro Gerät und Update den letzten abgeschlossenen Versuch innerhalb des gewählten Zeitraums, ohne Zeitraum über alle verfügbaren Ergebnisse. Sie zählt nicht jeden Wiederholungsversuch als zusätzliche Arbeit. Definitionsupdates sind standardmäßig vollständig enthalten.

Aktueller Patch- und Handlungsstatus beantwortet dagegen, was noch zu tun ist. Die Tabelle geht von ausstehenden Updates im Geräteinventar aus und ergänzt den letzten Ausführungs- und Freigabestatus. Ein freigegebenes Update ist deshalb noch kein installiertes Update. Definitionsupdates werden standardmäßig auf das neueste je Gerät und Definitionsfamilie reduziert.

Beide Tabellen erlauben für Definitionsupdates Latest, All oder Exclude; das Zeilenlimit ist standardmäßig 500, maximal 1000. Die Zusammenfassung vollständig gepatchter Geräte zählt Geräte mit vorhandenem Inventar und ohne ausstehende Updates, geteilt durch alle ausgewählten Geräte. Fehlendes Inventar zählt nicht als vollständig gepatcht; das Alter des Inventars wird dabei nicht geprüft. Kontrolliere daher zusätzlich, wann Geräte zuletzt gemeldet haben.

Info-Karten (Info)

• Geräteübersicht — serverseitig aufgelöste Übersicht der Geräte im Geltungsbereich (Summen + Aufschlüsselung).
• Kundenaufschlüsselung — serverseitig aufgelöste Kunden-Übersicht (Namen + Anzahl), gefiltert nach Kunde und Standort des Berichts.
• Management-Scorecard — ein Gesamtwert mit Ampelstatus, aufgeteilt in Säulen, die dieselben Grün-/Orange-/Rot-Bänder verwenden wie die jeweils passenden einzelnen KPI-Karten. Einzelne Checks lassen sich über Checks ausblenden aus dem Wert heraushalten.
• Tacho (statisch) — einzelner Tacho mit konfigurierbarem Wertebereich und Schweregrad-Schwellen. Vom Autor bereitgestellter Wert — fragt keine Live-Daten ab und ist nicht geltungsbereich-sensitiv.
• Ampel-Gitter — vom Autor gepflegtes Gitter aus Status-Zellen (Ok / Warning / Critical / Unknown). Vom Autor vorgegeben und nicht geltungsbereich-sensitiv.

Checks (Checks)

• Check-Detail — Details für einen oder mehrere Checks (aktueller Status, letztes Ergebnis, Konfigurations-Zusammenfassung), mit letztem Benutzer und letzter Sichtung des Geräts. Das Limit gilt pro Check; eine Änderung der Check-Auswahl leert die bisherige Geräteauswahl.
• Check-Verlauf (pro Gerät) — Ergebnisverlauf eines einzelnen Checks pro Gerät, ein Eintrag je Gerät mit seinem jüngsten Trend. Lässt sich auf bestimmte Geräte oder Status einschränken.
• Check-Status-Timeline — Zeitleiste der Status-Übergänge eines einzelnen Checks über den Geltungsbereich.
• Check-Statusverteilung (Donut) — Ergebnisverteilung eines ausgewählten Checks (Ok / Warnung / Kritisch / Unbekannt).
• Check-Statusverlauf (Diagramm) — Zeitreihe des Ergebnisverlaufs eines ausgewählten Checks über den Geltungsbereich.
• Check-Erfolgsrate — KPI-Karte mit dem Anteil der Geräte, deren letztes Ergebnis für einen ausgewählten Check Ok ist. Lässt sich auf bestimmte Geräte oder Status einschränken. Auto-Status-Schwellen: über 90 % Ok, über 70 % Warnung, darunter Kritisch.
• Check-Ergebnisse (Tabelle) — Pro-Gerät-Ergebnisse für einen ausgewählten Check (Status, Wert, zuletzt ausgewertet).
• Check-Alarmierung je Gerät — pro Gerät das letzte Ergebnis eines ausgewählten Checks zusammen mit seiner Alarmierungslage: keine Alarmierung eingerichtet, Alarmierung eingerichtet und ruhig, oder aktuell offener Alarm. Begrenzt durch das Limit des Widgets (Standard 50).
• SLA-Incidents — jeder Incident (eine ununterbrochene Folge von Warnung- oder Kritisch-Ergebnissen) eines ausgewählten Checks im Berichtszeitraum, mit Gerät, Beginn, Behebung, Dauer und schlechtestem Status. Die Tabelle gibt das Zeitfenster aus, das die Zahlen tatsächlich abdecken: Check-Ergebnisse werden 30 Tage vorgehalten, ein längerer Zeitraum liefert also nur die noch vorhandene Historie. Begrenzt durch das Limit (Standard 50).
• Sophos-Status (Tabelle) — Sophos-Details pro Gerät aus dem Check Sophos Antivirus: Gerät, Status, Echtzeitschutz, Signaturen aktuell, Bedrohungen, Health und Version. Es erscheinen nur Geräte, denen dieser Check zugewiesen ist; die Zeilen sind nach schlechtestem Status zuerst sortiert und durch das Limit des Widgets begrenzt (Standard 50). Die eingebaute Vorlage Sophos-Bericht kombiniert diese Tabelle mit der KPI Sophos-Schutz aktiv.

Layout (Layout)

Strukturelle Widgets — keine Live-Daten und nicht geltungsbereich-sensitiv.

• Überschrift — Text einer Abschnittsüberschrift.
• Absatz — Fließtext.
• Hinweisbox — farbige Callout-Box mit einer der sechs Hintergrundfarben.
• Stichpunktliste — Stichpunktliste mit Markierungs-Stil Dot, Check oder Dash.
• Trennlinie — horizontale Linie.
• Abstand — vertikaler Leerraum.
• Seitenumbruch — erzwingt an dieser Stelle einen Seitenumbruch im PDF.

Geltungsbereich-Semantik

Beim Erzeugen eines Berichts trägt das Request-Payload customerId? und siteId? — beide optional, eine siteId ist nur sinnvoll in Kombination mit einer customerId. Der Renderer schränkt die Datenabfrage jedes geltungsbereich-sensitiven Widgets auf diesen Kunden (und optional den Standort) ein.

Widgets, die nicht geltungsbereich-sensitiv sind (Tacho, Ampel-Gitter und alle Layout-Widgets), ignorieren den Geltungsbereich — ihr Inhalt ist vom Autor vorgegeben und rendert unabhängig von customerId / siteId gleich.

Kunde und Standort werden nicht in der Vorlage gespeichert. Sie sind Parameter zur Erzeugungszeit — dieselbe Vorlage kann je nach übergebenen Werten einen mandantenweiten, einen kundenbezogenen oder einen standortbezogenen Bericht erzeugen.

Der Gerätefilter ist der eine Teil des Geltungsbereichs, der doch in der Vorlage gespeichert wird. Das Feld deviceRules enthält Regelgruppen, die mit ODER verknüpft sind (ein Gerät passt, sobald es eine Gruppe erfüllt); jedes gerätebezogene Widget wird zusätzlich zum Kunde-/Standort-Geltungsbereich auf die passenden Geräte eingeschränkt. Case-Widgets werden nicht gerätegefiltert. Du setzt den Filter über die Schaltfläche Gerätefilter auf der Vorlagenseite, aktualisierst ihn über das deviceRules-UpdateValue, und beim Klonen einer Vorlage wird er zusammen mit den rows mitkopiert. Ein Filter kann unter anderem auf den Gehäusetyp zugreifen.

Der angeforderte Geltungsbereich kann den Zugriff des angemeldeten Benutzers nie erweitern. Vorschau und PDF-Erzeugung schneiden Geräte, Kunden, Fälle und Zeiteinträge zusätzlich mit dessen aktuellem Gruppenbereich. Das gilt auch für Widget-Auswahllisten. Ein Benutzer ohne erreichbare Geräte erhält keine Gerätedaten, auch wenn der Kunde-/Standort- oder Gerätefilter passen würde.

Eingebaute vs. eigene Vorlagen

Beide Typen teilen sich Schema und Editor-Erfahrung. Die Unterschiede sind verhaltensbezogen:

• Erstellt von — eingebaut wird mit octoja geliefert; eigen wird von dir erstellt.
• name — eingebaut ist ein i18n-Schlüssel (bei Anzeige lokalisiert); eigen ist die wörtliche Benutzereingabe.
• slug / iconName — bei eingebauten gesetzt (slug steuert den PDF-Dateinamen, iconName das Kartensymbol); bei eigenen null (Dateiname aus name slugifiziert, generisches Vorlagensymbol).
• Bearbeiten — eingebaute sind schreibgeschützt; vorher klonen, um anzupassen. Eigene Vorlagen sind bearbeitbar.
• Löschen — eingebaute sind serverseitig geschützt; eigene Vorlagen sind löschbar.
• Duplizieren — für beide erlaubt und erzeugt stets eine neue eigene Vorlage.

Berechtigungen

Der Bereich „Berichte“ nutzt zwei Berechtigungen:

• reports.view — Vorlagen auflisten und öffnen, die Editor-Vorschau rendern, ein PDF erzeugen sowie Zeitpläne auflisten und öffnen.
• reports.manage — eigene Vorlagen erstellen, bearbeiten, löschen und umbenennen; die Widget-Palette und ihre Check-Geräte-Auswahl lesen; Zeitpläne erstellen, aktualisieren, löschen oder sofort ausführen.

Beide werden über Gruppen unter Administration → Gruppen vergeben.

PDF-Dateiname

Der Dateiname des erzeugten PDFs wird durch den content-disposition-Header der Antwort gesetzt:

• Eingebaute Vorlage: <slug>-<jjjj-mm-tt>.pdf (z. B. executive-snapshot-2026-04-20.pdf).
• Eigene Vorlage: <slugifizierter-name>-<jjjj-mm-tt>.pdf (z. B. quarterly-customer-review-2026-04-20.pdf).

Das Datum ist das Erzeugungsdatum. Das Datenfenster des Berichts ist eine separate Einstellung: der optionale Berichtszeitraum rangeStart / rangeEnd beim Erzeugen-Aufruf (der Zeitraum-Wähler in der UI, mit den Vorgaben Gesamter Zeitraum, Aktueller Monat, Letzter Monat und Benutzerdefiniert). Zeitfensterbezogene Widgets berücksichtigen ihn; Momentaufnahme-Widgets wie die Inventar-Tabellen zeigen stets den aktuellen Stand.

PDF-Sprache

Der Erzeugen-Aufruf nimmt einen expliziten Parameter language entgegen, und die Vorlagenseite hat neben der Download-Schaltfläche eine Auswahl Sprache. Wählst du dort eine Sprache, kommt das PDF in dieser Sprache heraus — unabhängig davon, worauf die Oberfläche eingestellt ist. Die Auswahl startet auf deiner aktuellen UI-Sprache.

Unterstützte Werte sind en, de, fr und nl; jeder andere Wert liefert 400 Bad Request. Fehlt language im Request, fällt das PDF auf die Sprache aus dem Header Accept-Language zurück. Der Vorschau-Endpunkt des Editors nimmt denselben Parameter mit demselben Rückfallverhalten.

Zeitpläne

Berichte können automatisch und wiederkehrend zugestellt werden. Ein Zeitplan bündelt eine oder mehrere Berichtsvorlagen mit einem Cron-Ausdruck und einer Menge von Empfängern; wird der Zeitplan ausgelöst, erzeugt octoja jede Vorlage als PDF und versendet sie per E-Mail an die Empfänger. Die Berichtsseite hat einen Eintrag Zeitplanung, der diesen Verwaltungsbereich öffnet.

• cron — ein standardmäßiger 5-Feld-Cron-Ausdruck, ausgewertet in der Zeitzone der Instanz (per Vorgabe Europe/Berlin; UTC nur dann, wenn für die Instanz keine gültige Zeitzone konfiguriert ist). Er wird beim Speichern geprüft; ein ungültiger Ausdruck liefert 400 Bad Request.
• receivers — ein oder mehrere Einträge mit optionaler customerId, einer Liste siteIds, Empfänger-emails und language. Ohne Kunde umfasst der Empfänger alle Kunden; das darf nur mit globalem Kundenzugriff gespeichert werden, und siteIds muss leer sein. Bei leerer Liste entsteht je Vorlage ein PDF über den gesamten Kunden beziehungsweise alle Kunden. Bei mehreren Standort-IDs entsteht je Vorlage und Standort ein eigenes PDF; alle Standorte müssen zum gewählten Kunden gehören. Gleichnamige Anhänge erhalten bei Bedarf einen Nummernzusatz.
• language (pro Empfänger) — die Auswahl Sprache in jeder Empfängerzeile. Seine PDFs und die Zustell-E-Mail entstehen in dieser Sprache, sodass ein Zeitplan aus denselben Vorlagen einen deutschen und einen französischen Kunden bedienen kann. Dieselben unterstützten Werte wie beim Erzeugen-Aufruf (en, de, fr, nl); jeder andere Wert liefert beim Speichern 400 Bad Request. Empfänger, die vor diesem Feld angelegt wurden, tragen keinen Wert und fallen auf Englisch zurück, bis du einen setzt.
• enabled — ein deaktivierter Zeitplan bleibt erhalten, wird aber nie ausgelöst; die nächste Ausführungszeit wird nur berechnet, solange er aktiviert ist.
• subject — optionale eigene Betreffzeile für die Zustell-E-Mail; leer lassen für den Standard.

Beim Erstellen oder Aktualisieren speichert octoja den aktuellen Benutzer als Ausführenden. Jeder geplante Lauf wertet dessen aktuelle Berechtigungen sowie Kunden-, Geräte-, Fall- und Zeiteintrag-Geltungsbereiche neu aus. Fehlt reports.view, globaler Kundenzugriff für einen Alle-Kunden-Empfänger oder Zugriff auf einen ausdrücklich gewählten Kunden, schlägt der gesamte Lauf geschlossen fehl. Der Gerätefilter einer Vorlage kann diesen Benutzerumfang nur weiter verkleinern. Deshalb erfordern Erstellen und Aktualisieren sowohl reports.manage als auch reports.view; Löschen und Jetzt ausführen erfordern reports.manage, Auflisten und Ansehen nur reports.view.

Verwandte Artikel

• Berichtsvorlage erstellen — durchgängige Anleitung.