Neun Kapitel unter docs/anleitung/ fuer Technik und Verwaltung, mit 35 Bildern aus `pnpm docs:screenshots` und einem Fehlerbehebungskapitel aus echten Meldungen. `pnpm docs:pdf` macht daraus 72 Seiten A4 — hell gedruckt, mit Deckblatt, Inhaltsverzeichnis und Seitenzahlen, ohne neue Abhaengigkeit. Die Ablaeufe pruefen ihre Voraussetzungen, bevor der erste startet: antwortet ein gebauter Stand, steht der Seed-Bestand, und liest der Server dieselbe Datenbank wie der Testprozess. Jeder Ablauf legt an, was er braucht, und raeumt es weg. Vier neue kommen dazu: Hauptablauf, Onboarding mit Vergleich der Zwischenablage, Rollen und 390 px auf achtzehn Seiten. Drei Fehler kamen dabei heraus. Das Projekt „handy" pruefte 412 px statt der verlangten 390. Ein angemeldeter Benutzer ohne Recht erfuhr nie, warum er abgewiesen wurde — die Meldung stand auf einer Seite, die ihn sofort weiterleitet; jetzt gibt es /kein-zugriff. Und der Verzeichnis-Ablauf schrieb die Attributzuordnung der ersten vorhandenen Quelle um, in einer echten Installation also der produktiven. 101 Ablaeufe in INTERN und 97 in DIENSTLEISTUNG, beide ohne Fehlschlag. Closes #18 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
179 lines
8.8 KiB
Markdown
179 lines
8.8 KiB
Markdown
# Mitarbeiter, Abteilungen und Geräte
|
|
|
|
Unter **Mitarbeiter & Geräte** (im Modus Dienstleistung: **Personen & Geräte**) liegen die
|
|
Stammdaten. Oben schalten zwei Reiter um: **Personen** und **Geräte**.
|
|
|
|
Personen und Geräte pflegen darf die Rolle **Techniker**, **Redakteur** oder **Administrator** —
|
|
beim Onboarding steht der Techniker vor der Person, bevor der nächste Verzeichnisabgleich gelaufen
|
|
ist. **Abteilungen** bleiben beim **Administrator**: an ihnen hängen Ziel-OU und Standardgruppen,
|
|
also das, was die späteren PowerShell-Befehle in ein Verzeichnis schreiben.
|
|
|
|
## Personen
|
|
|
|

|
|
|
|
Gesucht wird über **Name, Mail, UPN oder sam** — im Ticket steht mal das eine, mal das andere. Dazu
|
|
der Filter **Abteilung** und das Häkchen **auch deaktivierte**; ohne das erscheinen nur aktive
|
|
Personen.
|
|
|
|
Eine Zeile trägt den Namen, die Kennungen, die Abteilung und die Zahl der Geräte und Läufe. Zwei
|
|
Kennzeichen sind wichtig:
|
|
|
|
- **aus dem Verzeichnis** — diese Person kommt aus dem Active Directory. Ihre Stammdaten werden
|
|
dort gepflegt.
|
|
- **deaktiviert** — nicht mehr im Haus. Steht mit Durchstreichung da.
|
|
|
|
### Eine Person von Hand anlegen
|
|
|
|
Unter **Person von Hand anlegen**: **Vorname**, **Nachname**, **Mail-Adresse (optional)** und
|
|
**Abteilung (optional)** — für die Abteilung schlägt das Feld vorhandene Namen vor. Hinter
|
|
**Verzeichnis-Angaben (UPN, sAMAccountName, Titel)** stehen die drei Felder, die das Verzeichnis
|
|
sonst liefert. Im Modus Dienstleistung außerdem der **Kunde**. Dann **Person anlegen**.
|
|
|
|
Gedacht ist das für das Onboarding: die Person entsteht hier, das AD-Konto danach. Eine so angelegte
|
|
Person bleibt vollständig änderbar, und der nächste Verzeichnisabgleich **übernimmt** sie über UPN
|
|
oder sAMAccountName, statt sie ein zweites Mal anzulegen.
|
|
|
|
### Die Seite einer Person
|
|
|
|

|
|
|
|
Oben Name, Titel, Abteilung, gegebenenfalls der Vorgesetzte. Darunter:
|
|
|
|
- der Knopf **deaktivieren** beziehungsweise **wieder aktivieren**,
|
|
- **Geräte** — was dieser Person zugeordnet ist, mit Tag-Code,
|
|
- **Stammdaten** — das Formular, **Stammdaten speichern** übernimmt.
|
|
|
|
Kommt die Person **aus dem Verzeichnis**, ist jedes Feld der Stammdaten gesperrt, und oben steht,
|
|
warum: „Die Stammdaten werden dort gepflegt — eine Änderung hier würde der nächste Abgleich
|
|
zurücksetzen.“ Die Werte stehen trotzdem da, nur schreibgeschützt; ein ausgeblendetes Feld wäre eine
|
|
schlechtere Auskunft als ein gesperrtes. **Deaktivieren lässt sie sich trotzdem.**
|
|
|
|

|
|
|
|
### Deaktivieren statt löschen
|
|
|
|
**Personen werden nie gelöscht, nur deaktiviert.** Ein archivierter Lauf muss auch in zehn Jahren
|
|
noch sagen können, für wen er lief. Eine deaktivierte Person verschwindet aus den Auswahllisten,
|
|
bleibt aber in jeder Historie auffindbar.
|
|
|
|
## Personen aus einer CSV-Datei einlesen
|
|
|
|

|
|
|
|
Unter **Personen aus einer CSV-Datei einlesen**. Die Spalten heißen wie im Verzeichnis, die
|
|
deutschen Entsprechungen gehen genauso:
|
|
|
|
| Spalte | Auch |
|
|
|---|---|
|
|
| `givenName` | vorname |
|
|
| `sn` | surname, nachname |
|
|
| `displayName` | anzeigename |
|
|
| `mail` | email, mailadresse |
|
|
| `upn` | userPrincipalName |
|
|
| `sam` | sAMAccountName |
|
|
| `department` | abteilung |
|
|
| `title` | titel |
|
|
|
|
Groß- und Kleinschreibung ist unerheblich, Trennzeichen darf Komma oder Semikolon sein, höchstens
|
|
500 Zeilen je Datei. Datei wählen oder Inhalt einfügen, im Modus Dienstleistung den **Kunden**
|
|
wählen, dann **Einlesen**.
|
|
|
|
Was der Import zusagt:
|
|
|
|
- **Wiedererkannt** wird eine Person über `sam` oder `upn`, sonst über den Anzeigenamen. Wer schon
|
|
da ist, wird aktualisiert statt ein zweites Mal angelegt.
|
|
- **Eine leere Zelle löscht nichts.** Was in der Datei nicht steht, bleibt, wie es ist.
|
|
- Fehlen `givenName` und `sn`, wird `displayName` am letzten Leerzeichen geteilt.
|
|
- **Personen aus dem Verzeichnis werden nicht überschrieben** — solche Zeilen werden gemeldet.
|
|
- Eine **deaktivierte** Person wird erkannt und aktualisiert, aber **nicht wieder aktiviert**. Dafür
|
|
gibt es den Schalter auf ihrer Seite.
|
|
- **Abteilungen legt der Import nicht an.** Der Name wird nur bei der Person eingetragen; als
|
|
Abteilung mit Ziel-OU und Standardgruppen übernimmt sie ein Administrator.
|
|
|
|
Eine fehlerhafte Zeile bricht den Import nicht ab. Sie wird unten mit ihrer **Zeilennummer** und dem
|
|
Grund gemeldet — genau die Zeilen sind in der Datei zu ändern.
|
|
|
|
## Abteilungen
|
|
|
|
Abteilungen liegen unter **Admin → Abteilungen**, weil an ihnen die Struktur des Verzeichnisses
|
|
hängt.
|
|
|
|

|
|
|
|
Eine Abteilung hat:
|
|
|
|
- **Name** — er muss **genauso lauten wie im Verzeichnis**, sonst findet die Zuordnung ihn nicht.
|
|
Verknüpft wird über den Abteilungsnamen der Person, nicht über eine Kennung.
|
|
- **Ziel-OU (optional)** — wo ein neues Konto landet, etwa
|
|
`OU=Buchhaltung,OU=Benutzer,DC=firma,DC=de`. Sie füllt den Platzhalter `{{ou}}`.
|
|
- **Standardgruppen, mit Komma getrennt** — sie füllen `{{gruppen}}`. **Die Reihenfolge bleibt
|
|
erhalten**, sie landet so im Gruppen-Befehl.
|
|
- **Mail-Domain (optional)** und **Notizen (optional)**.
|
|
|
|
Ein Tippfehler in der Ziel-OU legt ein Konto an der falschen Stelle an — das ist der Grund, warum
|
|
diese Seite dem Administrator gehört. Fehlen Ziel-OU und Standardgruppen, bleiben `{{ou}}` und
|
|
`{{gruppen}}` im Lauf leer.
|
|
|
|
**Bearbeiten** klappt das Formular an der Zeile auf. **archivieren** nimmt eine Abteilung aus dem
|
|
Angebot; gelöscht wird nichts, an einer Abteilung hängen Läufe. **wieder freigeben** macht es
|
|
rückgängig.
|
|
|
|
### Noch nicht gepflegte Abteilungen
|
|
|
|

|
|
|
|
Steht ein Abteilungsname bei Personen, ohne dass es dazu eine Abteilung gibt, erscheint oben
|
|
**Noch nicht gepflegt**. Ein Klick auf **Anlegen** legt die Abteilung mit diesem Namen an — **und
|
|
nur den Namen.** Ziel-OU, Standardgruppen und Mail-Domain sind danach leer und werden in der Liste
|
|
darunter nachgetragen.
|
|
|
|
## Geräte
|
|
|
|

|
|
|
|
Gesucht wird über **Hostname, Bezeichnung, Seriennummer, Tag-Code**, gefiltert nach **Typ** und mit
|
|
dem Häkchen **auch archivierte**.
|
|
|
|
Jede Karte zeigt Tag-Code, Namen, Typ, Besitzer, Modell, Serien- und Inventarnummer und die Zahl der
|
|
Läufe. Der Name führt auf die [Geräteseite](03-qr-tags.md). Kennzeichen: **Tag ohne Zuordnung** für
|
|
einen vorgedruckten Aufkleber, **archiviert** für ein Gerät außer Dienst.
|
|
|
|
**Stammdaten bearbeiten** klappt das Formular an der Karte auf: Hostname, Bezeichnung, Typ, Modell,
|
|
Seriennummer, Inventarnummer, Besitzer und Notizen. Zur Wahl als Besitzer stehen nur aktive Personen
|
|
desselben Kunden.
|
|
|
|
### Ein Gerät anlegen
|
|
|
|
Unter **Gerät anlegen**: **Hostname** und **Bezeichnung** (eines von beiden genügt), **Typ**,
|
|
**Modell**, **Seriennummer**, **Inventarnummer**, **Besitzer (optional)**, **Notizen (optional)**
|
|
und im Modus Dienstleistung der **Kunde**. Dann **Gerät anlegen**.
|
|
|
|
Der **Tag-Code entsteht dabei** und steht danach in der Erfolgsmeldung — er kommt auf den Aufkleber.
|
|
Drucke das Etikett gleich mit, solange du weißt, welches Gerät gemeint ist.
|
|
|
|
### Geräte aus einer CSV-Datei einlesen
|
|
|
|
Dieselbe Mechanik wie bei den Personen, höchstens 500 Zeilen. Spalten: `hostname`, `label`
|
|
(bezeichnung), `serialNumber`, `inventoryNumber`, `type`, `model`. **Eine der beiden Spalten
|
|
`hostname` oder `label` muss es geben** — sonst weiß niemand, was das Gerät ist. Jede eingelesene
|
|
Zeile verbraucht einen Tag-Code; lieber zweimal drucken als einmal zu viel einlesen.
|
|
|
|
### Archivieren statt löschen
|
|
|
|
**archivieren** nimmt ein Gerät aus dem Bestand: es taucht in keiner Auswahl mehr auf und nimmt
|
|
keine neue Arbeit an, bleibt aber in jeder Historie und lässt sich mit **wieder freigeben**
|
|
zurückholen. Das ist der normale Weg für ein ausgemustertes Gerät.
|
|
|
|
**löschen** ist die einzige echte Löschung in Laufzettel, und sie ist eng eingehegt:
|
|
|
|
- Sie erscheint nur, wenn **kein Lauf** an dem Gerät hängt. Sonst sagt Laufzettel: „An … hängen 3
|
|
Läufe. Das Gerät lässt sich deshalb nur archivieren.“
|
|
- Sie verlangt die Rolle **Administrator**.
|
|
- Sie fragt nach.
|
|
|
|
Der Grund für die Ausnahme: der Vertipper von eben stünde sonst für immer in der Liste. Der Preis
|
|
steht in der Rückfrage: **der Tag-Code bleibt für immer vergeben.** Er wird nie neu ausgegeben, ein
|
|
Aufkleber zeigt nie auf ein zweites Gerät — und ein schon gedruckter Aufkleber dieses Codes ist
|
|
danach wertlos.
|