Zum Inhalt

Demodaten

Unter Administration > Demo-Daten (/v2/admin/demo-data) können Testdaten verwaltet werden.

Demodaten einspielen

Demodaten erstellen eine vollständige Testumgebung:

  • Ein Demo-Zugang je Grundrolle (Laborleitung, Techniker, Administration, Auditor, Buchhaltung, Kunde) plus ein Admin mit allen Rechten
  • Testkunden mit Prüfmitteln und Kalibrierungen
  • Feldkonfigurationen und Grid-Templates
  • Standorte, Reparaturen, Standards, Kontakte und Kategorien
  • Leihgeräte und einen Messkoffer für das Leihmodul
  • Support-Desk, Wiki und Ressourcen — die Module rund um den Kalibrierbetrieb

Demo-Zugänge

Ist Demo-Zugangsdaten anzeigen eingeschaltet, listet die Anmeldeseite diese Zugänge; ein Klick füllt das Formular.

E-Mail Passwort Rolle
admin@test.calserver.local test-admin-password Vollzugriff (alle Rechte)
laborleitung@demo.calserver.local demo-laborleitung Laborleitung
techniker@demo.calserver.local demo-techniker Techniker
administration@demo.calserver.local demo-administration Administration
auditor@demo.calserver.local demo-auditor Auditor
buchhaltung@demo.calserver.local demo-buchhaltung Buchhaltung
kunde@demo.calserver.local demo-kunde Kunde (nur Weserwerk Antriebstechnik)

Die Rollen-Zugänge tragen die ausgelieferte Rolle selbst, keine einzelnen Rechte: Was sie dürfen, steht in der Rollenverwaltung. Laborleitung, Techniker, Auditor und Buchhaltung sind allen Demo-Kunden zugeordnet, weil keine dieser Rollen alle Geräte global sieht; der Kunde nur seinem eigenen. Die Testbenutzer viewer und noapi gibt es weiter, sie sind Testfälle der Suite und erscheinen nicht auf der Anmeldeseite.

Leihmodul

Der Basis-Datensatz legt Geräte an, ordnet sie aber keiner Kategorie zu — und verleihbar ist ein Gerät nur über eine Kategorie mit dem Kennzeichen verleihbar. Ein eigener Schritt (DemoRentalSeeder) ergänzt deshalb:

Datensatz Zweck
Kategorie „Leihgeräte" (verleihbar) macht drei Geräte des Basissatzes ausleihbar
Unterkategorie „Messkoffer" (verleihbar) Katalog für Sets
KOF-0001 mit drei Untergeräten ein Testkoffer, der als Set ausgeliehen wird

Damit zeigt die Geräteauswahl nach dem Einspielen sofort Einzelgeräte und ein Set, und der Filter „Nur übergeordnete Geräte" hat etwas zu filtern.

Getrennt vom Testfixture

Der Schritt ist bewusst nicht Teil des Basis-Seeders: Den nutzt die Testsuite, und dort brechen zusätzliche Datensätze die Zählungen. Demodaten sollen vorzeigbar sein, ein Testfixture minimal und stabil.

Support-Desk, Wiki und Ressourcen

Aus demselben Grund ergänzt ein weiterer Schritt (DemoLabModulesSeeder) die Module, mit denen ein Labor betrieben wird — ohne sie sehen diese Bereiche nicht leer aus, sondern unfertig:

Datensatz Zweck
2 Projekte, 4 Tickets mit Kommentaren Support-Modul mit gefülltem Verlauf
Ticket-Typen, -Kategorien, -Prioritäten, 4 Ticket-Status die Metadaten, ohne die ein Ticket keine Auswahl hat
2 Wiki-Kategorien, 3 Wiki-Seiten mit Inhalt Wissensdatenbank mit echten Arbeitsanweisungen
Gruppen „Kalibrierlabor" / „Kundenservice" Zuweisungsziel für Tickets und Aufgaben
3 Ressourcen (Kalibrierplätze, Klimakammer) Ressourcenplanung
5 Messpunkte je für die 4 jüngsten Kalibrierungen Messwerttabelle der Kalibrierung — die Ansicht, an der ein Kalibrierlabor gemessen wird

Zwei Tickets sind mit den Geräten verknüpft, die sie im Titel nennen — damit hat der Reiter „Tickets" in der Geräteansicht etwas zu zeigen.

Demodaten erweitern (MCP)

Für weitere Anwendungsbeispiele muss niemand einen Seeder schreiben. Der MCP-Server kann Daten fachlich aufbauen, danach wird der Zustand als Demo-Paket gesichert:

  1. Demo-Modus aus (schreibende MCP-Werkzeuge sind im Demo-Modus gesperrt).
  2. Daten aufbauen: create_row / update_row für Geräte, Kalibrierungen, Kunden, Standorte, Reparaturen, Aufträge und Ansprechpartner, create_config für alles Übrige — Kategorien, Status, Tickets, Projekte, Wiki-Seiten, Aufgaben, Prüfabläufe, Testschritte, Prüfnormen, Standardartikel, Ressourcen und Gruppen —, assign_categories für die Zuordnung Gerät ↔ Kategorie (unter anderem das Kennzeichen „verleihbar"). Ein Gerätetyp bleibt ohne Blaupause eine reine Katalogzeile und gibt einem neuen Gerät nichts vor: create_config mit device_type_blueprint schaltet ihn ein und setzt die Feldvorgaben (vor allem Kalibrierintervall und Intervall-Einheit). Zum Kalibrierschein gehört mehr als die Kalibrierzeile: set_calibration_results schreibt die gemessenen Werte samt Konformitätsentscheidung (Testschritte halten nur den Messplan), assign_calibration_standards die eingesetzten Normale und damit die Rückführungskette. get_calibration_record zeigt beides zusammen mit dem Messplan.
  3. Ansprechpartner hängen über customer_id am Kunden — das Feld steht nicht in der Feldverwaltung, ist aber am contact-Datensatz schreibbar und wird von describe_table mitgeführt. Ohne es entsteht ein Kontakt, der unter keinem Kunden auftaucht.
  4. Felder, die auf einen anderen Datensatz zeigen (Bearbeiter, Kunde, Gerät), füllt lookup: Name rein, id raus. Für Benutzer ist das der einzige Weg an die uID — lookup nutzt dieselbe Registry wie die Auswahlfelder im Frontend.
  5. Firmenname, Logo und Modul-Vorgaben setzt update_settings; list_settings zeigt vorher, welche Schlüssel eine Gruppe kennt und was sie erwarten.
  6. Hierarchien entstehen über das Feld „Zubehör zu Asset No." (parent_asset_number) am Untergerät. Der Pfad-Cache wird dabei automatisch gepflegt, weil MCP über die Modelle schreibt.
  7. Zustand sichern: Demo-Daten > Paket exportieren, das ZIP herunterladen und auf anderen Instanzen importieren oder als Freeze-Punkt setzen.

Kein eigenes Tool heißt nicht: geht nicht

Die maßgebliche Liste liefert list_config_resources. Module ohne eigenes Werkzeug — Tickets, Wiki, Aufgaben, Prüfabläufe, Messpunkte — laufen alle über dieselben vier Config-Tools, Referenzen auf andere Datensätze löst lookup auf. Messwerte und eingesetzte Normale stehen dort nicht: ihre Tabellen haben zusammengesetzte Schlüssel, deshalb haben sie eigene Werkzeuge (siehe Schritt 2). Ohne Weg über MCP sind derzeit nur DMS-Dokumente (brauchen einen Datei-Upload) sowie das Anlegen von Benutzern und Rollen (dafür create_demo_user / create_demo_role); gelesen werden Benutzer über lookup.

Nicht als Testdaten verwenden

Ein Paket ist ein Datenbankabzug, kein Testfixture. Die Testsuite bleibt bei Seedern und Factories: schneller, schemaunabhängig und im Code nachlesbar.

Datumswerte wandern mit (Zeitanker)

Eine gespeicherte Vorlage ist eine Datenbankkopie mit festen Werten. Ohne Gegenmaßnahme stellt jede Wiederherstellung genau den Stand von damals wieder her — und ein Vierteljahr später führt die Demo ein Labor vor, das seit Monaten nichts mehr getan hat: alles überfällig, kein Termin in der Zukunft, die „laufende" Kalibrierung seit 90 Tagen laufend.

Deshalb trägt jedes Paket einen Zeitanker (den Tag, an dem es gespeichert wurde), und beim Einspielen wandern alle Datumswerte von diesem Anker auf heute:
Was wandert Vorlagen und Freeze-Points
Was nicht wandert Sicherungen (manuell, Auto-Sicherung vor einer Wiederherstellung)
Schrittweite ganze Wochen — ein Montag bleibt ein Montag
Was gleich bleibt die Abstände: 180 Tage zwischen Kalibrierung und Fälligkeit bleiben 180 Tage, ein um fünf Tage überfälliges Gerät bleibt um fünf Tage überfällig

Die Vorlagenliste zeigt Anker und Verschiebung, der Import-Dialog nennt sie noch einmal, und der Wiederherstellungs-Log protokolliert sie.

Was nicht angefasst wird, obwohl es nach einem Datum aussieht: Uhrzeiten und Zeitzonen (sie wandern unverändert mit dem Tag), die Sentinels 0000-00-00 und 31.12.2099 („unbefristet" in der Preisliste) sowie Text, der zufällig eine Jahreszahl enthält — eine Zertifikatsnummer D-2026-0001 bleibt stehen. Steht eine Vorlage länger als ein Jahr, laufen Nummernkreis und Datum deshalb auseinander; der Weg dahin ist, die Vorlage neu zu speichern.

Abschalten lässt sich das an drei Stellen:

  • global über Datumswerte beim Zurücksetzen mitführen in den Demo-Einstellungen,
  • für ein einzelnes Paket über "date_shift": false in seiner meta.json,
  • für einen einzelnen Lauf über --no-date-shift (siehe CLI unten).

Vorlage zeitnah speichern

Der Anker ist der Tag des Exports. Ist der Bestand über zwei Wochen entstanden, ist der Anker um zwei Wochen zu spät — korrigierbar, indem time_anchor in der meta.json des Pakets auf den gewünschten Tag gesetzt wird.

Demodaten entfernen

Testdaten können sauber entfernt werden, ohne die Systemkonfiguration zu beeinträchtigen.

Automatisches Reseed

Für Demonstrationsumgebungen kann ein automatisches Reseed konfiguriert werden:

Einstellung Beschreibung
Aktiviert Automatisches Reseed ein/aus
Intervall Zeitabstand in Stunden (Standard: 24)
Datensatzgröße small oder large

CLI-Alternative

Demodaten können auch per Artisan-Kommando verwaltet werden: 

php artisan demo:data seed --force
php artisan demo:data remove --force

# Vorlagen samt Zeitanker auflisten und eine davon einspielen
php artisan demo:data templates
php artisan demo:data seed --template=<slug> --force

# ... mit den gespeicherten Datumswerten statt auf heute gezogen
php artisan demo:data seed --template=<slug> --no-date-shift --force