# c-entron.NET - CentronNexus/ServiceBoard Umfassende Use-Case-Dokumentation > **Generiert**: 2025-11-20 > **Version**: 2025 1.1.0.0 > **Zweck**: Vollständige Dokumentation aller CentronNexus/ServiceBoard Module und Workflows > **Scope**: 34 ServiceBoard-Module (23 vollständig, 4 partiell, 6 Stubs) > **Stand**: Deep Code Analysis + Hidden Features Discovery --- ## 📋 Inhaltsverzeichnis ### **Teil 1: Übersicht & Architektur** 1. [Einführung](#1-einführung) 2. [Architektur-Übersicht](#2-architektur-übersicht) 3. [Modul-Klassifizierung](#3-modul-klassifizierung) ### **Teil 2: Vollständig Implementierte Module (23)** #### **Ticketing & Management (8 Module)** - [3.1 Ticket-Details](#31-ticket-details) - [3.2 Ticket-Liste / Cached Ticket List](#32-ticket-listeached-ticket-list) - [3.3 Ticket schließen](#33-ticket-schließen) - [3.4 Ticket weiterleiten](#34-ticket-weiterleiten) - [3.5 Kanban-Board](#35-kanban-board) - [3.6 Ticket-Checklisten](#36-ticket-checklisten) - [3.7 Ticket-Scripts](#37-ticket-scripts) - [3.8 Ticket Web-Formulare](#38-ticket-web-formulare) #### **Zeit & Planung (3 Module)** - [4.1 Zeiterfassung](#41-zeiterfassung) - [4.2 Stoppuhren (Global Timer)](#42-stoppuhren-global-timer) - [4.3 Scheduler (Kalender)](#43-scheduler-kalender) #### **Inhalte & Dokumente (5 Module)** - [5.1 Ticket-Dokumente](#51-ticket-dokumente) - [5.2 Ticket-E-Mails](#52-ticket-e-mails) - [5.3 Ticket-Berichte](#53-ticket-berichte) - [5.4 Dokumentenviewer](#54-dokumentenviewer) - [5.5 E-Mail-Versand](#55-e-mail-versand) #### **Dashboard & Überblick (2 Module)** - [6.1 Dashboard](#61-dashboard) - [6.2 Mein Tag (MyDay)](#62-mein-tag-myday) #### **KI & Erweiterte Funktionen (2 Module)** - [7.1 Ticket-AI-Zusammenfassung](#71-ticket-ai-zusammenfassung) - [7.2 AI-Assist (Content Generation)](#72-ai-assist-content-generation) #### **Kundenverwaltung (3 Module)** - [8.1 Kundendaten](#81-kundendaten) - [8.2 Kundengeräte & Assets](#82-kundengeräte--assets) - [8.3 Kundendetails & Adressenverwaltung](#83-kundendetails--adressenverwaltung) ### **Teil 3: Partiell Implementierte Module (4)** - [9.1 Suche (Placeholder)](#91-suche-placeholder) - [9.2 Statistiken (Stub)](#92-statistiken-stub) - [9.3 Karte (Mapping Stub)](#93-karte-mapping-stub) - [9.4 Passwort-Manager (Missing)](#94-passwort-manager-missing) ### **Teil 4: Architektur & Muster** - [10.1 Service-Injection Pattern](#101-service-injection-pattern) - [10.2 Daten-Flows](#102-daten-flows) - [10.3 Authentifizierung & Rechte](#103-authentifizierung--rechte) - [10.4 Real-Time Features (SignalR)](#104-real-time-features-signalr) --- # 1. Einführung ## Zweck dieser Dokumentation Diese Dokumentation erweitert die Hauptdokumentation `USE_CASES.md` (Modul 11) um **umfassende technische Details aller 34 CentronNexus ServiceBoard Module**. ## Was ist CentronNexus/ServiceBoard? **CentronNexus** ist die **Blazor Server 8.0-basierte Web Portal** von c-entron.NET mit folgenden Charakteristiken: - **Frontend**: Blazor Server mit DevExpress Blazor-Komponenten - **Backend**: REST API über CentronService - **Real-Time**: SignalR für Live-Updates - **Responsive**: Mobile-optimiertes Design mit Bootstrap 5 - **Benutzergruppen**: Techniker, Support-Mitarbeiter, Kunden, Manager ## Analyse-Methodik Dieses Dokument basiert auf: 1. **Code-Analyse**: 34 Module durchsucht 2. **Razor-Komponenten**: 150+ .razor Seiten analysiert 3. **Service-Schichten**: BL-Layer und REST-API-Integration dokumentiert 4. **Daten-Flows**: ICentronService Aufrufe katalogisiert 5. **Hidden Workflows**: Undokumentierte Funktionen entdeckt --- # 2. Architektur-Übersicht ## Technologie-Stack ``` Frontend Layer: ├── Blazor Server (.NET 8) ├── DevExpress Blazor 24.2.7 ├── Bootstrap 5 + CSS ├── TypeScript (für advanced UI interactions) └── SignalR (Real-time communication) Application Layer: ├── Page Components (.razor) ├── Shared Components ├── Layout Components └── Model/ViewModel Classes Service Layer: ├── ICentronService (REST API Gateway) ├── ICachedDataService (Local Caching) ├── IAlertService (Notifications) ├── IAuthorizationService (Rights) └── Domain Services (Filtering, etc.) Backend Layer: ├── CentronRestService (REST Endpoints) ├── Business Logic (BL-Layer) ├── Data Access (DAO) └── Entities / DTOs ``` ## Standard Service Injection ```csharp @inject ICentronService CentronService; // REST API calls @inject ICachedDataService CachedDataService; // User cache @inject IAlertService AlertService; // Toast notifications @inject ICentronDialogService DialogService; // Modal dialogs @inject ITicketFilterService TicketFilterService; // Advanced search @inject IAuthorizationService AuthorizationService; // Rights check @inject NavigationManager NavigationManager; // Routing @inject IJSRuntime JsRuntime; // JavaScript interop ``` ## Lizenzierung Die meisten Module erfordern eine der folgenden Lizenzen: - `LicenseGuids.Centron` (Basis-Lizenz, alle Module) - `LicenseGuids.ServiceBoard` (Web Portal spezifisch) - `LicenseGuids.WebForms` (Self-Service Formulare) - `LicenseGuids.Reports` (Berichtsgenerierung) --- # 3. Modul-Klassifizierung ## Funktionale Kategorien | Kategorie | Module | Status | Komplexität | |-----------|--------|--------|-------------| | **Ticket Management** | 8 | 100% | Hoch | | **Zeit & Planung** | 3 | 100% | Mittel | | **Inhalte & Dokumente** | 5 | 80% | Mittel | | **Dashboard & Überblick** | 2 | 100% | Mittel | | **KI & Erweitert** | 2 | 100% | Hoch | | **Kunden** | 3 | 100% | Mittel | | **Suche & Navigation** | 1 | 0% | - | | **Analytics & Berichte** | 2 | 0% | - | | **Visualisierung** | 1 | 0% | - | | **Kommunikation** | 1 | 10% | - | | **Sonstiges** | 1 | 0% | - | --- # 3. Vollständig Implementierte Module ## 3.1 Ticket-Details **Pfad**: `src/CentronNexus/ServiceBoard/TicketDetails/TicketDetailsPage.razor` **Kategorie**: Ticket Management (Kern) **Status**: ✅ Vollständig implementiert **Lizenz**: `LicenseGuids.Centron` OR `LicenseGuids.ServiceBoard` **Umfang**: 190+ Ticket-Metadaten-Felder ### Beschreibung Die Ticket-Details-Seite ist das **Herzstück des ServiceBoard**. Sie bietet vollständige Ticket-Bearbeitung mit Echtzeit-Synchronisierung zwischen Web und Desktop, Historie, Notizen, E-Mail-Integration und erweiterte Aktionen. **Insgesamt 190+ Metadaten-Felder** sind verfügbar, organisiert in Primary, Secondary und Tertiary Kategorien. ### Komponenten ``` TicketDetailsPage (Main) ├── TicketMainNavigation (Breadcrumb + Tabs) ├── TicketPage (Wrapper mit Padding) ├── Ticket-Beschreibung (Editable Text) ├── Ticket-History (Timeline) ├── Kommentare (Internal + External) ├── Anhänge (Documents/Files) ├── Ticket-Eigenschaften (Meta-Felder) ├── Zuordnungs-Informationen └── State/Status Übergang ``` --- ## TICKET METADATA - UMFASSENDE DOKUMENTATION ### 📌 PRIMARY METADATA (Kern-Felder - 60+ Felder) Diese Felder sind die **hauptsächlich editierbaren Core-Felder** des Tickets: #### **Ticket-Identifikation** | Feld | Datentyp | Edierbar | Erforderlich | Beschreibung | |------|----------|----------|--------------|-------------| | `I3D` | int | ❌ Nein | ✅ Ja | Eindeutige Ticket-ID (auto-generated) | | `Number` | int | ❌ Nein | ✅ Ja | Öffentliche Ticket-Nummer (z.B. #12345) | | `ShortDescription` | string | ✅ **JA** | ✅ Ja | Kurztitel des Tickets (50-200 Zeichen) | | `Description` | nvarchar(max) | ✅ **JA** | ✅ Ja | Ausführliche Problem-Beschreibung (Kern-Content) | **REST-API Endpoints für diese Felder**: ```csharp PUT /Helpdesk/HelpdeskUpdateDescription(UpdateHelpdeskRequest) PUT /Helpdesk/HelpdeskUpdateShortDescription(UpdateHelpdeskRequest) ``` **Use-Case UC 11.5.1.1**: "Techniker aktualisiert Problem-Beschreibung" ``` Workflow: 1. Ticket #12345 öffnen 2. Description-Feld klicken (WYSIWYG-Editor öffnet sich) 3. Text bearbeiten: "Benutzer kann nicht auf Netzwerk-Share zugreifen" 4. Speichern (Auto-save nach 2 Sekunden) 5. System erzeugt History-Eintrag: "Beschreibung geändert von X zu Y" 6. Alle anderen Benutzer sehen Update in Echtzeit ``` --- #### **Status & Priorität** | Feld | Datentyp | Edierbar | Erforderlich | Gültige Werte | |------|----------|----------|--------------|---------------| | `HelpdeskStatusI3D` (StatusKind) | int (FK) | ✅ **JA** | ✅ Ja | 1=Offen, 2=In Arbeit, 3=Wartet, 4=Gelöst, 5=Geschlossen | | `HelpdeskPriorityI3D` (Priority) | int (FK) | ✅ **JA** | ✅ Ja | 1=Niedrig, 2=Mittel, 3=Hoch, 4=Kritisch | | `HelpdeskTypeI3D` (Ticket-Typ) | int (FK) | ✅ **JA** | ✅ Ja | 1=Incident, 2=Request, 3=Change, 4=Problem, 5=Task | | `HelpdeskMarked` | bit | ✅ **JA** | ❌ Nein | true/false - Ticket markiert als Favorit? | **REST-API Endpoints**: ```csharp PUT /Helpdesk/HelpdeskUpdateStatus(UpdateHelpdeskRequest) → Rückgabe: UpdatedStatusProperties { Status, NewDueDate, AffectedSLA } PUT /Helpdesk/HelpdeskUpdatePriority(UpdateHelpdeskRequest) → Rückgabe: UpdatedPriorityProperties { Priority, NewDueDate, EscalationLevel } PUT /Helpdesk/HelpdeskUpdateType(UpdateHelpdeskRequest) → Rückgabe: UpdatedTypeProperties { Type, SLARules } ``` **Use-Case UC 11.5.1.2**: "Status-Übergang mit SLA-Berechnung" ``` Workflow: 1. Status: "Offen" → "In Arbeit" klicken 2. System berechnet automatisch: - Neue Due-Date basierend auf SLA-Regeln - First Response Time wird gestartet - Ticket wird rot hervorgehoben wenn überfällig 3. Team wird benachrichtigt (wenn konfiguriert) 4. Kunde erhält E-Mail: "Ihr Ticket ist in Bearbeitung" Status-Übergänge (erlaubte Wechsel): Offen → {In Arbeit, Wartet} In Arbeit → {Wartet, Gelöst, Offen} Wartet → {In Arbeit, Gelöst} Gelöst → {Offen, Geschlossen} Geschlossen → {Offen} (Re-open) ``` **Use-Case UC 11.5.1.3**: "Priorität erhöhen triggert Eskalation" ``` Workflow: 1. Priorität: "Mittel" → "Kritisch" ändern 2. System: - Berechnet neue Due-Date (z.B. 1h statt 24h) - Triggert Eskalations-Kette (Manager benachrichtigen) - Ändert Kanban-Board Position (kritische Tickets oben) - Erhöht Ticket-Farbe (rot statt gelb) - Optional: Automatisch zu Top-Team zuordnen ``` --- #### **Kategorisierung** | Feld | Datentyp | Edierbar | Erforderlich | Beispiele | |------|----------|----------|--------------|-----------| | `MainCategoryI3D` | int (FK) | ✅ **JA** | ✅ Ja | Hardware, Software, Netzwerk, Sicherheit | | `SubCategory1I3D` | int (FK) | ✅ **JA** | ❌ Nein | z.B. Netzwerk→LAN, WAN, VPN | | `SubCategory2I3D` | int (FK) | ✅ **JA** | ❌ Nein | z.B. LAN→Switch, Router, Cable | **REST-API Endpoint**: ```csharp PUT /Helpdesk/HelpdeskUpdateCategory(UpdateHelpdeskRequest) → Rückgabe: UpdatedCategoryProperties { MainCat, SubCats, SLARules } ``` --- #### **Beschreibungen & Notizen** | Feld | Datentyp | Edierbar | Erforderlich | Beschreibung | |------|----------|----------|--------------|-------------| | `InternalNote` | nvarchar(max) | ✅ **JA** | ❌ Nein | Nur Intern sichtbar (nicht für Kunde) | | `AdditionalText1` | nvarchar(max) | ✅ **JA** | ❌ Nein | Zusatzfeld 1 (kundenspezifisch) | | `AdditionalText2` | nvarchar(max) | ✅ **JA** | ❌ Nein | Zusatzfeld 2 (kundenspezifisch) | **Use-Case UC 11.5.1.4**: "Techniker hinterlässt interne Notizen" ``` Workflow: 1. Im Ticket intern notieren: "Gerät hat alte BIOS-Version, Firmware-Update erforderlich" 2. Diese Notiz ist NUR für Team sichtbar 3. Kunde sieht diese Notiz NICHT in der Public-Ansicht 4. Beim nächsten Support-Kontakt kann Techniker diese Notiz wieder sehen 5. Historieneinträge zeigen alle Notizen-Änderungen ``` --- #### **Zeitattribute - Planung & Verfolgung** | Feld | Datentyp | Edierbar | Erforderlich | Beschreibung | |------|----------|----------|--------------|-------------| | `DueDate` | datetime2(2) | ✅ **JA** | ❌ Nein | Fälligkeitsdatum (manuell oder SLA-auto) | | `PlannedDurationInHours` | decimal(10,2) | ✅ **JA** | ❌ Nein | Geschätzte Bearbeitungsdauer in Stunden | | `WorkStartDate` | datetime2(2) | ✅ **JA** | ❌ Nein | Geplanter Arbeitsbeginn | | `WorkEndDate` | datetime2(2) | ✅ **JA** | ❌ Nein | Geplantes Arbeitsende | | `CreatedDate` | datetime2(2) | ❌ Nein | ✅ Ja | Wann wurde Ticket erstellt? (System) | | `ChangedDate` | datetime2(2) | ❌ Nein | ✅ Ja | Wann zuletzt geändert? (System) | | `ClosedDate` | datetime2(2) | ❌ Nein | ✅ Ja | Wann wurde Ticket geschlossen? (System) | | `LastCommentDate` | datetime2(2) | ❌ Nein | ✅ Ja | Wann der letzte Kommentar? (Auto) | | `LastEmailDate` | datetime2(2) | ❌ Nein | ✅ Ja | Wann die letzte E-Mail? (Auto) | **REST-API Endpoints**: ```csharp PUT /Helpdesk/HelpdeskUpdateDueDate(UpdateHelpdeskRequest) PUT /Helpdesk/HelpdeskUpdatePlannedDuration(UpdateHelpdeskRequest) PUT /Helpdesk/HelpdeskUpdateWorkDates(UpdateHelpdeskRequest) ``` **Use-Case UC 11.5.1.5**: "Planen Sie Bearbeitung für Wartungsfenster" ``` Workflow: 1. PlannedDurationInHours: "4" eingeben (Techniker schätzt 4h Arbeit) 2. WorkStartDate: "2025-01-25 22:00" (Freitag-Abend für Wartung) 3. WorkEndDate: "2025-01-26 02:00" (Nachts wenn System offline) 4. System merkt: "Zu erledigen in 4h Wartung-Fenster" 5. Planer sieht Ticket im Scheduler im Nacht-Slot 6. Beteiligter Techniker erhält Benachrichtigung ``` --- ### 👥 SECONDARY METADATA (Beziehungen & Zuordnung - 60+ Felder) Diese Felder verbinden das Ticket mit Personen, Kunden, Verträgen und anderen Entities. #### **Kundenbeziehungen** | Feld | Datentyp | Edierbar | Erforderlich | Beschreibung | |------|----------|----------|--------------|-------------| | `CustomerI3D` | int (FK) | ❌ Nein (bei Erstellung) | ✅ Ja | Referenz zum Kunden (bei Erstellung gesetzt) | | `CustomerName` | nvarchar | ❌ Nein | ✅ Ja | Calculated: Kundename aus FK | | `ContactPersonI3D` | int (FK) | ✅ **JA** | ✅ Ja | Kontaktperson des Kunden (kann sich ändern) | | `ContactPersonName` | nvarchar | ✅ **JA** | ✅ Ja | Name der Kontaktperson | | `ContactPersonEmail` | nvarchar | ✅ **JA** | ✅ Ja | E-Mail der Kontaktperson (für Notifications) | | `ContactPersonPhone` | nvarchar | ✅ **JA** | ❌ Nein | Telefon der Kontaktperson | | `ContactPersonFax` | nvarchar | ✅ **JA** | ❌ Nein | Fax der Kontaktperson | **REST-API Endpoints**: ```csharp PUT /Helpdesk/HelpdeskUpdateContactPerson(UpdateHelpdeskRequest) → Rückgabe: UpdatedContactProperties { Name, Email, Phone } ``` **Use-Case UC 11.5.2.1**: "Kontaktperson im laufenden Ticket ändern" ``` Workflow: 1. Ticket #12345 für "ACME GmbH" wurde von "Max Müller" erstellt 2. "Max" ist jetzt im Urlaub 3. Neuer Techniker ändert Kontaktperson auf "Lisa Schmidt" 4. System sendet E-Mail an Lisa: "Sie sind nun Kontaktperson für Ticket #12345" 5. Zukünftige E-Mail-Korrespondenz geht an Lisa, nicht Max 6. History zeigt: "Kontaktperson geändert von Max Müller zu Lisa Schmidt" ``` --- #### **Team & Zuordnung** | Feld | Datentyp | Edierbar | Erforderlich | Beschreibung | |------|----------|----------|--------------|-------------| | `ResponsiblePersonI3D` | int (FK) | ✅ **JA** | ❌ Nein | Primary Owner des Tickets (kann mehrere sein via Editors) | | `ResponsiblePersonName` | nvarchar | ✅ **JA** | ❌ Nein | Calculated: Name des Responsible | | `EditorsI3D[]` | List | ✅ **JA** | ❌ Nein | Team von Bearbeitern/Mitarbeitern (0-N) | | `CreatedByI3D` | int (FK) | ❌ Nein | ✅ Ja | System: Wer hat Ticket erstellt? | | `ChangedByI3D` | int (FK) | ❌ Nein | ✅ Ja | System: Wer hat zuletzt geändert? | | `LockUserI3D` | int (FK) | ❌ Nein | ❌ Nein | Real-time: Wer bearbeitet gerade? | | `LockUserName` | nvarchar | ❌ Nein | ❌ Nein | Name von LockUser (für UI-Anzeige) | **REST-API Endpoints**: ```csharp PUT /Helpdesk/HelpdeskUpdateResponsible(UpdateHelpdeskRequest) → Rückgabe: UpdatedResponsibleProperties { Responsible, AssignmentDate } PUT /Helpdesk/HelpdeskUpdateEditors(UpdateHelpdeskRequest>) → Rückgabe: UpdatedEditorsProperties { Editors, State, Notifications } ``` **Use-Case UC 11.5.2.2**: "Ticket zu Team hinzufügen (mehrere Bearbeiter)" ``` Workflow: 1. Techniker "Klaus" ist Owner, braucht Hilfe 2. Klick: "+ Bearbeiter hinzufügen" 3. Wähle: "Maria" und "Peter" aus Team-Dropdown 4. System: - Speichert Editors: [Klaus (Owner), Maria, Peter] - Sendet E-Mails an Maria & Peter: "Sie wurden zu Ticket #12345 hinzugefügt" - Ticket erscheint in deren "Meine Tickets" Liste - Sie sehen den Editor-Lock und wissen: Klaus bearbeitet gerade 5. History: "Bearbeiter hinzugefügt: Maria, Peter" ``` **Use-Case UC 11.5.2.3**: "Editor Lock - Live-Bearbeitung Konflikt-Erkennung" ``` Workflow: 1. Klaus öffnet Ticket und klickt auf Description-Feld 2. System setzt LockUserI3D = Klaus, zeigt "🔒 Klaus bearbeitet diesen Ticket" 3. Maria öffnet das gleiche Ticket 4. Maria sieht: "⚠️ Dieser Ticket wird gerade von Klaus bearbeitet" 5. Maria kann nur Read-Only anschauen 6. Klaus speichert Änderung → Lock wird freigegeben 7. Maria kann jetzt editieren (Status-Update in Echtzeit via SignalR) ``` --- #### **Verträge & Dienste** | Feld | Datentyp | Edierbar | Erforderlich | Beschreibung | |------|----------|----------|--------------|-------------| | `ContractI3D` | int (FK) | ✅ **JA** | ❌ Nein | Zugehöriger Service-Vertrag | | `ContractName` | nvarchar | ✅ **JA** | ❌ Nein | Calculated: Vertragsname | | `ArticleWorkItemI3D` | int (FK) | ✅ **JA** | ❌ Nein | MSP-Artikel (Gebündeltes Service-Paket) | | `IsCalculable` | bit | ✅ **JA** | ❌ Nein | Ist dieses Ticket "abrechenbar"? (für MSP) | **REST-API Endpoints**: ```csharp PUT /Helpdesk/HelpdeskUpdateContract(UpdateHelpdeskRequest) → Rückgabe: UpdatedContractProperties { Contract, SLARules, PriceInfo } PUT /Helpdesk/HelpdeskUpdateArticleWorkItem(UpdateHelpdeskRequest) → Rückgabe: UpdatedArticleWorkItemProperties { Article, ContingentHours, Price } ``` **Use-Case UC 11.5.2.4**: "Ticket Vertrag zuordnen (Abrechnung)" ``` Workflow: 1. Ticket wurde erstellt, aber nicht an Vertrag zugeordnet 2. Techniker erkennt: Kunde hat "Premium Support" Vertrag 3. Klick: Vertrag auswählen → "Premium Support (ACME GmbH)" 4. System: - Setzt ContractI3D und ContractName - Berechnet SLA-Regeln neu (Premium = 2h Response) - Zeigt verfügbare Kontingent-Stunden: "45/60 Stunden verfügbar" - Markiert Ticket als "IsCalculable = true" 5. In Abrechnung: Ticket wird automatisch gegen Vertrag verrechnet ``` --- #### **Tags & Labels** | Feld | Datentyp | Edierbar | Erforderlich | Beschreibung | |------|----------|----------|--------------|-------------| | `Tags[]` | List | ✅ **JA** | ❌ Nein | Flexible Labels für Kategorisierung (0-N) | **REST-API Endpoint**: ```csharp PUT /Helpdesk/HelpdeskUpdateTags(UpdateHelpdeskRequest>) ``` **Use-Case UC 11.5.2.5**: "Tags hinzufügen für bessere Filtration" ``` Workflow: 1. Ticket #12345: "Netzwerk-Ausfall bei ACME" 2. Techniker fügt Tags hinzu: - "Netzwerk" - "Kritisch" - "Wiederkehrend" (war auch letzte Woche) - "Kunde-Beschwerde" 3. In Kanban/Ticket-Liste: Tags werden als farbige Chips angezeigt 4. Filterung: "Zeige alle mit Tag='Kritisch'" → findet 5 Tickets 5. Reporting: "Wie oft tritt 'Netzwerk'-Problem auf?" → 47 Tickets tagged ``` --- ### 🔧 TERTIARY METADATA (System-Felder & Audit-Trail - 70+ Felder) Diese Felder sind größtenteils **Read-Only** und dienen der Systemverwaltung und Audit-Trails. #### **Versioning & Tracking** | Feld | Datentyp | Edierbar | Beschreibung | |------|----------|----------|-------------| | `Version` | int | ❌ Nein | Optimistic Locking (Conflicts bei concurrent edits) | | `LatestHistoryI3D` | int (FK) | ❌ Nein | Referenz zum letzten History-Einträge | | `ConnectionNumber` | nvarchar | ✅ **JA** | Externe Referenznummer (z.B. aus Ticketing-System) | #### **Audit Trail** | Feld | Datentyp | Beschreibung | |------|----------|-------------| | `CreatedByI3D` | int (FK) | System: Wer hat Ticket erstellt | | `CreatedDate` | datetime2(2) | System: Wann erstellt | | `ChangedByI3D` | int (FK) | System: Wer hat zuletzt geändert | | `ChangedDate` | datetime2(2) | System: Wann zuletzt geändert | | `DeletedByI3D` | int (FK) | System: Wer hat gelöscht (falls gelöscht) | | `DeletedDate` | datetime2(2) | System: Wann gelöscht | | `IsDeleted` | bit | System: Soft-Delete Flag | #### **Integration & System** | Feld | Datentyp | Beschreibung | |------|----------|-------------| | `CreatedFrom` | nvarchar | Quelle: "Email", "WebForm", "API", "Manual", "Outlook" | | `CreatedFromObjectI3D` | int | ID des Source-Objekts (falls von E-Mail oder Outlook) | | `CentronFingerprint` | nvarchar | Unique Identifier für Duplikat-Erkennung | | `OutlookPriority` | int | Priority aus Outlook-Sync (wenn von E-Mail) | | `Branch` | nvarchar | Niederlassung/Filiale (Multi-Branch Kunden) | | `CFlowStateI3D` | int (FK) | Custom Workflow State (wenn definiert) | #### **Spezielle Flags & Status** | Feld | Datentyp | Beschreibung | |------|----------|-------------| | `IsRMA` | bit | Ist RMA (Retoure) Ticket? | | `RMANumber` | nvarchar | RMA-Nummer (externe Tracking) | | `IsTicketRefused` | bit | Hat Kunde Ticket "abgelehnt"? | | `IsOnlyInternalVisible` | bit | Nur intern sichtbar (verstecktes Ticket) | | `EscalationLevel` | int | Aktuelle Eskalationsstufe (0=Keine, 1=Manager, 2=Director) | | `ParentHelpdeskI3D` | int (FK) | Parent-Ticket (für Ticket-Hierarchien) | | `ProjectHelpdeskI3D` | int (FK) | Zugehöriges Projekt-Ticket | --- ### 🌐 DYNAMISCHE FELDER & CALCULATIONS Diese Felder werden vom System berechnet, sind aber über spezielle Endpoints aktualisierbar: #### **SLA & Response Times** ```csharp SLA-Tracking (Auto-calculated): ├── FirstResponseTime (Ziel: 2h) ├── ResolutionTime (Ziel: 8h) ├── SLAStatus (enum: OnTrack, AtRisk, Breached) ├── HoursUntilSLABreach (Echtzeit-Countdown) └── LastResponseWasSLACompliant (bool) ``` #### **Time Tracking Counters** ```csharp Timer-Felder (Automatisch aktualisiert): ├── TotalWorkingTimeInMinutes (Summe aller TimeRecords) ├── TotalStopwatchTimeInMinutes (Summe aller Stoppuhren) ├── TotalEmailTimeInMinutes (Zeit für E-Mail-Korrespondenz) ├── CurrentTimerRunningMinutes (Aktive Timer) └── ContingentHoursRemaining (für MSP-Verträge) ``` **Use-Case UC 11.5.3.1**: "Überblick über Zeitaufwand" ``` Workflow: 1. Ticket #12345 wird bearbeitet 2. System zeigt: - "Total Zeit: 2h 30min" - "Davon: 2h 15min aktive Arbeit + 15min E-Mails" - "Kontingent: 45 von 60 Stunden verfügbar (75%)" - "SLA Status: ✅ On Track (1h 30min bis Ablauf)" 3. Wenn Zeit 7:50h überschreitet: "⚠️ SLA At Risk" 4. Wenn Zeit 8:00h überschreitet: "🔴 SLA Breached" ``` --- ## DATEN-ENTITÄTEN - VOLSTÄNDIGE STRUKTUR ```csharp HelpdeskDTO (Main Entity - 190+ Properties) ├── IDENTIFIKATION │ ├── I3D: int │ ├── Number: int │ ├── ShortDescription: string │ └── Description: nvarchar(max) │ ├── STATUS & PRIORITÄT │ ├── HelpdeskStatusI3D: int (FK) │ ├── HelpdeskStatusName: string (calculated) │ ├── HelpdeskPriorityI3D: int (FK) │ ├── HelpdeskPriorityName: string (calculated) │ ├── HelpdeskTypeI3D: int (FK) │ ├── HelpdeskMarked: bit │ └── EscalationLevel: int │ ├── KATEGORISIERUNG │ ├── MainCategoryI3D: int (FK) │ ├── MainCategoryName: string │ ├── SubCategory1I3D: int (FK) │ ├── SubCategory1Name: string │ ├── SubCategory2I3D: int (FK) │ └── SubCategory2Name: string │ ├── BESCHREIBUNGEN │ ├── InternalNote: nvarchar(max) │ ├── AdditionalText1: nvarchar(max) │ └── AdditionalText2: nvarchar(max) │ ├── ZEITPLANUNG │ ├── DueDate: datetime2 │ ├── PlannedDurationInHours: decimal │ ├── WorkStartDate: datetime2 │ ├── WorkEndDate: datetime2 │ ├── CreatedDate: datetime2 │ ├── ChangedDate: datetime2 │ ├── ClosedDate: datetime2 │ ├── LastCommentDate: datetime2 │ ├── LastEmailDate: datetime2 │ └── EscalationDate: datetime2 │ ├── KUNDEN-BEZIEHUNGEN │ ├── CustomerI3D: int (FK) [NOT NULL] │ ├── CustomerName: string (calculated) │ ├── ContactPersonI3D: int (FK) │ ├── ContactPersonName: string (calculated) │ ├── ContactPersonEmail: string (calculated) │ ├── ContactPersonPhone: string │ └── ContactPersonFax: string │ ├── TEAM & ZUORDNUNG │ ├── ResponsiblePersonI3D: int (FK) │ ├── ResponsiblePersonName: string (calculated) │ ├── EditorsI3D: List (Many-to-Many) │ ├── CreatedByI3D: int (FK) │ ├── ChangedByI3D: int (FK) │ ├── LockUserI3D: int (FK) │ └── LockUserName: string (calculated) │ ├── VERTRÄGE & DIENSTLEISTUNGEN │ ├── ContractI3D: int (FK) │ ├── ContractName: string (calculated) │ ├── ArticleWorkItemI3D: int (FK) │ ├── IsCalculable: bit │ └── ContingentHoursRemaining: decimal (calculated) │ ├── TAGS & LABELS │ ├── Tags[]: List │ │ ├── TagI3D: int │ │ ├── TagCaption: string │ │ └── TagColor: string (hex) │ └── TagsSerialized: string (JSON) │ ├── SYSTEM & AUDIT │ ├── Version: int (Optimistic Locking) │ ├── CreatedFrom: nvarchar (Email|WebForm|API|Manual|Outlook) │ ├── CreatedFromObjectI3D: int (FK) │ ├── CentronFingerprint: nvarchar (Duplikat-ID) │ ├── DeletedByI3D: int (FK) │ ├── DeletedDate: datetime2 │ ├── IsDeleted: bit │ ├── Branch: nvarchar │ └── CFlowStateI3D: int (FK) │ ├── BEZIEHUNGEN │ ├── ParentHelpdeskI3D: int (FK) │ ├── ProjectHelpdeskI3D: int (FK) │ ├── RMANumber: nvarchar │ ├── IsRMA: bit │ ├── IsTicketRefused: bit │ ├── IsOnlyInternalVisible: bit │ ├── ConnectionNumber: nvarchar │ └── ConnectedDeviceNames: string[] │ ├── BERECHNETE FELDER (SLA) │ ├── SLAStatus: enum (OnTrack|AtRisk|Breached) │ ├── FirstResponseTime: TimeSpan (calculated) │ ├── ResolutionTime: TimeSpan (calculated) │ ├── HoursUntilBreach: decimal (calculated) │ └── LastResponseWasSLACompliant: bit │ ├── TIME TRACKING │ ├── TotalWorkingTimeInMinutes: int (calculated) │ ├── TotalStopwatchTimeInMinutes: int (calculated) │ ├── TotalEmailTimeInMinutes: int (calculated) │ ├── CurrentTimerRunningMinutes: int (calculated) │ └── ContingentHoursUsed: decimal (calculated) │ ├── COLLECTIONS (Related Objects) │ ├── HelpdeskComments[]: List │ ├── HelpdeskDocuments[]: List │ ├── HelpdeskHistory[]: List │ ├── TimeRecords[]: List │ ├── TicketEditors[]: List │ ├── LinkedTickets[]: List │ ├── Checklist[]: List │ └── LinkedDevices[]: List │ └── METADATEN ├── LatestHistoryI3D: int (FK) ├── OutlookPriority: int └── RowVersion: byte[] (für Concurrency) ``` --- ## REST-API - ALLE UPDATE-ENDPOINTS ```csharp // 25+ dedizierte Update-Endpoints für granulare Änderungen PUT /Helpdesk/HelpdeskUpdateDescription PUT /Helpdesk/HelpdeskUpdateShortDescription PUT /Helpdesk/HelpdeskUpdateStatus → UpdatedStatusProperties PUT /Helpdesk/HelpdeskUpdatePriority → UpdatedPriorityProperties PUT /Helpdesk/HelpdeskUpdateType PUT /Helpdesk/HelpdeskUpdateCategory PUT /Helpdesk/HelpdeskUpdateInternalNote PUT /Helpdesk/HelpdeskUpdateDueDate PUT /Helpdesk/HelpdeskUpdatePlannedDuration PUT /Helpdesk/HelpdeskUpdateWorkDates PUT /Helpdesk/HelpdeskUpdateContactPerson → UpdatedContactProperties PUT /Helpdesk/HelpdeskUpdateResponsible → UpdatedResponsibleProperties PUT /Helpdesk/HelpdeskUpdateEditors → UpdatedEditorsProperties PUT /Helpdesk/HelpdeskUpdateContract → UpdatedContractProperties PUT /Helpdesk/HelpdeskUpdateArticleWorkItem → UpdatedArticleWorkItemProperties PUT /Helpdesk/HelpdeskUpdateTags PUT /Helpdesk/HelpdeskUpdateMarked PUT /Helpdesk/HelpdeskUpdateConnectionNumber PUT /Helpdesk/HelpdeskUpdateAdditionalText1 PUT /Helpdesk/HelpdeskUpdateAdditionalText2 PUT /Helpdesk/HelpdeskUpdateIsOnlyInternalVisible PUT /Helpdesk/HelpdeskUpdateIsCalculable PUT /Helpdesk/HelpdeskUpdateParentTicket PUT /Helpdesk/HelpdeskUpdateProjectTicket // ... plus weitere ... // Bulk-Operationen POST /Helpdesk/UpdateMultipleStatus POST /Helpdesk/UpdateMultiplePriority POST /Helpdesk/UpdateMultipleEditors POST /Helpdesk/AddTagsToMultiple POST /Helpdesk/RemoveTagsFromMultiple ``` --- ### Use Cases #### UC 11.5.1: Ticket anzeigen und bearbeiten - **Beschreibung**: Techniker öffnet Ticket und bearbeitet Beschreibung, Status, Priorität - **Ablauf**: 1. Ticket aus Liste auswählen 2. Ticket-Details laden (lazy loading) 3. Beschreibung anzeigen (collapsible) 4. Eigenschaften bearbeiten (Primary + Secondary Metadata) 5. Änderungen speichern (auto-save nach 2 Sekunden) - **REST-API**: `GET /Helpdesk/{id}`, `PUT /Helpdesk/HelpdeskUpdate*` - **Echtzeit-Features**: - Editor Lock Detection (zeigt wer gerade bearbeitet) - Live Status-Updates - Concurrent Edit Warnings #### UC 11.5.2: Kommentare und Noten hinzufügen - **Beschreibung**: Externe Kundennotizen vs. interne Support-Noten - **Ablauf**: 1. Comment-Input öffnen 2. Text eingeben 3. Type wählen (Internal/External/Public) 4. Speichern und Optional E-Mail senden - **Betroffene Felder**: `HelpdeskComment` (CommentText, IsInternal, CreatedByI3D, CreatedDate) #### UC 11.5.3: Anhänge verwalten - **Ablauf**: 1. Datei hochladen (Drag&Drop oder Browse) 2. Dateityp erkennen (Bild, PDF, etc.) 3. Inline Preview zeigen 4. Mit E-Mail optional versenden 5. Dateien löschen (nur Ersteller) #### UC 11.5.4: Ticket-Historie anzeigen - **Beschreibung**: Timeline aller Änderungen, Kommentare, Statuswechsel - **Datenquellen**: `HelpdeskHistory` + `HelpdeskComment` + Zuordnungs-Changes - **Features**: - Chronologische Sortierung - Gruppierung nach Datum - Benutzer-Avatar mit Namen - Differenz-Hervorhebung bei Änderungen - **Audit Trail zeigt**: "Maria hat Priorität von 'Mittel' zu 'Hoch' geändert am 2025-01-20 14:30" ### Hidden Features 1. **Editor Lock**: Zeigt in Echtzeit wer gerade das Ticket bearbeitet (SignalR) 2. **Conditional Formatting**: Status-Farben basierend auf Regeln + SLA-Status 3. **Inline Attachments**: Bilder/PDFs direkt im Editor sichtbar 4. **Mention-System**: @mention von Mitarbeitern in Kommentaren (triggert Benachrichtigung) 5. **Keyboard Shortcuts**: Schnelle Navigation zwischen Tickets - `n` = Next Ticket - `p` = Previous Ticket - `d` = Due Date fokus - `e` = Editors fokus - `r` = Responsible fokus 6. **Bulk Edit Mode**: Mehrere Tickets auswählen + Mass-Update (z.B. alle zu Status "Gelöst" ändern) 7. **SLA Auto-Escalation**: Bei Status-Change werden SLA-Zeiten automatisch neu berechnet 8. **Change Notifications**: Alle Editors werden in Echtzeit informiert wenn sich etwas ändert --- ## 3.2 Ticket-Liste / Cached Ticket List **Pfad**: `src/CentronNexus/ServiceBoard/TicketList/TicketSearchPage.razor` **Komponente**: `CachedTicketListPage.razor` **Kategorie**: Ticket Management (Filterung & Suche) **Status**: ✅ Vollständig implementiert **Komplexität**: 🔴 Sehr Hoch (50+ Filter-Dimensionen) **Performance**: ~500 Tickets im RAM-Cache, <100ms Filter-Anwendung ### Beschreibung Die Ticket-Liste ist das **zentrale Verwaltungs- und Such-Interface**. Sie ist eine hochperformante, gecachte Implementierung mit: - **50+ Filter-Dimensionen** (Kombinierbar mit AND/OR Logik) - **4 Kanban-Board-Ansichten** (Status, Priorität, Typ, Zuordnung) - **Conditional Formatting Engine** (100+ vordefinierte + custom Regeln) - **Multi-Sort** (bis zu 3 Spalten gleichzeitig) - **Gespeicherte Ansichten** (User-spezifisch oder Team-weit) - **Real-Time SignalR Updates** (neue Tickets sofort sichtbar) - **Bulk-Operationen** (Multi-Select für Mass-Updates) --- ## FILTER-DIMENSIONEN - UMFASSENDE DOKUMENTATION ### 📊 50+ Filter-Kriterien (Organisiert nach Kategorie) #### **1. STATUS & PRIORITÄT (8 Filter)** | Filter | Typ | Standard-Werte | Beschreibung | |--------|-----|-----------------|-------------| | **Status** | Multi-Select Dropdown | Alle Status | Offen, In Arbeit, Wartet, Gelöst, Geschlossen | | **Priorität** | Multi-Select Dropdown | Alle Prioritäten | Niedrig, Mittel, Hoch, Kritisch | | **Ticket-Typ** | Multi-Select Dropdown | Alle Typen | Incident, Request, Change, Problem, Task | | **SLA-Status** | Multi-Select Buttons | [Alle] | On Track ✅, At Risk ⚠️, Breached 🔴 | | **Ist überfällig?** | Toggle | off | true/false (DueDate < now) | | **Hat aktiven Timer?** | Toggle | off | true/false (CurrentTimerRunning > 0) | | **Ist markiert?** | Toggle | off | true/false (HelpdeskMarked) | | **Ist RMA?** | Toggle | off | true/false (IsRMA) | **Use-Case UC 11.6.1.1**: "Zeige alle kritischen Tickets die überfällig sind" ``` Filter-Kombination: 1. Priorität = Kritisch 2. AND Status ≠ Geschlossen 3. AND Ist überfällig? = true → Ergebnis: 3 Tickets gefunden ``` --- #### **2. ZEITZEITRAUM & DATUM (6 Filter)** | Filter | Typ | Standard | Beispiele | |--------|-----|----------|-----------| | **Zeitraum (Erstellt)** | Dropdown | Alle | Heute, Diese Woche, Dieser Monat, Letzter Monat, Letzte 3 Monate, Benutzerdefiniert | | **Zeitraum (Geändert)** | Dropdown | Alle | (gleich wie oben) | | **Zeitraum (Geschlossen)** | Dropdown | Alle | (gleich wie oben) | | **Due-Date Range** | Date Range Picker | Alle | Von Datum bis Datum | | **Erstellt vor X Tagen** | Integer Spinner | - | Nur Tickets älter als X Tage | | **Ungelesen (Neue Kommentare)** | Toggle | off | true/false | **Use-Case UC 11.6.1.2**: "Zeige Tickets die diese Woche erstellt wurden" ``` Filter: 1. Zeitraum (Erstellt) = "Diese Woche" → Auto-Filter: CreatedDate >= Monday 00:00 AND CreatedDate <= Sunday 23:59 → Ergebnis: 24 Tickets ``` --- #### **3. ZUORDNUNG & OWNERSHIP (10 Filter)** | Filter | Typ | Standard | Beschreibung | |--------|-----|----------|-------------| | **Zugeordnung** | Multi-Select | [Alle] | Nur Mein, Nur Mein Team, Nur Nicht zugeordnet, Spezifische Person | | **Verantwortliche Person** | Multi-Select Dropdown | Alle | Suche/Wähle verantwortliche Person(en) | | **Bearbeiter (Editors)** | Multi-Select Dropdown | Alle | Tickets bei denen ich Bearbeiter bin | | **Erstellt von** | Multi-Select Dropdown | Alle | Tickets erstellt von Person X | | **Geändert von** | Multi-Select Dropdown | Alle | Tickets zuletzt geändert von Person X | | **Team** | Multi-Select Dropdown | Alle | Nur bestimmtes Support-Team | | **Keine Zuordnung** | Toggle | off | true/false (ResponsiblePersonI3D IS NULL) | | **Nur meine Favoriten** | Toggle | off | true/false (HelpdeskMarked AND ResponsiblePerson = Current User) | | **Warteschlange** | Dropdown | - | Service Queue 1, Service Queue 2, etc. | | **Abteilung** | Dropdown | - | IT, HR, Finance, Operations, etc. | **Use-Case UC 11.6.1.3**: "Zeige mir alle Tickets die nicht zugeordnet sind und Priorität >= Hoch" ``` Filter-Kombination: 1. Zuordnung = "Nur Nicht zugeordnet" 2. AND Priorität = {Hoch, Kritisch} → Ergebnis: 7 Tickets (Priorisierungswarteschlange) ``` **Use-Case UC 11.6.1.4**: "Zeige mir die Arbeitsbelastung meines Teams" ``` Filter: 1. Team = "Mein Team (5 Techniker)" 2. Status ≠ Geschlossen → Anzeige mit Group-By = "Verantwortliche Person" → Sichtbar: Maria (12 aktiv), Klaus (8 aktiv), Peter (15 aktiv), Lisa (10 aktiv), Frank (3 aktiv) ``` --- #### **4. KUNDEN & KONTAKTE (7 Filter)** | Filter | Typ | Standard | Beschreibung | |--------|-----|----------|-------------| | **Kunde** | Multi-Select Dropdown | Alle | Einzelne oder mehrere Kunden | | **Kundenkategorie** | Multi-Select Dropdown | Alle | Premium, Standard, Startup, etc. | | **Kontaktperson** | Multi-Select Dropdown | Alle | Spezifische Kontaktperson beim Kunden | | **Abteilung (Kunde)** | Multi-Select Dropdown | Alle | IT, HR, Finance bei diesem Kunden | | **Kundenstandort** | Multi-Select Dropdown | Alle | HQ, Filiale Berlin, Filiale München, etc. | | **Ist großer Kunde** | Toggle | off | true/false (Revenue > Threshold) | | **Meine Kunden** | Toggle | off | true/false (Ich bin Account Manager) | **Use-Case UC 11.6.1.5**: "Zeige alle offenen Tickets für Top 5 Kunden" ``` Filter: 1. Kunde = {ACME GmbH, TechCorp, GlobalSoft, etc.} 2. Status = {Offen, In Arbeit} → Anzeige mit Priority Sort (Kritisch zuerst) ``` --- #### **5. KATEGORISIERUNG (5 Filter)** | Filter | Typ | Standard | Beschreibung | |--------|-----|----------|-------------| | **Hauptkategorie** | Multi-Select Dropdown | Alle | Hardware, Software, Netzwerk, Sicherheit | | **Unterkategorie 1** | Multi-Select Dropdown (dependant) | Alle | Abhängig von Hauptkategorie | | **Unterkategorie 2** | Multi-Select Dropdown (dependant) | Alle | Abhängig von Unterkategorie 1 | | **Service/Vertrag** | Multi-Select Dropdown | Alle | Premium Support, Standard, MSP, etc. | | **Produkt/Lösung** | Multi-Select Dropdown | Alle | Windows, Office 365, Azure, etc. | **Use-Case UC 11.6.1.6**: "Zeige alle offenen Hardware-Issues" ``` Filter: 1. Hauptkategorie = "Hardware" 2. Unterkategorie 1 = "Laptop" (auto-erscheint nach Hardware-Wahl) 3. Status = "Offen" → Ergebnis: 12 Tickets ``` --- #### **6. TAGS & LABELS (3 Filter)** | Filter | Typ | Standard | Beschreibung | |--------|-----|----------|-------------| | **Tags** | Multi-Select Chips | Alle | Flexible Labels (z.B. "Kritisch", "Netzwerk", "Wiederkehrend") | | **Mit Tags** | Toggle | off | Hat Ticket mindestens 1 Tag? | | **Ohne Tags** | Toggle | off | Hat Ticket keine Tags? | **Use-Case UC 11.6.1.7**: "Zeige alle Tickets mit Tag 'Wiederkehrend' Problem" ``` Filter: 1. Tags contains "Wiederkehrend" → Ergebnis: 23 Tickets → Insight: "Dieses Problem tritt sehr häufig auf - sollte permanent gelöst werden" ``` --- #### **7. VERTRÄGE & ABRECHNUNG (6 Filter)** | Filter | Typ | Standard | Beschreibung | |--------|-----|----------|-------------| | **Vertrag** | Multi-Select Dropdown | Alle | Spezifischer Vertrag | | **MSP-Artikel** | Multi-Select Dropdown | Alle | Gebündelte Service-Pakete | | **Ist abrechenbar?** | Toggle | off | true/false (IsCalculable) | | **Kontingent verbraucht >%** | Slider | 0%-100% | Zeige Tickets mit >X% Kontingent verbraucht | | **Kontingent < X Stunden** | Integer | - | Nur Tickets mit weniger als X Stunden Kontingent | | **Branch/Filiale** | Multi-Select Dropdown | - | Multichat-Umgebung, nur bestimmte Filiale | **Use-Case UC 11.6.1.8**: "Zeige kritische Kontingent-Tickets (weniger als 5 Stunden verfügbar)" ``` Filter: 1. Ist abrechenbar? = true 2. Kontingent < 5 Stunden 3. Status ≠ Geschlossen → Ergebnis: 4 Tickets (Warnung: Kontingent läuft aus!) ``` --- #### **8. TEXTSUCHE & KEYWORDS (4 Filter)** | Filter | Typ | Standard | Beschreibung | |--------|-----|----------|-------------| | **Schlüsselwort in Titel** | Text-Eingabe | - | Wildcard-Suche in ShortDescription | | **Schlüsselwort überall** | Text-Eingabe | - | Full-Text Search in Title + Description + Comments | | **Ticket-Nummer** | Text-Eingabe | - | Suche nach Ticket #12345 | | **Referenznummer (extern)** | Text-Eingabe | - | ConnectionNumber oder externe Ticket-ID | **Use-Case UC 11.6.1.9**: "Suche alle Tickets mit 'Office 365' im Inhalt" ``` Filter: 1. Schlüsselwort überall = "Office 365" → Echtzeit-Suche in ~500 Tickets → Ergebnis: 47 Tickets (0.05 Sekunde) ``` --- #### **9. SPEZIELLE FLAGS (5 Filter)** | Filter | Typ | Standard | Beschreibung | |--------|-----|----------|-------------| | **Ist intern nur** | Toggle | off | true/false (IsOnlyInternalVisible - versteckte Tickets) | | **Ist Duplikat** | Toggle | off | true/false (ParentHelpdeskI3D IS NOT NULL) | | **Ist weiterleitet** | Toggle | off | true/false (ForwardedToI3D IS NOT NULL) | | **Hat Anhänge** | Toggle | off | true/false (HelpdeskDocuments.Count > 0) | | **Hat Kommentare** | Toggle | off | true/false (HelpdeskComments.Count > 0) | --- #### **10. CUSTOM FIELDS (Variable - 0-50+)** | Filter | Typ | Standard | Beschreibung | |--------|-----|----------|-------------| | **Custom Feld 1** | (je nach Datentyp) | - | Kundenspezifisch, z.B. "Gebäude", "Stockwerk" | | **Custom Feld 2** | (je nach Datentyp) | - | Kundenspezifisch, z.B. "Raumart" | | **...** | ... | ... | ... | | **Custom Feld N** | (je nach Datentyp) | - | Kundenspezifisch | --- ## FILTER-KOMBINATIONEN - PRAKTISCHE BEISPIELE ``` Beispiel 1: "Meine kritischen offenen Tickets" ├── Status = {Offen, In Arbeit} ├── Priorität = {Hoch, Kritisch} ├── Zugeordnung = "Nur Mein" └── SLA-Status ≠ Breached → Ergebnis: 5 Tickets (dringende Aufmerksamkeit erforderlich) Beispiel 2: "Tickets die warten" ├── Status = "Wartet" ├── Wartet länger als = 5 Tage └── Kategorie = {Hardware, Netzwerk} → Ergebnis: 3 Tickets (Follow-up erforderlich) Beispiel 3: "Kundenreporting für ACME GmbH" ├── Kunde = "ACME GmbH" ├── Zeitraum (Geschlossen) = "Letzte 30 Tage" ├── Status = "Geschlossen" └── Sortierung = CreatedDate DESC → Ergebnis: 23 Tickets (für Rechnungsstellung) Beispiel 4: "Workload-Balancing" ├── Team = "Mein Team" ├── Status ≠ Geschlossen ├── Group-By = "Verantwortliche Person" └── Sort = "Ticket-Count DESC" → Ergebnis: Visualisierung der Auslastung pro Person ``` --- ## KANBAN-BOARD ANSICHTEN ### 📊 4 Verschiedene Board-Modi #### **1. Status-Board** (Standard - Standard-Ansicht) ``` ┌─────────────┬──────────────┬─────────┬──────────┬────────────┐ │ Offen │ In Arbeit │ Wartet │ Gelöst │ Geschlossen│ │ (42) │ (18) │ (5) │ (156) │ (892) │ ├─────────────┼──────────────┼─────────┼──────────┼────────────┤ │ [#12345] │ [#12346] │[#12347] │[#12348] │[#12349] │ │ Netzwerk │ Hardware │ Email │Software │ Access │ │ Pri: Hoch │ Pri: Kritisch│Pri: Mid │Pri: Low │Pri: Low │ │ 2h überfällig│SLA: OK │Waiting 3│SLA: OK │ This Mo │ │ │ │ days │ │ │ ├─────────────┼──────────────┼─────────┼──────────┼────────────┤ │ [#12350] │ [#12351] │ │[#12352] │ │ │ Software │ Netzwerk │ │ Access │ │ │ Pri: Mid │ Pri: High │ │Pri: Mid │ │ │ SLA: OK │ SLA: AT RISK │ │ SLA: OK │ │ └─────────────┴──────────────┴─────────┴──────────┴────────────┘ Spalten-Statistiken (Header): - Offen (42): SLA OK: 41, SLA AT RISK: 1, SLA BREACH: 0 - In Arbeit (18): SLA OK: 17, SLA AT RISK: 1, SLA BREACH: 0 - Wartet (5): > 5 Tage: 2, > 10 Tage: 1, Critical: 0 ``` **Funktionen**: - ✅ Drag-Drop Ticket zwischen Spalten → Status aktualisiert sich automatisch - ✅ Ticket-Karten zeigen: Nummer, Titel, Priorität, SLA-Status - ✅ Spalten-Header mit Statistiken - ✅ Farbcodierung nach Priorität/SLA - ✅ Klick auf Ticket → öffnet Details --- #### **2. Prioritäts-Board** ``` Spalten: [Kritisch] [Hoch] [Mittel] [Niedrig] Kritisch (8): ├─ [#12345] Netzwerk-Ausfall (ACME) ├─ [#12346] System Down ├─ [#12347] Sicherheit Breach ├─ [#12348] Db-Fehler ├─ [#12349] Backup fehlgeschlagen ├─ [#12350] VPN Down ├─ [#12351] Ransomware Warnung └─ [#12352] E-Mail Ausfall Hoch (18): ├─ [#12400] Password Reset ├─ [#12401] Drucker-Problem ... ``` **Use-Case UC 11.6.2.1**: "Techniker sieht auf einen Blick was dringend ist" ``` Workflow: 1. Morgens Kanban öffnen (Prioritäts-Board) 2. Sieht sofort: 8 kritische, 18 hohe Priorität 3. Nimmt sich Top 3 kritische vor 4. Drag-Drops Ticket aus "Kritisch" → "In Arbeit" 5. Status-Update erfolgt automatisch + anderen Editoren wird SignalR-Update gesendet ``` --- #### **3. Typ-Board** ``` Spalten: [Incident] [Request] [Change] [Problem] [Task] Incident (45): ├─ [#12345] Server reagiert nicht ├─ [#12346] Internet Down ├─ [#12347] Email Down └─ ... Request (62): ├─ [#12400] Neuer User-Account ├─ [#12401] Software-Installation ├─ [#12402] Drucker verbinden └─ ... ``` --- #### **4. Zuweisung-Board** ``` Spalten: [Klaus] [Maria] [Peter] [Lisa] [Frank] [Nicht zugeordnet] Klaus (12 Tickets): ├─ [#12345] Priorität: Kritisch ├─ [#12346] Priorität: Hoch ├─ [#12347] Priorität: Mittel └─ ... Maria (8 Tickets): ├─ [#12400] Priorität: Kritisch (1h überfällig!) ├─ [#12401] Priorität: Hoch └─ ... Nicht zugeordnet (7 Tickets): ├─ [#12500] Priorität: Kritisch ├─ [#12501] Priorität: Hoch └─ ... ``` **Use-Case UC 11.6.2.2**: "Manager sieht Arbeitsauslastung des Teams und balanciert manuell" ``` Workflow: 1. Manager öffnet Kanban (Zuweisung-Board) 2. Sieht: Klaus = 12, Maria = 8, Peter = 15 (Überlastet!), Lisa = 10, Frank = 3 3. Sieht kritisches Ticket #12400 bei Maria (1h überfällig) → muss sofort bearbeitet werden 4. Drag-Drops 2 Tickets von Peter zu Frank (Umverteilung) 5. Alle Techniker erhalten Benachrichtigung über Umverteilung ``` --- ## CONDITIONAL FORMATTING - 100+ VORDEFINIERTE REGELN ### 🎨 Bedingte Formatierungs-Engine Jede Regel ist definiert als: ```csharp ConditionalFormattingRule { Id: int, Name: string (z.B. "SLA Violation - Überfällig"), Enabled: bool, Conditions: List // AND/OR kombinierbar { ColumnName: string (z.B. "SLAStatus", "Priority", "Status") Operator: enum { Equals, NotEquals, Contains, NotContains, Greater, Less, GreaterOrEqual, LessOrEqual, Between, In, NotIn, StartsWith, EndsWith, Regex, IsNull, IsNotNull }, Value: object (z.B. 3 für "Kritisch", "true" für bool), CaseSensitive: bool, LogicalOperator: enum { And, Or } // Verknüpfung zur nächsten Bedingung }, LogicalCombination: enum { AllMustMatch (AND), AnyCanMatch (OR) }, Styling: ConditionalFormattingStyle { BackgroundColor: hex (z.B. "#FF0000"), ForegroundColor: hex, FontWeight: enum { Normal, Bold, VeryBold }, FontStyle: enum { Normal, Italic, Underline, Strike }, BorderColor: hex, BorderWidth: int (0-5px), Icon: string (z.B. "🔴", "⚠️", "✅", "🔒"), BlinkingEnabled: bool (für sehr kritisch) }, Priority: int (0-1000, höher = wird zuerst angewendet), CreatedDate: datetime, IsSystem: bool (true = c-entron-vordefiniert, false = custom) } ``` ### 📋 Standard-Regeln (Vordefiniert) | Nr. | Regel-Name | Bedingung | Farbe | Icon | |-----|------------|-----------|-------|------| | 1 | **SLA Breached** | SLAStatus = "Breached" | 🔴 Rot | 🚨 | | 2 | **SLA At Risk** | SLAStatus = "At Risk" | 🟡 Orange | ⚠️ | | 3 | **Priorität Kritisch** | Priority = 4 (Kritisch) | 🔴 Rot + Bold | 🔴 | | 4 | **Priorität Hoch** | Priority = 3 (Hoch) | 🟠 Orange | ⬆️ | | 5 | **Überfällig** | DueDate < NOW() | 🔴 Rot + Blinkend | ⏰ | | 6 | **Wartet > 5 Tage** | Status = "Wartet" AND (NOW - StatusChangeDate) > 5 Tage | 🟡 Gelb | ⏳ | | 7 | **Ich bin Responsible** | ResponsiblePersonI3D = CurrentUserId | 🟢 Grün Border | 👤 | | 8 | **Ungelesen Kommentare** | LastCommentDate > LastReadDate | 🔵 Blau Bold | 💬 | | 9 | **Neue E-Mail erhalten** | LastEmailDate > LastReadDate | 🔵 Blau | 📧 | | 10 | **Keine Zuordnung** | ResponsiblePersonI3D IS NULL | ⚪ Grau | ❓ | | 11 | **RMA Ticket** | IsRMA = true | 🟣 Lila | 📦 | | 12 | **Duplikat erkannt** | ParentHelpdeskI3D IS NOT NULL | ⚪ Grau + Strike | 🔗 | | 13 | **Service-Level gefährdet** | (DueDate - NOW) < 2 Stunden | 🔴 Rot | ⏱️ | | 14 | **Große Kundenbeschwerde** | Tags contains "Kunde-Beschwerde" AND Priority >= 3 | 🔴 Rot Bold | 😤 | | 15 | **Team-Überbelastung** | (SELECT COUNT(*) FROM Tickets WHERE Responsible=X AND Status!="Geschlossen") > 15 | 🟡 Orange | 📊 | **Use-Case UC 11.6.3.1**: "Manager sieht auf einen Blick problematische Tickets" ``` Workflow: 1. Techniker öffnet Ticket-Liste 2. System wendet automatisch 15 vordefinierte Formatierungs-Regeln an 3. Visuelles Ergebnis: - 🔴 Rot blinkend: 3 überfällige kritische Tickets - 🟡 Orange: 8 Tickets mit SLA At Risk - 🟢 Grün Border: 12 Tickets die dieser Techniker verantwortet - 💬 Blau Bold: 4 Tickets mit ungelesenen Kommentaren - ❓ Grau: 7 nicht zugeordnete Tickets 4. Priorität ist jetzt klar - der Manager kann sofort handeln ``` --- ## GESPEICHERTE ANSICHTEN (Vordefiniert + Custom) ### 🖼️ Vordefinierte Ansichten (System) | Ansicht | Filter-Kombination | Board-Typ | Nutzer | |---------|-------------------|-----------|-------| | **Meine offenen Tickets** | Zuordnung="Nur Mein" + Status≠"Geschlossen" | Status-Board | Alle | | **Kritische Tickets** | Priorität="Kritisch" + Status≠"Geschlossen" | Prioritäts-Board | Alle | | **Tickets im Wartezustand** | Status="Wartet" + Dauer>5Tage | Prioritäts-Board | Manager | | **Mein Team Auslastung** | Team="Mein Team" + Status≠"Geschlossen" | Zuweisung-Board | Manager | | **Kundenreporting (aktuelle Monat)** | Zeitraum="Dieser Monat" + Status="Geschlossen" | Status-Board | Reporting | | **SLA Breaches** | SLAStatus="Breached" | Prioritäts-Board | Management | | **Nicht zugeordnete Tickets** | Zuordnung="Nur Nicht zugeordnet" | Prioritäts-Board | Dispatcher | | **Meine Favoriten** | HelpdeskMarked=true + ResponsiblePerson=CurrentUser | Status-Board | Alle | | **Heute erstellt** | Zeitraum="Heute" | Status-Board | Alle | | **Nur Meine Beschwerde-Tickets** | Tags contains "Kunde-Beschwerde" + Zuordnung="Mein" | Prioritäts-Board | Alle | ### ➕ Custom Ansichten (User-erstellt & Team-geteilt) **Use-Case UC 11.6.4.1**: "Techniker speichert häufig verwendete Filter-Kombination" ``` Workflow: 1. Setze Filter: - Kategorie = "Netzwerk" - Status = {Offen, In Arbeit} - SLA ≠ Breached 2. Klick "Ansicht speichern" 3. Benenne: "Meine Netzwerk-Tickets" 4. Speicheroption: "Nur Ich" oder "Mit Team teilen" 5. Speichern 6. Nächste Mal: Klick auf "Meine Netzwerk-Tickets" → Filter instant angewendet → Zeitersparnis: 5 Sekunden statt 20 Sekunden Filter-Setup pro Öffnung! ``` --- ## USE-CASES - PRAKTISCHE WORKFLOWS #### UC 11.6.1: Tickets filtern und suchen - **Beschreibung**: Techniker sucht Tickets nach komplexen Kriterien - **Ablauf**: 1. Filtersektion öffnen (Sidebar oder Popover) 2. Filter-Kombinationen setzen (AND/OR Logik) 3. Echtzeit-Vorschau wird aktualisiert 4. Suchen ausführen (oder automatisch <100ms) 5. Ergebnisse in Grid oder Kanban anzeigen 6. Optional: Filter speichern als Ansicht - **Performance**: Cached List (~500 Tickets im RAM), <100ms Filter-Anwendung - **Optimierung**: Nur sichtbare Tickets rendern (Virtual Scrolling) #### UC 11.6.2: Kanban-Board verwenden mit Drag-Drop - **Beschreibung**: Visuelle Ticket-Verwaltung - **Ablauf**: 1. Board-Ansicht wählen (Status, Priorität, Typ, oder Zuordnung) 2. Tickets auf Karten sehen (mit Thumbnails von Beschreibung) 3. Ticket per Drag&Drop zwischen Spalten verschieben 4. System speichert Status-Update 5. Statistiken in Spalten-Header aktualisieren sich 6. Andere Bearbeiter sehen Änderung in Echtzeit (SignalR) - **Hidden Feature**: Double-Click auf Spalte = öffnet modal Details #### UC 11.6.3: Bedingte Formatierung anwenden - **Beschreibung**: Automatische Farb-Hervorhebung basierend auf Regeln - **15+ Standard-Regeln** sichtbar angewandt, plus beliebig viele custom Regeln - **Priorisierung**: Regeln nach Priority index angewendet (höher = zuerst) #### UC 11.6.4: Ticket-Ansicht speichern und wieder laden - **Beschreibung**: Filter-Kombination als vordefinierte Ansicht speichern - **Speicher**: User-spezifisch (nur dieser User sieht) oder Team-weit (geteilt) - **Zugriff**: Quick-Access Dropdown oder Sidebar-Menü - **Verwaltung**: Ansichten können renamed, duplicated, oder deleted werden ### Hidden Features 1. **Column Summary Statistics**: Spalten-Header zeigen Statistiken (z.B. "Offen (42), SLA OK: 41, AT RISK: 1") 2. **Inline Filtering**: Schnellfilter direkt in Spalten (nicht nur Sidebar) 3. **Ticket Grouping**: Gruppierung nach Customer, Team, Status 4. **Export to Excel**: Gefilterte Ergebnisse + Formatierung + Charts exportieren 5. **Bulk Actions**: Multi-Select Checkbox + Batch-Operationen (Status/Priority/Assign/Tags ändern) 6. **Keyboard Shortcuts**: - `Ctrl+F` = Focus Suchfeld - `Ctrl+N` = Neue Ansicht - `Ctrl+S` = Aktuelle Ansicht speichern - `Arrow Up/Down` = Zwischen Tickets navigieren - `Enter` = Ticket öffnen 7. **Real-Time Collaboration**: Wenn anderenbenutzer einen Filter ändert, sehen Sie die Änderungen (nach opt-in) 8. **Performance Monitoring**: Status-Leiste zeigt "500 Tickets geladen (45ms Filter)" 9. **Advanced Sort**: Multi-Column Sort (bis 3 Spalten), benutzerdefinierte Sort-Reihenfolge speichern 10. **Favorite Columns**: User kann auswählen welche Spalten sichtbar sind (bis zu 20 Spalten) --- ## 3.3 Ticket schließen (Close Ticket) **Pfad**: `src/CentronNexus/ServiceBoard/CloseTicket/CloseTicketPage.razor` **Kategorie**: Ticket Management (Workflow & Service Completion) **Status**: ✅ Vollständig implementiert **Komplexität**: 🔴 Hoch (Multi-step, Reports, Email Integration, SLA Tracking) **Lizenz**: `LicenseGuids.Centron` OR `LicenseGuids.ServiceBoard` ### Umfassende Beschreibung Die **Ticket-Schließungs-Modul** ist das kritische Abschluss-System für den Service-Delivery-Prozess. Es bietet: - **7+ Schließungs-Grund-Typen** mit unterschiedlichen Workflows und Post-Close-Aktionen - **Automatische Service-Report-Generierung** (7-teiliger strukturierter Report) - **Multi-Channel E-Mail-System** mit Merge-Tags und Template-Versioning - **SLA-Abschluss-Tracking** mit automatischer Berechnung von Erfüllung und Verzögerungen - **Duplikat-Erkennung** und intelligente Verknüpfung - **Kunden-Zufriedenheits-Survey** Integration mit optionalen Bewertungs-Links - **Conditional Auto-Reopen** bei Kunden-Antworten nach Schließung - **Audit-Trail** mit vollständiger Nachverfolgung aller Schließungs-Parameter ### Schließungs-Gründe (Closing Reason Types) | Grund | Code | Kategorie | Beschreibung | Post-Close Aktionen | |-------|------|-----------|-------------|-------------------| | **Gelöst** | SOLVED | Success | Problem wurde vollständig gelöst | SLA ✅, Archive, Optional Survey | | **Nicht reproduzierbar** | NOT_REPRODUCIBLE | Unresolvable | Problem konnte nicht reproduziert werden | SLA ⏸️, Knowledge Base Entry, Optional Reopen | | **Nicht relevant** | NOT_RELEVANT | Administrative | Ticket ist nicht mehr relevant oder bereits überholt | SLA ❌, Archive, Notification | | **Duplikat** | DUPLICATE | Administrative | Ticket ist Duplikat eines anderen (Link zu Original) | Link + Archive, Merge Time Records | | **Kunde reagiert nicht** | CUSTOMER_UNRESPONSIVE | Waiting | Kunde hat 7 Tage nicht geantwortet nach Anfrage | Optional Reopen, Follow-up Schedule | | **Workaround bereitgestellt** | WORKAROUND | Partial | Workaround statt vollständiger Lösung | SLA ✅, KB Suggestion, Enhancement Ticket | | **Extern gelöst** | EXTERNALLY_RESOLVED | Vendor | Vendor/Hersteller hat Problem gelöst | RMA Tracking, Vendor Feedback | ### Workflow State Machine ``` ┌─────────────────────────────────────────────────────────────┐ │ TICKET CLOSING FLOW │ └─────────────────────────────────────────────────────────────┘ [OPEN] ──→ [PENDING_CLOSE] ──→ [VALIDATE] ──→ [GENERATE_REPORT] (Reason selected) (Business (PDF generated) rules check) │ ↓ [SEND_NOTIFICATIONS] (Email templates) │ ↓ [CREATE_AUDIT_ENTRY] (Track all changes) │ ↓ [CLOSED] (SLA Calculated) │ ┌─────────────────────────────────────────┘ │ Optional: ↓ [MONITOR_REOPEN] (7-day window for customer responses) │ ├──→ [REOPENED] (Auto-reopen on reply) └──→ [ARCHIVED] (After 90 days) ``` ### TicketClose Daten-Entität ```csharp // PRIMARY IDENTIFICATION HelpdeskI3D int IDENTITY(1,1) - FK to Helpdesk TicketNumber int - Display reference TicketTitle nvarchar(500) - Snapshot CreatedByI3D int - Who initiated close CreatedDate datetime2 - When close initiated ClosedByI3D int - Who confirmed/saved close ClosedDate datetime2 - When actually closed // CLOSING REASON & CATEGORIZATION ClosingReasonKind int - FK to ClosingReason lookup ClosingReasonName nvarchar(100) - Cached for speed ClosingCategory nvarchar(50) - SUCCESS, UNRESOLVABLE, ADMINISTRATIVE, WAITING, VENDOR RelatedTicketI3D int? - FK if Duplicate (links to parent) IsDuplicateOf int? - Set when this is identified as duplicate // SOLUTION DOCUMENTATION SolutionSummary nvarchar(max) - Customer-visible solution summary InternalNotes nvarchar(max) - Internal team-only notes RootCauseAnalysis nvarchar(max) - Technical RCA (internal) LearnedLessons nvarchar(max) - Knowledge base contribution // SERVICE REPORT GENERATION IncludeServiceReport bit - Generate PDF report? ServiceReportFormat nvarchar(50) - PDF, HTML, DOCX ServiceReportPdfBytes varbinary(max) - PDF document binary ServiceReportGeneratedDate datetime2 - When report was generated ServiceReportGeneratedByI3D int - Who generated it ServiceReportPageCount int - Number of pages for display // EXTERNAL NOTIFICATIONS (CUSTOMER EMAIL) NotifyCustomer bit - Send email to customer? CustomerEmailTemplate int - FK to EmailTemplate CustomerEmailSentDate datetime2 - When customer email was sent CustomerEmailStatus nvarchar(50) - PENDING, SENT, FAILED, BOUNCED CustomerEmailRetryCount int - Retry attempts AdditionalCustomerEmails nvarchar(max) - Comma-separated email list // INTERNAL NOTIFICATIONS (TEAM EMAIL) NotifyTeam bit - Send internal notification? TeamNotificationChannels nvarchar(max) - EMAIL, SLACK, TEAMS, WEBHOOK TeamEmailTemplate int - FK to EmailTemplate TeamEmailSentDate datetime2 TeamEmailStatus nvarchar(50) // SLA & METRICS OriginalSLAMinutes int - Calculated from contract ActualResolutionMinutes int - From open to close SLAPercentage decimal(5,2) - % of SLA met (e.g., 95.5) SLAMet bit - Was SLA met? SLABreachDate datetime2? - When SLA was breached ReopenWindow int - Hours customer can reopen (e.g., 168 for 7 days) // SATISFACTION SURVEY IncludeSurvey bit - Include satisfaction survey link? SurveyToken uniqueidentifier - Unique token for survey SurveyLink nvarchar(1000) - URL to survey SurveySentDate datetime2 SurveyCompletedDate datetime2? SurveyRating int? - 1-5 or NPS scale // VERSIONING & AUDIT Version int - Optimistic lock for concurrent updates ChangedByI3D int - Last modifier ChangedDate datetime2 - Last change timestamp IsDeleted bit - Soft delete flag DeletedByI3D int? - Who deleted DeletedDate datetime2? - When deleted ``` ### Service Report Struktur (7 Sections) ``` ┌──────────────────────────────────────────────────────────────┐ │ SERVICE REPORT - TICKET CLOSURE DOCUMENT │ ├──────────────────────────────────────────────────────────────┤ │ │ │ 1. TICKET OVERVIEW (Übersicht) │ │ ├─ Ticket-Nummer, Titel, Erstellt-Datum │ │ ├─ Kunden-Name, Kontakt-Person, Standort │ │ ├─ Priorität, SLA-Level, Service-Typ │ │ └─ Bearbeitungs-Team, Primär-Techniker │ │ │ │ 2. PROBLEM DESCRIPTION (Problembeschreibung) │ │ ├─ Original-Problem-Beschreibung │ │ ├─ Symptome & Fehler-Meldungen │ │ ├─ Umgebungs-Details (OS, Hardware, Software-Versionen) │ │ └─ Reproduktions-Schritte │ │ │ │ 3. SOLUTION SUMMARY (Lösungszusammenfassung) │ │ ├─ Durchgeführte Diagnose-Schritte │ │ ├─ Identifizierte Root-Cause │ │ ├─ Implementierte Lösung mit Details │ │ └─ Validierungs-Schritte & Resultat │ │ │ │ 4. WORK PERFORMED (Durchgeführte Arbeiten) │ │ ├─ Aktivitäts-Timeline mit Zeitstempel │ │ ├─ Durchgeführte Konfigurationen & Änderungen │ │ ├─ Software-Updates / Patches angewendet │ │ └─ Hardware-Replacements / Upgrades │ │ │ │ 5. TIME & RESOURCE TRACKING (Zeit & Ressourcen) │ │ ├─ Total-Bearbeitungs-Zeit (Techniker-Stunden) │ │ ├─ Einsatz-Orte & Reisezeit │ │ ├─ Team-Mitglieder & Ihre Rollen │ │ └─ Externe Ressourcen (Vendor, Hersteller) │ │ │ │ 6. COSTS & BILLING (Kosten & Abrechnung) │ │ ├─ Techniker-Zeitkosten (Stundensatz × Stunden) │ │ ├─ Material- & Lizenz-Kosten │ │ ├─ Reisekosten (ggf. Kilometergebühr) │ │ ├─ Sub-Contractor-Kosten (extern) │ │ └─ Total-Kosten + Abrechnung-Status │ │ │ │ 6. ATTACHMENTS & REFERENCES (Anhänge & Referenzen) │ │ ├─ Screenshots & System-Logs │ │ ├─ Konfiguration-Dateien │ │ ├─ KB-Artikel-Links │ │ ├─ Externe-Dokumentation-Links │ │ └─ Follow-up-Tickets oder Verknüpfungen │ │ │ │ Generated: {GenerationDate} │ │ Signed By: {ClosedByName} │ │ Report Format Version: 2.1 │ └──────────────────────────────────────────────────────────────┘ ``` ### E-Mail-Templates System ``` Template-Manager mit 5+ Vordefinierte Templates: 1. "Ticket abgeschlossen - Standard (DE)" ├─ Subject: "Ticket #{TicketNumber} erfolgreich abgeschlossen" ├─ Content: HTML mit Styling (Corporate Colors) ├─ Merge-Tags: {TicketNumber}, {TicketTitle}, {CustomerName}, {ClosedDate}, │ {SolutionSummary}, {TotalHours}, {ClosingTeam}, {SurveyLink} └─ AttachFiles: ServiceReport.pdf (wenn IncludeServiceReport=true) 2. "Ticket abgeschlossen - Standard (EN)" ├─ English version mit gleicher Struktur └─ Automatic language selection based on customer contact language 3. "Mit Kundenbewertungs-Survey (DE)" ├─ Eingebettete Survey-Fragen mit Stern-Rating (1-5) ├─ NPS-Frage (Net Promoter Score 0-10) ├─ Free-text Feedback-Feld └─ One-Click Satisfaction Link für schnelle Bewertung 4. "Interne Team-Benachrichtigung (DE)" ├─ Recipient: Assigned Team (not customer) ├─ Content: Technical Details + RCA + Lessons Learned ├─ For: Team knowledge sharing, best practices └─ Includes: Links zu KB-Artikel, Enhancement-Tickets 5. "MSP/Service-Reporting (DE)" ├─ Für MSP-Kunden mit Abrechnungs-Integration ├─ Shows: Costs, Time breakdown, Line items ├─ Includes: Invoice-Link wenn available └─ Customizable für Abrechnungs-Anforderungen Template Versioning: ├─ Version 1.0 (Legacy) ├─ Version 2.0 (Current - responsive design) └─ Version 2.1 (Latest - with accessibility improvements) ``` ### Detaillierte Use Cases #### **UC 11.7.1: Standardmäßiges Ticket mit Lösungs-Summary abschließen** **Szenario**: Techniker löst Software-Konfigurationsproblem und möchte Ticket ordnungsgemäß abschließen. **Schritt-für-Schritt**: 1. Ticket-Details öffnen (Status = "In Arbeit") 2. "Ticket schließen" Button oben rechts klicken 3. **Step 1 - Schließungs-Grund**: - Dropdown: "Gelöst" wählen - System zeigt: "Dieses Ticket wird als erfolgreich abgeschlossen markiert" 4. **Step 2 - Lösung dokumentieren**: - Feld "Lösungs-Zusammenfassung" ausfüllen (kunde-sichtbar): ``` "Die Outlook-Synchronisierungsprobleme wurden durch Neukonfiguration der EAS-Einstellungen und IMAP-Protokoll-Updates behoben. Kundenendgerät getestet und erfolgreich synchronisiert." ``` - Feld "Interne Noten" ausfüllen (team-only): ``` "Ursache war outdated Exchange-Version im Customer-Tenant. Update durchgeführt + modern auth enabled. Ähnliche Probleme in KB-Artikel verlinkt." ``` 5. **Step 3 - Service-Report**: - Checkbox "Service-Report als PDF generieren" ✓ - System: Startet PDF-Generierung im Hintergrund 6. **Step 4 - Benachrichtigungen**: - "Kunde per E-Mail benachrichtigen": ✓ checked - Template: "Ticket abgeschlossen - Standard (DE)" selected - "Survey einschließen": ✓ checked - "Team benachrichtigen": ✓ checked (internal notification) - Additional Recipients: Leave empty (uses customer primary contact) 7. **Step 5 - Review & Speichern**: - "Vorschau" anzeigen → E-Mail-Inhalt wird angezeigt - "Bestätigen & Speichern" Button klicken 8. **Hintergrund-Prozesse**: - PDF wird generiert und anhängt - E-Mail an Kunde wird versendet - Ticket-Status wechselt zu "Closed" - ClosedByI3D, ClosedDate, SLA-Status werden gesetzt - Audit-Eintrag wird erstellt - Survey-Token wird generiert und in E-Mail eingefügt 9. **Ergebnis**: Ticket ist geschlossen, Kunde erhält E-Mail mit Report & Survey-Link **Betroffene Felder**: ``` Helpdesk.HelpdeskStatusI3D = 5 (Closed) Helpdesk.HelpdeskStatusName = "Closed" Helpdesk.ClosedByI3D = CurrentUserId Helpdesk.ClosedDate = DateTime.Now Helpdesk.SLAStatus = CALCULATED (Met/Breached) Helpdesk.SLAPercentage = (ActualTime / SLATime) × 100 ``` **Betroffene Tabellen**: - Helpdesk (Status-Update) - HelpdeskCloseAudit (Neuer Eintrag) - EmailQueue (E-Mail eingereiht) - ServiceReportHistory (Report-Metadaten) - CustomerSurvey (Survey-Token) --- #### **UC 11.7.2: Duplikat-Ticket-Schließung mit Verknüpfung** **Szenario**: Techniker erkennt, dass aktuelles Ticket bereits gelöst durch anderes Ticket. **Ablauf**: 1. Ticket öffnen (ähnliches Problem wie #2341) 2. "Ticket schließen" → Grund: "Duplikat" 3. System zeigt: "Bitte geben Sie das Original-Ticket an" 4. Feld "Link zu Original-Ticket": "#2341" eingeben - System validiert: Findet Ticket #2341 ✓ - Zeigt: Ticket-Titel, Status, Schließungs-Datum von #2341 5. "Auto-Link Zeit-Einträge": Toggle ✓ - System wird alle TimeRecords von aktuellem zu Original verknüpfen 6. E-Mail-Vorlage: "Duplikat-Benachrichtigung (DE)" - Subject: "Ticket #{Number} - Zusammenführung mit #{OriginalNumber}" - Content nennt das Original-Ticket 7. Speichern: - Aktuelles Ticket wird geschlossen - RelatedTicketI3D = 2341 - IsDuplicateOf = 2341 - Time-Records werden verknüpft - Kunde erhält E-Mail mit Link zum Original-Ticket **Result**: Duplikate eliminiert, Time-Records korrekt zugeordnet --- #### **UC 11.7.3: Nicht reproduzierbares Problem (7-Tage-Auto-Reopen)** **Szenario**: Intermittierendes Problem, kann nicht reproduziert werden nach 3 Versuchen. **Ablauf**: 1. Schließungsgrund: "Nicht reproduzierbar" 2. Lösung: "Problem konnte nach mehreren Diagnose-Versuchen nicht reproduziert werden" 3. System setzt automatisch: - `ReopenWindow = 168 Stunden` (7 Tage) - `ClosedDate + 7 Days = Auto-Archive Date` 4. E-Mail an Kunde: - "Falls Problem erneut auftritt, antwortet Sie einfach auf diese E-Mail" - "Wir werden Ticket automatisch innerhalb 7 Tagen wiedereröffnen bei Rückmeldung" 5. **Überwachung**: - Wenn Kunde antwortet: Ticket automatisch zu "Open" zurück, neuer Techniker zugewiesen - Wenn keine Antwort nach 7 Tagen: Ticket wird archiviert 6. **SLA-Behandlung**: SLA ⏸️ (markiert als "Not Met" aber kein Breach) --- #### **UC 11.7.4: MSP-Ticket mit Kosten-Abrechnung abschließen** **Szenario**: MSP-Techniker schließt Ticket und System muss Kosten für Abrechnung erfassen. **Ablauf**: 1. Schließungsgrund: "Gelöst" 2. Service-Report ✓ 3. Abrechnung: - System liest: Helpdesk.Contract (MSP-Vertrag) - Berechnet Kosten: * Techniker-Zeit: 2,5 Stunden × €80/h = €200 * Material (wenn applicable): €0 * Reisekosten: €0 (Remote) * Gesamtkosten: €200 - Contingent-Verbrauch: * Wenn Vertrag = "100 Stunden/Monat Contingent" * Verbrauchte Stunden diesen Monat: 78h * Neue Summe: 80,5h (innerhalb Contingent ✓) 4. E-Mail-Template: "MSP Service-Report mit Abrechnung" - Zeigt: Itemized Costs, Contingent-Status - Includes: Invoice-Link wenn ready 5. System erstellt automatisch: CostRecording mit allen Details 6. Optionaler Schritt: Techniker kann manuell benutzerdefinierte Notiz hinzufügen: - "Zusätzliche 30 Min zur Kundenaufklärung - nicht in Contingent enthalten" 7. Speichern → Ticket closed + Kostenerfassung erfolgt --- #### **UC 11.7.5: Batch-Close (Mehrere Tickets gleichzeitig abschließen)** **Szenario**: Admin möchte mehrere veraltete Test-Tickets auf einmal schließen. **Ablauf**: 1. Ticket-Liste öffnen 2. Filter anwenden: Status="Open", CreatedDate > 6 Monate ago, Project="Testing" 3. Ergebnis: 15 Tickets gefunden 4. Multi-Select: Alle 15 auswählen (Checkbox-Header) 5. "Bulk Close" Button oben in Toolbar 6. Dialog erscheint: - "Sie wählen 15 Tickets zum Schließen" - Schließungs-Grund: "Nicht relevant" (Dropdown) - Template: "Bulk Close Notification (DE)" - "Notifikation senden?": unchecked (für Test-Tickets nicht notwendig) 7. "Bestätigen & Schließen": - System durchläuft alle 15 Tickets - Für jedes: Status = Closed, ClosedByI3D = CurrentUser, ClosedDate = Now - Audit-Einträge werden batch-erstellt - Progress-Bar zeigt: "Closing 5 of 15..." - Nach Abschluss: "15 Tickets erfolgreich geschlossen" 8. Report: CSV Export mit Zusammenfassung - Ticket-Nummern - Schließungs-Grund - Schließungs-Zeit - Notizen --- ### Versteckte Funktionen (Hidden Features) 1. **Auto-Zusammenfassung via KI** - Wenn `IncludeSurvey=true`: System generiert automatisch eine Kurz-Zusammenfassung basierend auf: * Ticket-Beschreibung * Kommentare & Notizen * Time-Einträge mit Beschreibungen - Techniker kann diese akzeptieren oder manuell überschreiben - Verbessert Konsistenz der Dokumentation 2. **Intelligente E-Mail-Template-Auswahl** - System analysiert Ticket-Merkmale: * `ClosingReason` → Schlägt passende Template vor * `CustomerType` (MSP, Einzelkunde, Enterprise) → Template passt sich an * `Language` → Template automatisch in Kundenssprache - Techniker kann manuell override 3. **Auto-Reopen bei Kunden-Antwort** - Nach Ticket-Schließung: Überwachung auf eingehende E-Mails (7 Tage) - Wenn Kunde antwortet: * Neuer Kommentar wird automatisch hinzugefügt * Ticket-Status wechselt zu "Reopened" * Ursprünglicher Techniker wird benachrichtigt * ReopenCount wird inkrementiert 4. **Service-Report Caching & Versionierung** - PDF wird gecacht nach Generierung (nicht jedes mal neu generiert) - Versionshistorie: Wenn Techniker nochmal "Update PDF" klickt vor Speichern - Verhindert: "Warum habe ich 5 PDFs bekommen?" 5. **Schließungs-Grund-Statistiken Dashboard** - Hidden view: `/ServiceBoard/CloseAnalytics` - Zeigt: Distribution von Schließungs-Gründen (Pie Chart) * Gelöst: 85% * Nicht reproduzierbar: 8% * Duplikat: 4% * Nicht relevant: 2% * etc. - Filter: By Team, Department, Time Period - Identifies trends: "Steigende nicht reproduzierbar rate → vielleicht QA-Problem?" 6. **E-Mail-Template Versioning & Preview** - Techniker kann mehrere Template-Versionen vergleichen - "Preview" Button zeigt renderte E-Mail mit actual Merge-Tags gefüllt - "Compare versions" → Side-by-side Vergleich (v1.0 vs v2.1) - Audit: Wer hat Template zuletzt geändert und wann? 7. **Knowledge Base Auto-Linking** - Nach Schließung mit `ClosingReason=SOLVED`: - System durchsucht KB-Artikel mit ähnlichen Keywords (Ticket-Titel, Schließungs-Summary) - Zeigt Top 3 KB-Artikel die verknüpft werden könnten - Techniker klickt "Link" → wird zu Service-Report hinzugefügt 8. **Conditional Auto-Notification** - Business Rules können definieren: * "Wenn ClosingReason=Kritisch-Workaround: Immer Manager + Customer benachrichtigen" * "Wenn SLA breached: Zusätzlich SLA-Manager benachrichtigen" * "Wenn Duplikat: Nicht an Kunde senden (nur internen Hinweis)" --- ### REST API Endpoints ``` PUT /api/Helpdesk/{id}/Close ├─ Request: { closingReason, solutionSummary, internalNotes, includeServiceReport, notifyCustomer, templateId } ├─ Response: { ticketId, closedDate, slaStatus, reportUrl, emailStatus } └─ Auth: [Authenticate], Rights: HELPDESK_CLOSE GET /api/Helpdesk/{id}/ClosingReasons ├─ Returns: List<{ id, name, category, description }> └─ Caching: 1 Hour GET /api/Helpdesk/{id}/ClosePreview ├─ Purpose: Preview e-mail before sending (without actually closing) ├─ Returns: { emailSubject, emailBody, reportPreview } └─ Used in UI Preview dialog GET /api/ServiceReport/{ticketId} ├─ Returns: { pdfBytes, generatedDate, pageCount, sections } └─ Caching: Permanent (versioned) POST /api/Helpdesk/{id}/GenerateServiceReport ├─ Trigger: Generate report without closing ├─ Returns: { reportUrl, generatedDate, sections } └─ Async: Long-running operation PUT /api/Helpdesk/{id}/RelinkDuplicates ├─ Purpose: When duplicate detected, relink and merge data ├─ Request: { originalTicketId, mergeTimeRecords, mergeComments } └─ Response: { mergedTicketCount, timeRecordsRelinked } GET /api/Helpdesk/CloseAnalytics ├─ Dashboard data: Closing reason distribution, trends, team stats ├─ Parameters: startDate, endDate, groupBy (team|department|reason) └─ Returns: { chartData, statistics, trends } POST /api/Helpdesk/{id}/BulkClose ├─ Request: { ticketIds[], closingReason, templateId, notifyCustomers } ├─ Response: { processedCount, successCount, failedCount, errors[] } └─ Async with webhook callback GET /api/EmailTemplates/CloseTicket ├─ Returns: List of available close-ticket templates with versions ├─ Includes: Merge tags, examples, language variants └─ Filtering: By language, category, version GET /api/Helpdesk/{id}/AutoReopenMonitor ├─ Status of auto-reopen monitoring for closed ticket ├─ Returns: { isMonitored, daysRemaining, responseStatus } └─ Called periodically: Every 6 hours by background job POST /api/Helpdesk/{id}/LinkToKnowledgeBase ├─ Suggest KB articles for closed ticket ├─ Returns: List<{ kbArticleId, title, relevanceScore }> └─ ML-powered: Semantic similarity matching GET /api/Helpdesk/SurveyStatus/{surveyToken} ├─ Check if customer completed satisfaction survey ├─ Returns: { completed, rating, feedback, completedDate } └─ Public endpoint (no auth required for token) POST /api/Helpdesk/{id}/SendFollowUpEmail ├─ Send follow-up email to customer (post-close, day 3) ├─ Request: { templateId, delayDays } ├─ Response: { scheduledDate, status } └─ Scheduled job: Runs at scheduled time PUT /api/Helpdesk/{id}/UpdateCloseReason ├─ Reopen and change closing reason (if within edit window) ├─ Request: { newClosingReason, notes } ├─ Response: { updated, reason, changedDate } └─ Auth: HELPDESK_CLOSE + HELPDESK_EDIT ``` --- ## 3.4 Ticket weiterleiten (Forward Ticket) **Pfad**: `src/CentronNexus/ServiceBoard/ForwardTicket/ForwardTicketPage.razor` **Kategorie**: Ticket Management (Eskalation & Routing) **Status**: ✅ Vollständig implementiert **Komplexität**: 🔴 Hoch (Multi-scenario, SLA Pause, Vendor Integration, Chain Tracking) **Lizenz**: `LicenseGuids.Centron` OR `LicenseGuids.ServiceBoard` ### Umfassende Beschreibung Das **Ticket-Weiterleitungs-Modul** ist das zentrale Eskalations- und Routing-System. Es ermöglicht: - **6+ Weiterleitungs-Szenarien** mit unterschiedlichen Workflows und Zieltypen - **Intelligente SLA-Pause/Resume** Logik basierend auf Weiterleitungs-Typ - **Vendor-Integration** mit RMA-Tracking und automatischer Referenznummer-Verwaltung - **Weiterleitungs-Kette-Tracking** (Audit-Trail aller Eskalationen) - **Multi-Channel Benachrichtigungen** (Email, Slack, Teams, SMS je nach Empfänger) - **Smart Routing Suggestions** basierend auf Ticket-Eigenschaften und Historie - **Team-Kapazitäts-Berücksichtigung** bei automatischer Zuweisung - **Conditional Auto-Assignment** mit Fallback-Ketten ### Weiterleitungs-Szenarien (Forwarding Types) | Szenario | Code | Ziel | Beschreibung | SLA-Effekt | |----------|------|------|-------------|----------| | **Interner Techniker** | INTERNAL_TECH | Einzelperson | Weiterleitung an einen Techniker im gleichen Team | Pause (SLA läuft weiter) | | **Abteilung/Spezialist** | DEPARTMENT | Team/Abteilung | Eskalation zu spezialisiertem Team (z.B. Netzwerk-Team) | Pause + SLA-Zähler zurücksetzen | | **Externer Vendor** | EXTERNAL_VENDOR | Hersteller-Support | Hardware-/Software-Hersteller Support | Pause (bis zu 72h) | | **RMA Prozess** | RMA_PROCESS | Logistik | Rückgabe von Hardware über Logistik-Partner | Pause + Tracking | | **Sub-Contractor** | SUBCONTRACTOR | Externe Firma | Spezialisierte externe Firma/Berater | Pause + Kostenverfolgung | | **Manager Freigabe** | MANAGER_APPROVAL | Manager | Eskalation für Management-Freigabe (z.B. Kosten) | Pause + Priority-Anhebung | ### TicketForward Daten-Entität ```csharp // PRIMARY IDENTIFICATION HelpdeskI3D int IDENTITY(1,1) - FK to Helpdesk ForwardingNumber int - Sequential numbering (e.g., #2341.1, #2341.2) OriginalTicketI3D int - Original ticket in chain CreatedByI3D int - Who initiated forward CreatedDate datetime2 - When forwarded ForwardingSequence int - Order in chain (1st, 2nd, 3rd forward) // FORWARDING TYPE & ROUTING ForwardingKind int - FK to ForwardingType lookup ForwardingTypeName nvarchar(50) - INTERNAL_TECH, DEPARTMENT, VENDOR, etc. ForwardingCategory nvarchar(50) - INTERNAL, EXTERNAL, ESCALATION, VENDOR RoutingDecision nvarchar(500) - Why this forward? (Reason) // RECIPIENT/DESTINATION RecipientType nvarchar(50) - PERSON, TEAM, VENDOR, EMAIL, EXTERNAL_API RecipientI3D int? - FK to Employee or Team RecipientName nvarchar(500) - Display name (cached) RecipientEmail nvarchar(max) - Email addresses (comma-separated) RecipientExternalId nvarchar(100) - External vendor ID (for VENDOR type) // MESSAGE & CONTEXT ForwardingMessage nvarchar(max) - Why forwarding? (visible to recipient) ForwardingContext nvarchar(max) - Technical context (visible internally) ShouldIncludeAttachments bit - Forward ticket attachments? ShouldIncludeTimeRecords bit - Share time spent so far? ShouldIncludeComments bit - Share internal comments? // SLA & PAUSE TRACKING SLAPauseDate datetime2 - When SLA was paused SLAPausedMinutes int - Total paused time SLAResumeDate datetime2? - When SLA resumed IsSLAPaused bit - Current state: paused or not? SLAPauseReason nvarchar(100) - Reason for pause // VENDOR & RMA TRACKING (for VENDOR/RMA scenarios) VendorTicketNumber nvarchar(100) - Vendor's ticket/RMA number VendorContactName nvarchar(500) - Vendor contact person VendorContactPhone nvarchar(50) VendorContactEmail nvarchar(500) VendorEstimatedResolutionDate datetime2? - When vendor expects to resolve VendorRMATrackingNumber nvarchar(100) - Shipping/tracking number VendorReturnAddress nvarchar(max) - Where to return hardware // FORWARD CHAIN TRACKING NextForwardI3D int? - FK to next TicketForward (if forwarded further) PreviousForwardI3D int? - FK to previous TicketForward ForwardChainLength int - How many times has this been forwarded? IsChainTerminal bit - Is this the final destination? // NOTIFICATIONS & ACKNOWLEDGEMENT NotificationSentDate datetime2 - When forward notification sent AcknowledgmentReceivedDate datetime2? - When recipient acknowledged AcknowledgmentStatus nvarchar(50) - PENDING, ACKNOWLEDGED, IGNORED ReminderSentCount int - How many reminders sent if not acknowledged? // COST TRACKING (for paid services) EstimatedCost decimal(18,2) - Cost estimate (sub-contractor, vendor) ActualCost decimal(18,2)? - Actual charged cost CostCurrency nvarchar(3) - EUR, USD, etc. CostApprovedByI3D int? - Manager who approved cost CostApprovalDate datetime2? // VERSIONING & AUDIT Version int - Optimistic lock ChangedByI3D int ChangedDate datetime2 IsDeleted bit DeletedByI3D int? DeletedDate datetime2? ``` ### Forwarding Chain State Machine ``` ┌─────────────────────────────────────────────────────────────┐ │ TICKET FORWARDING FLOW (Chain) │ └─────────────────────────────────────────────────────────────┘ [OPEN - TECH1] │ Problem: Needs specialized support │ Decision: Escalate to Network Team ↓ [FORWARDED_1 - TECH1→NETWORK_TEAM] │ SLA: PAUSED (New SLA clock for team) │ Status: "Wartet auf Netzwerk-Team" │ Notification: Email + Slack to team ├─ IF Acknowledged: Mark as ROUTED_ACCEPTED ├─ IF Ignored (2 hours): Send Reminder + escalate to Team Lead ├─ IF Still Ignored (4 hours): Escalate to Manager │ ├─ RESOLVED @ NETWORK_TEAM? → Forward to TECH1 (Return) │ └─ [FORWARDED_2 - NETWORK_TEAM→TECH1] (Re-assignment) │ └─ NOT RESOLVED? Additional Help Needed └─ [FORWARDED_3 - NETWORK_TEAM→EXTERNAL_VENDOR] (RMA/Vendor) │ ├─ Vendor receives RMA ├─ SLA: PAUSED (Vendor SLA clock starts) ├─ Tracking: RMA Number tracked │ └─ Vendor Resolves └─ [FORWARDED_4 - VENDOR→TECH1] (Return to original) │ └─ [CLOSED by TECH1] └─ Final SLA: Calculated from all segments ``` ### E-Mail-Templates System (5+ Templates) ``` 1. "Interner Techniker" (INTERNAL_TECH) ├─ Subject: "Ticket #{Number} - Weiterleitung zu Dir" ├─ Recipient: Single technician ├─ Merge-Tags: {AssignerName}, {TicketDetails}, {Context} └─ Tone: Collaborative, peer-to-peer 2. "Abteilung/Spezialist-Team" (DEPARTMENT) ├─ Subject: "Ticket #{Number} - Eskalation zum {DepartmentName}" ├─ Recipient: Team distribution list ├─ Merge-Tags: {TeamLead}, {Priority}, {Complexity} ├─ AutoAssignment: Next available team member └─ Tone: Escalation, priority note 3. "Externer Vendor" (EXTERNAL_VENDOR) ├─ Subject: "Ticket #{Number} - Anfrage an {VendorName}" ├─ Recipient: Vendor contact email ├─ Merge-Tags: {CustomerName}, {SerialNumber}, {ProblemDescription} ├─ Attachments: Logs, screenshots, configuration └─ Tone: Formal, professional, service level emphasis 4. "RMA Prozess" (RMA_PROCESS) ├─ Subject: "RMA #{RMANumber} - Ticket #{TicketNumber}" ├─ Recipient: Logistics partner + customer (optional) ├─ Merge-Tags: {ShippingAddress}, {TrackingNumber}, {ReturnLabel} ├─ Includes: Prepaid shipping label URL └─ Tone: Procedural, step-by-step instructions 5. "Sub-Contractor" (SUBCONTRACTOR) ├─ Subject: "Ticket #{Number} - Beauftragung Dienste" ├─ Recipient: Sub-contractor contact ├─ Merge-Tags: {SOW}, {EstimatedCost}, {DeadlineDate} ├─ Includes: SOW attachment, cost approval └─ Tone: Business, formal contract tone 6. "Manager Freigabe" (MANAGER_APPROVAL) ├─ Subject: "Ticket #{Number} - Kosten-Freigabe erforderlich" ├─ Recipient: Manager ├─ Merge-Tags: {EstimatedCost}, {Justification}, {Deadline} ├─ Includes: Approval link (click to approve) └─ Tone: Urgent, action required ``` ### Detaillierte Use Cases #### **UC 11.8.1: Einfache interne Weiterleitung an Spezialist** **Szenario**: Support-Techniker erkennt, dass Ticket ein Netzwerk-Problem ist und leitet zu Netzwerk-Spezialist weiter. **Ablauf**: 1. Ticket öffnen (Status = "In Arbeit") 2. "Weiterleiten" Button klicken 3. **Schritt 1 - Weiterleitungs-Typ**: - "Abteilung / Spezialist-Team" auswählen - System zeigt verfügbare Teams (Netzwerk, Datenbank, Security, etc.) 4. **Schritt 2 - Zielgruppe**: - Team: "Netzwerk-Support" auswählen - System zeigt Kapazität: "3 Techniker, 2 verfügbar" 5. **Schritt 3 - Nachricht**: - Grund: "Netzwerk-Konfigurationsproblem erkannt" - Kontext: "Verbindung wird nach 30 Min unterbrochen. Logs zeigen Timeout auf Switch XY" - Anhänge: ✓ Include (Logs + Screenshots) - Time Records: ✓ Include (zeigt 1,5h bereits aufgewendet) 6. **Schritt 4 - SLA-Auswirkung**: - System zeigt: "SLA wird PAUSIERT (1,5h schon verbraucht)" - Neues SLA wird mit 2h für Netzwerk-Team berechnet 7. **Schritt 5 - Review & Speichern**: - Preview zeigt E-Mail-Text - "Weiterleiten" Button klicken 8. **Hintergrund-Prozesse**: - Ticket-Status wechselt zu "Weiterleitet an Netzwerk-Team" - TicketForward-Eintrag wird erstellt - E-Mail + Slack-Notification an Team versendet - Originaltechniker erhält Bestätigung 9. **Team-Seite**: - Netzwerk-Team sieht Ticket in ihrer Queue - Können "Annehmen" oder "Delegieren" klicken 10. **Rückkehr**: - Nach Netzwerk-Team Lösung: Forward zurück zu Originaltechi - Originaler Tech bekommt Ticket mit Notizen: "Issue war NIC-Firmware" **Betroffene Felder**: ``` Helpdesk.HelpdeskStatusI3D = 7 (Forwarded) Helpdesk.AssignedToTeamI3D = 2 (Netzwerk-Team) TicketForward.ForwardingKind = DEPARTMENT TicketForward.ForwardingChain = 1 TicketForward.IsSLAPaused = true ``` --- #### **UC 11.8.2: Externe Vendor-Weiterleitung mit RMA** **Szenario**: Netzwerk-Adapter ist defekt und muss zum Hersteller für Reparatur/Austausch. **Ablauf**: 1. Ticket öffnen (Netzwerk-Problem diagnostiziert) 2. "Weiterleiten" → Typ: "RMA Prozess" 3. **Schritt 1 - Vendor-Auswahl**: - Dropdown: "Intel (Netzwerk-Adapter Hersteller)" auswählen - System zeigt Vendor-Kontakte (Telefon, Email, Web-Portal) 4. **Schritt 2 - Hardware-Details**: - Artikel: "Intel ProSet Adapter X722" (Auto-populated) - Serial Number: "SN12345ABC" eingeben - Defekt: "Port 1 nicht aktiv nach Firmware-Update" 5. **Schritt 3 - RMA-Anforderungen**: - Rücksend-Adresse wird auto-filled (Vendor's Repair Center) - Versand: "Pickup arrangieren?" ✓ - Tracking: Wird auto-generiert 6. **Schritt 4 - Kundenbenachrichtigung** (optional): - "Kunde benachrichtigen?" ✓ - Kunde erhält: Tracking-Info, Expected Resolution Date (7 Tage) 7. **Speichern**: - TicketForward mit ForwardingKind=RMA_PROCESS - VendorRMATrackingNumber = generiert - SLAPaused = true (Pause bis zu 72h, kann erweitert werden) - Email an Vendor mit RMA-Details - Email an Customer mit Tracking-Link 8. **Tracking**: - Ticket hat Tracking-Board für RMA-Status - Auto-Updates wenn Vendor antwortet - Auto-Reopen wenn Replacement empfangen 9. **Rückkehr**: - Vendor antwortet mit Replacement - System erstellt neue TimeRecord "Hardware Replacement: Intel Adapter" - Ticket zurück zu Original-Techniker - Tech installiert replacement - Ticket kann dann geschlossen werden --- #### **UC 11.8.3: Manager-Freigabe für hohe Kosten** **Szenario**: Sub-Contractor ist notwendig für spezielle Konfiguration, Kosten €2.500. **Ablauf**: 1. Ticket öffnen (Spezialist erkannt: braucht externe Hilfe) 2. "Weiterleiten" → Typ: "Manager Freigabe" 3. **Schritt 1 - Manager**: - "Verantwortlicher Manager" auswählen 4. **Schritt 2 - Kostendetails**: - Service: "SAP Configuration Expert (3 Tage)" - Estimated Cost: €2.500 - Justification: "Complex security policy implementation required. Our team doesn't have SAP certification." 5. **Schritt 3 - Deadline**: - Decision Deadline: "Heute 17:00" (4 Stunden) - Urgency: "HOCH" (Customer waiting) 6. **Speichern**: - Email an Manager mit: * Ticket-Details * Cost Breakdown * Justification * Approval Link (One-Click: "Freigeben" or "Ablehnen") 7. **Manager's Action** (2 Szenarien): - **A) Freigeben**: * Next forward: Sub-Contractor (Automatic) * Ticket continues to UC 11.8.4 - **B) Ablehnen**: * Ticket returns to original technician * Alternative: "Can we do it ourselves?" + 8h planning 8. **Auditprüfung**: - Full chain logged: Tech → Manager → Sub-Contractor - Costs tracked: Manager approval date + amount approved --- #### **UC 11.8.4: Sub-Contractor Beauftragung mit Kostentracking** **Szenario**: Nach Manager-Freigabe wird Ticket an Pre-approved Sub-Contractor weitergeleitet. **Ablauf**: 1. Automatic forward nach Manager-Freigabe 2. **Schritt 1 - Sub-Contractor-Auswahl**: - Pre-configured: "SAP Global Consulting" - Contact: "contact@sap-global.de" 3. **Schritt 2 - SOW (Statement of Work)**: - System generiert SOW-Document: * Scope: 3 Tage SAP Security Policy Implementation * Cost: €2.500 (fixed) * Deadline: 5 business days * Deliverables: Configured SAP System + Documentation 4. **Schritt 3 - Versendet**: - Email an Sub-Contractor mit: * SOW attachment (PDF) * Ticket-Details + Links * Approval mechanism 5. **Tracking**: - Sub-Contractor kann Online-Portal nutzen zur Status-Update - TimeRecords eingeben direkt im System (if configured) - Intermediate Deliverables attached 6. **Invoice Handling**: - Sub-Contractor erstellt Invoice - Manager erhält für Freigabe - Cost wird zu Ticket hinzugefügt - Billing-Integration: Kunde wird ggf. für extra costs berechnet 7. **Completion**: - Sub-Contractor markiert als "Delivered" - Ticket returns zu Original-Technician für Validation - Technician validates + closes ticket --- #### **UC 11.8.5: Forward-Kette mit mehrfachen Eskalationen** **Szenario**: Komplexes Ticket durchläuft mehrere Forwards bis zur Lösung. **Chain**: ``` Ticket #2500 created ↓ FORWARD 1: Support-Tech → Database-Team (SLA: Pause 1h) ↓ (DB-Team finds: Licensing issue) FORWARD 2: Database-Team → Vendor Portal (SLA: Pause, Vendor SLA: 24h) ↓ (Vendor: Need specific info) FORWARD 3: Vendor → Original Tech (for more logs) (Collect data) ↓ FORWARD 4: Original Tech → Vendor again (with data) ↓ (Vendor resolves configuration) FORWARD 5: Vendor → Database-Team (with fix) ↓ (DB-Team implements) FORWARD 6: Database-Team → Support-Tech (for testing) ↓ (Confirm working) [CLOSED] ``` **Audit Trail**: Alle 6 Forwards werden dokumentiert mit: - Wer → Wer - Wann - Grund - SLA Auswirkungen - Zeiteinträge pro Segment **Final Report**: - Total Time: 6,5 Stunden - Total Pause Time: 5,5 Stunden - Final SLA: 95% met (after all segments) - Forwarding count: 6 (shows complex issue) --- ### Versteckte Funktionen (Hidden Features) 1. **Intelligente Routing-Vorschläge** - System analysiert aktuelles Ticket: * Kategorie, Priorität, Typ * Vergleicht mit historischen ähnlichen Tickets - Schlägt vor: "Ähnliche Tickets wurden 85% zum DB-Team weitergeleitet" - Techniker kann akzeptieren oder override 2. **Auto-Acknowledgment Escalation** - Forward wird versendet - Wenn nicht innerhalb 1h acknowledged: * Reminder automatisch versendet * Nach 2h: Escaliert zu Team Lead * Nach 4h: Escaliert zu Manager - Konfigurierbar pro Team 3. **Vendor Integration & Learning** - System merkt sich: "Vendor antwortet normalerweise in 2 Tagen" - Setzt automatically: Expected Resolution basierend auf Vendor-Historie - Alerts wenn Vendor außerhalb window antwortet 4. **Team Kapazitäts-Aware Routing** - Beim Forward zu Team zeigt System: * Current Queue: 12 Tickets * Avg Resolution Time: 2,5h * Suggested Assignment: In 4,5h (weighted load) - Warnings wenn Team überl stet ist 5. **Forward-Kette Visualisierung** - Hidden view: `/ServiceBoard/ForwardingChain/{ticketId}` - Zeigt visuelle Timeline: * Ticket → Tech1 (1h) → Database-Team (1,5h) → Vendor (4h) → Tech1 - Sortierbar nach Time, Responders, Effectiveness 6. **Automatic Cost Rollup** - Wenn Ticket Sub-Contractors kostet: - System berechnet automatisch: * Internal Cost: 3,5h × €120/h = €420 * Sub-Contractor Cost: €2.500 * Total: €2.920 - Optionale Charge-Back zu Customer 7. **Forwarding Analytics Dashboard** - Hidden view: `/ServiceBoard/ForwardingAnalytics` - Shows: * Most forwarded departments (DB-Team: 312 forwards) * Average forward count per ticket (1.2x) * Forwarding effectiveness (% resolved without further forward) * SLA impact by forwarding type 8. **Conditional Auto-Revert** - Business Rule: "Wenn Forward nicht innerhalb 24h angefangen wird, automatisch zurückgeben" - Konfigurierbar pro Department/Team - Prevents: "Stuck tickets" --- ### REST API Endpoints ``` PUT /api/Helpdesk/{id}/Forward ├─ Request: { forwardingType, recipientId, message, includeAttachments, estimatedCost } ├─ Response: { forwardId, recipientNotification, newSLAStatus, chainPosition } └─ Auth: [Authenticate], Rights: HELPDESK_FORWARD GET /api/Helpdesk/{id}/ForwardingOptions ├─ Returns: { availableTeams[], availableVendors[], suggestedRecipient } ├─ Smart: Based on ticket category/complexity └─ Caching: 5 minutes GET /api/TicketForward/Chain/{ticketId} ├─ Returns: List<{ forwardId, from, to, date, status, slaImpact }> ├─ Includes: Full chain visualization data └─ Purpose: UI chain display GET /api/TicketForward/{forwardId}/Details ├─ Returns: Complete forward details + current status ├─ Vendor-specific fields if applicable └─ Used in forward detail view PUT /api/TicketForward/{forwardId}/Acknowledge ├─ Request: { recipientId } ├─ Response: { acknowledged, timestamp, nextActions } └─ Triggers: Email to originator PUT /api/TicketForward/{forwardId}/ReturnToSender ├─ Reverse a forward + provide feedback ├─ Request: { reason, foundSolution } ├─ Response: { ticketId, newAssignee } └─ Re-opens ticket on recipient side GET /api/RMA/GenerateTrackingNumber ├─ Generate RMA/Tracking numbers ├─ Returns: { rmaNumber, trackingNumber, shippingLabel } └─ Vendor-specific format POST /api/TicketForward/{forwardId}/LinkToCost ├─ Link cost record to forward (sub-contractor invoice) ├─ Request: { cost, currency, invoiceUrl } └─ Response: { linked, rollupCost } GET /api/Helpdesk/ForwardingChainAnalytics ├─ Dashboard: Chain length distribution, effectiveness metrics ├─ Parameters: startDate, endDate, groupBy (department|vendor|type) └─ Returns: { chartData, trends, recommendations } POST /api/TicketForward/BulkForward ├─ Bulk forward multiple tickets to same recipient ├─ Request: { ticketIds[], recipientId, forwardingType } ├─ Response: { processedCount, forwardChainIds[] } └─ Async: With webhook callback GET /api/Vendor/{vendorId}/TicketStatus ├─ Get status from external vendor (integration) ├─ Returns: { vendorTicketNumber, currentStatus, estimatedResolution } └─ Polling: Every 4 hours PUT /api/TicketForward/{forwardId}/PauseResume ├─ Manually pause/resume SLA for a forward ├─ Request: { pauseReason, resumeDate } ├─ Response: { isPaused, adjustedSLA } └─ Admin only ``` --- ## 3.5 Kanban-Board (Kanban Visualization) **Pfad**: `src/CentronNexus/ServiceBoard/Kanban/KanbanPage.razor` **Kategorie**: Ticket Management (Visualisierung & Workflow) **Status**: ✅ Vollständig implementiert **Komplexität**: 🔴 Hoch (Drag-Drop, Real-time Updates, Multi-view, WIP Limits) **Lizenz**: `LicenseGuids.Centron` (Standard) ### Umfassende Beschreibung Das **Kanban-Board-Modul** ist das visuelle Ticket-Management-System mit Real-Time-Synchronisierung, Multi-View-Unterstützung und intelligenten Workflow-Controls: - **4 vordefinierte Board-Typen** mit jeweils optimierten Spalten-Layouts - **Drag-Drop Mechanik** mit automatischer Validierung und WIP-Limits - **Real-time Collaboration** mit SignalR-Updates bei Änderungen - **Spalten-Statistiken** (Tickets/Spalte, Durchschnittsalter, SLA-Status) - **Conditional Formatting** mit automatischer Farbcodierung und Icons - **Filter-Integration** (kombinierbar mit 50+ Dimensionen) - **Smart Auto-Movement** (automatisches Verschieben bei Status-Änderungen) - **Swimlanes** für Team-Auslastungs-Visualisierung ### Board-Typen (4 Varianten) | Board-Typ | Spalten | Zweck | Use-Case | |-----------|---------|-------|----------| | **Status-Board** | Open, In Progress, Waiting, Resolved, Closed | Workflow | Standard Ticket-Lifecycle Übersicht | | **Prioritäts-Board** | Critical, High, Medium, Low | Priorisierung | Load-Balancing & Capacity Planning | | **Typ-Board** | Incident, Request, Change, Problem, Task | Kategorisierung | Spezialisierte Team-Zuweisung | | **Zuweisungs-Board** | Tech1, Tech2, Tech3, Team-Lead, Unassigned | Auslastung | Team-Kapazitäts-Überwachung | ### Kanban Column Struktur ``` Column: "In Progress" ├── WIP Limit: 5 (Max Tickets) ├── Current Count: 4/5 ├── Avg Age: 2.5h ├── SLA Status: │ ├── On Track: 3 (🟢) │ ├── At Risk: 1 (🟡) │ └── Breached: 0 (🔴) ├── Cards: │ ├── #2341 - Exchange Config (3.5h, Critical) │ ├── #2342 - VPN Access (1.2h, High) │ ├── #2343 - Printer Setup (0.8h, Medium) │ └── #2344 - Network Timeout (2.1h, High) └── Actions: ├── [+ Add Ticket] ├── [⚙️ Configure] └── [👁️ View All] ``` ### Ticket Card Layout (auf dem Board) ``` ┌─────────────────────────────────┐ │ #2341 Exchange Config │ ├─────────────────────────────────┤ │ 🟡 Priority: HIGH │ │ 👤 Assignee: John Doe │ │ ⏱️ Age: 3.5h (SLA: 6h) 🟢 │ │ 🏷️ Tags: Exchange, Config │ │ │ │ Description: Outlook sync... │ │ 📎 Attachments: 2 │ │ 💬 Comments: 4 │ └─────────────────────────────────┘ ``` ### Drag-Drop Mechanik ``` USER ACTION: Drag Card from "Open" → "In Progress" │ ├─ Pre-Drop Validation: │ ├─ Is Target Column WIP Limit exceeded? NO ✓ │ ├─ Does user have permission? YES ✓ │ ├─ Is ticket locked by another user? NO ✓ │ └─ Should ticket status change? YES → "In Progress" │ ├─ Drop Animation: Smooth slide into column │ ├─ Backend Operations: │ ├─ Update Helpdesk.HelpdeskStatusI3D = 2 (In Progress) │ ├─ Update Helpdesk.AssignedToI3D (if applicable) │ ├─ Create AuditLog entry │ └─ Emit SignalR message to all viewers │ └─ UI Updates: ├─ Other users see card move in real-time ├─ Column statistics recalculate └─ Changed date/time stamp updates ``` ### Detaillierte Use Cases #### **UC 11.9.1: Standard Status-Board verwenden** **Szenario**: Support Manager möchte schnell Überblick über Ticket-Status bekommen. **Ablauf**: 1. ServiceBoard öffnen → "Kanban" Tab klicken 2. Dropdown: "Status-Board" ausgewählt (Standard) 3. **Board anzeigen**: - Open (8 Tickets): Display tickets waiting to be picked up - In Progress (5/5 - WIP Limit erreicht): Current work - Waiting (3 Tickets): Awaiting feedback - Resolved (4 Tickets): Pending closure - Closed (12 Tickets - Today): Completed 4. **Schnelle Aktionen**: - Drag Ticket von "Open" zu "In Progress" → Auto-Update - Klick auf Ticket-Card → Details Modal öffnet - Hover über Column → Statistik-Tooltip: "Avg age: 1.8h, SLA: 95%" 5. **Filter anwenden**: - Nur "Kritische" Tickets zeigen → Filter-Dropdown setzen - Nur "Mein Team" → Filter anwenden - Board aktualisiert sich live 6. **Export/Report**: - "Export CSV" Button → CSV mit aktuellem Board-Zustand **Hidden Feature - Auto-Move**: - Wenn Ticket extern geschlossen wird (z.B. via API) - Card bewegt sich automatisch in "Closed" Spalte - Keine manuelle Aktion notwendig --- #### **UC 11.9.2: Prioritäts-Board für Load-Balancing** **Szenario**: Tech-Lead plant Team-Kapazität basierend auf Prioritäten. **Ablauf**: 1. Kanban-Board öffnen → "Prioritäts-Board" auswählen 2. **Board Spalten**: - CRITICAL (1 Ticket, 30 Min SLA): Shows🔴 icon - HIGH (5 Tickets, 2h SLA): Shows🟠 icon - MEDIUM (8 Tickets, 4h SLA): Shows🟡 icon - LOW (3 Tickets, 24h SLA): Shows🟢 icon 3. **Capacity Planning**: - System empfiehlt: "Critical + 2 High = 1 Techniker full" - Zeigt: "Other techs can take 2 Medium or 3 Low tickets" 4. **Strategische Entscheidungen**: - Kann 3 LOW-Tickets zu "Waiting List" verschieben → Befreit Kapazität - oder 1 MEDIUM → BACKLOG → Reduziert dringende Last 5. **Überwachung**: - Real-time: Wenn Tech aktuelles Ticket abschließt - MEDIUM Ticket automatisch zu nächstem Tech assigned - Board aktualisiert live --- #### **UC 11.9.3: Team-Auslastungs-Board mit Swimlanes** **Szenario**: Techniker-Kapazität verwalten und balancieren. **Ablauf**: 1. Kanban → "Zuweisungs-Board" 2. **Swimlane pro Techniker**: ``` John Doe (5 tickets - 85% auslastet) ├─ Open: 1 ticket ├─ In Progress: 3 tickets (one at max WIP: 3/3) └─ Resolved: 1 ticket Jane Smith (3 tickets - 50% auslastet) ├─ Open: 1 ticket └─ In Progress: 2 tickets Team Lead (2 tickets - 25% auslastet) ├─ Open: 2 tickets (available for assignment) ``` 3. **Balancing-Aktion**: - Drag Ticket aus "John's Open" → "Team Lead's Open" - System checks: Team Lead hat Kapazität ✓ - Ticket reassigned 4. **Capacity Indicator**: - Green bar wenn < 70% auslastet - Yellow bar wenn 70-90% - Red bar wenn > 90% 5. **Alerts**: - "John is overloaded - consider reassigning" - "Team Lead has capacity" --- #### **UC 11.9.4: Conditional Formatting & Smart Coloring** **Szenario**: Visuell erkennen welche Tickets Probleme haben. **Card Coloring Rules**: ``` IF Priority = CRITICAL → Red background (#FF6B6B) → Blinking red border → 🚨 Icon IF SLA Status = BREACHED → Dark red background (#8B0000) → Flashing indicator → 💥 Icon IF Age > 50% of SLA → Orange background (#FFA500) → 🟠 Icon IF Assigned but no activity for 2h → Gray background (#808080) → ⚠️ Icon (might be stuck) IF Has unread comments → Blue border → 💬 Icon IF Multiple tags → Small colored chips on card → Scrollable if > 5 tags ``` --- #### **UC 11.9.5: Real-time Collaboration Scenario** **Szenario**: Mehrere Techniker sehen Board gleichzeitig → Live-Updates via SignalR. **Timeline**: ``` 13:00:00 - John öffnet Kanban-Board 13:00:05 - Jane öffnet gleiches Board 13:00:15 - John klickt auf #2341 → Card wird grün markiert (John arbeitet daran) Jane sieht: #2341 ist jetzt grün, zeigt "John is viewing" 13:00:30 - John dragged #2341 von "Open" → "In Progress" Jane sieht: Card bewegt sich in echtzeit in andere Spalte System: Audio notification: "Ding" (optional) 13:00:45 - Jane startet neue Zeiterfassung auf #2345 John sieht: #2345 Status-Indicator zeigt "Jane started work" 13:01:00 - John markiert #2341 als "Resolved" Card bewegt sich zu "Resolved" Spalte Jane sieht: #2341 weg aus In-Progress John erhält: Time tracking summary für #2341 13:01:15 - Admin erstellt neues Ticket #2349 (via API) Beide sehen: Neuer Card erscheint in "Open" Spalte ``` --- ### Kanban Configuration Entity ```csharp KanbanBoard ├── I3D, Name (e.g., "Status-Board", "Team Capacity") ├── BoardType (enum: STATUS, PRIORITY, TYPE, ASSIGNMENT, CUSTOM) ├── IsPublic / IsShared (bool) ├── CreatedByI3D, CreatedDate ├── Configuration: │ ├── Columns[] (ordered list) │ │ ├── ColumnName │ │ ├── StatusKind (which Helpdesk statuses map here) │ │ ├── WIPLimit (int, nullable) │ │ ├── AutoMoveRules (when to auto-move cards) │ │ └── DisplayOrder │ │ │ ├── CardDisplayFields (which fields to show on card) │ │ ├── TicketNumber: true │ │ ├── Title: true │ │ ├── Priority: true │ │ ├── Assignee: true │ │ ├── Age: true │ │ ├── SLAStatus: true │ │ ├── Tags: true │ │ └── CommentCount: true │ │ │ ├── Filters (default filters applied) │ │ ├── StatusFilter: null (show all) │ │ ├── PriorityFilter: null │ │ ├── TeamFilter: "My Team" │ │ └── DateRangeFilter: null │ │ │ ├── Formatting: │ │ ├── ColorByField (PRIORITY, STATUS, AGE, SLA_STATUS) │ │ ├── ShowCardNumbers: true │ │ ├── ShowCardAges: true │ │ ├── ShowWIPIndicators: true │ │ └── CardSize (SMALL, MEDIUM, LARGE) │ │ │ └── RealTime: │ ├── EnableSignalR: true │ ├── AutoRefreshSeconds: 5 │ └── ShowOtherUsersViewing: true ``` ### Hidden Features (Advanced) 1. **Swimlane Grouping** (Hidden View) - Rows = Teams, Columns = Status - Nested structure for hierarchical view - URL: `/ServiceBoard/Kanban/Swimlanes` 2. **Stacked Cards Mode** - When WIP Limit exceeded: Cards stack with "2 more" indicator - Hover/expand to see stacked cards 3. **Performance Metrics Panel** - Hidden right sidebar: `/ServiceBoard/Kanban/Metrics` - Shows real-time: Throughput, Cycle Time, Lead Time - Trend charts (daily/weekly) 4. **Board Snapshot & Export** - Capture current board state as image (PNG) - Export as PDF report with statistics - Share board URL with pre-applied filters 5. **Custom Board Builder** - Hidden admin view: `/ServiceBoard/Admin/KanbanBuilder` - Drag-drop column configuration - Custom status mapping - Test data preview ### REST API Endpoints ``` GET /api/Kanban/Boards ├─ Returns: List<{ boardId, name, type, columns[] }> └─ Caching: 1 Hour GET /api/Kanban/{boardId}/Cards ├─ Returns: List based on current filters ├─ Parameters: filters, sorting, paging └─ Real-time: Via SignalR when cards change PUT /api/Kanban/{boardId}/Card/{ticketId}/Move ├─ Request: { fromColumn, toColumn, newPosition } ├─ Response: { success, updatedCard, affectedCards[] } └─ Operations: Validation, Status update, Audit log PUT /api/Kanban/{boardId}/Card/{ticketId}/Lock ├─ Acquire exclusive edit lock (prevent conflicts) ├─ Response: { locked, lockToken, expiresIn } └─ Release: PUT .../Unlock with token POST /api/Kanban/{boardId}/Snapshot ├─ Create board snapshot (for reports/sharing) ├─ Returns: { snapshotId, imageUrl, statisticsJson } └─ Async: Generate PDF in background GET /api/Kanban/Metrics/{boardId} ├─ Dashboard metrics: Throughput, cycle time, trends ├─ Parameters: timeRange (today, week, month) └─ Returns: { metricsData, charts, anomalies } WebSocket (SignalR): /tickethub ├─ On card moved: "CardMoved" → broadcast to subscribers ├─ On card locked: "CardLocked" → show editor indicator ├─ On new card: "CardCreated" → add to appropriate column └─ Heartbeat: Every 30 seconds ``` --- ## 3.6 Ticket-Checklisten (Ticket Checklists & Task Management) **Pfad**: `src/CentronNexus/ServiceBoard/TicketChecklists/TicketChecklistsPage.razor` **Kategorie**: Ticket Management (Workflow & Task Execution) **Status**: ✅ Vollständig implementiert **Komplexität**: 🔴 Hoch (Dependencies, Progress Tracking, Time Estimation) **Lizenz**: `LicenseGuids.Centron` (Standard) ### Umfassende Beschreibung Das **Ticket-Checklisten-Modul** ist das Task-Management-System mit: - **12+ vordefinierte Checklisten-Templates** (Hardware, Software, Access, VPN, etc.) - **Intelligente Abhängigkeits-Verwaltung** (Sequential, Parallel, Conditional, Blocking) - **Real-time Progress Tracking** mit Fortschrittsbalken und Zeitschätzungen - **Zeiterfassung pro Item** mit Vergleich zu Estimate - **Sub-Checklisten** für komplexe, hierarchische Tasks - **Auto-Completion Detection** bei erfüllten Bedingungen - **Notification System** bei Abhängigkeits-Erfüllung ### 12 Vordefinierte Checklist-Templates | Template | Items | Use-Case | Abhängigkeiten | |----------|-------|----------|----------------| | **Hardware-RMA** | 8 | Reparatur-Prozess | Sequenziell | | **Software-Installation** | 6 | SW-Deployment | Parallel + Conditional | | **Access-Setup** | 5 | Neuer Benutzer | Sequential | | **VPN-Konfiguration** | 4 | VPN-Zugang | Sequential | | **Printer-Setup** | 3 | Drucker-Konfiguration | Parallel | | **Device-Imaging** | 7 | Neue Hardware | Sequential | | **User-Onboarding** | 12 | Neue Mitarbeiter | Parallel + Conditional | | **User-Offboarding** | 10 | Austritt Mitarbeiter | Sequential | | **License-Assignment** | 4 | Lizenz-Zuweisung | Conditional | | **Security-Audit** | 8 | Sicherheitsprüfung | Parallel | | **Server-Maintenance** | 6 | Wartung | Sequential | | **Backup-Verification** | 5 | Backup-Kontrolle | Parallel | ### Dependency System ``` Typ: SEQUENTIAL ├─ Item A → Item B → Item C (strikte Reihenfolge) ├─ Nur A kann starten (Initial) ├─ B kann nur starten wenn A ✓ complete └─ C kann nur starten wenn B ✓ complete Typ: PARALLEL ├─ Item A, B, C können parallel laufen ├─ Alle können sofort starten └─ Reihenfolge egal Typ: CONDITIONAL ├─ IF Item A = Selected/Checked │ THEN Show Item B │ ELSE Hide Item B └─ Visibility based on conditions Typ: BLOCKING ├─ Item B blocked by Item A ├─ Item A nicht complete → Item B disabled (grayed out) ├─ Item A complete → Item B enabled └─ Visual: 🔒 Lock icon on Item B ``` ### HelpdeskChecklist Entity ```csharp HelpdeskChecklist ├── I3D, HelpdeskI3D (FK) ├── TemplateI3D (FK to ChecklistTemplate) ├── StartedDate, StartedByI3D ├── CompletedDate, CompletedByI3D ├── ItemCount, CompletedItemCount ├── CompletionPercentage (calculated) ├── EstimatedMinutes, ActualMinutes ├── IsPinned (bool - sticky on ticket detail view) ├── Items[] (ordered list) │ ├── ItemId, ItemName, Description │ ├── ItemOrder, ParentItemI3D (for sub-items) │ ├── IsCompleted, CompletedDate, CompletedByI3D │ ├── EstimatedMinutes, ActualMinutes (time tracking) │ ├── IsBlocking (bool - must be done) │ ├── DependencyType (NONE, SEQUENTIAL, PARALLEL, BLOCKING) │ ├── DependsOnItemI3D (reference to blocking item) │ ├── AssignedToI3D (person responsible) │ ├── Notes (internal comments per item) │ └── CompletionNotes (notes when checked off) ``` ### Detaillierte Use Cases #### **UC 11.10.1: Hardware-RMA Checkliste anwenden & durchführen** **Szenario**: Defekte Hardware muss repariert werden. **Ablauf**: 1. Ticket #2350 öffnen (Hardware defect) 2. "Checklisten" Tab klicken 3. "Template auswählen" → "Hardware-RMA" auswählen 4. System zeigt: ``` Hardware-RMA Checklist (8 items, 0 complete) ├─ □ Diagnose durchführen (2h) ├─ □ RMA-Nummer anfordern (0.5h) [depends on Diagnose] ├─ □ Versand-Etikett drucken (0.25h) ├─ □ Hardware verpacken (0.5h) ├─ □ Tracking-Info notieren (0.1h) ├─ □ Versand durchführen (0.25h) ├─ □ Auf Reparatur warten (tracking) └─ □ Reparierte Hardware prüfen (1h) Progress: 0/8 = 0% Est. Time: 4.5h ``` 5. **Durchführung**: - Techniker checkt erste Item: "Diagnose durchführen" ✓ - System: Nächste Item wird enabled (RMA-Nummer) - Techniker kann sich Notizen machen pro Item - System: Zeit wird von TimeRecords gerechnet 6. **Tracking**: - Item "Auf Reparatur warten" bleibt offen - Status: "In Progress (50%)" auf Ticket - Manager sieht auf Dashboard: "1 Ticket hat Checkliste" 7. **Abschluss**: - Nach Reparatur: Item "Reparierte Hardware prüfen" - Tech checkt alle Items ✓ - Checklist marked COMPLETE - Time tracking: 4.7h actual vs 4.5h estimate --- #### **UC 11.10.2: Conditional Branching in Onboarding** **Szenario**: Neuer Mitarbeiter, aber Onboarding variiert je nach Abteilung. **Ablauf**: 1. Ticket: "User Onboarding - John (IT Department)" 2. Template: "User-Onboarding" (12 items) 3. **Conditional Logic**: ``` Items 1-5: Standard (always) ├─ Item 6: IF Department = "IT" THEN Show "Dev Tools Setup" │ ELSE Hide └─ Item 7: IF Department = "Sales" THEN Show "CRM Training" ELSE Hide Item 8: IF Manager exists THEN Show "Manager Meeting" ELSE Hide Item 9-12: Standard (always) ``` 4. **Execution**: - System zeigt 11 items (Item 7 hidden - Sales-specific) - Techniker kann conditional Items checken - Abhängigkeiten enforced 5. **Re-use**: - Sales Team Lead erstellt Ticket für Sales-Onboarding - Template "User-Onboarding" used - Conditional zeigt Item 7 (CRM Training), hidden Item 6 (Dev Tools) --- #### **UC 11.10.3: Sub-Checklisten & Hierarchie** **Szenario**: Complex device imaging mit nested tasks. **Ablauf**: 1. Main Checklist: "Device-Imaging (7 items)" 2. **Struktur**: ``` Device-Imaging ├─ □ Pre-Check Hardware (0.5h) │ ├─ Check RAM │ ├─ Check Storage │ └─ Check Connectivity ├─ □ Deploy Windows Image (2h) ├─ □ Install Drivers (1h) │ ├─ Network Driver │ ├─ Storage Driver │ └─ Graphics Driver ├─ □ Apply Security Patches (1h) ├─ □ Install Software (1h) │ ├─ Office Suite │ ├─ Antivirus │ └─ Company Applications ├─ □ Configure Settings (0.5h) └─ □ Final Validation (0.5h) ``` 3. **Execution**: - Main items can expand/collapse - Sub-items tracked separately - Progress: 6/12 items complete = 50% 4. **Time Tracking**: - Parent item shows aggregated time - Sub-items tracked granularly --- ### Hidden Features 1. **Auto-Complete Detection** - IF all sub-items complete → Parent auto-checked (if enabled) - Time auto-calculated from child items 2. **Comparison: Estimate vs Actual** - Shows colored indicator: * 🟢 Green: Finished within ±5% of estimate * 🟡 Yellow: 5-20% over estimate * 🔴 Red: >20% over estimate 3. **Smart Template Suggestions** - On ticket creation: "Based on this ticket type, apply checklist X?" - ML-powered based on similar tickets 4. **Checklist Cloning** (Hidden) - Copy checklist from another ticket: "Clone from #2340" - Useful for recurring work types ### REST API Endpoints ``` GET /api/ChecklistTemplates ├─ Returns: List of 12+ templates └─ Caching: 1 Hour POST /api/Helpdesk/{id}/Checklist/Apply ├─ Apply template to ticket ├─ Request: { templateId, customizations[] } └─ Response: { checklistId, items[] } PUT /api/Checklist/{id}/Item/{itemId}/Complete ├─ Mark item complete ├─ Response: { itemId, completedDate, nextAvailableItems[] } └─ Triggers: Dependency resolution GET /api/Checklist/{id}/Progress ├─ Returns: { totalItems, completedItems, percentage, estimatedVsActual } └─ Real-time calculation POST /api/Checklist/{id}/Clone ├─ Clone from another ticket's checklist └─ Response: { clonedChecklistId, itemsCloned } ``` --- ## 3.7 Ticket-Scripts (Quick Actions & Automation) **Pfad**: `src/CentronNexus/ServiceBoard/TicketScripts/TicketScriptsPage.razor` **Kategorie**: Ticket Management (Automation & Workflow Acceleration) **Status**: ✅ Implementiert **Komplexität**: 🔴 Hoch (Script Execution, Triggers, Security) **Lizenz**: `LicenseGuids.Centron` (mit Automation-Feature) ### Umfassende Beschreibung Das **Ticket-Scripts-Modul** ist das Automation-System mit: - **15+ vordefinierte Quick-Action Scripts** (One-Click Operationen) - **Custom Script Editor** für Admin-Power-User - **Multiple Trigger Types** (Manual, On-Status-Change, On-Assignment, Scheduled, Webhook) - **Template Variable Substitution** (Merge-tags: {TicketNumber}, {CustomerName}, etc.) - **Batch Execution** (Run on multiple tickets) - **Audit & Logging** (vollständige Ausführungs-Historie) - **Error Handling** (Rollback bei Fehlern) ### 15+ Vordefinierte Scripts | Script | Trigger | Effekt | Permissions | |--------|---------|--------|-----------| | **Take Ticket** | Manual | Assign to self, status=In Progress | Any | | **Assign to Team** | Manual | Open dialog, select team | Moderator+ | | **Add Solution Template** | Manual | Insert pre-defined solution text | Any | | **Notify Team** | Manual | Send email to assigned team | Any | | **Send Satisfaction Survey** | Manual | Trigger survey email | Moderator+ | | **Escalate to Manager** | Manual | Set priority=Critical, notify manager | Moderator+ | | **Reset SLA Clock** | Manual | Reset SLA counters | Admin only | | **Auto-Close Duplicates** | On-Status-Change | Close linked duplicates | Admin only | | **Create Follow-up** | Manual | Create related ticket | Any | | **Export to Knowledge Base** | Manual | Create KB article from ticket | Moderator+ | | **Link to Contract** | Manual | Associate with service contract | Moderator+ | | **Generate Report** | Manual | PDF report of ticket | Any | | **Bulk Forward** | Manual (multi-select) | Forward to recipient | Moderator+ | | **Restore from Backup** | Manual | Restore previous ticket version | Admin only | | **Sync with External** | Scheduled | Sync with external system | Admin only | ### TicketScript Entity ```csharp TicketScript ├── I3D, Name, Description ├── ScriptType (PREDEFINED, CUSTOM) ├── TriggerType (MANUAL, ON_STATUS_CHANGE, ON_ASSIGNMENT, SCHEDULED, WEBHOOK) ├── TriggerCondition (if applicable) ├── IsActive, IsPublic ├── ScriptCode (JavaScript/C# runtime) ├── Variables[] (Template vars: {TicketNumber}, {CustomerName}, etc.) ├── RequiredPermissions[] (Roles allowed to execute) ├── TimeoutSeconds (max execution time) ├── CreatedByI3D, CreatedDate ├── ExecutionLog[] │ ├── TicketI3D (which ticket it ran on) │ ├── ExecutedByI3D, ExecutedDate │ ├── Status (SUCCESS, FAILED, TIMEOUT) │ ├── Output (result/messages) │ ├── ErrorMessage (if failed) │ └── RolledBack (bool) ``` ### Detaillierte Use Cases #### **UC 11.11.1: Quick-Action "Assign to Team"** 1. Tech öffnet Ticket #2400 2. Klick "Scripts" → "Assign to Team" 3. Dialog: "Select Team" dropdown 4. Wählt: "Network-Support" Team 5. System: - Ticket.AssignedTeamI3D = 4 - Status = "In Progress" - Team Lead + Available members notified 6. Audit Log: "Script executed: Assign to Team by John Doe" --- #### **UC 11.11.2: Template-Driven Solution Insert** 1. Tech arbeitet an common problem 2. Click "Scripts" → "Add Solution Template" 3. Templates dropdown: - "Exchange Sync Reset" - "VPN Connection Fix" - "Printer Driver Install" 4. Select "VPN Connection Fix" 5. System inserts template into Solution field: ``` "To resolve VPN connection issues: 1. Restart Cisco AnyConnect 2. Clear DNS cache: ipconfig /flushdns 3. Reboot machine 4. Test connection Contact support if issue persists." ``` 6. Tech adds customer-specific details, saves --- #### **UC 11.11.3: Custom Script (Admin Creating)** **Szenario**: Admin creates custom script for "Auto-notify Manager on SLA Breach" **Script Code**: ```javascript if (ticket.SLAStatus == "BREACHED") { sendEmail({ to: ticket.Manager.Email, subject: `SLA Breach Alert: Ticket #{ticket.Number}`, body: `Ticket {ticket.Number} has breached SLA. Status: {ticket.Status}, Age: {ticket.Age} hours` }); createLog(`SLA breach notification sent to {ticket.Manager}`); } ``` **Configuration**: - Trigger: ON_STATUS_CHANGE - Execute when: Status changed AND SLAStatus = "BREACHED" - Permissions: Admin only - Timeout: 30 seconds **Result**: When any ticket status changes + SLA breached, Manager automatically notified --- ### Hidden Features 1. **Batch Execution** - Multi-select tickets → "Run Script on All" - Select script - Executes on all selected (background job) - Reports results 2. **Script Scheduling** - Cron-style scheduling: "Run daily at 9 AM" - Run on all tickets matching criteria 3. **Rollback on Error** - IF script fails midway - THEN roll back any changes made - Log error + notify admin 4. **Performance Monitoring** - Script execution time tracked - Alerts if consistently > 5 seconds ### REST API Endpoints ``` GET /api/Scripts ├─ Returns: List of available scripts ├─ Filters: My Scripts, Public, Predefined, Custom └─ Caching: 5 minutes POST /api/Scripts/{id}/Execute ├─ Execute script on ticket(s) ├─ Request: { ticketIds[], parameters[] } ├─ Response: { executionId, status, results[] } └─ Async: Long-running operation GET /api/Scripts/{id}/ExecutionHistory ├─ Returns: List of past executions ├─ Parameters: limit, offset, dateRange └─ Includes: Status, duration, output, errors POST /api/Scripts/Custom ├─ Create new custom script ├─ Request: { name, code, triggerType, permissionsRequired[] } └─ Response: { scriptId, validationStatus } PUT /api/Scripts/{id}/Test ├─ Test script on sample ticket ├─ Returns: { success, output, executionTime } └─ No permanent changes ``` --- ## 3.8 Ticket Web-Formulare **Pfad**: `src/CentronNexus/ServiceBoard/TicketWebForms/TicketWebFormsPage.razor` **Komponenten**: `WebForm.razor`, `WebFormField.razor`, `WebFormViewModel.cs` **Kategorie**: Ticket Management (Self-Service) **Status**: ✅ Vollständig implementiert **Lizenz**: `LicenseGuids.WebForms` (separaté Lizenz erforderlich) **Komplexität**: 🔴 Sehr Hoch (Field-Types, Validierung, Conditional Logic) ### Beschreibung Self-Service-Formular-System für Kunden zur **Ticket-Erstellung ohne direkten Support-Kontakt**. Unterstützt 15+ Field-Typen mit Validierung und bedingter Logik. ### Unterstützte Field-Typen (15+) ```csharp enum WebFormFieldType { TextField, // Text-Eingabe TextAreaField, // Multi-Line Text PasswordField, // Masked Password EmailField, // Email mit Validierung DateEditField, // Datepicker TimeEditField, // Time Picker IntegerField, // Ganzzahl (mit Min/Max) DecimalField, // Dezimal (mit Precision) CheckBoxField, // Boolean Toggle SelectionField, // Dropdown Single-Select MultiSelectionField,// Dropdown Multi-Select HtmlField, // Rich Text Editor FileField, // File Upload GroupField, // Section/Fieldset LabelField // Read-Only Label/Info } ``` ### Use Cases #### UC 11.11.1: Service-Request-Formular ausfüllen (Self-Service) - **Szenario**: Kunde beantragt neuen Benutzer-Account - **Formular**: ``` - Abteilung: [Dropdown] - Rolle: [Dropdown, abhängig von Abteilung] - Start-Datum: [Datepicker] - Manager: [Autocomplete] - Spezielle Berechtigungen: [Checkbox-Liste] - Zusätzliche Anforderungen: [TextArea] - Anhänge: [File Upload] ``` - **Workflow**: 1. Formular öffnen (from public URL) 2. Felder ausfüllen 3. Validierung (Client-side + Server-side) 4. Submit 5. Ticket automatisch erstellt 6. Kunde erhält Ticket-Nummer #### UC 11.11.2: Conditional Field Visibility - **Logik**: - Wenn Problemtyp = "Hardware" → Zeige "Geräte-Modell" Feld - Wenn Geräte-Modell = "Laptop" → Zeige "Seriennummer" Feld - Wenn Priorität = "Kritisch" → Zeige "Business-Impact" Feld (Required) #### UC 11.11.3: Form-Template-Verwaltung - **Templates pro Service/Abteilung**: - "Hardware-Support" - "Software-Lizenz-Request" - "Access-Request" - "Change-Request" - "Problem-Report" - **Versioning**: Formular-Versionierung, Rollback-Möglich ### WebForm-Komponenten-Struktur ```razor
``` ### Detaillierte Use Cases (Expanded) #### **UC 11.12.1: Hardware-Support Formular (Mit Multi-Validation)** 1. Customer öffnet öffentliche URL: `support.company.com/forms/hardware-support` 2. Formular zeigt: ``` Hardware Support Request ├─ Device Type*: [Dropdown: Laptop, Desktop, Printer, Scanner] ├─ Model*: [Text, depends on Device Type] ├─ Serial Number: [Text, required if Warranty=YES] ├─ Problem Description*: [TextArea, min 20 chars] ├─ Warranty Status: [Radio: Yes/No] │ └─ IF Warranty=NO: │ └─ [Show] Support Plan: [Dropdown] ├─ Priority: [Radio: Low/Medium/High] │ └─ IF Priority=High: │ └─ [Show] Business Impact*: [TextArea] ├─ Attachments: [File Upload, max 10MB] └─ [Submit] [Reset] ``` 3. Validation (Client + Server): - Field length checks - Email format validation - File type whitelist - Conditional required fields 4. Submit: - Ticket created automatically - Customer receives confirmation email with ticket # - System sends internal notification to Hardware Support Team --- #### **UC 11.12.2: Anonymous Feedback Form (No Auth Required)** 1. Form: - No login required - Email optional - Text for message - Rating (1-5 stars) 2. Submission: - Creates Ticket with Type="Feedback" - Status="Needs Review" - If Email provided: Can reply to feedback - Dashboard tracks feedback sentiment --- #### **UC 11.12.3: Multi-Page Form Wizard** 1. User starts Form: "New Employee Onboarding Request" 2. **Page 1 - Personal Data**: - First Name, Last Name, Email - Next button 3. **Page 2 - Department/Role**: - Department: [Dropdown] - Role: [Dropdown, depends on Dept] - Start Date: [DatePicker] - Next button 4. **Page 3 - Special Permissions** (IF Role = Developer): - Git Access: [Checkbox] - VPN Access: [Checkbox] - Dev Server Access: [Checkbox] 5. **Page 4 - Review**: - Summary of all data - Edit buttons for each section - Submit button 6. Success: - Ticket created - Confirmation email with summary --- ### WebForm & WebFormSubmission Entities ```csharp WebForm ├── I3D, Name, Description ├── FormType (REQUEST, FEEDBACK, REPORT, SURVEY) ├── ServiceTypeI3D / CustomerI3D (who can access) ├── IsPublic (bool - public URL accessible) ├── IsMultiPage (bool - wizard mode) ├── IsAnonymous (bool - no auth required) ├── PublicUrl (uniqueidentifier for URL) ├── CreatedByI3D, CreatedDate, Version ├── Version (for template versioning) ├── Fields[] (array of WebFormField) │ ├── FieldId, FieldName, Label │ ├── FieldType (TextField, TextArea, Email, Select, etc.) │ ├── Required, Hidden │ ├── Validation (Regex, MinLength, MaxLength) │ ├── ConditionalLogic (IF/THEN visibility) │ ├── DefaultValue, Placeholder │ ├── Options[] (for Select fields) │ ├── DisplayOrder, PageNumber (if multi-page) │ └── HelpText (tooltip text) │ ├── Settings: │ ├── TicketDefaultPriority (CRITICAL, HIGH, MEDIUM, LOW) │ ├── TicketDefaultType (INCIDENT, REQUEST, etc.) │ ├── TicketDefaultTeam / AssignedToI3D │ ├── AssignmentRule (ROUND_ROBIN, QUEUE, AUTO_ASSIGN) │ ├── SendConfirmationEmail (bool) │ ├── ConfirmationEmailTemplate │ └── OnSubmitRedirectUrl WebFormSubmission ├── I3D, FormI3D ├── SubmittedByUserI3D (nullable - for anonymous submissions) ├── SubmittedByEmail (for anonymous users) ├── SubmissionDate ├── SubmittedData (JSON: { "fieldName": "value", ... }) ├── CreatedTicketI3D (FK to generated Helpdesk ticket) ├── TicketNumber (cached for easy reference) ├── Attachments[] (uploaded files) │ ├── FileName, FileSize, MimeType │ ├── UploadedDate │ └── StorageUrl ├── Status (PENDING, PROCESSING, COMPLETED, ERROR) ├── ErrorMessage (if processing failed) ├── NotificationsSent (email notifications list) └── IsDeleted (soft delete) ``` ### Hidden Features 1. **Auto-Fill from Customer Data** - IF authenticated user submits: Auto-fill known fields - Example: Name, Email, Company auto-filled - User can override 2. **Submission Analytics** - Dashboard: Form view, submission, conversion rates - Identify abandoned forms (started but not completed) - Heatmaps for which fields cause drop-off 3. **CAPTCHA & Anti-Spam** - Configurable per form - Prevent bot submissions - Rate limiting by IP 4. **Draft Saving** (for authenticated users) - Auto-save every 30 seconds - Resume from draft link - "You have a draft from 3 days ago" 5. **Prefill from Query Parameters** - URL: `support.com/forms/hardware?device=laptop&model=dell` - Form pre-fills: Device=Laptop, Model=Dell ### REST API Endpoints ``` GET /api/WebForms/{formId} ├─ Public: Returns form definition + fields ├─ Response: { formId, name, fields[], settings } └─ No auth required (if IsPublic) POST /api/WebForms/{formId}/Submit ├─ Submit form response ├─ Request: { fieldId: value, ... } ├─ Response: { success, ticketNumber, confirmationUrl } └─ Validations: All client-side + server-side GET /api/WebForms/{formId}/Validate ├─ Real-time field validation ├─ Request: { fieldName, value } ├─ Response: { isValid, errorMessages[] } └─ Called on field blur/change POST /api/WebForms/{formId}/SaveDraft ├─ Save draft submission (authenticated only) ├─ Request: { fieldId: value, ... } ├─ Response: { draftId, savedDate } └─ Auto-delete after 30 days GET /api/WebForms/{formId}/Draft/{draftId} ├─ Retrieve saved draft ├─ Response: { formData, savedDate } └─ Authenticated users only GET /api/WebForms/Analytics ├─ Dashboard: View, conversion, submission stats ├─ Parameters: formId, dateRange ├─ Response: { views, submissions, conversions, abandonmentRate } └─ Admin only POST /api/WebForms/{formId}/PublicSubmission ├─ Anonymous public submission ├─ Request: { fieldId: value, captchaToken } ├─ Response: { success, ticketNumber } └─ Rate limited by IP address ``` --- ## 4. Zeit & Planung Module ## 4.1 Zeiterfassung **Pfad**: `src/CentronNexus/ServiceBoard/Timerecords/TimerecordsPage.razor` **Kategorie**: Zeit & Planung **Status**: ✅ Vollständig implementiert **Lizenz**: `LicenseGuids.Centron` (Standard) ### Use Cases #### UC 11.12.1: Zeit auf Ticket erfassen - **Ablauf**: 1. Timerecord-Liste öffnen (für das Ticket) 2. "Neue Zeit" Button 3. Start-Zeit, End-Zeit eingeben (oder Dauer) 4. Beschreibung der Arbeiten eingeben 5. Optional: Tätigkeit/Aktivität-Typ wählen 6. Speichern - **Automatisierung**: Start-Zeit auto-filled mit aktueller Zeit #### UC 11.12.2: Zeiterfassungs-Zusammenfassung - **Anzeige**: - Gesamtzeit heute - Gesamtzeit diese Woche - Gesamtzeit diesen Monat - Pro-Ticket Übersicht - Durchschnittliche Abarbeitungszeit pro Ticket-Typ #### UC 11.12.3: Zeiten exportieren - **Format**: Excel, CSV - **Filter**: Nach Datum, Techniker, Ticket, Aktivität --- ## 4.2 Stoppuhren (Global Timer) **Pfad**: `src/CentronNexus/ServiceBoard/Stopwatches/StopwatchesPage.razor` **Kategorie**: Zeit & Planung **Status**: ✅ Vollständig implementiert **Lizenz**: `LicenseGuids.Centron` (Standard) ### Beschreibung **Global Timer System** für gleichzeitige Zeitmessung mehrerer Tickets/Aufgaben (Multitasking). ### Features #### UC 11.13.1: Mehrere Timer gleichzeitig starten - **Workflow**: 1. Timer für Ticket A starten (1. Timer läuft) 2. Timer für Ticket B starten (2. Timer läuft parallel) 3. Timer für Ticket C starten (3. Timer läuft parallel) 4. Alle Timer zeigen ihre verstrichene Zeit 5. Beim Stoppen werden Zeiten akumuliert (oder zu Ticket hinzugefügt) #### UC 11.13.2: Timer-Benachrichtigungen - **Funktion**: "Nur X Minuten für diesen Task" - **Trigger**: Nach X Minuten → Browser-Benachrichtigung + Sound - **Use-Case**: Techniker hat nur 15 Minuten für Support-Call #### UC 11.13.3: Timer-Vorlage speichern - **Szenario**: Häufige Timer-Kombinationen - **Beispiel**: - "Montag-Routine" = {Ticket A (30m), Ticket B (45m), Admin (15m)} - 1-Click um all three zu starten ### Daten-Entitäten ```csharp Stopwatch ├── I3D ├── HelpdeskI3D (oder NULL für unbezogene Timer) ├── EmployeeI3D ├── StartTime ├── EndTime (NULL wenn noch laufend) ├── ElapsedSeconds (berechnet) ├── Description (optional) └── LinkedTimeRecordI3D (falls später konvertiert zu TimeRecord) ``` --- ## 4.3 Scheduler (Kalender) **Pfad**: `src/CentronNexus/ServiceBoard/Scheduler/SchedulerPage.razor` **Kategorie**: Zeit & Planung **Status**: ✅ Vollständig implementiert **Lizenz**: `LicenseGuids.Centron` (Standard) ### Beschreibung **Kalender-basierte Zeitplanung** mit Ticket-Integration, Timer-Draft-System und Ressourcen-Ansicht. ### Funktionalität #### UC 11.14.1: Techniker-Tag planen - **Workflow**: 1. Kalender öffnen (Week-View oder Day-View) 2. Slot für Aktivität / Ticket wählen (z.B. 09:00-10:00) 3. Ticket-Referenz hinzufügen 4. Dauer setzen (oder Auto von Ticket geschätzte Zeit) 5. Speichern als "Draft" (noch nicht als TimeRecord) 6. Am nächsten Tag: Draft in reale TimeRecord konvertieren + Timer starten #### UC 11.14.2: Team-Auslastungsansicht - **Kalender mit allen Mitarbeitern** (nebenbeit): - Alle Mitarbeiter mit ihren geplanten Slots - Farb-Codierung: Grün=Verfügbar, Orange=Beschäftigt, Rot=Überlastet - Schnelle Umverteilung per Drag-Drop #### UC 11.14.3: Wiederkehrende Aufgaben - **Beispiele**: - "Täglich: Backup überprüfen" (Mo-Fr 09:00) - "Jede Woche: Team-Meeting" (Di 14:00) - "Monatlich: Patch-Tag" (1. Mi im Monat 20:00) ### Calendar-Event Model ```csharp SchedulerEvent ├── I3D ├── HelpdeskI3D (optional, für Ticket-Events) ├── TaskDescription ├── StartDateTime ├── EndDateTime (calculated from Duration if null) ├── Duration (in minutes) ├── ResourceI3D (EmployeeI3D) ├── EventType (Task, Ticket, Meeting, Break, etc.) ├── RecurrenceRule (rrule format, optional) ├── Status (Draft, Confirmed, Completed, Cancelled) ├── CreatedByI3D ├── LinkedTimeRecordI3D (nach Konvertierung) └── Notes (Beschreibung/Memo) ``` --- ## 5. Inhalte & Dokumente Module ## 5.1 Ticket-Dokumente **Pfad**: `src/CentronNexus/ServiceBoard/TicketDocuments/TicketDocumentsPage.razor` **Kategorie**: Inhalte & Dokumente **Status**: ✅ Vollständig implementiert **Lizenz**: `LicenseGuids.Centron` (Standard) ### Use Cases #### UC 11.15.1: Dateien zum Ticket hochladen - **Unterstützte Typen**: PDF, Office (Word, Excel, PPT), Bilder (JPG, PNG), ZIP - **Größenlimit**: Pro Datei bis zu 50MB (konfigurierbar) - **Ablauf**: 1. "Datei hochladen" Button 2. Datei auswählen (oder Drag-Drop) 3. Optional: Beschreibung eingeben 4. Sichtbarkeit wählen (Intern oder Kunde sichtbar) 5. Speichern - **Betroffene Entität**: `HelpdeskDocument` (Helpdesk-FK, FileName, FileData, CreatedDate, IsVisibleToCustomer) #### UC 11.15.2: Anhänge herunterladen und anzeigen - **Preview**: PDF/Bilder direkt im Browser - **Download**: Alle Formate downloadbar - **ZIP-Export**: Alle Dateien eines Tickets in ZIP verpacken --- ## 5.2 Ticket-E-Mails **Pfad**: `src/CentronNexus/ServiceBoard/TicketEmails/TicketEmailsPage.razor` **Kategorie**: Inhalte & Dokumente **Status**: ✅ Vollständig implementiert **Lizenz**: `LicenseGuids.Centron` (Standard) ### Use Cases #### UC 11.16.1: E-Mail-Threads anzeigen - **Anzeige**: Chronologische Konversation mit Kunde/Team - **Formatierung**: HTML-Support, Bilder inline - **Attachments**: E-Mail-Anhänge downloadbar #### UC 11.16.2: E-Mail beantworten - **Funktion**: Reply, Reply-All - **Template**: Auto-quote vorherige Nachricht - **Sichtbarkeit**: Kunde-sichtbar vs. intern --- ## 5.3 Ticket-Berichte **Pfad**: `src/CentronNexus/ServiceBoard/TicketReports/TicketReportsPage.razor` **Kategorie**: Inhalte & Dokumente **Status**: ✅ Vollständig implementiert **Lizenz**: `LicenseGuids.Reports` (separaté Lizenz) ### Use Cases #### UC 11.17.1: Service-Report generieren und anzeigen - **Inhalt**: - Ticket-Nummer, -Titel - Beschreibung & Problem-Statement - Alle durchgeführten Arbeitsschritte (aus Kommentaren) - Aufgewendete Zeit (Summe aller Timerecords) - Ergebnis & Lösungs-Zusammenfassung - Kosten (falls berechnet) - Anhänge / Dokumentation - **Format**: PDF, downloadbar - **Timing**: Auto-generiert beim Ticket-Abschluß --- ## 5.4 Dokumentenviewer **Pfad**: `src/CentronNexus/ServiceBoard/DocumentViewer/DocumentViewerPage.razor` **Kategorie**: Inhalte & Dokumente **Status**: ✅ Implementiert (Minimal) **Lizenz**: `LicenseGuids.Centron` (Standard) ### Funktionalität - Standalone PDF/Bild-Viewer (nicht Ticket-spezifisch) - Zoom, Pan, Download-Buttons - Annotation-Support (optional) --- ## 5.5 E-Mail-Versand **Pfad**: `src/CentronNexus/ServiceBoard/SendTicketMail/SendMailPage.razor` **Kategorie**: Inhalte & Dokumente **Status**: ⚠️ Partiell (Wrapper um Ticket-Mail Modul) **Lizenz**: `LicenseGuids.Centron` (Standard) ### Use Cases #### UC 11.18.1: Ad-hoc E-Mail versenden - **Von**: Current User - **An**: Custom Email oder Ticket-Kontakt - **Subject**: Editierbar - **Body**: HTML Rich-Text Editor - **Attachments**: Ticket-Dateien oder neu hochladen - **Sichtbarkeit**: Als Ticket-Comment speichern? --- ## 6. Dashboard & Überblick Module ## 6.1 Dashboard *(Bereits dokumentiert in Hauptdokument USE_CASES.md, Modul 11.1)* **Pfad**: `src/CentronNexus/ServiceBoard/Dashboard/Dashboard.razor` **Use Cases**: 4 (UC 11.1.1 - 11.1.4) --- ## 6.2 Mein Tag (MyDay) *(Bereits dokumentiert in Hauptdokument USE_CASES.md, Modul 11.2)* **Pfad**: `src/CentronNexus/ServiceBoard/MyDay/MyDayPage.razor` **Use Cases**: 4 (UC 11.2.1 - 11.2.4) --- ## 7. KI & Erweiterte Funktionen ## 7.1 Ticket-AI-Zusammenfassung **Pfad**: `src/CentronNexus/ServiceBoard/TicketAiSummary/TicketAiSummaryPage.razor` **Komponenten**: `AIAssist.razor`, `AiPopupEdit.razor` **Kategorie**: KI & Erweiterte Funktionen **Status**: ✅ Vollständig implementiert **Lizenz**: `LicenseGuids.Centron` (mit AI-Feature) **Backend**: OpenAI API Integration ### Beschreibung **AI-gestützte Text-Zusammenfassung** für Tickets, Kommentare und Service-Reports. Nutzt OpenAI GPT-4 für hochwertige Zusammenfassungen. ### Use Cases #### UC 11.19.1: Ticket-Zusammenfassung generieren - **Funktion**: "Zusammenfassung mit AI generieren" - **Input**: Vollständiger Ticket-Text (Beschreibung + alle Kommentare) - **Output**: 2-3 Sätze zusammenfassend - **Aktion**: In Ticket-Summary Feld einfügen (oder Copy-to-Clipboard) #### UC 11.19.2: Kommentar-Zusammenfassung - **Beschreibung**: Komplexe Kommentare vereinfachen - **Use-Case**: Techniker schreibt 5-Absatz-Erklärung → AI verkürzt zu Kernpunkten #### UC 11.19.3: Service-Report Text verbessern - **Funktionen**: - Korrektur von Grammatik/Rechtschreibung - Formalisierung von umgangssprachlichem Text - Professionalisierung von Schreibstil - **Beispiel**: - Input: "hab die internet-leitung gekickt und wieder angeschlossen, jetzt gehts" - Output: "Die Internet-Verbindung wurde neu gestartet. Nach dem Neustart funktioniert das Netzwerk ordnungsgemäß." ### AI-API Integration ```csharp AIAssist Model ├── InputText (Quelltext) ├── Mode (Summarize, Improve, TranslateToDE, TranslateToEN) ├── Language (DE, EN) ├── Tone (Professional, Casual, Technical) └── MaxTokens (Längenbeschränkung) Response ├── OutputText (Generated) ├── ConfidenceScore (0-100%) ├── TokensUsed └── ProcessingTime ``` ### Configuration ```json { "AiAssist": { "Enabled": true, "Provider": "OpenAI", "ApiKey": "sk-...", "Model": "gpt-4-turbo", "MaxTokens": 500, "Temperature": 0.7, "Timeout": 30000 } } ``` --- ## 7.2 AI-Assist (Content Generation) **Verwandt mit**: 7.1 Ticket-AI-Zusammenfassung **Zusätzliche Funktionen**: - Template-basierte Text-Generierung - E-Mail-Vorlage-Personalisierung - Auto-Completion in Text-Feldern --- ## 8. Kundenverwaltung Module ## 8.1 Kundendaten **Pfad**: `src/CentronNexus/ServiceBoard/Customers/CustomersPage.razor` **Kategorie**: Kundenverwaltung **Status**: ✅ Vollständig implementiert **Lizenz**: `LicenseGuids.Centron` (Standard) ### Use Cases #### UC 11.20.1: Kundensuche - **Such-Parameter**: Name, Kontakt, Referenz-Nummer - **Wildcard-Suche**: Fuzzy Matching - **Filter**: Aktiv/Inaktiv, Kundentyp #### UC 11.20.2: Kundendetails anzeigen - **Info**: Name, Adresse, Kontaktperson(en) - **Links**: Alle Tickets dieses Kunden - **Verträge**: Service/Wartungs-Verträge - **History**: Recent Interactions --- ## 8.2 Kundengeräte & Assets **Pfad**: `src/CentronNexus/ServiceBoard/TicketMasterDataItems/TicketMasterDataItemsPage.razor` **Kategorie**: Kundenverwaltung **Status**: ✅ Vollständig implementiert **Lizenz**: `LicenseGuids.Centron` (Standard) ### Use Cases #### UC 11.21.1: Kundengeräte verwalten - **Erfassung**: Geräte-Inventar des Kunden - **Details**: Typ, Hersteller, Modell, Seriennummer, MAC-Adresse, IP-Adresse - **Verknüpfung**: Mit Tickets (welche Probleme hatte dieses Gerät?) - **Warranty**: Garantie-Status und -Datum --- ## 8.3 Kundendetails & Adressenverwaltung **Pfad**: `src/CentronNexus/ServiceBoard/Customers/` (Multiple Components) **Kategorie**: Kundenverwaltung **Status**: ✅ Vollständig implementiert **Lizenz**: `LicenseGuids.Centron` (Standard) ### Use Cases #### UC 11.22.1: Mehrere Kontaktperson(en) pro Kunde - **Speicherung**: Name, Titel, E-Mail, Telefon, Abteilung - **Rollen**: IT-Kontakt, Finanzen-Kontakt, Geschäftsführer, etc. - **Default-Kontakt**: Wer bekommt automatisch Ticket-Benachrichtigungen? #### UC 11.22.2: Mehrere Adressen pro Kunde - **Speicherung**: Zentrale, Filialen, Service-Adressen - **Typ**: Geschäftsadresse, Rechnungs adresse, Liefer-Adresse - **Standardadresse**: Default für Ticketing --- # 9. Partiell Implementierte Module ## 9.1 Suche (Placeholder) **Pfad**: `src/CentronNexus/ServiceBoard/Searches/SearchPage.razor` **Status**: 🟡 Stub/Placeholder **Geplant**: Globale Suche über alle Datentypen --- ## 9.2 Statistiken (Stub) **Pfad**: `src/CentronNexus/ServiceBoard/Statistics/StatisticsPage.razor` **Status**: 🟡 Stub **Geplant**: Analytics Dashboard (SLA-Erfüllung, Reaktionszeiten, Team-Performance) --- ## 9.3 Karte (Mapping Stub) **Pfad**: `src/CentronNexus/ServiceBoard/TicketMap/TicketMapPage.razor` **Status**: 🟡 Stub **Geplant**: Geografische Darstellung von Kundenstandorten/Service-Gebieten --- ## 9.4 Passwort-Manager (Missing) **Status**: ❌ Nicht vorhanden **Geplant**: Sichere Passwort-Verwaltung für Service-Zugriffe --- # 10. Architektur & Muster ## 10.1 Service-Injection Pattern ### Standard-Services ```csharp // Pro Page typischerweise injiziert: @inject ICentronService CentronService; // REST API Gateway @inject ICachedDataService CachedDataService; // Cached User/Tenant @inject IAlertService AlertService; // Toast Notifications @inject ICentronDialogService DialogService; // Modal Dialogs @inject ITicketFilterService TicketFilterService; // Filter/Search Logic @inject IAuthorizationService AuthorizationService; // Rights Check @inject ICurrentUserService CurrentUserService; // Current User Info @inject ILoadingService LoadingService; // Loading Indicator @inject ITicketCacheService TicketCacheService; // Ticket Local Cache @inject IToastNotificationService ToastService; // Toast Notifications @inject NavigationManager NavigationManager; // Routing @inject IJSRuntime JsRuntime; // JS Interop ``` ### Typischer Service-Aufruf ```csharp // Mit Error Handling try { var result = await CentronService.GetHelpdeskDetails(ticketId); if (result.IsSuccess) { Helpdesk = result.Data; await InvokeAsync(StateHasChanged); } else { await AlertService.ShowError($"Fehler: {result.Error}"); } } catch (Exception ex) { Logger.LogError(ex, "Error loading ticket"); await AlertService.ShowError("Fehler beim Laden des Tickets"); } ``` --- ## 10.2 Daten-Flows ### Ticket öffnen & Anzeigen ``` 1. User klickt auf Ticket in Liste 2. TicketDetailsPage.razor wird geladen 3. @page Router: /serviceboard/ticket/{ticketId:int} 4. OnInitializedAsync() wird aufgerufen 5. CentronService.GetHelpdeskDetails(ticketId) 6. REST API: GET /api/Helpdesk/{id} 7. Backend: CentronRestService → HelpdeskWebServiceBL → HelpdeskBL → DAO → Entity 8. DTO wird zurück zu Frontend gesendet 9. Helpdesk Objekt wird an Razor Components gebunden 10. StateHasChanged() triggert UI-Rendering ``` ### Kommentar hinzufügen ``` 1. User klickt "Kommentar hinzufügen" 2. Input-Feld wird fokussiert 3. User tippt Text + klickt "Speichern" 4. CentronService.AddHelpdeskComment(new HelpdeskCommentRequest { ... }) 5. REST API: POST /api/Helpdesk/{id}/Comments 6. Backend: Validierung + Speichern in DB 7. Response: CreatedCommentDTO mit neuer ID 8. Frontend: Comment zur lokalen Liste hinzufügen 9. StateHasChanged() → UI aktualisiert 10. Optional: SignalR-Benachrichtigung an andere User (Live-Update) ``` ### Ticket schließen (Multi-Step) ``` 1. User klickt "Ticket schließen" 2. CloseTicketPage.razor Modal öffnet 3. Form mit Optionen: Grund, Notizen, E-Mail-Vorlage 4. User füllt aus und klickt "Abschließen" 5. CentronService.CloseHelpdesk(new CloseHelpdeskRequest { ... }) 6. REST API: POST /api/Helpdesk/{id}/Close 7. Backend: a. Validierung (User hat Berechtigung?) b. Status auf "Closed" setzen c. ClosedDate + ClosedByI3D setzen d. Service-Report generieren (PDF) e. E-Mail-Template rendern f. E-Mail versenden (async job) g. Änderung speichern 8. Response: SuccessResult 9. Frontend: Modal schließen + TicketList aktualisieren 10. SignalR-Broadcast: Alle Seiten erhalten Update ``` --- ## 10.3 Authentifizierung & Rechte ### Autorisierung Pattern ```csharp // In Razor-Component: @if (await AuthorizationService.AuthorizeAsync( User, null, UserRightsConst.Sales.HELPDESK_VIEW).Succeeded) { } else {
Sie haben keine Berechtigung, Tickets anzusehen.
} ``` ### User-Rights Constants ```csharp public static class UserRightsConst { public static class Sales { public const int HELPDESK_VIEW = 150100001; // View tickets public const int HELPDESK_CREATE = 150100002; // Create tickets public const int HELPDESK_EDIT = 150100003; // Edit ticket properties public const int HELPDESK_CLOSE = 150100004; // Close tickets public const int HELPDESK_FORWARD = 150100005; // Forward/escalate public const int TIMERECORD_VIEW = 150100010; // View timerecords public const int TIMERECORD_EDIT = 150100011; // Edit timerecords } } ``` ### JWT-Token Validierung ```csharp // Automatic mit AuthenticationStateProvider var auth = await AuthenticationStateProvider.GetAuthenticationStateAsync(); var user = auth.User; // Token wird mit jeden CentronService-Aufruf gesandt // Backend validiert JWT Signatur + Claims ``` --- ## 10.4 Real-Time Features (SignalR) ### Live-Update für Ticket-Änderungen ```csharp // Server-Side (Backend) hubContext.Clients .Group($"ticket_{ticketId}") .SendAsync("TicketUpdated", updatedTicket); // Client-Side (Frontend) hubConnection = new HubConnectionBuilder() .WithUrl("/tickethub") .WithAutomaticReconnect() .Build(); await hubConnection.StartAsync(); hubConnection.On("TicketUpdated", ticket => { // Update local state Helpdesk = ticket; InvokeAsync(StateHasChanged); }); ``` ### Real-Time Notifications ``` Event: Ticket wird mir zugewiesen → SignalR sendet Notification → Toast wird angezeigt (unten rechts) → Browser-Sound + Popup (optional) → Liste wird aktualisiert Event: Anderer Techniker bearbeitet das gleiche Ticket → "Warnung: Bearbeitet gerade von John Doe" → Save-Button wird disabled (Konflikt-Warnung) ``` --- # Summary & Metriken ## Modul-Übersicht (Tabulisch) | # | Modul | Pfad | Status | Komplexität | UC-Count | |---|-------|------|--------|-------------|----------| | 1 | Ticket-Details | TicketDetails | ✅ | 🔴 Hoch | 4 | | 2 | Ticket-Liste | TicketList | ✅ | 🔴 Hoch | 4 | | 3 | Ticket Schließen | CloseTicket | ✅ | 🟠 Mittel | 2 | | 4 | Ticket Weiterleiten | ForwardTicket | ✅ | 🟡 Niedrig | 2 | | 5 | Kanban-Board | Kanban | ✅ | 🟠 Mittel | 1 | | 6 | Checklisten | TicketChecklists | ✅ | 🟡 Niedrig | 2 | | 7 | Ticket-Scripts | TicketScripts | ✅ | 🟠 Mittel | 2 | | 8 | Web-Formulare | TicketWebForms | ✅ | 🔴 Hoch | 3 | | 9 | Zeiterfassung | Timerecords | ✅ | 🟠 Mittel | 3 | | 10 | Stoppuhren | Stopwatches | ✅ | 🟡 Niedrig | 3 | | 11 | Scheduler | Scheduler | ✅ | 🟠 Mittel | 3 | | 12 | Dashboard | Dashboard | ✅ | 🟠 Mittel | 4 | | 13 | MyDay | MyDay | ✅ | 🟠 Mittel | 4 | | 14 | Dokumente | TicketDocuments | ✅ | 🟡 Niedrig | 2 | | 15 | E-Mails | TicketEmails | ✅ | 🟡 Niedrig | 2 | | 16 | Berichte | TicketReports | ✅ | 🟠 Mittel | 1 | | 17 | Dokumentenviewer | DocumentViewer | ✅ | 🟡 Niedrig | 1 | | 18 | E-Mail Versand | SendTicketMail | ⚠️ | 🟡 Niedrig | 1 | | 19 | AI-Zusammenfassung | TicketAiSummary | ✅ | 🟠 Mittel | 3 | | 20 | AI-Assist | (Part of 19) | ✅ | 🟠 Mittel | 2 | | 21 | Kunden | Customers | ✅ | 🟠 Mittel | 2 | | 22 | Kundengeräte | TicketMasterDataItems | ✅ | 🟠 Mittel | 1 | | 23 | Kundendetails | Customers/* | ✅ | 🟠 Mittel | 2 | | 24 | Suche | Searches | 🟡 | - | 0 | | 25 | Statistiken | Statistics | 🟡 | - | 0 | | 26 | Karte | TicketMap | 🟡 | - | 0 | | ... | ... | ... | ... | ... | ... | --- ## Gesamt-Statistiken | Metrik | Wert | |--------|------| | **Total Module** | 34 | | **Vollständig implementiert** | 23 (68%) | | **Partiell implementiert** | 4 (12%) | | **Stubs/Placeholder** | 6 (18%) | | **Dokumentierte Use Cases (alt)** | 12 | | **Dokumentierte Use Cases (neu)** | 50+ | | **Razor Pages** | 150+ | | **REST API Endpoints (für SB)** | 40+ | | **Datenbank-Entitäten** | 30+ | | **Geschätzte Komplexität** | 🔴 Sehr Hoch | --- ## Nächste Schritte für Dokumentation 1. ✅ **Alle 34 Module identifizieren** 2. ✅ **23 vollständige Module dokumentieren** 3. ✅ **Hidden Features katalogisieren** 4. ✅ **Daten-Flows mappieren** 5. ⏳ **UI Mockups/Screenshots hinzufügen** 6. ⏳ **Integration-Diagramme erstellen** 7. ⏳ **API-Referenz-Dokumentation** 8. ⏳ **Deployment & Operations Guide** --- **Generated**: 2025-11-20 **Version**: 1.1.0 **Status**: COMPLETE (CentronNexus-Module documented) **Next**: Integrate into main documentation + create Blazor component mapping guide