Gerätetypen¶
Die Gerätetypenverwaltung ermöglicht das Anlegen und Pflegen von Gerätetypen, die als Vorlage für einzelne Inventargeräte dienen. Die Verwaltung erfolgt über den DeviceTypeController in der Laravel-API.
Übersicht¶
Gerätetypen definieren die Stammdaten eines Gerätemodells (z. B. Hersteller, Bezeichnung, Kalibrierintervall). Einzelne Inventargeräte werden einem Gerätetyp zugeordnet und erben dessen Eigenschaften.
Route: /device-types
Listenansicht¶
Die Listenansicht zeigt alle angelegten Gerätetypen in einer filterbaren und sortierbaren Tabelle:
| Spalte | Beschreibung |
|---|---|
| Bezeichnung | Name des Gerätetyps |
| Hersteller | Herstellername |
| Modell | Modellbezeichnung |
| Kalibrierintervall | Intervall in Monaten |
| Anzahl Geräte | Zugeordnete Inventargeräte |
| Prozeduren | Verknüpfte Kalibrierprozeduren |
Spalte „Anzahl Geräte"¶
Die Spalte zählt die Inventargeräte, die auf den jeweiligen Gerätetyp verweisen
(inventories.device_type_id). Sie beantwortet die übliche Frage vor einem
Typenkatalog: welche Typen sind tatsächlich im Einsatz und welche kann man
aufräumen. Über die Spaltenüberschrift lässt sich danach sortieren.
Der Wert wird bei jedem Aufruf gezählt und nirgends gespeichert – es gibt also keinen Zähler, der veralten kann.
Nur sichtbare Geräte zählen mit
Gezählt wird ausschließlich, was der angemeldete Benutzer auch sehen darf.
Ohne die Berechtigung inventory_global sieht ein Benutzer nur Geräte der
ihm zugeordneten Kunden – und genau diese werden gezählt. Zwei Benutzer
können vor demselben Gerätetyp deshalb unterschiedliche Zahlen sehen; jede
ist die Anzahl der Geräte, die dieser Benutzer im Inventar auch findet.
Wer die Spalte nicht braucht, blendet sie über die Spaltenauswahl des Grids aus; umbenennen oder ganz entfernen lässt sie sich in der Feldverwaltung wie jedes andere Feld.
Spalten „Kalibrierintervall (Vorgabe)" und „Intervall-Einheit (Vorgabe)"¶
Diese beiden Spalten zeigen, was der Typ einem neuen Gerät vorgibt – nicht, was an einem vorhandenen Gerät steht. Der Wert kommt aus der Blaupause des Typs (Abschnitt „Vorgaben für neue Geräte" auf seiner Detailseite) und ist dort auch zu ändern; leer heißt: Der Typ gibt nichts vor.
Nach einem Lauf „Aus Bestand ableiten" mit Blaupausen-Option steht hier, was aus den Geräten der jeweiligen Gruppe abgelesen wurde. Wie „Anzahl Geräte" werden die Werte bei jedem Aufruf gelesen und nirgends zwischengespeichert; sortieren und filtern lässt sich danach nicht.
CRUD-Operationen¶
Gerätetyp anlegen¶
Über den Button „Neuer Gerätetyp" wird das Anlageformular geöffnet. Pflichtfelder sind mit einem Stern (*) gekennzeichnet.
Felder:
- Bezeichnung *
- Hersteller
- Modell
- Beschreibung
- Kalibrierintervall (Monate)
- Kategorie
Gerätetyp bearbeiten¶
Ein Klick auf einen Gerätetyp öffnet die Detailansicht mit Bearbeitungsmöglichkeit.
Gerätetyp löschen¶
Achtung
Ein Gerätetyp kann nur gelöscht werden, wenn ihm keine Inventargeräte mehr zugeordnet sind. Andernfalls muss zuerst die Zuordnung aufgehoben werden.
Prozeduren verknüpfen¶
Jedem Gerätetyp können eine oder mehrere Kalibrierprozeduren zugeordnet werden. Diese Verknüpfung legt fest, welche Prüfschritte bei der Kalibrierung eines Geräts dieses Typs durchgeführt werden.
Die Zuordnung erfolgt im Tab „Prozeduren" der Gerätetyp-Detailansicht per Drag & Drop oder über ein Auswahlfeld.
Duplizieren¶
Über das Kontextmenü (drei Punkte) kann ein bestehender Gerätetyp dupliziert werden. Dabei werden alle Stammdaten und Prozedurzuordnungen in einen neuen Datensatz kopiert. Die Bezeichnung erhält den Zusatz „(Kopie)".
Tipp
Die Duplizierfunktion eignet sich besonders, wenn ähnliche Gerätetypen mit leicht abweichenden Parametern angelegt werden sollen.
Typ als Blaupause (Vorlage für neue Geräte)¶
Ein Gerätetyp kann optional als Blaupause für neue Inventargeräte dienen – analog zum Verhalten in calServer V1, wo die Auswahl eines Typs beim Anlegen eines Geräts Hersteller/Modell übernommen und eine im Typ vorgewählte Inventarkategorie kopiert hat.
Die Blaupause-Konfiguration liegt pro Typ als eigener Datensatz vor und lässt die
V1-types-Tabelle unangetastet. Zu sehen und zu ändern ist sie auf der
Detailseite des Gerätetyps im Abschnitt „Vorgaben für neue Geräte". Sie
steuert, ob und wie ein Typ angewendet wird:
| Einstellung | Wirkung |
|---|---|
Als Vorlage für neue Geräte verwenden (enabled) |
Ohne das ist der Typ eine reine Katalogzeile und gibt nichts vor |
Hersteller, Modell und Typcode übernehmen (copy_type_fields) |
Die Stammdaten des Typs landen im neuen Gerät |
Kategorien übernehmen (copy_categories) |
Das neue Gerät bekommt die Kategorien des Typs (Abschnitt „Kategorien" auf derselben Seite) |
Feldvorgaben (field_defaults) |
Vorgabewerte je Inventarfeld – insbesondere Kalibrierintervall und Intervall-Einheit. Angeboten werden die Felder, die in der Feldverwaltung „beim Kopieren übernehmen" tragen |
Woher die Kategorien kommen
Die Vorgabe sind die Kategorien, die dem Typ selbst zugeordnet sind —
dieselben, die im Grid in der Spalte „Kategorie" stehen. Wer sie dort
ändert, ändert damit auch die Vorgabe für neue Geräte. Eine abweichende
Liste lässt sich nur über die API setzen (category_ids); sie gewinnt dann
gegen die Zuordnung des Typs.
Wann die Vorgaben greifen:
- Beim Anlegen eines Geräts über „Neues Inventar erstellen": Sobald ein Gerätetyp gewählt ist, füllen sich die leeren Felder und die Kategorieauswahl. Jeder Wert lässt sich vor dem Speichern noch ändern.
- Bei der Serienanlage (Schnellerfassung) und über die API: Dort greifen die Vorgaben nur, wenn die Blaupause aktiv ist. Selbst eingetragene Werte gewinnen immer gegen die Vorgabe.
GET /api/v2/device-types/{id}/blueprint # Konfiguration lesen
PUT /api/v2/device-types/{id}/blueprint # Konfiguration speichern (Upsert)
DELETE /api/v2/device-types/{id}/blueprint # Blaupause entfernen
GET /api/v2/device-types/{id}/blueprint/prefill # Vorbelegung für ein neues Gerät
Über MCP liegt dieselbe Konfiguration als Config-Ressource
device_type_blueprint (create_config / update_config / query_config,
ein Datensatz je Typ über type_id).
Der Prefill-Endpunkt liefert die fertige Vorbelegung (Inventarattribute,
Type-Verknüpfung, Kategorie-IDs), die das Frontend beim Anlegen eines neuen
Geräts anwendet. In der Listenansicht kennzeichnet das Attribut is_blueprint,
welche Typen als Vorlage konfiguriert sind. Beim Duplizieren eines Typs wird
eine vorhandene Blaupause mitkopiert.
Typtabelle aus Bestandsdaten ableiten¶
Aus einer bestehenden Gerätedatenbank lässt sich eine initiale Typtabelle erzeugen: Der Lauf gruppiert das Inventar nach Hersteller + Modell und legt je Gruppe den noch fehlenden Typ an. Vorhandene Typen bleiben unverändert. Das ist die Nachfolge der V1-Funktion „Make Types" aus dem Typ-Grid.
In der Oberfläche¶
Im Gerätetypen-Grid oben rechts „Aus Bestand ableiten". Der Dialog zeigt zuerst eine Vorschau — welche Hersteller/Modell-Gruppen gefunden wurden, wie viele Typen neu wären, wie viele Geräte dahinter stehen. Bis auf „Typen anlegen" geklickt wird, schreibt der Dialog nichts.
Zwei Schalter:
| Schalter | Wirkung |
|---|---|
| Bestandsgeräte an ihren Typ binden (Vorgabe: an) | Trägt den erzeugten Typ bei den Geräten der Gruppe ein. Ohne das entsteht nur der Katalog, die Geräte bleiben ohne Typ. |
| Typen als Blaupause anlegen (Vorgabe: aus) | Macht jeden erzeugten Typ zur Vorlage für neue Geräte: Kalibrierintervall und Einheit aus dem häufigsten Wert der Gruppe, jede weitere Vorgabe nur aus einem Wert, den alle Geräte der Gruppe teilen. |
Mit eingeschalteter Blaupause erscheint darunter die Auswahl „Diese Felder als Vorgabe übernehmen". Vorbelegt sind Kalibrierintervall und Intervall-Einheit; zur Wahl steht, was in der Feldverwaltung als kopierbar gekennzeichnet ist.
Warum das nicht automatisch alles ist
Das Kennzeichen „beim Kopieren übernehmen" gehört zur Duplizieren-Funktion, und die kopiert bewusst mehr, als eine Typvorgabe sein sollte (Bemerkung, Zubehör-Zuordnung, Behälter-Kennzeichen). Es ist hier deshalb die Auswahlliste, nicht die Auswahl.
Die Kategorien kommen immer mit
Kategorien, die auf allen Geräten einer Gruppe liegen, ordnet der Lauf dem Typ zu — unabhängig vom Blaupausen-Schalter. Sie sind keine Vorgabe für spätere Geräte, sondern die Einordnung des Typs selbst. Ein Typ, der schon Kategorien trägt, bleibt unangetastet.
Nach dem Lauf meldet die Meldung oben rechts, wie viele Typen Kategorien und wie viele Feldvorgaben bekommen haben. Was genau ein Typ vorgibt, steht auf seiner Detailseite unter „Vorgaben für neue Geräte".
Der Knopf erscheint nur mit dem Recht „Typtabelle aus Bestand ableiten"
(types_derive) — siehe Berechtigungen.
Große Bestände: die Vorschau zeigt eine Auswahl
Findet der Lauf mehr als 200 Hersteller/Modell-Gruppen, führt die Tabelle nur die 200 größten auf und sagt das unter der Liste. Der Lauf selbst umfasst trotzdem alle Gruppen, und die Zahlen über der Tabelle (neu, vorhanden, Geräte binden) zählen den ganzen Bestand.
Auf der Kommandozeile¶
Für sehr große Bestände (der Lauf scannt das komplette Inventar) und für Skripte:
php artisan types:derive # fehlende Typen anlegen
php artisan types:derive --dry-run # nur anzeigen, nichts schreiben
php artisan types:derive --blueprint # zusätzlich Vorgaben aus den Daten ableiten
php artisan types:derive --link # Bestandsgeräte an ihren Typ zurückbinden
Die Kategorien, die auf allen Geräten einer Gruppe liegen, ordnet jeder Lauf dem Typ zu; ein Typ, der schon Kategorien hat, bleibt dabei unangetastet.
Mit --blueprint kommen die Feldvorgaben dazu: Kalibrierintervall und
Zeiteinheit aus dem häufigsten Wert der jeweiligen Gerätegruppe. Weitere Felder
nur, wenn sie mit --default-field ausdrücklich gewählt werden, und auch dann
nur, wenn alle Geräte der Gruppe denselben Wert tragen:
php artisan types:derive --list-fields # welche Felder wählbar sind
php artisan types:derive --blueprint \
--default-field=recall_interval \
--default-field=recall_interval_unit \
--default-field=description
Berechtigungen¶
Die Verwaltung von Gerätetypen erfordert entsprechende Benutzerrechte im
Rollenmanagement. Die Blaupause-Endpunkte sind an die Typ-Rechte gebunden:
Lesen (show/prefill) über types_view, Schreiben/Löschen über types_edit.
Das Ableiten der Typtabelle hat ein eigenes Recht (types_derive), das im
Standard keiner Rolle zugewiesen ist — zunächst kommt also nur der
Superadmin daran. Grund: Der Lauf legt in einem Zug Hunderte Typen an und
schreibt (mit „binden") an Geräten, die der Aufrufer nicht einzeln gesehen hat.
Wer das darf, entscheidet der Betreiber, indem er das Recht im Rollenmanagement
einer Rolle zuweist. Wer nur types_edit hat, sieht den Knopf nicht.