Dateiverwaltung¶
Effektives Dateimanagement ist ein entscheidender Aspekt für den reibungslosen Betrieb und die Sicherheit jedes Unternehmens. Es umfasst die Organisation, Speicherung, Sicherung und den Zugriff auf digitale Informationen. Ein gut strukturiertes Dateimanagement-System erhöht nicht nur die Produktivität, sondern gewährleistet auch die Datensicherheit und erleichtert die Zusammenarbeit zwischen Teammitgliedern.
In dieser Sektion werden wir die verschiedenen Aspekte des Dateimanagements behandeln, einschließlich Best Practices, Technologien und Strategien zur Optimierung der Dateiverwaltung. Besonderes Augenmerk legen wir dabei auf die Gewährleistung der Geschäftskontinuität, wie am Beispiel des Plans für den Zugriff auf Kundenzertifikate bei Serverstörungen deutlich wird.
Business Continuity Plan für den Zugriff auf Kundenzertifikate bei Serverstörung
Einstellungen
DMS Browser
Einstellungen¶
Die Struktur des Moduls umfasst drei wesentliche Teilbereiche:
- Dateieinstellungen
- File Links
- Einstellungen externe Dokumente
1. Dateieinstellungen¶
Die dargestellte Maske dient der Konfiguration von Dateizuordnungen innerhalb eines datenbankgestützten Dokumentenmanagements. Administratoren definieren hier, in welchen Modulen (z. B. INVENTORY, REPAIR, WIKI) welche Dokumente über bestimmte Datenbankspalten referenziert sind und in welche DMS-Verzeichnisse die zugehörigen Dateien systematisch abgelegt oder gefunden werden sollen. Zusätzlich können feingranulare Sichtbarkeitsregeln definiert werden.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | Tabellenverknüpfung | Gibt an, zu welcher Haupttabelle (z. B. INVENTORY, REPAIR, WIKI) die Dateizuweisung gehört. |
| ② | Spalte | Interne technische Bezeichnung der Spalte, in der die Dateiinformation gespeichert wird. |
| ③ | Spalten Label | Anzeigename für die Spalte im UI; für Endnutzer lesbar und verständlich benannt. |
| ④ | Zuordnung | Platzhalter-Logik zur dynamischen Benennung oder Kategorisierung von Dateien. |
| ⑤ | Verzeichnisname | Zielverzeichnis innerhalb des DMS, in dem die Dateien abgelegt oder gefunden werden. |
| ⑥ | Nur Rollen-basiert freigegebene Dateien anzeigen | Beschränkt die Sichtbarkeit auf Benutzer mit bestimmten Rollen. |
| ⑦ | Nur Gruppen-basiert freigegebene Dateien anzeigen | Beschränkt die Sichtbarkeit auf Benutzer in bestimmten Gruppen. |
| ⑧ | Aktionen | Kontextmenü zur Bearbeitung oder Löschung des jeweiligen Dateieintrags. |
Typische Nutzungsszenarien und Abläufe¶
- Pflege von Dokumentenfeldern in Modulen:
- Neue Datenbankfelder zur Dokumentenverknüpfung werden erstellt (z. B.
inventory_doc_1) und hier konfiguriert. - Die Dateizuweisung erfolgt dabei über den Feldnamen (②), eine sprechende Bezeichnung (③) sowie das Zielverzeichnis (⑤).
- Neue Datenbankfelder zur Dokumentenverknüpfung werden erstellt (z. B.
- Verzeichniszuordnung:
- Für jede Datei wird definiert, in welchem Ordner des DMS sie abgelegt ist (z. B. „manuals“, „certificates“).
- Dies erlaubt eine klare Trennung und Wiederauffindbarkeit von Dokumenttypen.
- Dynamische Pfadzuweisungen mit Platzhaltern:
- Über das Feld „Zuordnung“ (④) kann eine automatisierte Benennung oder Pfadgenerierung erfolgen, z. B. mit Werten aus Formularfeldern (
{name},{RTAG}).
- Über das Feld „Zuordnung“ (④) kann eine automatisierte Benennung oder Pfadgenerierung erfolgen, z. B. mit Werten aus Formularfeldern (
- Zugriffskontrolle auf Dateiebene:
- Die Sichtbarkeit von Dateien kann differenziert über Rollen (⑥) oder Benutzergruppen (⑦) eingeschränkt werden.
- So lassen sich beispielsweise sensible Zertifikate nur für Administratoren zugänglich machen.
Funktionale und technische Hinweise¶
- Tabellenverknüpfung (①):
- Definiert das zugehörige Modul bzw. Datenobjekt (z. B. INVENTORY = Inventarverwaltung).
- Diese Zuweisung ist entscheidend für das Zusammenspiel mit der Datenstruktur im Backend.
- Technische Spaltenbezeichnung (②):
- Wird systemintern genutzt, um Dateifelder zu identifizieren und zu referenzieren.
- Muss exakt mit der Bezeichnung in der Datenbank übereinstimmen.
- Label (③):
- Dieser Wert wird im Frontend angezeigt, z. B. im Benutzerformular oder bei Datei-Uploads.
- Zuordnung mit Platzhaltern (④):
- Unterstützt die dynamische Erstellung von Pfad- oder Dateinamensbestandteilen.
- Platzhalter wie
{C2396}oder{14202}beziehen sich auf Datenfelder aus verknüpften Objekten.
- Verzeichnisname (⑤):
- Zielverzeichnis innerhalb des DMS, in dem die Dateien physisch abgelegt oder gesucht werden.
- Muss exakt mit der Verzeichnisstruktur im DMS übereinstimmen.
- Rollensichtbarkeit (⑥) und Gruppensichtbarkeit (⑦):
- Einträge in diesen Spalten definieren, für wen die Datei sichtbar ist, sofern keine Freigabe erfolgt.
- „Leer“ bedeutet: keine Einschränkung – Datei ist für alle sichtbar.
- Aktionen (⑧):
- Bearbeiten: Öffnet eine Eingabemaske zur Anpassung aller Felder.
- Löschen: Entfernt die Dateizuweisung aus der Konfiguration, jedoch nicht die physische Datei.
Abgrenzung¶
Diese Dokumentation beschreibt ausschließlich die funktionale Logik der Dateiverknüpfungskonfiguration auf Tabellenebene. Die physikalische Dateiablage, Uploadprozesse oder Benutzerinteraktionen beim Öffnen werden hier nicht behandelt.
2. File Links¶
Die Konfigurationsmaske „File Links“ erlaubt es Administratoren, spezifische Aktionen oder Verlinkungen für Dateien mit bestimmten Erweiterungen in definierten Ordnern zu hinterlegen. Dadurch können Dateien direkt mit externen Programmen, Ausführungskommandos oder symbolischen Icons versehen werden. Diese Funktion ist besonders relevant für komplexe DMS-Integrationen, in denen Dateiaktionen über einfache Downloads hinausgehen.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | Linked Folder | Gibt den DMS-Ordner an, für den der Link gilt bzw. mit dem die Dateioperation verknüpft ist. |
| ② | File Extension | Bestimmt die Dateiendung, auf die die definierte Verlinkung angewendet wird (z. B. .pdf). |
| ③ | Link | Definiert die URL, den Dateipfad oder Befehl, der beim Zugriff auf eine Datei ausgeführt wird. |
| ④ | Icon | Symbolische Darstellung für den Dateityp oder die Linkaktion im Frontend. |
| ⑤ | Aktionen | Menü zur Bearbeitung oder Löschung der definierten Verlinkung. |
Typische Nutzungsszenarien und Abläufe¶
- Dateiaufruf über benutzerdefinierten Befehl:
- Für bestimmte Dateitypen (z. B.
.pxe) können über das Feld „Link“ (③) externe Kommandos definiert werden, die z. B. ein Spezialprogramm mit Parametern starten.
- Für bestimmte Dateitypen (z. B.
- Symbolische Darstellung im DMS:
- Über das Icon-Feld (④) wird die Datei im UI mit einem passenden Symbol versehen (z. B. PDF-Icon für
.pdf). - Dies erhöht die visuelle Orientierung für Endanwender im Dateibrowser.
- Über das Icon-Feld (④) wird die Datei im UI mit einem passenden Symbol versehen (z. B. PDF-Icon für
- Verzeichnisspezifische Regelung:
- Die Konfiguration erfolgt pro „Linked Folder“ (①), sodass z. B. unterschiedliche Regeln für „manuals“ und „procedures“ gelten können.
Funktionale und technische Hinweise¶
- Linked Folder (①):
- Bezieht sich auf einen Ordner im DMS, in dem die Regel zur Anwendung kommt.
- Die Verlinkung wirkt nur, wenn eine Datei im entsprechenden Verzeichnis gespeichert ist.
- File Extension (②):
- Nur Dateien mit dieser Endung (z. B.
.pdf,.pxe) werden von der Regel betroffen. - Groß-/Kleinschreibung ist zu beachten, falls das System zwischen
.PDFund.pdfunterscheidet.
- Nur Dateien mit dieser Endung (z. B.
- Link (③):
- Unterstützt sowohl klassische Pfade (
file://...) als auch ausführbare Kommandos (z. B.mcruntime). - Platzhalter wie
{documentfile}oder{14201}können verwendet werden, um dynamische Pfade oder Parameter zu übergeben.
- Unterstützt sowohl klassische Pfade (
- Icon (④):
- Wird als CSS-Klassenname oder Referenz auf eine Icon-Bibliothek hinterlegt (z. B.
file-pdf-o,cloud-upload). - Diese Darstellung erscheint direkt im Dateibrowser und verbessert die Benutzerführung.
- Wird als CSS-Klassenname oder Referenz auf eine Icon-Bibliothek hinterlegt (z. B.
- Aktionen (⑤):
- Bearbeiten: Öffnet ein Formular zur Anpassung der Regeldefinition.
- Löschen: Entfernt die Regel vollständig – dabei bleiben die Dateien selbst unberührt.
Abgrenzung¶
Diese Dokumentation fokussiert ausschließlich die Konfiguration von Datei-Links innerhalb der „File Links“-Verwaltung. Sie beschreibt nicht die tatsächliche Ausführung des Links, etwa das Startverhalten externer Programme oder die Verfügbarkeit verlinkter Ressourcen im Netzwerk.
3. Einstellungen externe Dokumente¶
Diese Einstellungsmaske ist Teil der Funktion zur automatischen Integration externer Dokumente in das interne Dokumentenmanagementsystem (DMS). Sie ermöglicht das kontinuierliche Monitoring eines externen Dateisystempfades und die automatisierte Überführung neu erkannter Dateien in ein spezifisches Zielverzeichnis des DMS.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | External Documents Folder | Verzeichnis auf dem Dateisystem, das auf neue externe Dokumente überwacht wird. |
| ② | Target Inbox Folder | Zielordner innerhalb des DMS, in den erkannte Dateien automatisch verschoben werden. |
| ③ | Check for new Documents Interval | Zeitintervall in Minuten, in dem das Quellverzeichnis auf neue Dokumente geprüft wird. |
Typische Nutzungsszenarien und Abläufe¶
- Automatisierter Dokumentenimport:
- Externe Anwendungen (z. B. Messgeräte, E-Mail-to-File-Gateways, Scanlösungen) speichern Dateien in einen überwachten Ordner.
- Das System erkennt neue Dateien dort automatisch und verschiebt sie zeitgesteuert in ein vordefiniertes DMS-Verzeichnis.
- Zentrale Dokumentensammlung:
- Mehrere externe Systeme können auf einen gemeinsamen Importpfad schreiben, während die DMS-Zielordner pro Datenquelle konfiguriert sind (z. B. „certificates“ für Zertifikate).
- Zeitgesteuertes Monitoring:
- Über das Feld „Check for new Documents Interval“ (③) wird die Häufigkeit der Verzeichniskontrolle angepasst, z. B. alle 5 Minuten oder alle 30 Minuten.
Funktionale und technische Hinweise¶
- External Documents Folder (①):
- Pfadangabe zu einem externen Verzeichnis, z. B. auf einem Netzlaufwerk oder lokalen Speicher.
- Der Pfad muss vom System erreichbar und lesbar sein. Schreibrechte sind nur bei Lösch-/Verschiebeoperationen erforderlich.
- Target Inbox Folder (②):
- Name des Zielordners innerhalb der DMS-Struktur, in den die Dokumente nach Erkennung automatisch einsortiert werden.
- Dieser Ordner muss vorher im DMS vorhanden sein (z. B. „certificates“).
- Check for new Documents Interval (③):
- Gibt das Prüfintervall in Minuten an.
- Zu kleine Intervalle können bei großen Datenmengen die Systemlast erhöhen; zu große Intervalle verzögern die Datenverfügbarkeit.
- Speichern & Neuer externer Ordner:
- Speichern: Übernimmt die aktuelle Konfiguration und aktiviert das Monitoring.
- Neuer externer Ordner: Ermöglicht das Anlegen zusätzlicher Überwachungsregeln für andere Pfade und Zielordner.
Abgrenzung¶
Diese Dokumentation beschreibt ausschließlich die Konfiguration zur automatisierten Überwachung und Übernahme externer Dateien. Themen wie Dateiinhaltserkennung, Formatvalidierung oder Folgeprozesse im DMS sind nicht Bestandteil dieses Abschnitts.
DMS Browser¶
DMS Verwaltung¶
Der dargestellte Bereich gehört zur DMS Verwaltung (Document Management System) und stellt die klassische Browseransicht zum Navigieren, Verwalten und Öffnen von Dokumenten innerhalb eines strukturierten Dateisystems dar. Das Modul dient der zentralen Ablage, Organisation und dem Zugriff auf Dateien wie Handbücher, Zertifikate, Wartungsprotokolle oder IT-Dokumente.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | Navigationsbaum | Dient zur Verzeichnisnavigation innerhalb des DMS (Document Management System); zeigt die Ordnerstruktur an. |
| ② | Dateiübersicht | Zeigt die im aktuell gewählten Verzeichnis befindlichen Dateien an, inklusive Dateityp (z. B. Excel-Datei). |
Typische Nutzungsszenarien und Abläufe¶
- Auffinden und Öffnen von Dokumenten:
- Benutzer navigieren über die linke Baumstruktur (①) zu einem spezifischen Ordner (z. B.
manuals) und wählen dort ein Dokument zur Anzeige oder Bearbeitung aus (②).
- Benutzer navigieren über die linke Baumstruktur (①) zu einem spezifischen Ordner (z. B.
- Pflege der Dateistruktur:
- Administratoren oder Power-User legen neue Ordner an, verschieben Dokumente oder löschen nicht mehr benötigte Dateien – typischerweise direkt über die Toolbar oberhalb der Dateiansicht.
- Verknüpfung mit anderen Modulen:
- Dokumente, die im DMS liegen, können aus anderen Systembereichen referenziert oder aufgerufen werden (z. B. in einem Ticket, Kalibrierungsbericht oder Arbeitsauftrag).
Funktionale und technische Hinweise¶
- Navigationsbaum (①):
- Zeigt die hierarchische Ordnerstruktur unterhalb eines DMS-Root-Pfads (
[Local] DMS) an. - Ordner lassen sich durch Klicken auf- oder zuklappen; die Auswahl eines Ordners aktualisiert die Dateiansicht rechts.
- Die Pfadangabe unterhalb zeigt den aktuellen Ordnerkontext (
File Manager/inbox/manuals).
- Zeigt die hierarchische Ordnerstruktur unterhalb eines DMS-Root-Pfads (
- Dateiübersicht (②):
- Im rechten Bereich werden alle Dateien im aktuell aktiven Ordner angezeigt.
- Jede Datei ist mit einem Icon versehen, das den Typ kennzeichnet (hier:
.xlsxfür Excel). - Ein Klick auf eine Datei öffnet diese entweder direkt (bei unterstützten Formaten) oder stellt sie zur Weiterverarbeitung bereit (z. B. Download oder Verlinkung).
- Technische Zusatzfunktionen (nicht markiert, aber sichtbar):
- Die obere Symbolleiste erlaubt grundlegende Dateioperationen wie Hochladen, Umbenennen, Kopieren, Ausschneiden, Löschen.
- Suchfeld oben rechts dient zur Volltextsuche im aktuellen Verzeichnis.
- Informationen zur Gesamtanzahl und Dateigröße sind unten rechts sichtbar (z. B. „Objekte: 1, Summe: 297 KB“).
Abgrenzung¶
Diese Dokumentation beschreibt ausschließlich die funktionale Struktur und Bedienlogik der markierten Navigations- und Inhaltsbereiche innerhalb des DMS-Browsers. Nicht dokumentiert sind tiefergehende Dateibearbeitungsfunktionen, Zugriffskontrollen oder Workflow-Verknüpfungen.
Business Continuity Plan für den Zugriff auf Kundenzertifikate bei Serverstörung¶
Business Continuity Plan für den Zugriff auf Kundenzertifikate bei Serverstörung in CalServer
Zielsetzung¶
Dieser Artikel beschreibt die Vorgehensweise, wie bei einer Serverstörung der Zugriff auf im Dokumentenmanagementsystem (DMS) von CalServer abgelegte Kundenzertifikate gewährleistet werden kann. Durch die automatische Erstellung einer Indexdatei (contents.csv) bei jeder Aktualisierung des DMS ist es möglich, Kundendokumente manuell zu finden und wiederherzustellen.
Vorgehensweise¶
1. Automatische Erstellung der DMS-Indexdatei¶
Bei jeder Aktualisierung des DMS (z. B. bei einem neuen Upload, einer Änderung oder einer Archivierung von Dokumenten) wird automatisch eine Indexdatei (contents.csv) erstellt. Diese Datei enthält wichtige Metadaten zu den im DMS gespeicherten Dokumenten und wird im Rahmen der CalServer-Konfiguration für Berichte automatisch generiert.
Folgende Informationen sollten in der Indexdatei mindestens festgehalten werden:
- link_table: Das Verzeichnis oder die Datenbanktabelle, in der die Datei ursprünglich abgelegt wurde.
- name: Der ursprüngliche Dateiname des Dokuments.
- hash: Der im DMS erstellte Ablagename (Hash), der als eindeutiger Identifikator für die Datei fungiert.
-
created: Das Datum, an dem die Datei in das DMS hochgeladen wurde.
Administration der Exportdatei für das DMS
Weitere optionale Parameter könnten sein:
- major_version: Diese Spalte enthält die Hauptversionsnummer des Dokuments. Im calServer Versionskontrollsystem wird die Hauptversion erhöht, wenn ein Release, also eine Freigabe zum Dokument erstellt wird. Es gibt Auskunft darüber, wie viele bedeutende Updates (Freigaben) an der Datei vorgenommen wurden.
- minor_version: Diese Spalte enthält die Nebenversionsnummer des Dokuments. Sie wird bei Änderungen oder dem erneuten Upload der Datei erhöht. Die Kombination von Haupt- und Nebenversionsnummern gibt einen klaren Überblick über den Versionsstand der Datei.
- status: Der Status gibt an, in welchem Bearbeitungs- oder Freigabestand sich das Dokument befindet. Beispiele für Statuswerte könnten “Upload", oder "Release" sein. Dieser Wert hilft zu verstehen, ob die Datei noch bearbeitet wird oder ob sie bereits final ist.
- filename: Dies ist der tatsächliche Dateiname, der der Datei zugewiesen wurde, als sie in das DMS hochgeladen wurde. Es gibt an, wie die Datei im System benannt ist und hilft bei der Wiedererkennung.
- is_latest: Diese Spalte enthält eine Angabe darüber, ob die Datei die neueste Version ist. Der Wert ist "true" (wahr) , wenn es die aktuellste Version ist, oder "false" (falsch), wenn es sich um eine ältere Version handelt. Dies ist nützlich, um festzustellen, ob weitere Revisionen existieren oder um direkt auf die aktuelle Version zuzugreifen.
- created_by: Diese Spalte zeigt an, von welchem Benutzer die Datei erstellt wurde. Der Benutzername oder die Benutzer-ID wird hier gespeichert und ermöglicht es, nachzuvollziehen, wer das Dokument ursprünglich hochgeladen hat. Bei einem automatischen Ordner-Upload steht hier der Systemname.
2. Vorteile der automatischen Indexdatei¶
Die automatische Erstellung der contents.csv stellt sicher, dass jederzeit ein aktueller Überblick über alle im DMS gespeicherten Dokumente vorliegt. Im Falle einer Serverstörung kann auf diese Datei zurückgegriffen werden, um Kundenzertifikate schnell und manuell zu finden.
3. Manueller Zugriff auf Kundenzertifikate¶
Sollte es zu einer Serverstörung kommen, kann mit Hilfe der contents.csv-Datei ein manueller Zugriff auf die im DMS gespeicherten Kundenzertifikate erfolgen. Dazu geht man folgendermaßen vor:
- Öffnen Sie die Datei
contents.csv: Nutzen Sie ein Tabellenkalkulationsprogramm (wie Excel), um die Datei zu durchsuchen. - Suchen Sie das Zertifikat: Verwenden Sie Informationen wie den Dateinamen oder das Upload-Datum, um das entsprechende Kundenzertifikat zu identifizieren.
- Nutzen Sie den Hash-Wert: Der Hash-Wert (Ablagename) dient dazu, die Datei im physischen Speicher oder einem Backup-System zu finden und aufzurufen.
Durch die Indexdatei können Dateien effizient und zielgerichtet gefunden werden, ohne dass auf das reguläre DMS-System zugegriffen werden muss.
4. Notfallbetrieb: Sicherung der Indexdatei¶
Um sicherzustellen, dass die contents.csv-Datei im Notfall verfügbar ist, wird empfohlen, die Datei auf einem separaten Server, einer sicheren Cloud oder einem externen Backup-System abzulegen. Dies gewährleistet, dass die Datei selbst bei einem vollständigen Serverausfall zugänglich bleibt.
Kontakt bei Rückfragen: Für weitere Informationen oder Unterstützung bei der Einrichtung der Exportfunktion steht unser Support-Team unter support@calhelp.de zur Verfügung.
Support-Verwaltung¶
Die Struktur des Moduls umfasst zwölf wesentliche Teilbereiche:
- Meldungen – Meldungen
- Meldungsart – Meldungsarten verwalten
- Bereiche – Kategorien verwalten
- Schadensausmaß(Risk 1) – Schadensausmaß verwalten
- Eintrittswahscheinlichkeit(Risk 2) – Eintrittswahscheinlichkeit verwalten
- Erkennung(Risk 3) – Bearbeiten Erkennung(Risk 3)
- Typen – Supporttypen verwalten
- Prioritäten – Supportprioritäten verwalten
- E-Mail-Protokoll – Mail-Protokolle verwalten
- Beauftragte Gruppen – Beauftragte Gruppen verwalten
- Options – Options
Meldungen¶
Diese erweiterte Ansicht wird verwendet zur umfassenden Verwaltung und Bewertung von Systemmeldungen, Fehlern, Hinweisen oder Risiken. Sie eignet sich besonders für Qualitätsmanagement, Support-Teams und Sicherheitsbeauftragte.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | ID | Eindeutige Identifikationsnummer der Meldung. Dient zur Referenzierung und Nachverfolgung. |
| ② | Betreff | Titel oder Kurzbeschreibung des gemeldeten Vorfalls oder Themas. |
| ③ | Empfänger | Zugewiesene Person oder Rolle, die die Meldung bearbeitet oder verantwortlich ist. |
| ④ | Meldungstyp | Klassifizierung der Meldung (z. B. 1 = Fehler, 2 = Anmerkung). |
| ⑤ | Priorität | Dringlichkeitsstufe der Meldung, z. B. „Niedrig“, „Normal“, „Sehr hoch“. |
| ⑥ | Schadensausmaß (Risk 1) | Bewertung des potenziellen Schadens, wenn die Meldung nicht bearbeitet wird (z. B. Skala 1–3). |
| ⑦ | Eintrittswahrscheinlichkeit (Risk 2) | Wahrscheinlichkeit, dass das gemeldete Problem tatsächlich eintritt oder eingetreten ist. |
| ⑧ | Aktualisiert am | Datum der letzten Bearbeitung oder Statusänderung. |
| ⑨ | Status | Aktueller Bearbeitungsstatus der Meldung („in Arbeit“, „gelöst“, „NEU“). |
| ⑩ | erstellt | Zeitpunkt der ursprünglichen Erstellung der Meldung. |
| ⑪ | Letzte Änderung von | Benutzer, der die letzte Änderung durchgeführt hat. |
| ⑫ | Aktionen | Menü für Aktionen wie Bearbeiten, Kommentieren oder Löschen der Meldung. |
Typische Nutzungsszenarien und Abläufe¶
- Risikobewertung: Jede Meldung wird anhand von Schadensausmaß (⑥) und Eintrittswahrscheinlichkeit (⑦) klassifiziert. Diese Werte fließen in Risikobewertungen ein.
- Statusverfolgung: Über die Spalte Status (⑨) lässt sich erkennen, ob eine Meldung noch offen ist, in Bearbeitung oder bereits gelöst wurde.
- Zuweisung & Verantwortung: Die Spalte Empfänger (③) zeigt, wer für die Abarbeitung verantwortlich ist. Diese Rolle kann manuell oder automatisiert vergeben werden.
- Verlaufsüberwachung: Die Spalten Aktualisiert am (⑧) und Erstellt (⑩) erlauben eine zeitliche Nachverfolgung des Meldungsprozesses.
- Dokumentation & Audit: Die Kombination der Spalten erlaubt eine vollständige Historie und Dokumentation für interne Audits, ISO-Zertifizierungen oder externe Prüfungen.
Funktionale und technische Hinweise¶
- Felder mit „Leer“ sollten systemseitig regelmäßig überprüft werden, insbesondere Empfänger (③), Priorität (⑤) und Risikowerte (⑥, ⑦), da sie für die Priorisierung relevant sind.
- Die Priorität (⑤) beeinflusst z. B. Benachrichtigungs- oder Eskalationsprozesse.
- Risikobewertungen (⑥, ⑦) sind typischerweise auf numerischer Skala (z. B. 1–3 oder 1–5) hinterlegt und können in Dashboards aggregiert dargestellt werden.
- Kommentare zur letzten Bearbeitung können über das Icon in Spalte Letzte Änderung von (⑪) angezeigt oder ergänzt werden.
- Über das Aktionsmenü (⑫) kann direkt in die Bearbeitung oder Kommentierung gewechselt werden.
Meldungsart¶
Diese Ansicht ermöglicht die Verwaltung der systemweit verwendeten Meldearten, die zur Klassifikation einzelner Meldungen dienen. Sie ist besonders wichtig für Administratoren, QM-Verantwortliche oder Supportleiter, um einheitliche Klassifizierungen und Workflows sicherzustellen.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | ID | Eindeutige numerische Identifikation der Meldeart. |
| ② | Name | Bezeichnung der Meldungsart (z. B. „Reklamation“, „Interne Meldung“). |
| ③ | Alias | Technischer Alias zur internen Referenzierung oder API-Verwendung. |
| ④ | Aktiv | Gibt an, ob die Meldeart aktuell verwendet werden kann („Ja“ / „Nein“). |
| ⑤ | Meldungen | Anzahl der im System vorhandenen Meldungen, die dieser Meldeart zugewiesen sind. |
| ⑥ | Ersteller | Benutzer, der die Meldungsart ursprünglich angelegt hat. |
| ⑦ | erstellt | Zeitstempel der Erstellung der Meldungsart. |
| ⑧ | Aktionen | Menü zum Bearbeiten oder Löschen der Meldungsart. |
Typische Nutzungsszenarien und Abläufe¶
- Pflege und Erweiterung: Neue Meldearten können bei Bedarf hinzugefügt werden, z. B. „Auditabweichung“, „Supportanfrage“, „Technikmeldung“.
- Auswertung: Die Spalte Meldungen (⑤) zeigt, wie oft eine bestimmte Meldeart im System tatsächlich verwendet wird – nützlich für Analysen.
- Aktivitätssteuerung: Über Aktiv (④) lassen sich veraltete oder nicht mehr genutzte Meldearten deaktivieren, ohne historische Daten zu verlieren.
- Alias-Nutzung: Der Alias (③) wird oft in Schnittstellen, Skripten oder Filterdefinitionen verwendet – wichtig für Entwickler oder Systemanpassungen.
Funktionale und technische Hinweise¶
- Die ID (①) wird systemseitig vergeben und kann als Primärschlüssel in relationalen Auswertungen dienen.
- Die Kombination aus Name (②) und Alias (③) sorgt für eine eindeutige Identifikation sowohl auf Benutzer- als auch auf Systemebene.
- Änderungen an einer aktiv genutzten Meldeart sollten mit Vorsicht erfolgen, da sie in bestehenden Workflows referenziert sein kann.
- Die Daten in dieser Tabelle werden häufig mit anderen Modulen wie Risiko- oder Statuskonfigurationen verknüpft.
- Über das Aktionsmenü (⑧) können bestehende Einträge editiert oder – sofern nicht verwendet – gelöscht werden.
Bereiche¶
Diese Ansicht ermöglicht die Pflege von organisatorischen oder thematischen Bereichen, denen Meldungen im System zugewiesen werden können. Sie wird primär zur strukturierten Kategorisierung und Auswertung von Meldungen verwendet (z. B. „Laborbereiche“, „Abteilungen“, „Systeme“).
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | ID | Eindeutige Identifikationsnummer des Bereichs zur internen Referenz. |
| ② | Name | Bezeichnung des Bereichs, z. B. „elektrisches Labor“, „sonstige“. |
| ③ | Alias | Technischer Alias zur systeminternen Verwendung (z. B. für APIs, Filterregeln). |
| ④ | Meldungen | Anzahl der zu diesem Bereich zugeordneten Meldungen. |
| ⑤ | Ersteller | Benutzer, der den Bereich ursprünglich erstellt hat. |
| ⑥ | erstellt | Zeitstempel der Erstellung des Bereichs. |
| ⑦ | Aktionen | Menü zum Bearbeiten oder Löschen des Bereichs. |
Typische Nutzungsszenarien und Abläufe¶
- Anlage neuer Bereiche: Neue Kategorien wie „IT“, „Qualitätssicherung“, „Mechanik-Labor“ können angelegt werden, um Meldungen besser zu strukturieren.
- Nutzung bei Erstellung von Meldungen: Benutzer wählen bei der Meldungserfassung den passenden Bereich aus – dieser erscheint dann in Analysen und Filtern.
- Pflege von Alias-Werten: Der Alias (③) wird systemtechnisch genutzt, z. B. für APIs oder automatische Verarbeitung.
- Analyse und Auswertung: Die Spalte Meldungen (④) zeigt an, wie häufig ein Bereich in Meldungen referenziert wurde – nützlich für Hotspot-Erkennung.
- Verwaltung über Aktionsmenü: Einträge können direkt bearbeitet oder gelöscht werden, sofern sie nicht in Verwendung sind.
Funktionale und technische Hinweise¶
- Alias-Namen (③) sollten ohne Leerzeichen und mit Kleinbuchstaben gepflegt werden – dies erhöht die Kompatibilität mit externen Tools oder Schnittstellen.
- Bereiche mit Meldungen = 0 (④) können als ungenutzt identifiziert und ggf. bereinigt oder archiviert werden.
- Die Anzeige von Ersteller (⑤) und Erstellt (⑥) unterstützt die Rückverfolgbarkeit – insbesondere bei Änderungen durch verschiedene Rollen.
- Filterfunktion (oberhalb jeder Spalte) erleichtert die gezielte Suche nach bestimmten Bereichen, z. B. bei großer Anzahl an Kategorien.
Risiken¶
Diese Ansicht unterstützt die Definition und Bewertung von Risikoklassen, die systemweit zur Bewertung und Priorisierung von Meldungen verwendet werden. Sie ist essenziell für Qualitätsmanagement, Risikomanagement und Compliance-Verantwortliche.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | Risiko | Definierter Risikobereich auf Basis von Schadensausmaß × Eintrittswahrscheinlichkeit (z. B. „1–3“, „9–12“). |
| ② | Farbe | Farbkennzeichnung zur visuellen Darstellung des Risikoniveaus im System (HEX-Wert). |
| ③ | Priorität | Bewertete Dringlichkeit, die sich aus dem Risiko ergibt (z. B. „Niedrig“, „Sehr hoch“). |
| ④ | Meldungen | Anzahl der Meldungen, die dem jeweiligen Risikobereich zugeordnet sind. |
| ⑤ | Aktionen | Menü zur Bearbeitung oder Löschung des Risikoeintrags. |
Typische Nutzungsszenarien und Abläufe¶
- Klassifikation von Risiken: Basierend auf Risikobereichen (①), werden Meldungen automatisch oder manuell einem bestimmten Risikoniveau zugewiesen.
- Prioritätsautomatisierung: Die zugeordnete Priorität (③) dient z. B. zur automatischen Sortierung in Dashboards, Bearbeitungsreihenfolgen oder Eskalationslogiken.
- Visuelle Unterstützung: Die Farbcodierung (②) wird in Meldelisten oder Risiko-Matrizen verwendet, um Gefahrenstufen schnell zu erkennen (z. B. grün = niedrig, rot = hoch).
- Auswertung und Reporting: Die Spalte Meldungen (④) zeigt, wie häufig bestimmte Risikobereiche genutzt werden – hilfreich für Risikoanalysen und Jahresberichte.
Funktionale und technische Hinweise¶
- Die Risikoskalierung (①) basiert typischerweise auf Multiplikation von zwei Faktoren:
- Schadensausmaß (z. B. 1–3)
- Eintrittswahrscheinlichkeit (z. B. 1–4)
- Prioritätszuweisungen (③) können systemintern als Trigger für Eskalationen oder Benachrichtigungen verwendet werden.
- Die Farbcodes (②) sollten kontrastreich gewählt sein, um Barrierefreiheit zu gewährleisten (z. B.
#FF0D5Dfür sehr hoch). - Risikowerte können durch Anpassung von Schwellwerten erweitert oder verfeinert werden (z. B. 1–5 oder 1–25).
- Über das Aktionsmenü (⑤) können Risikoeinträge gepflegt, erweitert oder gelöscht werden – letzteres nur, wenn sie nicht verwendet werden.
Schadensausmaß(Risk 1)¶
Diese Ansicht wird zur Verwaltung und Dokumentation von Schadensausmaß-Stufen (Risk 1) genutzt. Diese Bewertungen sind Teil des Risikomanagements und beeinflussen die Risikobewertung (z. B. in Kombination mit Eintrittswahrscheinlichkeit).
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | ID | Systeminterne Identifikationsnummer des Eintrags zum Schadensausmaß. |
| ② | Schadensausmaß (Risk 1) | Kategorisierung der Schwere eines möglichen Schadens (z. B. „gering“, „moderat“, „hoch“). |
| ③ | Risiko | Bewertungsstufe (z. B. 1, 2, 3), dient zur Risikoberechnung mit Eintrittswahrscheinlichkeit. |
| ④ | Beschreibung | Textliche Erläuterung des Schadensausmaßes – inkl. Beispielen und Auswirkungen. |
| ⑤ | Color | Farbkennzeichnung zur Visualisierung des Risikotyps (z. B. für Ampelanzeige). |
| ⑥ | Alias | Technischer Kurzname des Eintrags, zur Verwendung in Systemprozessen. |
| ⑦ | Meldungen | Anzahl der Meldungen, denen dieses Schadensausmaß zugeordnet wurde. |
| ⑧ | Ersteller | Benutzername der Person, die den Eintrag erstellt hat (falls gepflegt). |
| ⑨ | erstellt | Datum und Uhrzeit der Erstellung des Eintrags. |
| ⑩ | Aktionen | Menü zur Bearbeitung oder Löschung des Eintrags. |
Typische Nutzungsszenarien und Abläufe¶
- Risikoanalyse bei Meldungen: Beim Anlegen oder Bewerten einer Meldung wird ein Schadensausmaß (②) ausgewählt – dies beeinflusst die Gesamtrisikoklassifikation.
- Verwendung in Matrixlogik: Die Kombination aus Schadensausmaß (②) und Eintrittswahrscheinlichkeit ergibt das berechnete Risiko.
- Visuelle Klassifikation: Die Farbwerte (⑤) dienen der Darstellung in Ampellogiken (z. B. grün = gering, rot = hoch).
- Dokumentation und Nachvollziehbarkeit: Die Beschreibung (④) hilft dabei, die Auswahl objektiv zu begründen und ist für Audits nützlich.
- Historienauswertung: Die Spalte Meldungen (⑦) zeigt, wie häufig eine Stufe in der Vergangenheit verwendet wurde.
Funktionale und technische Hinweise¶
-
Die Schadensstufen sind typischerweise aufsteigend in ihrer Auswirkung:
gering (1)<moderat (2)<hoch (3) -
Die Alias-Felder (⑥) werden in automatisierten Systemprozessen verwendet und sollten eindeutig sowie sprechend sein.
- Color (⑤) kann systemweit verwendet werden (z. B. in Dashboards, Risiko-Matrix, Filter).
- Änderungen an bestehenden Risikostufen wirken sich retrospektiv auf verknüpfte Meldungen aus – bei strukturellen Änderungen sollte ein neuer Eintrag erstellt werden.
- Aktionen (⑩) ermöglichen Pflege oder Entfernung – letzteres nur, wenn keine Meldungen (⑦) zugeordnet sind.
Eintrittswahscheinlichkeit(Risk 2)¶
Diese Ansicht dient zur Definition und Pflege von Eintrittswahrscheinlichkeiten (Risk 2), welche zusammen mit dem Schadensausmaß zur Gesamtbewertung von Risiken in Meldungen beitragen.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | ID | Eindeutige Identifikationsnummer für den Eintrag zur Eintrittswahrscheinlichkeit. |
| ② | Eintrittswahrscheinlichkeit (Risk 2) | Klassifikation der Häufigkeit des Eintretens eines Ereignisses, z. B. „selten“, „häufig“. |
| ③ | Risiko | Numerischer Wert zur Berechnung des Gesamtrisikos (z. B. 1–4). |
| ④ | Beschreibung | Textliche Erläuterung der Klassifizierung, meist als zeitlicher Bezug formuliert. |
| ⑤ | Color | Farbcode zur farblichen Darstellung der Eintrittswahrscheinlichkeit im System. |
| ⑥ | Alias | Technisch eindeutiger Kurzbezeichner für systeminterne Referenzen. |
| ⑦ | Meldungen | Anzahl der Meldungen, die dieser Eintrittswahrscheinlichkeit zugeordnet wurden. |
| ⑧ | Ersteller | Benutzername der Person, die den Eintrag angelegt hat (falls gepflegt). |
| ⑨ | erstellt | Erstellungszeitpunkt des Eintrags. |
| ⑩ | Aktionen | Menü zur Bearbeitung oder Entfernung des Eintrags. |
Typische Nutzungsszenarien und Abläufe¶
- Bewertung von Risiken: Bei der Meldungserfassung oder -prüfung wird eine Eintrittswahrscheinlichkeit angegeben – sie fließt in die Risikomatrix ein.
- Erstellung einer Risikoformel: Der Wert in Spalte Risiko (③) wird mit dem Risk 1-Wert multipliziert, um die Risikostufe (z. B. „1–12“) zu berechnen.
- Standardisierung durch Beschreibung: Die Beschreibung (④) stellt sicher, dass die Einstufungen nachvollziehbar und reproduzierbar sind (z. B. „monatlich“ = „gelegentlich“).
- Farbvisualisierung: Über Color (⑤) erfolgt die Einbindung in Risiko-Matrix-Darstellungen oder Tabellen zur optischen Trennung nach Häufigkeit.
Funktionale und technische Hinweise¶
- Die Skala ist typischerweise wie folgt aufgebaut:
- selten = 1 (grün) → Ereignis tritt jährlich auf
- gelegentlich = 2 (gelb) → monatlich
- häufig = 3 (orange) → wöchentlich
- regelmäßig = 4 (rot) → täglich
- Farbwerte im HEX-Format (⑤) ermöglichen barrierearme Darstellung und Corporate-Design-Anpassungen.
- Alias-Namen (⑥) sollten systemweit eindeutig sein und konsistent mit anderen Risikokategorien geführt werden.
- Über Meldungen (⑦) lässt sich erkennen, welche Einträge aktiv genutzt werden – wichtig für Bereinigungen oder Umstellungen.
Erkennung(Risk 3)¶
Der Bereich „Erkennung (Risk 3)“ ist Bestandteil eines erweiterten Risikomanagement-Ansatzes, der neben Schadensausmaß (Risk 1) und Eintrittswahrscheinlichkeit (Risk 2) auch die Erkennbarkeit eines Risikos bewertet. Dieser dreidimensionale Ansatz wird z. B. in FMEA-Analysen (Fehlermöglichkeits- und -einflussanalyse) eingesetzt.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | ID | Systemseitige eindeutige Kennung eines Erkennungseintrags (Risk 3). |
| ② | Risiko | Numerischer Risiko-Score zur weiteren Differenzierung der Gesamtbewertung. |
| ③ | Beschreibung | Textliche Erläuterung der jeweiligen Erkennungsstufe (z. B. „leicht erkennbar“, „nur durch Analyse erkennbar“). |
| ④ | Color | Farbkennzeichnung zur visuellen Unterstützung der Risikoklassifikation. |
| ⑤ | Alias | Technischer Kurzname des Eintrags für systeminterne Nutzung. |
| ⑥ | Meldungen | Anzahl der Meldungen, denen diese Erkennungsstufe zugewiesen wurde. |
| ⑦ | Ersteller | Benutzer, der den Eintrag ursprünglich erstellt hat. |
| ⑧ | erstellt | Datum und Uhrzeit der Erstellung des Eintrags. |
| ⑨ | Aktionen | Kontextmenü für Bearbeitung oder Löschung eines Eintrags. |
Typische Nutzungsszenarien und Abläufe¶
- Erfassung von Erkennungsstufen: Administratoren oder Risikobeauftragte definieren Stufen wie „offensichtlich“, „nur durch Prüfung erkennbar“, „nicht erkennbar“.
- Erweiterte Risikoberechnung: Der Erkennungswert fließt in die Gesamtbewertung ein (z. B. RPN = Risk Priority Number = Risk1 × Risk2 × Risk3).
- Visualisierung und Steuerung: Die farbliche Kennzeichnung (④) hilft bei der grafischen Auswertung in Risiko-Matrizen oder Dashboards.
- Kategorisierung von Meldungen: Meldungen können optional mit einem Erkennungswert versehen werden, um schwer erkennbare Probleme schneller zu identifizieren.
Funktionale und technische Hinweise¶
- Derzeit sind keine Erkennungsstufen erfasst, was bedeutet, dass dieser Teil des Risikomodells aktuell nicht aktiv im System genutzt wird.
- Color (④) und Alias (⑤) folgen demselben Schema wie bei Risk 1 und 2.
- Die Pflege erfolgt analog zu den anderen Risikoarten und sollte bei Einführung der RPN-Logik zentral erfolgen.
- Eine nachträgliche Aktivierung dieses Faktors kann zu Rückwirkungen auf Risikoberechnungen oder Workflows führen – vorherige Planung und Test empfohlen.
Typen¶
Diese Ansicht wird genutzt zur Verwaltung von Typen für Supportmeldungen, die z. B. bei internen Tickets, technischen Problemen oder Feedbackprozessen eingesetzt werden. Die Typen sind ein wichtiger Filter- und Kategorisierungsparameter in Meldungserfassungen.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | ID | Eindeutige Identifikationsnummer des Supporttyps. |
| ② | Typ | Bezeichnung des Typs einer Meldung (z. B. „Fehler“, „Frage“). |
| ③ | Beschreibung | Erläuterung oder Zweck des Typs – dient der Nutzerführung und Auswertung. |
| ④ | Alias | Technischer Kurzname für interne Verlinkungen, APIs oder Automatisierung. |
| ⑤ | Meldungen | Anzahl der existierenden Meldungen, die diesem Typ zugewiesen wurden. |
| ⑥ | Aktionen | Menü zur Bearbeitung oder Löschung des jeweiligen Typs. |
Typische Nutzungsszenarien und Abläufe¶
- Typisierung bei Erstellung einer Meldung: Der Benutzer wählt einen vordefinierten Typ aus (z. B. „Fehler“ oder „Frage“), was die spätere Bearbeitung strukturiert.
- Kategorisierte Auswertung: Die Anzahl (⑤) der mit einem Typ verknüpften Meldungen erlaubt Rückschlüsse auf häufige Anliegen oder Verbesserungspotenzial.
- Verwaltung und Pflege: Über das Aktionsmenü (⑥) können Typen bei Bedarf angepasst, umbenannt oder gelöscht werden – letzteres nur, wenn keine Meldungen zugeordnet sind.
Funktionale und technische Hinweise¶
- Die Typen sollten sprechend und für Endnutzer klar verständlich benannt werden (z. B. „Verbesserung“ statt „OPT-REQ“).
- Das Alias-Feld (④) ist besonders relevant bei Integrationen mit externen Tools oder für automatisierte Klassifizierungen (z. B. E-Mail-Routing).
- Die Beschreibung (③) kann zur Nutzerführung beitragen – bei Bedarf kann hier ein Tooltip oder Hilfetext erscheinen.
- Typen mit 0 zugeordneten Meldungen (⑤) können gefahrlos gelöscht werden, wenn sie nicht mehr benötigt werden.
- Die Pflege dieser Tabelle sollte regelmäßig erfolgen, um die Übersichtlichkeit und Aktualität des Meldungssystems zu gewährleisten.
Prioritäten¶
Diese Ansicht ermöglicht die Verwaltung von Prioritätsstufen für Supportmeldungen, um eine einheitliche und systematische Bearbeitungsreihenfolge festzulegen. Sie ist besonders relevant für First-Level- und Second-Level-Support, Prozessmanager und QM-Verantwortliche.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | ID | Systemseitige eindeutige Identifikationsnummer der Priorität. |
| ② | Betreff | Bezeichnung der Priorität (z. B. „Niedrig“, „Normal“, „Sehr hoch“). |
| ③ | Alias | Technischer Kurzname zur internen Systemverwendung oder API-Zuweisung. |
| ④ | Meldungen | Anzahl der Supportmeldungen, denen diese Prioritätsstufe zugewiesen wurde. |
| ⑤ | Hintergrundfarbe | Farbcode zur farblichen Visualisierung des Prioritätslevels im System (z. B. grün = niedrig). |
| ⑥ | Farbe (Schriftfarbe) | Farbcode für die Textfarbe, um Kontrast und Lesbarkeit sicherzustellen. |
| ⑦ | Aktionen | Aktionsmenü zur Bearbeitung oder Entfernung der jeweiligen Prioritätsstufe. |
Typische Nutzungsszenarien und Abläufe¶
- Kategorisierung neuer Meldungen: Bei Erstellung oder Klassifizierung von Meldungen wird eine der definierten Prioritätsstufen ausgewählt.
- Bearbeitungssteuerung: Meldungen mit höherer Priorität („Sehr hoch“) erscheinen zuerst in Bearbeitungsübersichten und werden ggf. automatisch eskaliert.
- Visuelle Unterstützung: Die Kombination aus Hintergrund- (⑤) und Schriftfarbe (⑥) dient zur Hervorhebung wichtiger Meldungen (z. B. Warnfarben).
- Systempflege: Neue Prioritäten können angelegt und bestehende bei Bedarf angepasst oder deaktiviert werden, sofern sie nicht aktiv genutzt werden.
Funktionale und technische Hinweise¶
- Die Aliasnamen (③) sollten systemkonform, eindeutig und möglichst sprechend benannt werden – z. B. „niedrig“, „sehr-hoch“.
- Farbdefinitionen (⑤ + ⑥) sollten auf ausreichenden Kontrast und Barrierefreiheit geprüft werden – besonders bei roter Schrift auf dunklem Hintergrund.
- Meldungszähler (④) signalisiert, wie oft eine Priorität tatsächlich verwendet wird – hilfreich zur Optimierung oder Bereinigung ungenutzter Stufen.
- Über das Aktionsmenü (⑦) lassen sich Prioritätsstufen gezielt anpassen oder entfernen – letzteres nur möglich, wenn keine Zuweisung vorliegt.
E-Mail-Protokoll¶
Die Ansicht „Mail-Protokolle verwalten“ dient der Nachverfolgung aller ausgehenden System-E-Mails, insbesondere im Zusammenhang mit Support-Tickets oder Meldungsprozessen. Sie ist essenziell für Admins, Supportleiter und Systembetreuer zur Überwachung der E-Mail-Kommunikation.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | Vorlage | Name oder Zweck der E-Mail-Vorlage (z. B. „Ticket has changed in support module“). |
| ② | Konfigurationsname | Bezeichnung der verwendeten SMTP-Konfiguration (z. B. „tickets.calhelp.de SMTP“). |
| ③ | Empfänger E-Mail | Zieladresse des E-Mail-Empfängers (z. B. superadmin@…). |
| ④ | Cc | Optionales Cc-Feld für weitere Empfänger (selten befüllt). |
| ⑤ | Betreff | Betreffzeile der gesendeten E-Mail (oft mit Meldungsreferenz). |
| ⑥ | Anhang hinzufügen | Angabe, ob ein Anhang in der E-Mail enthalten war. |
| ⑦ | gesendet am | Zeitstempel, wann der E-Mail-Versand ausgelöst wurde. |
| ⑧ | Status | Ergebnis des E-Mail-Versands (z. B. „Erfolgreich“, „Fehlgeschlagen“). |
| ⑨ | Fehlermeldung | Technische Fehlerbeschreibung bei Versandproblemen (inkl. Link zur Fehlerdokumentation). |
| ⑩ | Aktionen | Menü zur Einsicht, Wiederholung oder Verwaltung des Protokolleintrags. |
Typische Nutzungsszenarien und Abläufe¶
- Nachvollziehbarkeit von Support-Kommunikation: Prüfen, ob und wann ein Benutzer über eine Änderung informiert wurde (z. B. bei Ticket-Statusänderung).
- Fehlersuche bei E-Mail-Problemen: E-Mails mit Status „Fehlgeschlagen“ (⑧) enthalten im Feld Fehlermeldung (⑨) Hinweise zur Fehlerursache (z. B. „SMTP connect() failed“).
- Technischer Audit-Trail: Alle versendeten Nachrichten sind hier mit Zeitstempel (⑦) und Zieladresse (③) dokumentiert.
- Analyse von Zustellbarkeit: Die Kombination aus Status (⑧) und Konfiguration (②) zeigt, ob bestimmte SMTP-Server häufiger Probleme verursachen.
- Manuelle Korrektur: Über das Aktionsmenü (⑩) können E-Mails ggf. erneut gesendet oder exportiert werden – je nach Systemfunktionalität.
Funktionale und technische Hinweise¶
- Bei häufigen SMTP-Fehlern (⑨) sollte die verlinkte PHP-Mailer-Wiki aufgerufen und die Konfiguration überprüft werden.
- Das System zeigt für jede E-Mail:
- Konfiguration (SMTP-Quelle)
- Empfänger (To / Cc)
- Vorlage (Name der Mailvorlage)
- Technischer Status (Erfolg / Fehler)
- Anhänge (⑥) sind relevant, wenn Zertifikate, Berichte oder andere Dateien automatisch versendet werden.
- Zur Optimierung von Zustellraten sollte SPF/DKIM korrekt konfiguriert sein – nicht Teil der Oberfläche, aber relevant im Kontext.
Beauftragte Gruppen¶
Diese Ansicht dient der Verwaltung beauftragter Gruppen, die in Prozessen wie Support, Eskalation oder Qualitätssicherung automatisiert benachrichtigt oder zugewiesen werden können. Sie ersetzt oder ergänzt individuelle E-Mail-Empfänger.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | Name | Bezeichnung der beauftragten Gruppe (z. B. „IT-Support“, „Qualitätssicherung“). |
| ② | Erstelldatum | Datum und Uhrzeit der erstmaligen Erstellung der Gruppe. |
| ③ | Änderungszeit | Zeitpunkt der letzten Änderung (z. B. Umbennung, Änderung von Mitgliedschaften). |
| ④ | Email Adressen | Anzahl der in dieser Gruppe hinterlegten E-Mail-Adressen. |
| ⑤ | Aktionen | Funktion zur Bearbeitung oder zum Löschen der Gruppe (z. B. über das Mülleimer-Symbol). |
Typische Nutzungsszenarien und Abläufe¶
- Gruppenzuweisung zu Meldungsarten oder Supportprozessen: Bei bestimmten Vorfällen wird eine ganze Gruppe benachrichtigt (z. B. „IT-Support“ bei technischen Fehlern).
- Pflege zentraler Empfängerlisten: Änderungen in der Gruppenstruktur (z. B. Austritt eines Mitarbeiters) müssen nur hier aktualisiert werden – nicht in jeder Regel einzeln.
- Transparenz und Protokollierung: Die Spalten Erstelldatum (②) und Änderungszeit (③) dokumentieren alle Änderungen für interne Audits.
- Auswertung aktiver Gruppen: Über die Anzahl der E-Mail-Adressen (④) lässt sich schnell erkennen, ob Gruppen aktiv befüllt sind oder verwaist.
Funktionale und technische Hinweise¶
- Gruppen mit 0 E-Mail-Adressen (④) können systemseitig noch existieren, lösen aber keine Benachrichtigungen aus – sollten regelmäßig geprüft werden.
- Einträge lassen sich über das Löschen-Icon (⑤) entfernen – dies sollte nur erfolgen, wenn die Gruppe nicht mehr in automatisierten Workflows referenziert ist.
- Die Funktion „Gruppe zuweisen“ (oben rechts) öffnet typischerweise eine Zuordnungsmaske, in der Empfänger-Adressen hinzugefügt werden.
- Es wird empfohlen, sprechende Namen (①) zu verwenden – z. B. „Qualitätssicherung“ statt „QS-GRP“.
Options¶
Die Optionsansicht dient der zentralen Systemkonfiguration und Standardisierung von Prozessen. Sie richtet sich an Administratoren und Systemverwalter, die u. a. Risikologik, E-Mail-Integration und Standardinhalte für Meldungen pflegen.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | Risiko Formel | Berechnungsformel zur Ermittlung des Risikowerts, z. B. [Risk_1] * [Risk_2]. |
| ② | IMAP Configuration | Auswahlfeld zur Auswahl einer vordefinierten IMAP-Konfiguration für den Mailabruf. |
| ③ | IMAP Path | Pfadauswahl für das E-Mail-Verzeichnis auf dem IMAP-Server (z. B. „INBOX“). |
| ④ | Bereich der Meldung | Vorausgewählter Bereich, für den die Standardbeschreibung gilt. |
| ⑤ | Beschreibung (EN) | Eingabefeld für die Standardbeschreibung auf Englisch, inkl. Textformatierung. |
| ⑥ | Beschreibung (DE) | Eingabefeld für die Standardbeschreibung auf Deutsch, inkl. Textformatierung. |
Typische Nutzungsszenarien und Abläufe¶
- Definition der Risikobewertung: Mit der Risikoberechnungsformel (①) wird gesteuert, ob z. B. nur Risk 1 × Risk 2 oder eine komplexere Formel (inkl. Risk 3) genutzt wird.
- Einbindung eines Mailkontos: Über die IMAP-Konfiguration (②) und den Pfad (③) können E-Mails aus einem bestimmten Postfach automatisch eingelesen und verarbeitet werden (z. B. für Ticket-Systeme).
- Standardtexte für Meldungen: Je nach ausgewähltem Bereich (④) wird eine mehrsprachige Standardbeschreibung (⑤, ⑥) verwendet, z. B. zur automatischen Befüllung bei Erstellung oder Anzeige.
Funktionale und technische Hinweise¶
- [Risk_1], [Risk_2], [Risk_3] sind Platzhalter für die numerischen Bewertungen aus den zugehörigen Modulen – die Eingabe muss systemkonform sein.
- Der Button „Verbindung testen“ unter dem IMAP-Bereich dient zur Validierung der Serververbindung.
- Die Standardbeschreibung kann Markdown oder HTML enthalten und ist typischerweise in mehrsprachiger Ausführung hinterlegt (nützlich für internationale Umgebungen).
- Ungültige Konfigurationen im IMAP-Bereich oder fehlerhafte Formeln können zu Systemfehlern führen – Eingaben sollten validiert werden.
Steuerungen¶
interne Funktion
Hilfeverwaltung¶
Die Struktur des Moduls umfasst zwei wesentliche Teilbereiche:
- Bereich
- Sektion
1. Bereich¶
Der dargestellte Applikationsausschnitt ist Teil des Hilfe-Management-Moduls. Hier werden Hilfestrukturen verwaltet, die typischerweise zur Gliederung von Hilfetexten, FAQs oder Benutzeranleitungen innerhalb einer Anwendung dienen. Über die Bereichsverwaltung erfolgt die Unterteilung der Hilfedokumentation in übergeordnete Bereiche und untergeordnete Sektionen.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | Bereich-Auswahl (Dropdown-Menü) | Auswahlfeld zur Selektion eines bestehenden Bereichs innerhalb des Hilfe-Management-Moduls. Die Auswahl eines Bereichs steuert, welche Sektionen und Inhalte zur weiteren Bearbeitung oder Ansicht bereitgestellt werden. |
Typische Nutzungsszenarien und Abläufe¶
-
Auswahl eines Bereichs:
Nutzer wählen über das Dropdown-Menü (①) einen bestehenden Bereich aus, um zugehörige Sektionen und Inhalte zu bearbeiten oder anzuzeigen.
-
Verwaltung von Bereichen:
Nach Auswahl eines Bereichs können Nutzer über die Buttons "Bereich hinzufügen" oder "Bereiche ordnen" neue Bereiche anlegen oder die Reihenfolge bestehender Bereiche anpassen.
-
Navigation zwischen Bereichen und Sektionen:
Über die Tabs am oberen Rand können Nutzer zwischen der Bereichs- und Sektionsverwaltung wechseln.
Funktionale und technische Hinweise¶
-
Dropdown-Menü (①):
Die Bereichsauswahl ist Voraussetzung für das weitere Arbeiten im Hilfe-Management. Ohne Auswahl eines Bereichs können keine Sektionen angezeigt oder bearbeitet werden.
-
Berechtigungen:
In der Regel ist die Verwaltung von Bereichen nur für Administratoren oder Redakteure mit entsprechenden Rechten möglich.
-
Datenabhängigkeit:
Die Auswahl eines Bereichs steuert die nachfolgenden Eingabe- und Bearbeitungsmöglichkeiten dynamisch.
-
Fehlermeldung:
Ist kein Bereich vorhanden, wird dies durch die Meldung "keine Einträge gefunden" angezeigt.
2. Sektion¶
Dieser Applikationsausschnitt zeigt das Formular zur Anlage oder Bearbeitung einer Sektion innerhalb des Hilfe-Management-Moduls. Sektionen dienen der strukturierten Untergliederung von Hilfetexten oder Dokumentationsbereichen und werden typischerweise unterhalb eines Bereichs angelegt.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | Name (Textfeld) | Eingabefeld zur Definition des Namens der Sektion. Hier wird der eindeutige und beschreibende Titel der Sektion festgelegt. |
| ② | Sprache (Dropdown-Menü) | Auswahlfeld zur Festlegung der Sprache, in der die Sektion erstellt wird. Die Auswahl bestimmt die Lokalisierung der Inhalte. |
Typische Nutzungsszenarien und Abläufe¶
-
Anlegen einer neuen Sektion:
Nutzer geben im Feld ① den gewünschten Namen der Sektion ein und wählen im Feld ② die entsprechende Sprache aus. Anschließend speichern sie die neue Sektion über den "Speichern"-Button.
-
Bearbeiten einer bestehenden Sektion:
Bei Änderungen an bestehenden Sektionen werden die vorhandenen Werte in den Feldern angezeigt und können angepasst werden.
-
Abbrechen der Aktion:
Mit "Abbrechen" kann der Vorgang jederzeit ohne Übernahme von Änderungen beendet werden.
Funktionale und technische Hinweise¶
-
Name (Textfeld, ①):
Der eingegebene Name sollte eindeutig sein, um eine klare Zuordnung innerhalb der Hilfe-Struktur zu ermöglichen. Typischerweise werden hier prägnante Titel vergeben, die den Inhalt der Sektion beschreiben.
-
Sprache (Dropdown-Menü, ②):
Über das Auswahlfeld wird die Sprache für die neue Sektion festgelegt. Dies ist insbesondere bei mehrsprachigen Anwendungen wichtig, um Hilfetexte zielgruppengerecht bereitzustellen. Die Auswahl kann Einfluss auf die Sichtbarkeit der Sektion für unterschiedliche Nutzergruppen haben.
-
Validierung:
Beide Felder sollten vor dem Speichern geprüft werden, um die Konsistenz und Vollständigkeit der Daten sicherzustellen.
-
Mehrsprachigkeit:
Die Möglichkeit, mehrere Sprachversionen anzulegen, ist essenziell für internationale Anwendungen. Die gewählte Sprache steuert, in welcher Sprache die Hilfetexte dieser Sektion erscheinen.
Informationsverwaltung¶
Die Struktur des Moduls umfasst fünf wesentliche Teilbereiche:
- Nutzung – Informationen
- Log – Log
- Änderungsübersicht – Änderungsübersicht
- Über – Über
- Lizenzen – Lizenzen
Nutzung¶
Diese Informationsansicht dient der Systemadministration und Kontrolle des Systemnutzungsgrads. Sie gibt sowohl Aufschluss über die Anzahl aktiver Entitäten im System (Benutzer, Inventare, Kalibrierungen) als auch über Speicherverbrauch und -kapazitäten. Zusätzlich wird eine Zuordnung von Kunden zu Inventaren dargestellt.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | Übersicht | Zeigt aggregierte Systeminformationen: Benutzeranzahl, Inventaranzahl, Kalibrierungen, Kundenanzahl und Speicherverbrauch nach Kategorien. |
| ② | Kunden Name (Filter) | Eingabefeld zur Filterung der unten stehenden Kundenliste nach Name. |
| ③ | Anzahl (Spalte) | Zeigt die Anzahl der dem jeweiligen Kunden zugeordneten Inventarobjekte. |
Typische Nutzungsszenarien und Abläufe¶
- Monitoring der Speicherauslastung: Systemadministratoren prüfen regelmäßig den Stand des Anwendungs-, Dokumenten-, Datenbank- und Gesamtspeichers (unter ①).
- Lizenz- oder Kapazitätsplanung: Bei zunehmender Nutzung (z. B. mehr Kunden oder Inventare) lassen sich durch diese Ansicht Kapazitätserweiterungen begründen.
- Inventarverteilung prüfen: Die Liste unter „Kunden und Inventare“ zeigt, wie viele Inventargegenstände einem bestimmten Kunden zugeordnet sind (③).
- Fehlzuweisungen identifizieren: Einträge mit Anzahl = 0 können als potenziell unvollständig oder fehlerhaft angesehen werden.
Funktionale und technische Hinweise¶
- Alle Speicheranzeigen sind in Absolutwerten (GB) angegeben, aufgeteilt in „Free Space“ und „Total Space“. Diese Werte gelten für:
- Anwendungsspeicher: allgemeine Systemdaten
- Dokumentenspeicher: abgelegte PDFs, Bilder, Zertifikate etc.
- Speicherverbrauch: gesamtheitlich
- Datenbankspeicher: strukturierte Daten (Tabellen, Verknüpfungen)
- Der Filter (②) im unteren Bereich erleichtert die gezielte Suche nach Kunden innerhalb der Liste.
- Die Anzahl-Spalte (③) ist sortierbar und ermöglicht eine schnelle Erkennung von Kunden mit besonders vielen oder wenigen Inventaren.
Log¶
Diese Ansicht dient zur Einsicht und Auswertung von System-Logs. Sie ist essenziell für Systemadministratoren, um Benutzeraktionen, Systemfehler und Sicherheitsereignisse nachvollziehen und analysieren zu können.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | Kategorie | Art des Log-Eintrags, z. B. „Login“, „Exception“, „DB-Command“. Dient der thematischen Einordnung. |
| ② | ID | Eindeutige Identifikationsnummer des Log-Eintrags. |
| ③ | Level | Schweregrad des Log-Ereignisses (z. B. „info“, „error“, „warning“). |
| ④ | Log Time | Zeitstempel, zu dem das Ereignis im System erfasst wurde. |
| ⑤ | Meldung | Vollständiger Logtext mit detaillierter Beschreibung des Ereignisses. |
| ⑥ | Aktionen | Aktionsmenü für weitere Funktionen wie Anzeige des vollständigen Eintrags, Kopieren oder Löschen. |
Typische Nutzungsszenarien und Abläufe¶
- Fehleranalyse: Bei Fehlverhalten oder Systemabstürzen kann über die Spalten Kategorie (①) und Level (③) gezielt nach kritischen Ereignissen gefiltert werden.
- Sicherheitsmonitoring: Login-Einträge (Kategorie „Login“) zeigen, wann sich welcher Benutzer im System angemeldet hat – wichtig zur Nachverfolgung.
- Kapazitätsüberwachung: Einträge mit „Too many connections“ oder Datenbankfehlern deuten auf Lastprobleme hin und sollten weiter untersucht werden.
- Audit- und Nachweispflicht: Die Protokollierung ist oft Bestandteil von ISO-Normen (z. B. ISO 9001, 27001) und dient der Revisionssicherheit.
Funktionale und technische Hinweise¶
- Die Log-ID (②) ist systemweit eindeutig und erlaubt bei Bedarf eine präzise Verlinkung oder Archivierung.
- Der Zeitstempel (④) wird automatisch vom System gesetzt und ist nicht bearbeitbar.
- Log-Level (③) sind in der Regel farblich codiert (z. B. blau = info, rot = error) und dienen der schnellen visuellen Priorisierung.
- Die Spalte Meldung (⑤) zeigt teils vollständige Stack-Traces, SQL-Fehler oder Systemhinweise und sollte nur durch technisch geschulte Personen interpretiert werden.
- Über das Aktionsmenü (⑥) können erweiterte Funktionen wie „Details anzeigen“, „Log exportieren“ oder „Eintrag löschen“ ausgeführt werden (abhängig von Berechtigungen).
Änderungsübersicht¶
Diese Ansicht dient zur Verwaltung und Nachverfolgung von Software-Updates und Versionsständen. Sie ist für technische Administratoren und DevOps-Verantwortliche gedacht, um Releases zu verwalten und den Update-Status einzusehen.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | Update and Deploy | Bereich zur Anzeige der aktuellen Systemversion, mit Funktionen zur Aktualisierung (Check for Updates), Änderung (Ändern) und Deployment (Deploy). Zeigt auch Fehlermeldungen an, z. B. fehlende Docker-Rechte. |
| ② | Changes Log | Anzeige der automatisiert generierten Changelog-Datei mit allen Release-Versionen. Bietet zusätzlich einen Button zum Herunterladen der Datei. |
Typische Nutzungsszenarien und Abläufe¶
- Update-Prüfung: Durch Klick auf „Check for Updates“ wird geprüft, ob eine neuere Softwareversion verfügbar ist.
- Deployment: Wird ein Update bereitgestellt, kann es über den Button „Deploy“ ausgerollt werden – meist automatisiert über Docker.
- Versionsüberblick: Die angezeigte Version (z. B.
4.55.0-447-g717d263dd) gibt den aktuellen Stand des Systems an, inklusive Build-Hash. - Fehlerbehandlung: Fehlermeldungen (z. B.
permission deniedbeim Zugriff auf Docker) informieren über technische Probleme beim Updateprozess. - Versionshistorie einsehen: Über die angezeigte
CHANGELOG.mdDatei kann der gesamte Entwicklungsverlauf nachvollzogen werden – hilfreich für Audits, Regressionstests oder Dokumentation. - Download des Changelogs: Die Schaltfläche „Herunterladen“ erlaubt das Exportieren des Änderungsprotokolls.
Funktionale und technische Hinweise¶
- Die Versionsanzeige basiert typischerweise auf Git-Tags und Commits, daher ist die Angabe
g717d263ddein Git-Commit-Hash. - Docker-basierte Deployments erfordern Systemzugriff auf den Docker-Daemon – entsprechende Rechte müssen gegeben sein, sonst erscheint die angezeigte Fehlermeldung.
- Der Changelog (②) wird automatisch aus dem Git-Log generiert und listet alle Releases chronologisch – dies ist wichtig für Nachverfolgbarkeit und Qualitätssicherung.
- Ein manuelles Update (über „Ändern“ oder „Deploy“) sollte nur durch befugte Personen mit Kenntnis über Systemarchitektur und Integrationsabhängigkeiten erfolgen.
Über¶
Der Reiter „Über“ dient der Bereitstellung von technischen und lizenzrechtlichen Hintergrundinformationen zur Softwarelösung calServer. Er richtet sich an Administratoren, IT-Dienstleister sowie externe Prüfer und dokumentiert die Architektur, Abhängigkeiten und Einsatzbedingungen der Software.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | Systembeschreibung („Über“) | Bereich zur Darstellung von Systeminformationen wie Eigentümerdaten, Funktionsübersicht, Systemvoraussetzungen und technologische Grundlagen von calServer. |
Inhaltliche Bestandteile¶
-
Adressdaten des Eigentümers:
calHelp, René Buske, Weidenbusch 8, 14532 Kleinmachnow
→ Relevanz für Impressumspflicht, Supportanfragen und Lizenzverantwortung.
-
Beschreibung von calServer:
Eine cloudbasierte, mobilfähige, offlinefähige Lab-Management-Software zur Verwaltung von Inventaren, Kunden, Kalibrierungen und weiteren betrieblichen Prozessen. Enthält Module für:
- Mehrmandantenfähigkeit
- Inventarmanagement mit Preisen, Status und Filteroptionen
- Kalibrier-, Wartungs- und Historienfunktionen
- Kundenmanagement mit Rollen- und Gruppensteuerung
- Angebots-, Bestell- und Abrechnungsfunktionen
- Ticketverwaltung mit Risikoanalyse
- Automatische Benachrichtigungen und Eskalationen
- Technische Mindestanforderungen:
- 64-bit Host, mindestens 2 GB RAM und 2 Cores
- Docker & Docker Compose oder Kubernetes
- (1-Core-Systeme sind theoretisch möglich, aber nicht empfohlen)
- Verwendete Basistechnologien:
- Yii Framework: PHP-Framework für sichere und performante Web-Anwendungen
- AdminLTE: Bootstrap-basierte Admin-Oberfläche
- Bootstrap: Frontend-Framework für responsive und strukturierte UI
- Open SourceHinweis: calServer ist teilweise quelloffen; Quellcode-Zugriff nach Absprache möglich
- Dritthersteller-Software:
Nutzung von Open-Source-Komponenten mit entsprechenden Lizenzhinweisen, einsehbar im System und bei den jeweiligen Bibliotheken.
Funktionale und technische Hinweise¶
- Der Versionshinweis auf eingesetzte Frameworks und Komponenten ermöglicht es Admins, Sicherheitsupdates, Patches oder Kompatibilitäten eigenständig zu prüfen.
- Die offene Architektur bietet gute Voraussetzungen für Erweiterungen oder Integrationen in bestehende Systemlandschaften.
- Docker-Abhängigkeit weist auf containerisierte Infrastruktur hin – wichtig für Deployment und Skalierung.
- Der Abschnitt unterstützt auch Audits, z. B. zur IT-Dokumentation oder bei externen Prüfungen (z. B. ISO, TISAX, DSGVO).
Lizenzen¶
Diese Ansicht listet alle Softwarebibliotheken und Frameworks auf, die im System (calServer) verwendet werden, zusammen mit deren Versionen. Sie dient der rechtlichen Absicherung, Dokumentation und Softwarepflege und ist insbesondere relevant für Administratoren, Compliance-Beauftragte und externe Auditoren.
Tabellarische Übersicht der markierten Elemente¶
| Nr. | Bezeichnung | Funktionale Beschreibung |
|---|---|---|
| ① | Lizenzliste | Auflistung aller im System verwendeten Drittanbieter- und Open-Source-Komponenten mit Namen und Versionsangaben. Dient der Transparenz in Bezug auf Lizenzverpflichtungen. |
Typische Nutzungsszenarien und Abläufe¶
- Lizenzprüfung: Vor einem Release kann sichergestellt werden, dass alle eingesetzten Komponenten korrekt lizenziert und dokumentiert sind.
- Updateplanung: Durch die Anzeige der genutzten Versionsnummern (z. B. TCPDF 6.2.26, mPDF 6.1.0) lassen sich Sicherheits- oder Funktionsupdates gezielt planen.
- Audit und IT-Dokumentation: Diese Liste ist essenzieller Bestandteil bei Software-Audits (z. B. ISO 27001, TISAX, DSGVO-konforme Dokumentation).
- Transparenz gegenüber Kunden: Kunden mit hohen Compliance-Anforderungen (z. B. in Medizin oder Automotive) fordern oft Offenlegung der eingesetzten Komponenten.
Funktionale und technische Hinweise¶
- Die Liste umfasst sowohl Backend- als auch Frontend-Komponenten wie:
- Yii Extensions (z. B. elFinder, RestfullYii)
- PDF- und Mail-Bibliotheken (mPDF, TCPDF, yii-mailer)
- JavaScript-Komponenten (jQuery.filer, CKEditor 4, typeahead)
- Datenvisualisierung und Tabellen (EDataTables)
- Admin- und UI-Komponenten (Booster, Adminer)
- Die Lizenzdetails (z. B. MIT, GPL, LGPL) sind meist über die Bibliotheken direkt oder im Quellcode/Projektverzeichnis verfügbar.
- Ein klickbarer Verweis (z. B. auf GitHub oder Lizenztexte) ist nicht in der Ansicht selbst vorhanden, sollte aber projektintern dokumentiert sein.























