diff --git a/Ergebnisse/Ergebnisse 01/Stakeholder_Requirements_Specification_ISO29148.md b/Ergebnisse/Ergebnisse 01/Stakeholder_Requirements_Specification_ISO29148.md deleted file mode 100644 index eb99e0a..0000000 --- a/Ergebnisse/Ergebnisse 01/Stakeholder_Requirements_Specification_ISO29148.md +++ /dev/null @@ -1,735 +0,0 @@ -# Stakeholder Requirements Specification (StRS) -## Centron .NET 8 Enterprise Application -### According to ISO/IEC/IEEE 29148:2018 Standards - ---- - -## Document Information -- **Document ID**: StRS-CENTRON-2025-001 -- **Version**: 1.0 -- **Date**: September 29, 2025 -- **Author**: ISO 29148 Stakeholder Requirements Agent -- **System**: Centron .NET 8 Enterprise Application - ---- - -## 1. Executive Summary - -This Stakeholder Requirements Specification (StRS) defines the complete set of stakeholder needs for the Centron .NET 8 enterprise application - a comprehensive business management system serving IT distribution and services companies. The system provides integrated customer relationship management, sales processing, inventory management, financial operations, and service delivery capabilities. - -The requirements are derived from extensive codebase analysis, examining 1000+ source files across backend business logic, frontend WPF modules, web services, and external API integrations. Each requirement includes specific evidence from implementation artifacts, ensuring traceability to actual system capabilities. - ---- - -## 2. System Context - -```mermaid -graph TB - subgraph "External Systems" - finapi[FinAPI Banking] - gls[GLS Shipping] - shipcloud[Shipcloud Logistics] - icecat[Icecat Product Data] - itscope[ITscope Distribution] - egis[EGIS Wholesale] - end - - subgraph "Centron Enterprise System" - wpf[WPF Desktop Client] - webservice[Web Services Layer] - backend[Business Logic Layer] - database[(SQL Server Database)] - - wpf --> webservice - wpf --> backend - webservice --> backend - backend --> database - end - - subgraph "Stakeholders" - sales[Sales Staff] - support[Support Teams] - admin[System Administrators] - customers[Customers] - management[Management] - finance[Finance Teams] - warehouse[Warehouse Staff] - end - - sales --> wpf - support --> wpf - admin --> wpf - management --> wpf - finance --> wpf - warehouse --> wpf - - backend --> finapi - backend --> gls - backend --> shipcloud - backend --> icecat - backend --> itscope - backend --> egis -``` - ---- - -## 3. Stakeholder Analysis - -### Primary Stakeholders -- **Sales Representatives**: Need efficient customer management, quote processing, and order tracking -- **Customer Support Teams**: Require helpdesk functionality, ticket management, and customer history access -- **System Administrators**: Need user management, security controls, and system configuration -- **Finance Teams**: Require accounting integration, financial reporting, and payment processing -- **Warehouse Staff**: Need inventory management, stock control, and logistics coordination -- **Management**: Require reporting, analytics, and business intelligence capabilities - -### Secondary Stakeholders -- **Customers**: Benefit from improved service delivery and accurate information -- **External Partners**: Integration with shipping providers, banks, and data suppliers -- **Auditors**: Need compliance reporting and audit trails - ---- - -## 4. Requirements Specification - -### Customer Relationship Management Requirements (StR-001 to StR-006) - -### StR-001: Account Management System -**Stakeholder**: Sales Representatives, Customer Support Teams -**Statement**: The system shall provide comprehensive account management capabilities for customers, suppliers, and partners with complete contact information, relationship tracking, and business classification. -**Rationale**: Central customer data management is critical for effective sales operations and customer service delivery. Account entities form the foundation for all business transactions. -**Priority**: High -**Acceptance Criteria**: -- System can create, update, and manage account records with full contact details -- Support for multiple account types (customers, suppliers, partners) with role-based access -- Maintain complete audit trail of account changes with timestamps and user tracking -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Accounts\Account.cs (lines 17-62), C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Services\Logics\Accounts\IAccountsLogic.cs (lines 22-34) -**Verification Method**: Test - -### StR-002: Contact Person Management -**Stakeholder**: Sales Representatives, Customer Support Teams -**Statement**: The system shall maintain detailed contact person records linked to accounts with role definitions, communication preferences, and interaction history. -**Rationale**: Effective relationship management requires tracking individual contacts within organizations to ensure personalized service and proper communication routing. -**Priority**: High -**Acceptance Criteria**: -- Create and maintain contact person records with roles and responsibilities -- Link contacts to accounts with proper hierarchical relationships -- Track communication preferences and interaction history per contact -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Accounts\Account.cs (lines 80-93), C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Services\Logics\Accounts\IAccountsLogic.cs (lines 134-141) -**Verification Method**: Test - -### StR-003: Customer Classification and Segmentation -**Stakeholder**: Sales Representatives, Management -**Statement**: The system shall provide customer classification capabilities with customizable categories, sales areas assignment, and customer segmentation for targeted marketing and sales strategies. -**Rationale**: Business success requires the ability to segment customers by various criteria to enable targeted sales approaches and customized service levels. -**Priority**: Medium -**Acceptance Criteria**: -- Define and manage customer classification categories -- Assign customers to sales areas and territories -- Support customer segmentation for marketing campaigns -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Services\Logics\Accounts\IAccountsLogic.cs (lines 36-40, 66-76), C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Accounts\Account.cs (lines 25-36) -**Verification Method**: Demo - -### StR-004: Account Relationship Mapping -**Stakeholder**: Sales Representatives, Management -**Statement**: The system shall enable mapping of relationships between accounts including parent-subsidiary connections, partnership links, and business network associations. -**Rationale**: Understanding business relationships is crucial for account management, cross-selling opportunities, and maintaining comprehensive customer intelligence. -**Priority**: Medium -**Acceptance Criteria**: -- Create and maintain account-to-account relationships with defined relationship types -- Visual representation of account networks and hierarchies -- Impact analysis when modifying related accounts -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Services\Logics\Accounts\IAccountsLogic.cs (lines 136-141), C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Accounts\Account.cs (lines 27-28) -**Verification Method**: Demo - -### StR-005: Customer Activity Tracking -**Stakeholder**: Sales Representatives, Customer Support Teams -**Statement**: The system shall track all customer interactions, activities, and touchpoints to maintain complete customer engagement history and enable relationship continuity. -**Rationale**: Comprehensive activity tracking ensures consistent customer experience regardless of which team member interacts with the customer and supports relationship building. -**Priority**: High -**Acceptance Criteria**: -- Record all customer interactions with date, time, type, and outcome -- Link activities to specific accounts and contacts -- Provide activity timeline views and reporting capabilities -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Accounts\Activities directory structure, C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Services\Logics\Accounts\IAccountsLogic.cs (lines 147-151) -**Verification Method**: Test - -### StR-006: CRM Settings and Configuration -**Stakeholder**: System Administrators, Management -**Statement**: The system shall provide comprehensive CRM configuration capabilities including workflow settings, field customization, and business process adaptation to organizational needs. -**Rationale**: Different organizations have varying CRM processes and requirements, necessitating flexible configuration options to optimize system adoption and effectiveness. -**Priority**: Medium -**Acceptance Criteria**: -- Configure CRM workflows and business processes -- Customize field definitions and validation rules -- Set up automation rules and notification preferences -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Services\Logics\Accounts\IAccountsLogic.cs (lines 104-106), C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\CustomerArea\CRM directory structure -**Verification Method**: Inspection - ---- - -### Sales and Order Processing Requirements (StR-007 to StR-011) - -### StR-007: Quote to Invoice Lifecycle Management -**Stakeholder**: Sales Representatives, Finance Teams -**Statement**: The system shall manage the complete sales document lifecycle from quotes through orders to invoices with status tracking, approval workflows, and financial integration. -**Rationale**: Streamlined sales processing is essential for business efficiency, requiring seamless progression through sales stages with appropriate controls and audit trails. -**Priority**: High -**Acceptance Criteria**: -- Create and manage quotes, orders, and invoices with proper status transitions -- Implement approval workflows with role-based authorization -- Maintain complete audit trail of document changes and approvals -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\DbEntities\RechKopf.cs (lines 10-163), C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\DbEntities (AngKopf.cs, AufKopf.cs, KalkKopf.cs) -**Verification Method**: Test - -### StR-008: Order Processing and Fulfillment -**Stakeholder**: Sales Representatives, Warehouse Staff -**Statement**: The system shall provide comprehensive order processing capabilities including order entry, modification, status tracking, and fulfillment coordination with inventory management. -**Rationale**: Efficient order processing is critical for customer satisfaction and business operations, requiring integration between sales and warehouse operations. -**Priority**: High -**Acceptance Criteria**: -- Process orders with real-time inventory checking and allocation -- Track order status from entry through delivery -- Coordinate fulfillment activities with warehouse operations -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\DbEntities\AufKopf.cs, C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Sales directory structure -**Verification Method**: Test - -### StR-009: Pricing and Discount Management -**Stakeholder**: Sales Representatives, Management -**Statement**: The system shall provide flexible pricing management including volume pricing, special agreements, customer-specific pricing, and promotional discount structures. -**Rationale**: Competitive pricing strategies require flexible pricing models to support various customer agreements and market conditions while maintaining profitability. -**Priority**: High -**Acceptance Criteria**: -- Configure volume-based pricing tiers and discount structures -- Manage customer-specific pricing agreements and special rates -- Calculate and apply promotional discounts with approval controls -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Warehousing\ArticleVolumePrices.cs, C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Warehousing\SpecialAgreement.cs, C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Accounts\SpecialPrices directory -**Verification Method**: Test - -### StR-010: Sales Performance Analytics -**Stakeholder**: Sales Representatives, Management -**Statement**: The system shall provide comprehensive sales analytics including performance metrics, trend analysis, and sales forecasting capabilities to support decision-making. -**Rationale**: Data-driven sales management requires detailed analytics to identify opportunities, track performance, and optimize sales strategies. -**Priority**: Medium -**Acceptance Criteria**: -- Generate sales performance reports by representative, territory, and product -- Provide trend analysis and comparative reporting capabilities -- Support sales forecasting and pipeline analysis -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Modules\Administration\EmployeeManagement\Dashboard\EmployeeSales directory, C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Sales directory structure -**Verification Method**: Demo - -### StR-011: Contract Management -**Stakeholder**: Sales Representatives, Legal, Management -**Statement**: The system shall manage customer contracts including service agreements, maintenance contracts, and licensing arrangements with renewal tracking and compliance monitoring. -**Rationale**: Contract management is essential for recurring revenue, compliance, and customer relationship continuity, requiring systematic tracking and renewal processes. -**Priority**: Medium -**Acceptance Criteria**: -- Create and manage various contract types with terms and conditions -- Track contract renewals and expiration dates with automated notifications -- Monitor contract compliance and performance metrics -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Accounts\AccountContracts directory, C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Sales\CustomerAssets\Contracts directory -**Verification Method**: Test - ---- - -### Financial Management Requirements (StR-012 to StR-015) - -### StR-012: Accounting System Integration -**Stakeholder**: Finance Teams, System Administrators -**Statement**: The system shall integrate with external accounting systems to synchronize financial data, chart of accounts, and transaction records for seamless financial operations. -**Rationale**: Financial data integrity requires seamless integration with accounting systems to eliminate manual data entry and ensure consistent financial reporting. -**Priority**: High -**Acceptance Criteria**: -- Synchronize chart of accounts and financial data with external accounting systems -- Transfer sales transactions and payment records automatically -- Maintain data consistency and reconciliation capabilities -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Accounting directory, C:\DEV\UseCaseAnalyse\src\apis\Centron.APIs.FinAPI project structure -**Verification Method**: Test - -### StR-013: Financial Reporting and Analysis -**Stakeholder**: Finance Teams, Management -**Statement**: The system shall provide comprehensive financial reporting including revenue analysis, profitability metrics, and financial performance dashboards for business intelligence. -**Rationale**: Financial visibility is critical for business management, requiring detailed reporting and analysis capabilities to support strategic decision-making. -**Priority**: High -**Acceptance Criteria**: -- Generate standard financial reports including P&L, revenue analysis, and cash flow -- Provide real-time financial dashboards with key performance indicators -- Support custom financial analysis and reporting requirements -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Accounting directory, C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\DbEntities\RechKopf.cs (lines 95-105 financial fields) -**Verification Method**: Demo - -### StR-014: Payment Processing and Banking -**Stakeholder**: Finance Teams, Customers -**Statement**: The system shall integrate with banking services to process payments, manage bank accounts, and handle various payment methods including SEPA, credit cards, and electronic transfers. -**Rationale**: Modern business requires flexible payment processing capabilities to improve cash flow and customer convenience while maintaining security and compliance. -**Priority**: High -**Acceptance Criteria**: -- Process various payment methods with appropriate security measures -- Integrate with banking APIs for automated payment handling -- Manage customer payment preferences and recurring payments -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\apis\Centron.APIs.FinAPI project, C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Services\Logics\Accounts\IAccountsLogic.cs (lines 84-94 bank accounts), C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\DbEntities\RechKopf.cs (line 23 SEPA) -**Verification Method**: Test - -### StR-015: Cost Center and Profitability Analysis -**Stakeholder**: Finance Teams, Management -**Statement**: The system shall provide cost center management and profitability analysis capabilities to track financial performance by business units, projects, and customer segments. -**Rationale**: Understanding profitability at granular levels is essential for effective business management and resource allocation decisions. -**Priority**: Medium -**Acceptance Criteria**: -- Define and manage cost centers with proper allocation rules -- Track profitability by various dimensions including customer, product, and project -- Generate profitability analysis reports with variance tracking -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Warehousing\CostCenter.cs, C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Services\Logics\Accounts\IAccountsLogic.cs (lines 90-94 cost centers) -**Verification Method**: Analysis - ---- - -### Inventory and Warehouse Management Requirements (StR-016 to StR-019) - -### StR-016: Comprehensive Inventory Management -**Stakeholder**: Warehouse Staff, Sales Representatives -**Statement**: The system shall provide comprehensive inventory management including stock tracking, location management, and real-time inventory visibility across multiple warehouses and locations. -**Rationale**: Accurate inventory management is fundamental to business operations, requiring real-time visibility and control to prevent stockouts and optimize inventory levels. -**Priority**: High -**Acceptance Criteria**: -- Track inventory levels in real-time across multiple locations -- Manage stock movements, transfers, and adjustments with full audit trails -- Provide inventory alerts and reorder point management -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Logistics\Warehousing directory, C:\DEV\UseCaseAnalyse\src\backend\Centron.BL\Logistics\Warehousing\StockBL.cs -**Verification Method**: Test - -### StR-017: Product and Article Management -**Stakeholder**: Warehouse Staff, Sales Representatives -**Statement**: The system shall manage comprehensive product information including specifications, images, pricing, and supplier relationships with support for complex product hierarchies and configurations. -**Rationale**: Effective product management is essential for sales operations and inventory control, requiring detailed product information and flexible categorization. -**Priority**: High -**Acceptance Criteria**: -- Maintain detailed product catalogs with specifications and media -- Support complex product hierarchies and part relationships -- Manage supplier relationships and procurement information -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Warehousing\Article.cs, C:\DEV\UseCaseAnalyse\src\backend\Centron.BL\Warehousing\ArticleBL.cs, multiple Warehousing entities -**Verification Method**: Test - -### StR-018: Barcode and Serial Number Tracking -**Stakeholder**: Warehouse Staff, Service Teams -**Statement**: The system shall provide barcode scanning and serial number tracking capabilities for individual item identification, asset tracking, and warranty management. -**Rationale**: Asset tracking and warranty support require individual item identification capabilities to ensure proper service delivery and compliance. -**Priority**: Medium -**Acceptance Criteria**: -- Generate and manage barcode labels for inventory items -- Track serial numbers throughout product lifecycle -- Maintain history of serial number movements and ownership -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Warehousing\BarCode.cs, C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Warehousing\SerialNumber.cs, C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Warehousing\BarcodeHistory.cs -**Verification Method**: Test - -### StR-019: Logistics and Shipping Integration -**Stakeholder**: Warehouse Staff, Customers -**Statement**: The system shall integrate with shipping providers to manage logistics operations including shipment creation, tracking, and delivery confirmation with automated status updates. -**Rationale**: Efficient logistics operations require integration with shipping providers to streamline fulfillment processes and provide customers with shipment visibility. -**Priority**: Medium -**Acceptance Criteria**: -- Create shipments with integrated shipping providers -- Provide real-time shipment tracking and status updates -- Manage shipping rates and service level selection -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\apis\Centron.Api.Gls project, C:\DEV\UseCaseAnalyse\src\apis\Centron.Api.Shipcloud project, C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\DbEntities\RechKopf.cs (lines 124, 147 tracking) -**Verification Method**: Test - ---- - -### User Management and Security Requirements (StR-020 to StR-023) - -### StR-020: Comprehensive User Authentication -**Stakeholder**: System Administrators, All Users -**Statement**: The system shall provide secure user authentication including password policies, multi-factor authentication options, and integration with Active Directory for enterprise environments. -**Rationale**: System security requires robust authentication mechanisms to protect sensitive business data and ensure compliance with security standards. -**Priority**: High -**Acceptance Criteria**: -- Implement strong password policies with complexity requirements -- Support multi-factor authentication for enhanced security -- Integrate with Active Directory for centralized user management -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Modules\Administration\EmployeeManagement\AdImport directory, Authentication attributes in web service interfaces -**Verification Method**: Test - -### StR-021: Role-Based Access Control -**Stakeholder**: System Administrators, Management -**Statement**: The system shall implement comprehensive role-based access control with granular permissions management to ensure users access only appropriate system functions and data. -**Rationale**: Data security and operational control require precise access management to ensure users can perform their roles while protecting sensitive information. -**Priority**: High -**Acceptance Criteria**: -- Define roles with specific permission sets for system functions -- Assign users to roles with inheritance and override capabilities -- Audit and monitor access attempts and permission changes -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\webservice\Centron.WebServices.Core\EntitiesWrongPlace\Administration\Rights\UserRightsConst.cs (lines 10-100), extensive rights management structure -**Verification Method**: Test - -### StR-022: Employee Management System -**Stakeholder**: Human Resources, System Administrators -**Statement**: The system shall provide comprehensive employee management including organizational structure, role assignments, and employee performance tracking with integration to Active Directory. -**Rationale**: Effective employee management is essential for organizational efficiency and proper system access control within the business context. -**Priority**: Medium -**Acceptance Criteria**: -- Manage employee records with organizational hierarchy -- Track employee roles, responsibilities, and performance metrics -- Synchronize with Active Directory for consistent user management -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\EmployeeArea directory (15+ employee-related entities), C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Modules\Administration\EmployeeManagement directory structure -**Verification Method**: Demo - -### StR-023: Audit Trail and Compliance -**Stakeholder**: System Administrators, Auditors, Management -**Statement**: The system shall maintain comprehensive audit trails for all business transactions and system changes to support compliance requirements and security investigations. -**Rationale**: Regulatory compliance and security investigations require complete audit trails to demonstrate proper controls and identify security issues. -**Priority**: High -**Acceptance Criteria**: -- Log all system access attempts and user activities -- Track changes to critical business data with before/after values -- Generate compliance reports and audit trail exports -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\BaseEntity.cs audit fields (CreatedDate, ChangedDate, CreatedByI3D, ChangedByI3D), extensive logging throughout entities -**Verification Method**: Inspection - ---- - -### Multi-Language and Localization Requirements (StR-024 to StR-025) - -### StR-024: German Language Support -**Stakeholder**: German-speaking Users, Management -**Statement**: The system shall provide comprehensive German language support as the primary language including user interface, reports, documents, and error messages with proper localization for German business practices. -**Rationale**: The primary market is German-speaking, requiring native language support for user adoption and regulatory compliance in German-speaking regions. -**Priority**: High -**Acceptance Criteria**: -- Provide complete German translations for all user interface elements -- Generate business documents and reports in German -- Support German-specific business rules and regulatory requirements -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Resources\LocalizedStrings.resx (German default), extensive German field names in entities like C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\DbEntities\RechKopf.cs -**Verification Method**: Inspection - -### StR-025: English Language Support -**Stakeholder**: International Users, Management -**Statement**: The system shall provide English language support as a secondary language to accommodate international operations and English-speaking users within the organization. -**Rationale**: Business expansion and international operations require English language support to serve global markets and multilingual teams. -**Priority**: Medium -**Acceptance Criteria**: -- Provide English translations for all major user interface components -- Support language switching during user sessions -- Maintain consistency in terminology across languages -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Resources\LocalizedStrings.en.resx, C:\DEV\UseCaseAnalyse\src\backend\Centron.BL\Resources\LocalizedStrings.en.resx, C:\DEV\UseCaseAnalyse\src\shared\Centron.Controls\Resources\LocalizedStrings.en.resx -**Verification Method**: Inspection - ---- - -### External System Integration Requirements (StR-026 to StR-029) - -### StR-026: Financial Services Integration -**Stakeholder**: Finance Teams, System Administrators -**Statement**: The system shall integrate with external financial services including FinAPI for banking operations, payment processing, and financial data synchronization. -**Rationale**: Modern financial operations require integration with external financial services to streamline banking operations and ensure real-time financial data access. -**Priority**: High -**Acceptance Criteria**: -- Connect to FinAPI services for banking operations and account management -- Synchronize financial transactions and account balances -- Process payments through integrated financial service providers -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\apis\Centron.APIs.FinAPI project structure -**Verification Method**: Test - -### StR-027: Product Data Integration -**Stakeholder**: Sales Representatives, Warehouse Staff -**Statement**: The system shall integrate with product data providers including Icecat, ITscope, and EGIS to maintain current product information, specifications, and pricing data. -**Rationale**: Accurate product information is essential for sales operations, requiring integration with industry data providers to maintain current specifications and competitive pricing. -**Priority**: Medium -**Acceptance Criteria**: -- Import and synchronize product catalogs from multiple data providers -- Maintain product specifications, images, and technical documentation -- Update pricing information based on supplier data feeds -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\apis\Centron.APIs.IcecatDataAccess project, C:\DEV\UseCaseAnalyse\src\apis\Centron.APIs.ITscopeDataAccess project, C:\DEV\UseCaseAnalyse\src\apis\Centron.APIs.EgisDataAccess project -**Verification Method**: Test - -### StR-028: Shipping and Logistics Integration -**Stakeholder**: Warehouse Staff, Customers -**Statement**: The system shall integrate with shipping providers including GLS and Shipcloud to manage shipment creation, tracking, and delivery services with automated status updates. -**Rationale**: Efficient fulfillment operations require integration with multiple shipping providers to optimize cost and service levels while providing customers with shipment visibility. -**Priority**: Medium -**Acceptance Criteria**: -- Create shipments with multiple shipping providers based on service requirements -- Provide real-time shipment tracking and delivery confirmation -- Compare shipping rates and service levels across providers -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\apis\Centron.Api.Gls project, C:\DEV\UseCaseAnalyse\src\apis\Centron.Api.Shipcloud project -**Verification Method**: Test - -### StR-029: EDI and Data Exchange -**Stakeholder**: System Administrators, Business Partners -**Statement**: The system shall support Electronic Data Interchange (EDI) for automated business document exchange with suppliers, customers, and partners including orders, invoices, and delivery notifications. -**Rationale**: Business efficiency requires automated document exchange with trading partners to reduce manual processing and improve data accuracy. -**Priority**: Medium -**Acceptance Criteria**: -- Support standard EDI formats for common business documents -- Manage EDI trading partner configurations and mappings -- Process inbound and outbound EDI transactions with error handling -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\EDI directory (25+ EDI-related entities), extensive EDI processing capabilities -**Verification Method**: Test - ---- - -### Service and Support Management Requirements (StR-030 to StR-032) - -### StR-030: Helpdesk and Ticket Management -**Stakeholder**: Customer Support Teams, Customers -**Statement**: The system shall provide comprehensive helpdesk capabilities including ticket creation, assignment, tracking, and resolution with escalation procedures and knowledge base integration. -**Rationale**: Effective customer support requires systematic ticket management to ensure timely resolution and maintain customer satisfaction levels. -**Priority**: High -**Acceptance Criteria**: -- Create and manage support tickets with proper categorization and priority assignment -- Route tickets to appropriate support teams with escalation procedures -- Track resolution times and maintain customer communication -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Modules\Helpdesk directory, C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\CustomerArea\Support directory -**Verification Method**: Test - -### StR-031: Asset and Device Management -**Stakeholder**: Service Teams, Customers -**Statement**: The system shall manage customer assets and devices including installation records, maintenance schedules, and warranty tracking with integration to support processes. -**Rationale**: Service businesses require comprehensive asset tracking to deliver proactive maintenance and support services while managing warranty obligations. -**Priority**: Medium -**Acceptance Criteria**: -- Maintain detailed records of customer assets and device configurations -- Schedule and track maintenance activities and service contracts -- Monitor warranty status and automate renewal notifications -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Devices directory (5+ device management entities), C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Sales\CustomerAssets directory -**Verification Method**: Demo - -### StR-032: Knowledge Management and Documentation -**Stakeholder**: Support Teams, Technical Staff -**Statement**: The system shall provide knowledge management capabilities including technical documentation, solution databases, and information sharing to support efficient problem resolution. -**Rationale**: Effective support operations require access to organized technical knowledge to enable consistent and efficient problem resolution. -**Priority**: Medium -**Acceptance Criteria**: -- Organize technical documentation with search and categorization capabilities -- Maintain solution databases linked to common issues and products -- Enable knowledge sharing and collaboration among support teams -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\DocumentationArea directory (5+ documentation entities), C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Modules\Global\VideoPortal directory -**Verification Method**: Demo - ---- - -### Reporting and Analytics Requirements (StR-033 to StR-034) - -### StR-033: Business Intelligence and Reporting -**Stakeholder**: Management, All Business Users -**Statement**: The system shall provide comprehensive business intelligence capabilities including standard reports, custom report generation, and interactive dashboards for operational and strategic decision-making. -**Rationale**: Data-driven decision making requires comprehensive reporting and analytics capabilities to transform operational data into business insights. -**Priority**: High -**Acceptance Criteria**: -- Generate standard business reports for all functional areas -- Provide custom report building capabilities for specific business needs -- Create interactive dashboards with real-time data visualization -**Source Evidence**: Report engine components throughout the system, statistics entities in C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\EmployeeArea\EmployeeStatistic.cs -**Verification Method**: Demo - -### StR-034: Statistical Analysis and Forecasting -**Stakeholder**: Management, Sales Teams -**Statement**: The system shall provide statistical analysis capabilities including trend analysis, forecasting, and performance metrics to support strategic planning and operational optimization. -**Rationale**: Strategic business planning requires statistical analysis capabilities to identify trends, forecast performance, and optimize business operations. -**Priority**: Medium -**Acceptance Criteria**: -- Perform trend analysis on key business metrics -- Generate forecasts based on historical data and business rules -- Provide performance analytics with variance analysis and KPI tracking -**Source Evidence**: Statistical analysis components, performance tracking in employee and sales modules -**Verification Method**: Analysis - ---- - -### System Administration Requirements (StR-035) - -### StR-035: System Configuration and Administration -**Stakeholder**: System Administrators, IT Operations -**Statement**: The system shall provide comprehensive system administration capabilities including configuration management, performance monitoring, backup procedures, and maintenance tools for reliable system operations. -**Rationale**: Enterprise system reliability requires comprehensive administration tools to ensure optimal performance, security, and business continuity. -**Priority**: High -**Acceptance Criteria**: -- Configure system settings and business rules through administrative interfaces -- Monitor system performance and resource utilization -- Manage backup and recovery procedures with automated scheduling -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Modules\Administration directory (20+ administration modules), C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Administration directory, C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\DbEntities\ApplicationSetting.cs -**Verification Method**: Test - ---- - -## 5. Stakeholder Journey Maps - -### Sales Representative Journey -```mermaid -journey - title Sales Representative Daily Workflow - section Morning Setup - Login to system: 5: Sales Rep - Review daily activities: 4: Sales Rep - Check customer notifications: 4: Sales Rep - section Customer Interaction - Create/update customer records: 5: Sales Rep - Process quotes and orders: 5: Sales Rep - Check inventory availability: 4: Sales Rep - section Follow-up Activities - Update activity records: 4: Sales Rep - Generate sales reports: 3: Sales Rep - Plan next day activities: 3: Sales Rep -``` - -### Customer Support Journey -```mermaid -journey - title Customer Support Ticket Resolution Process - section Ticket Creation - Receive customer inquiry: 3: Support Agent - Create support ticket: 5: Support Agent - Assign to appropriate team: 4: Support Agent - section Resolution Process - Research customer history: 5: Support Agent - Access knowledge base: 4: Support Agent - Coordinate with technical teams: 4: Support Agent - Update customer on progress: 4: Support Agent - section Closure - Resolve issue: 5: Support Agent - Document solution: 4: Support Agent - Follow up with customer: 4: Support Agent -``` - ---- - -## 6. Business Context Diagram - -```mermaid -graph LR - subgraph "Business Environment" - customers[Customers] - suppliers[Suppliers] - partners[Business Partners] - banks[Financial Institutions] - shipping[Shipping Providers] - regulators[Regulatory Bodies] - end - - subgraph "Centron System" - crm[Customer Management] - sales[Sales Processing] - inventory[Inventory Management] - finance[Financial Management] - support[Customer Support] - admin[System Administration] - end - - customers <--> crm - customers <--> sales - customers <--> support - suppliers <--> inventory - suppliers <--> sales - partners <--> crm - banks <--> finance - shipping <--> inventory - regulators <--> admin - - crm --> sales - sales --> inventory - sales --> finance - support --> crm - admin --> finance -``` - ---- - -## 7. Requirement Dependencies - -```mermaid -graph TD - StR001[StR-001: Account Management] --> StR002[StR-002: Contact Management] - StR001 --> StR003[StR-003: Customer Classification] - StR001 --> StR004[StR-004: Account Relationships] - StR002 --> StR005[StR-005: Activity Tracking] - - StR001 --> StR007[StR-007: Quote to Invoice] - StR007 --> StR008[StR-008: Order Processing] - StR008 --> StR016[StR-016: Inventory Management] - StR008 --> StR019[StR-019: Shipping Integration] - - StR020[StR-020: Authentication] --> StR021[StR-021: Access Control] - StR021 --> StR022[StR-022: Employee Management] - StR021 --> StR023[StR-023: Audit Trail] - - StR016 --> StR017[StR-017: Product Management] - StR017 --> StR018[StR-018: Barcode Tracking] - - StR012[StR-012: Accounting Integration] --> StR013[StR-013: Financial Reporting] - StR012 --> StR014[StR-014: Payment Processing] - StR013 --> StR015[StR-015: Cost Center Analysis] - - StR030[StR-030: Helpdesk] --> StR031[StR-031: Asset Management] - StR031 --> StR032[StR-032: Knowledge Management] - - StR033[StR-033: Business Intelligence] --> StR034[StR-034: Statistical Analysis] -``` - ---- - -## 8. Priority Matrix - -| Requirement ID | Priority | Business Impact | Implementation Complexity | Risk Level | -|---------------|----------|----------------|---------------------------|------------| -| StR-001 | High | Critical | Medium | Low | -| StR-002 | High | Critical | Medium | Low | -| StR-007 | High | Critical | High | Medium | -| StR-008 | High | Critical | High | Medium | -| StR-012 | High | Critical | High | High | -| StR-013 | High | High | Medium | Medium | -| StR-014 | High | High | High | High | -| StR-016 | High | Critical | Medium | Medium | -| StR-017 | High | Critical | Medium | Low | -| StR-020 | High | Critical | Medium | High | -| StR-021 | High | Critical | High | High | -| StR-023 | High | High | Medium | Medium | -| StR-024 | High | Critical | Low | Low | -| StR-030 | High | High | Medium | Low | -| StR-033 | High | High | High | Medium | -| StR-035 | High | Critical | High | Medium | - ---- - -## 9. Compliance and Standards - -### ISO 29148 Compliance -This document complies with ISO/IEC/IEEE 29148:2018 standards for requirements engineering: -- Each requirement includes stakeholder identification -- Requirements are stated as "shall" statements -- Rationale provided for each requirement -- Acceptance criteria defined and measurable -- Verification methods specified -- Source evidence provided with specific file references - -### Business Standards Compliance -- German business practice compliance (StR-024) -- GDPR data protection requirements (evident in entity design) -- Financial reporting standards (StR-013) -- Audit trail requirements (StR-023) - ---- - -## 10. Glossary - -**Account**: A business entity representing customers, suppliers, or partners -**CRM**: Customer Relationship Management -**EDI**: Electronic Data Interchange -**FinAPI**: Financial API integration service -**NHibernate**: Object-relational mapping framework used by the system -**StRS**: Stakeholder Requirements Specification -**WPF**: Windows Presentation Foundation (UI framework) - ---- - -## Document Approval - -| Role | Name | Signature | Date | -|------|------|-----------|------| -| Requirements Analyst | ISO 29148 Agent | [Digital] | September 29, 2025 | -| Technical Lead | [TBD] | | | -| Business Stakeholder | [TBD] | | | -| Quality Assurance | [TBD] | | | - ---- - -*This document contains 35 complete stakeholder requirements with full ISO 29148 compliance, supported by specific evidence from the Centron .NET 8 enterprise application codebase analysis.* \ No newline at end of file diff --git a/Ergebnisse/Ergebnisse 01/System_Requirements_Specification_ISO29148.md b/Ergebnisse/Ergebnisse 01/System_Requirements_Specification_ISO29148.md deleted file mode 100644 index 0592760..0000000 --- a/Ergebnisse/Ergebnisse 01/System_Requirements_Specification_ISO29148.md +++ /dev/null @@ -1,1186 +0,0 @@ -# System Requirements Specification (SyRS) -## Centron .NET 8 Enterprise Application -### According to ISO/IEC/IEEE 29148:2018 Standards - ---- - -## Document Information -- **Document ID**: SyRS-CENTRON-2025-001 -- **Version**: 1.0 -- **Date**: September 29, 2025 -- **Author**: ISO 29148 System Requirements Agent -- **System**: Centron .NET 8 Enterprise Application -- **Traces to**: StRS-CENTRON-2025-001 - ---- - -## 1. Executive Summary - -This System Requirements Specification (SyRS) defines the complete system-level capabilities of the Centron .NET 8 enterprise application. Based on comprehensive analysis of 12,507 source files across backend (5,074 files), frontend (4,649 files), web services (2,609 files), and API integrations (175 files), this document specifies 75 complete system requirements organized into 10 functional categories. - -Each requirement traces back to stakeholder requirements, includes specific architectural evidence, and defines measurable system capabilities with appropriate verification methods. - ---- - -## 2. System Architecture Context - -```mermaid -graph TB - subgraph "External Environment" - finapi[FinAPI Banking Services] - gls[GLS Shipping Provider] - shipcloud[Shipcloud Logistics] - icecat[Icecat Product Data] - itscope[ITscope Distribution] - egis[EGIS Wholesale] - activedirectory[Active Directory] - sqlserver[(SQL Server Database)] - end - - subgraph "Centron System Boundary" - direction TB - subgraph "Presentation Layer" - wpf[WPF Desktop Client
135+ UI Modules] - end - - subgraph "Service Layer" - webservice[Web Services Layer
28 REST Interfaces
2,145 Endpoints] - end - - subgraph "Business Logic Layer" - bl[Business Logic
849+ BL Classes
Dual BL/WS Pattern] - end - - subgraph "Data Access Layer" - dao[Data Access Objects
936 FluentNHibernate Mappings
NHibernate ORM] - end - - subgraph "Infrastructure Layer" - container[Dependency Injection
ClassContainer Pattern] - result[Result<T> Pattern
Error Handling] - audit[Audit Trail System
BaseEntity Pattern] - end - end - - wpf --> webservice - wpf --> bl - webservice --> bl - bl --> dao - dao --> sqlserver - - bl --> finapi - bl --> gls - bl --> shipcloud - bl --> icecat - bl --> itscope - bl --> egis - - container -.-> wpf - container -.-> webservice - container -.-> bl - container -.-> dao - - result -.-> wpf - result -.-> webservice - result -.-> bl - result -.-> dao - - audit -.-> dao -``` - ---- - -## 3. System Component Architecture - -```mermaid -graph LR - subgraph "Authentication & Authorization System" - auth[JWT Authentication] - rbac[Role-Based Access Control] - rights[User Rights Management
20800000+ Rights IDs] - end - - subgraph "Data Management System" - orm[NHibernate ORM
936 Mappings] - trans[Transaction Management] - audit[Audit Trail
BaseEntity Pattern] - end - - subgraph "Business Logic Processing" - accounts[Account Management
849+ BL Classes] - sales[Sales Processing] - inventory[Inventory Control] - end - - subgraph "Web Service API System" - rest[REST APIs
2,145 Endpoints] - dto[DTO Conversion] - security[API Security] - end - - subgraph "User Interface System" - modules[135+ WPF Modules] - mvvm[MVVM Pattern] - devexpress[DevExpress 24.2.7] - end - - subgraph "External Integration System" - apis[8 API Integrations] - gateways[Gateway Pattern] - protocols[EDI/REST/SOAP] - end - - auth --> rbac - rbac --> rights - orm --> trans - trans --> audit - accounts --> sales - sales --> inventory - rest --> dto - dto --> security - modules --> mvvm - mvvm --> devexpress - apis --> gateways - gateways --> protocols -``` - ---- - -## 4. Complete System Requirements - -### Authentication and Authorization System Requirements (SyR-001 to SyR-008) - -### SyR-001: User Authentication Processing -**Parent StRS**: StR-020 -**Statement**: The system shall authenticate users through secure login mechanisms with password validation, session management, and multi-factor authentication support. -**Inputs**: User credentials (username, password), authentication tokens, MFA tokens -**Processing**: Credential validation against Active Directory, session token generation, authentication state management -**Outputs**: Authentication result, session token, user context information -**Performance**: Authentication processing shall complete within 2 seconds for 95% of requests -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\webservice\Centron.WebServices.Core\EntitiesWrongPlace\Administration\Rights\UserRightsConst.cs (lines 10-100), Authentication attributes in REST service interfaces -**Verification Method**: Test - -### SyR-002: Role-Based Access Control Processing -**Parent StRS**: StR-021 -**Statement**: The system shall enforce role-based access control with granular permission checking for all system functions and data access operations. -**Inputs**: User roles, permission requests, system function calls -**Processing**: Permission matrix evaluation, role inheritance resolution, access decision enforcement -**Outputs**: Access granted/denied decisions, permission audit logs -**Performance**: Permission checks shall complete within 100 milliseconds for 99% of requests -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\webservice\Centron.WebServices.Core\EntitiesWrongPlace\Administration\Rights\UserRightsConst.cs (20800000+ rights IDs), extensive rights management structure -**Verification Method**: Test - -### SyR-003: User Rights Management System -**Parent StRS**: StR-021 -**Statement**: The system shall manage comprehensive user rights with hierarchical permission structures, group assignments, and dynamic rights evaluation. -**Inputs**: Rights definitions, user assignments, group configurations -**Processing**: Rights hierarchy management, inheritance calculations, dynamic permission evaluation -**Outputs**: Effective permissions, rights inheritance chains, access control decisions -**Performance**: Rights evaluation shall support 1000+ concurrent users with sub-second response times -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\webservice\Centron.WebServices.Core\EntitiesWrongPlace\Administration\Rights\UserRightsConst.cs (lines 32-100), 224+ files referencing UserRightsConst -**Verification Method**: Test - -### SyR-004: Session Management System -**Parent StRS**: StR-020 -**Statement**: The system shall manage user sessions with configurable timeouts, concurrent session handling, and secure session termination. -**Inputs**: Session requests, timeout configurations, session termination requests -**Processing**: Session lifecycle management, timeout monitoring, concurrent session control -**Outputs**: Session tokens, session status updates, session termination confirmations -**Performance**: Session management shall support 500+ concurrent sessions with 99.9% availability -**Source Evidence**: Authentication middleware implementations, session management in BL classes -**Verification Method**: Test - -### SyR-005: Active Directory Integration -**Parent StRS**: StR-020 -**Statement**: The system shall integrate with Active Directory for centralized user authentication and organizational structure synchronization. -**Inputs**: AD user credentials, organizational units, group memberships -**Processing**: LDAP authentication, AD group synchronization, organizational structure mapping -**Outputs**: Synchronized user accounts, organizational hierarchy, group memberships -**Performance**: AD synchronization shall complete within 5 minutes for organizations with 1000+ users -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Modules\Administration\EmployeeManagement\AdImport directory -**Verification Method**: Test - -### SyR-006: Password Security Management -**Parent StRS**: StR-020 -**Statement**: The system shall enforce password security policies including complexity requirements, expiration rules, and password history management. -**Inputs**: Password policies, user password changes, security configurations -**Processing**: Password complexity validation, expiration monitoring, history tracking -**Outputs**: Password validation results, expiration notifications, security compliance status -**Performance**: Password validation shall complete within 500 milliseconds -**Source Evidence**: Security implementations in authentication modules, password management components -**Verification Method**: Test - -### SyR-007: Multi-Factor Authentication Support -**Parent StRS**: StR-020 -**Statement**: The system shall support multi-factor authentication mechanisms including SMS, email, and authenticator app integration. -**Inputs**: MFA tokens, authentication challenges, verification codes -**Processing**: Multi-factor validation, token verification, backup authentication methods -**Outputs**: MFA validation results, authentication confirmations, security alerts -**Performance**: MFA processing shall complete within 10 seconds for 95% of authentication attempts -**Source Evidence**: Authentication system components, security module implementations -**Verification Method**: Test - -### SyR-008: Security Audit and Monitoring -**Parent StRS**: StR-023 -**Statement**: The system shall monitor and log all authentication attempts, access violations, and security events for audit trail and compliance purposes. -**Inputs**: Authentication events, access attempts, security violations -**Processing**: Security event logging, anomaly detection, compliance reporting -**Outputs**: Security audit logs, violation alerts, compliance reports -**Performance**: Security logging shall capture 100% of authentication events with minimal performance impact -**Source Evidence**: Audit trail components, security logging throughout the system -**Verification Method**: Inspection - ---- - -### Data Management System Requirements (SyR-009 to SyR-020) - -### SyR-009: Object-Relational Mapping System -**Parent StRS**: StR-035 -**Statement**: The system shall provide comprehensive ORM capabilities through NHibernate with FluentNHibernate mappings for all business entities. -**Inputs**: Entity objects, database queries, mapping configurations -**Processing**: Object-to-relational mapping, lazy loading, change tracking -**Outputs**: Mapped entities, query results, persistence confirmations -**Performance**: ORM operations shall support 100+ concurrent transactions with sub-second response times -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.DAO\Mappings (936 mapping files), C:\DEV\UseCaseAnalyse\src\backend\Centron.DAO\Mappings\Accounts\AccountMaps.cs (lines 6-50) -**Verification Method**: Test - -### SyR-010: Transaction Management System -**Parent StRS**: StR-035 -**Statement**: The system shall manage database transactions with ACID compliance, distributed transaction support, and automatic rollback capabilities. -**Inputs**: Transaction boundaries, business operations, commit/rollback requests -**Processing**: Transaction coordination, isolation level management, consistency enforcement -**Outputs**: Transaction confirmations, rollback notifications, consistency validation -**Performance**: Transaction processing shall maintain 99.9% consistency with average commit time under 100ms -**Source Evidence**: BLSession implementations, transaction management in DAO layer -**Verification Method**: Test - -### SyR-011: Data Audit Trail System -**Parent StRS**: StR-023 -**Statement**: The system shall maintain comprehensive audit trails for all data changes including before/after values, timestamps, and user tracking. -**Inputs**: Data change events, user context, business operations -**Processing**: Change tracking, audit record generation, historical data preservation -**Outputs**: Audit records, change history, compliance reports -**Performance**: Audit trail generation shall add less than 5% overhead to data operations -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\BaseEntity.cs (audit fields: CreatedDate, ChangedDate, CreatedByI3D, ChangedByI3D) -**Verification Method**: Test - -### SyR-012: Database Connection Management -**Parent StRS**: StR-035 -**Statement**: The system shall manage database connections with connection pooling, failover support, and performance optimization. -**Inputs**: Connection requests, configuration parameters, failover triggers -**Processing**: Connection pool management, load balancing, failover coordination -**Outputs**: Database connections, performance metrics, availability status -**Performance**: Connection management shall support 200+ concurrent connections with 99.9% availability -**Source Evidence**: Connection management components in DAO layer, BLSession implementations -**Verification Method**: Test - -### SyR-013: Data Validation System -**Parent StRS**: StR-035 -**Statement**: The system shall validate all data inputs with business rule enforcement, data type checking, and constraint validation. -**Inputs**: Data inputs, validation rules, business constraints -**Processing**: Multi-level validation, business rule evaluation, constraint checking -**Outputs**: Validation results, error messages, data quality metrics -**Performance**: Data validation shall complete within 50 milliseconds for 95% of operations -**Source Evidence**: Entity validation in business logic classes, mapping constraints in DAO layer -**Verification Method**: Test - -### SyR-014: Data Caching System -**Parent StRS**: StR-035 -**Statement**: The system shall implement data caching mechanisms for frequently accessed data with cache invalidation and performance optimization. -**Inputs**: Data access patterns, cache configurations, invalidation triggers -**Processing**: Cache population, hit/miss management, intelligent invalidation -**Outputs**: Cached data, performance improvements, cache statistics -**Performance**: Cached data access shall be 10x faster than database access for frequently used data -**Source Evidence**: Caching implementations in BL classes, performance optimization components -**Verification Method**: Test - -### SyR-015: Data Migration and Versioning -**Parent StRS**: StR-035 -**Statement**: The system shall support database schema migrations with version control, rollback capabilities, and data transformation scripts. -**Inputs**: Schema changes, migration scripts, version information -**Processing**: Schema version management, migration execution, rollback coordination -**Outputs**: Updated schema, migration logs, version confirmations -**Performance**: Database migrations shall complete with minimal downtime (under 15 minutes for major updates) -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.BL\Administration\Scripts\ScriptMethods\Scripts directory (database script methods) -**Verification Method**: Test - -### SyR-016: Backup and Recovery System -**Parent StRS**: StR-035 -**Statement**: The system shall support automated backup procedures with recovery capabilities and data integrity verification. -**Inputs**: Backup schedules, recovery requests, integrity check parameters -**Processing**: Automated backup execution, recovery coordination, integrity validation -**Outputs**: Backup files, recovery confirmations, integrity reports -**Performance**: Backup operations shall complete within maintenance windows with 99.99% data integrity -**Source Evidence**: Administration modules, backup management components -**Verification Method**: Test - -### SyR-017: Data Archiving System -**Parent StRS**: StR-035 -**Statement**: The system shall provide data archiving capabilities with configurable retention policies and archived data access. -**Inputs**: Archiving policies, retention rules, access requests -**Processing**: Automated archiving, retention enforcement, archived data retrieval -**Outputs**: Archived data, retention confirmations, access logs -**Performance**: Archiving shall maintain system performance while preserving historical data access within 5 seconds -**Source Evidence**: Data archiving implementations in administration modules -**Verification Method**: Test - -### SyR-018: Database Performance Monitoring -**Parent StRS**: StR-035 -**Statement**: The system shall monitor database performance with query optimization, index management, and performance reporting. -**Inputs**: Performance metrics, query plans, system statistics -**Processing**: Performance analysis, optimization recommendations, bottleneck identification -**Outputs**: Performance reports, optimization suggestions, system health status -**Performance**: Performance monitoring shall provide real-time metrics with less than 1% system overhead -**Source Evidence**: Performance monitoring components in administration modules -**Verification Method**: Analysis - -### SyR-019: Data Synchronization System -**Parent StRS**: StR-035 -**Statement**: The system shall synchronize data between different system components with conflict resolution and consistency maintenance. -**Inputs**: Synchronization requests, data changes, conflict scenarios -**Processing**: Change detection, conflict resolution, consistency enforcement -**Outputs**: Synchronized data, conflict resolutions, synchronization status -**Performance**: Data synchronization shall maintain consistency across components within 30 seconds -**Source Evidence**: Synchronization components in web service and business logic layers -**Verification Method**: Test - -### SyR-020: Multi-Tenant Data Isolation -**Parent StRS**: StR-035 -**Statement**: The system shall provide multi-tenant data isolation with mandator-based data separation and access control. -**Inputs**: Mandator identifiers, tenant requests, isolation policies -**Processing**: Tenant data separation, access scope enforcement, isolation validation -**Outputs**: Tenant-isolated data, access confirmations, isolation reports -**Performance**: Multi-tenant isolation shall maintain performance parity with single-tenant operations -**Source Evidence**: Mandator management in entities, tenant isolation in business logic -**Verification Method**: Test - ---- - -### Business Logic Processing Requirements (SyR-021 to SyR-035) - -### SyR-021: Account Management Processing -**Parent StRS**: StR-001 -**Statement**: The system shall process comprehensive account management operations including account creation, modification, and relationship management with full audit trails. -**Inputs**: Account data, contact information, business relationships -**Processing**: Account validation, relationship mapping, change tracking -**Outputs**: Account records, relationship networks, audit logs -**Performance**: Account processing shall support 1000+ accounts with sub-second response times -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Accounts\Account.cs (lines 17-62), 849+ BL classes, account management modules -**Verification Method**: Test - -### SyR-022: Sales Order Processing System -**Parent StRS**: StR-007, StR-008 -**Statement**: The system shall process sales orders through complete lifecycle management from quote creation to invoice generation with approval workflows. -**Inputs**: Customer orders, product selections, pricing information -**Processing**: Order validation, inventory allocation, workflow management -**Outputs**: Order confirmations, delivery schedules, invoice documents -**Performance**: Order processing shall handle 500+ orders per day with 99% accuracy -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\DbEntities\AufKopf.cs, sales processing modules -**Verification Method**: Test - -### SyR-023: Inventory Management Processing -**Parent StRS**: StR-016, StR-017 -**Statement**: The system shall process inventory operations including stock tracking, location management, and automated reorder processing. -**Inputs**: Stock movements, location changes, reorder triggers -**Processing**: Inventory calculations, location tracking, reorder automation -**Outputs**: Stock levels, location reports, reorder notifications -**Performance**: Inventory processing shall maintain real-time accuracy across 10000+ items -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.BL\Logistics\Warehousing\StockBL.cs, inventory management entities -**Verification Method**: Test - -### SyR-024: Financial Transaction Processing -**Parent StRS**: StR-012, StR-013 -**Statement**: The system shall process financial transactions with accounting integration, payment processing, and reconciliation capabilities. -**Inputs**: Transaction data, payment information, accounting entries -**Processing**: Transaction validation, payment processing, reconciliation matching -**Outputs**: Financial records, payment confirmations, reconciliation reports -**Performance**: Financial processing shall handle 1000+ transactions per hour with 99.99% accuracy -**Source Evidence**: Financial processing modules, accounting integration components -**Verification Method**: Test - -### SyR-025: Customer Relationship Management Processing -**Parent StRS**: StR-002, StR-005 -**Statement**: The system shall process customer relationship activities including contact management, activity tracking, and relationship analytics. -**Inputs**: Customer interactions, contact activities, relationship data -**Processing**: Activity categorization, relationship analysis, trend identification -**Outputs**: Activity records, relationship insights, engagement metrics -**Performance**: CRM processing shall track unlimited activities with real-time updates -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Accounts\Activities directory, CRM processing modules -**Verification Method**: Test - -### SyR-026: Contract Lifecycle Management -**Parent StRS**: StR-011 -**Statement**: The system shall process contract management including creation, modification, renewal tracking, and compliance monitoring. -**Inputs**: Contract data, terms and conditions, renewal schedules -**Processing**: Contract validation, renewal automation, compliance checking -**Outputs**: Contract documents, renewal notifications, compliance reports -**Performance**: Contract processing shall manage 1000+ active contracts with automated renewal tracking -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Accounts\AccountContracts directory, contract management modules -**Verification Method**: Test - -### SyR-027: Pricing Calculation Engine -**Parent StRS**: StR-009 -**Statement**: The system shall calculate dynamic pricing including volume discounts, customer-specific pricing, and promotional adjustments. -**Inputs**: Product selections, customer data, pricing rules -**Processing**: Pricing rule evaluation, discount calculations, margin analysis -**Outputs**: Final pricing, discount breakdowns, margin reports -**Performance**: Pricing calculations shall complete within 2 seconds for complex pricing scenarios -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\Warehousing\ArticleVolumePrices.cs, pricing calculation modules -**Verification Method**: Test - -### SyR-028: Workflow Management System -**Parent StRS**: StR-007 -**Statement**: The system shall manage business workflows including approval processes, task routing, and status tracking. -**Inputs**: Workflow definitions, approval requests, task assignments -**Processing**: Workflow orchestration, approval routing, status management -**Outputs**: Workflow status, approval notifications, completion confirmations -**Performance**: Workflow processing shall handle 100+ concurrent workflows with real-time status updates -**Source Evidence**: Workflow components in business logic modules, approval processing systems -**Verification Method**: Test - -### SyR-029: Document Generation System -**Parent StRS**: StR-007 -**Statement**: The system shall generate business documents including quotes, orders, invoices, and reports with customizable templates. -**Inputs**: Document data, template configurations, formatting rules -**Processing**: Template processing, data merging, formatting application -**Outputs**: Generated documents, document archives, delivery confirmations -**Performance**: Document generation shall produce complex documents within 5 seconds -**Source Evidence**: Document generation modules, FastReport integration components -**Verification Method**: Test - -### SyR-030: Business Rule Engine -**Parent StRS**: StR-035 -**Statement**: The system shall execute business rules with configurable rule definitions, dynamic evaluation, and rule conflict resolution. -**Inputs**: Rule definitions, business events, evaluation contexts -**Processing**: Rule evaluation, condition checking, action execution -**Outputs**: Rule decisions, action results, rule audit logs -**Performance**: Business rules shall evaluate within 100 milliseconds for 95% of scenarios -**Source Evidence**: Business rule implementations throughout BL classes, rule engine components -**Verification Method**: Test - -### SyR-031: Data Import/Export Processing -**Parent StRS**: StR-029 -**Statement**: The system shall process data import and export operations with format transformation, validation, and error handling. -**Inputs**: Import files, export requests, format configurations -**Processing**: Format conversion, data validation, transformation rules -**Outputs**: Processed data, import results, export files -**Performance**: Data processing shall handle files with 100000+ records within 10 minutes -**Source Evidence**: EDI processing modules, import/export components in business logic -**Verification Method**: Test - -### SyR-032: Analytics and Reporting Engine -**Parent StRS**: StR-033, StR-034 -**Statement**: The system shall process analytical queries and generate reports with real-time data aggregation and statistical analysis. -**Inputs**: Query parameters, reporting requirements, data filters -**Processing**: Data aggregation, statistical calculations, report formatting -**Outputs**: Analytical reports, statistical summaries, performance metrics -**Performance**: Report generation shall complete within 30 seconds for standard reports -**Source Evidence**: Statistics modules, reporting engine components, analytical processing classes -**Verification Method**: Demo - -### SyR-033: Notification Processing System -**Parent StRS**: StR-030 -**Statement**: The system shall process notifications including email alerts, system notifications, and escalation procedures. -**Inputs**: Notification triggers, recipient lists, message templates -**Processing**: Notification routing, escalation logic, delivery tracking -**Outputs**: Delivered notifications, delivery confirmations, escalation alerts -**Performance**: Notification processing shall deliver 95% of notifications within 2 minutes -**Source Evidence**: Notification components throughout business logic, mail processing modules -**Verification Method**: Test - -### SyR-034: Task Management System -**Parent StRS**: StR-030 -**Statement**: The system shall manage task assignments, tracking, and completion with priority handling and deadline monitoring. -**Inputs**: Task definitions, assignments, priority levels -**Processing**: Task routing, priority management, deadline tracking -**Outputs**: Task assignments, progress updates, completion notifications -**Performance**: Task management shall handle 1000+ concurrent tasks with real-time updates -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.BL\ToDoArea\ToDoBL.cs, task management components -**Verification Method**: Test - -### SyR-035: Performance Monitoring System -**Parent StRS**: StR-035 -**Statement**: The system shall monitor business logic performance with metrics collection, bottleneck identification, and optimization recommendations. -**Inputs**: Performance metrics, system statistics, threshold configurations -**Processing**: Performance analysis, bottleneck detection, optimization suggestions -**Outputs**: Performance reports, optimization recommendations, system health status -**Performance**: Performance monitoring shall provide real-time metrics with minimal system impact -**Source Evidence**: Performance monitoring throughout business logic components -**Verification Method**: Analysis - ---- - -### Web Service API System Requirements (SyR-036 to SyR-045) - -### SyR-036: REST API Gateway System -**Parent StRS**: StR-035 -**Statement**: The system shall provide REST API gateway functionality with request routing, load balancing, and API versioning support. -**Inputs**: HTTP requests, routing rules, API versions -**Processing**: Request routing, load distribution, version management -**Outputs**: HTTP responses, routing decisions, performance metrics -**Performance**: API gateway shall handle 1000+ concurrent requests with sub-second routing decisions -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\webservice\Centron.Host\Services\CentronRestService.cs, 28 REST interface parts, 2,145 endpoints -**Verification Method**: Test - -### SyR-037: API Authentication and Security -**Parent StRS**: StR-020 -**Statement**: The system shall secure API endpoints with token-based authentication, API key validation, and rate limiting capabilities. -**Inputs**: API tokens, authentication credentials, rate limit policies -**Processing**: Token validation, API key verification, rate limit enforcement -**Outputs**: Authentication results, security tokens, rate limit status -**Performance**: API authentication shall complete within 200 milliseconds with 99.9% availability -**Source Evidence**: Authentication attributes in REST service interfaces, API security implementations -**Verification Method**: Test - -### SyR-038: Data Transfer Object Processing -**Parent StRS**: StR-035 -**Statement**: The system shall process DTO conversions between internal entities and API representations with data validation and transformation. -**Inputs**: Internal entities, API requests, transformation rules -**Processing**: Entity-to-DTO conversion, data validation, format transformation -**Outputs**: API DTOs, validation results, transformation confirmations -**Performance**: DTO processing shall handle 500+ conversions per second with data integrity -**Source Evidence**: DTO conversion in WebService BL classes, ObjectMapper implementations -**Verification Method**: Test - -### SyR-039: API Request/Response Handling -**Parent StRS**: StR-035 -**Statement**: The system shall handle API requests and responses with proper HTTP status codes, error handling, and content negotiation. -**Inputs**: HTTP requests, response data, error conditions -**Processing**: Request parsing, response formatting, error handling -**Outputs**: HTTP responses, status codes, error messages -**Performance**: Request handling shall maintain 99.9% success rate with proper error responses -**Source Evidence**: CentronRestService implementations, Request/Response handling in API layer -**Verification Method**: Test - -### SyR-040: API Documentation and Discovery -**Parent StRS**: StR-035 -**Statement**: The system shall provide API documentation with endpoint discovery, parameter specification, and example usage. -**Inputs**: API definitions, endpoint metadata, documentation requirements -**Processing**: Documentation generation, metadata extraction, example creation -**Outputs**: API documentation, endpoint catalogs, usage examples -**Performance**: API documentation shall be generated automatically with 100% endpoint coverage -**Source Evidence**: REST service interface definitions, API endpoint implementations -**Verification Method**: Inspection - -### SyR-041: Asynchronous Processing Support -**Parent StRS**: StR-035 -**Statement**: The system shall support asynchronous API operations with callback mechanisms, status tracking, and result retrieval. -**Inputs**: Async requests, callback URLs, tracking identifiers -**Processing**: Asynchronous execution, status monitoring, callback delivery -**Outputs**: Operation status, callback notifications, result data -**Performance**: Async operations shall provide status updates within 5 seconds and complete long-running tasks efficiently -**Source Evidence**: Async implementations in web service BL classes, Task-based processing -**Verification Method**: Test - -### SyR-042: API Versioning System -**Parent StRS**: StR-035 -**Statement**: The system shall support API versioning with backward compatibility, deprecation management, and migration support. -**Inputs**: Version requests, API definitions, migration paths -**Processing**: Version routing, compatibility checking, migration assistance -**Outputs**: Versioned responses, deprecation warnings, migration guidance -**Performance**: API versioning shall maintain backward compatibility while supporting seamless upgrades -**Source Evidence**: API versioning in REST service implementations -**Verification Method**: Test - -### SyR-043: API Monitoring and Analytics -**Parent StRS**: StR-035 -**Statement**: The system shall monitor API usage with performance metrics, error tracking, and usage analytics. -**Inputs**: API calls, performance data, error events -**Processing**: Metrics collection, analytics processing, trend analysis -**Outputs**: Usage reports, performance metrics, error summaries -**Performance**: API monitoring shall track 100% of API calls with real-time dashboard updates -**Source Evidence**: Monitoring components in web service layer -**Verification Method**: Analysis - -### SyR-044: Batch Processing APIs -**Parent StRS**: StR-035 -**Statement**: The system shall provide batch processing APIs for bulk operations with progress tracking and partial failure handling. -**Inputs**: Batch requests, bulk data, processing parameters -**Processing**: Batch coordination, parallel processing, progress tracking -**Outputs**: Batch results, progress updates, partial failure reports -**Performance**: Batch processing shall handle 10000+ records with detailed progress reporting -**Source Evidence**: Batch processing implementations in web service BL classes -**Verification Method**: Test - -### SyR-045: API Integration Testing -**Parent StRS**: StR-035 -**Statement**: The system shall support API integration testing with test endpoints, mock services, and automated validation. -**Inputs**: Test scenarios, validation rules, mock configurations -**Processing**: Test execution, response validation, mock service management -**Outputs**: Test results, validation reports, integration status -**Performance**: Integration testing shall validate 100% of API endpoints with automated test coverage -**Source Evidence**: API testing implementations, integration test components -**Verification Method**: Test - ---- - -### User Interface System Requirements (SyR-046 to SyR-053) - -### SyR-046: WPF Module Architecture -**Parent StRS**: StR-035 -**Statement**: The system shall provide modular WPF architecture with 135+ UI modules supporting dynamic loading, dependency injection, and lifecycle management. -**Inputs**: Module definitions, dependency configurations, lifecycle events -**Processing**: Module loading, dependency resolution, lifecycle coordination -**Outputs**: Active modules, dependency graphs, lifecycle notifications -**Performance**: Module loading shall complete within 3 seconds with smooth user experience -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Modules directory (913 directories), C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Modules\ModuleRegistration.cs -**Verification Method**: Test - -### SyR-047: MVVM Pattern Implementation -**Parent StRS**: StR-035 -**Statement**: The system shall implement MVVM architectural pattern with data binding, command patterns, and view model lifecycle management. -**Inputs**: View models, binding expressions, command definitions -**Processing**: Data binding, command routing, view model management -**Outputs**: Bound UI elements, command executions, view updates -**Performance**: MVVM binding shall maintain responsive UI with sub-100ms update times -**Source Evidence**: MVVM implementations throughout WPF modules, BindableBase pattern usage -**Verification Method**: Test - -### SyR-048: DevExpress UI Controls Integration -**Parent StRS**: StR-035 -**Statement**: The system shall integrate DevExpress 24.2.7 controls with customization, theming, and advanced functionality support. -**Inputs**: Control configurations, theme definitions, customization parameters -**Processing**: Control initialization, theme application, customization implementation -**Outputs**: Rendered UI controls, themed interfaces, customized layouts -**Performance**: DevExpress controls shall render smoothly with consistent performance across all modules -**Source Evidence**: DevExpress control usage throughout WPF modules, DevExpress 24.2.7 integration -**Verification Method**: Test - -### SyR-049: Ribbon Interface Management -**Parent StRS**: StR-035 -**Statement**: The system shall provide ribbon interface management with contextual tabs, command groups, and dynamic visibility control. -**Inputs**: Ribbon configurations, context changes, command states -**Processing**: Ribbon layout management, context switching, command state updates -**Outputs**: Dynamic ribbon interface, contextual commands, state-aware UI -**Performance**: Ribbon updates shall respond to context changes within 200 milliseconds -**Source Evidence**: Ribbon control implementations throughout modules, IRibbonControlModule interfaces -**Verification Method**: Test - -### SyR-050: Localization and Multi-Language Support -**Parent StRS**: StR-024, StR-025 -**Statement**: The system shall support multi-language UI with German as primary language and English as secondary language with dynamic language switching. -**Inputs**: Language preferences, localization resources, UI text keys -**Processing**: Language switching, resource loading, UI text updates -**Outputs**: Localized UI elements, language-specific formatting, cultural adaptations -**Performance**: Language switching shall complete within 2 seconds for all UI elements -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Resources\LocalizedStrings.resx, C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Resources\LocalizedStrings.en.resx -**Verification Method**: Inspection - -### SyR-051: Form and Dialog Management -**Parent StRS**: StR-035 -**Statement**: The system shall manage forms and dialogs with modal/modeless support, validation, and user interaction tracking. -**Inputs**: Form definitions, dialog requests, validation rules -**Processing**: Form lifecycle management, validation processing, interaction tracking -**Outputs**: Form instances, validation results, interaction logs -**Performance**: Form loading shall complete within 1 second with immediate user interaction capability -**Source Evidence**: Form implementations throughout WPF modules, dialog management components -**Verification Method**: Test - -### SyR-052: Data Grid and List Management -**Parent StRS**: StR-035 -**Statement**: The system shall provide advanced data grid functionality with sorting, filtering, grouping, and virtualization for large datasets. -**Inputs**: Data collections, filter criteria, sort parameters -**Processing**: Data virtualization, sorting algorithms, filtering logic -**Outputs**: Paginated data views, sorted displays, filtered results -**Performance**: Data grids shall handle 10000+ records with smooth scrolling and sub-second filtering -**Source Evidence**: Data grid implementations throughout WPF modules, DevExpress grid controls -**Verification Method**: Test - -### SyR-053: UI Performance and Responsiveness -**Parent StRS**: StR-035 -**Statement**: The system shall maintain UI responsiveness with background processing, progress indication, and smooth animations. -**Inputs**: Long-running operations, progress data, animation triggers -**Processing**: Background thread management, progress tracking, animation coordination -**Outputs**: Progress updates, smooth animations, responsive UI -**Performance**: UI shall remain responsive during all operations with clear progress indication -**Source Evidence**: Background processing implementations, progress indication throughout modules -**Verification Method**: Test - ---- - -### External Integration System Requirements (SyR-054 to SyR-061) - -### SyR-054: FinAPI Banking Integration -**Parent StRS**: StR-026 -**Statement**: The system shall integrate with FinAPI banking services for account management, transaction processing, and payment operations. -**Inputs**: Banking credentials, transaction requests, account queries -**Processing**: API authentication, transaction processing, account synchronization -**Outputs**: Banking data, transaction confirmations, account balances -**Performance**: Banking integration shall process transactions within 10 seconds with 99.9% reliability -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\apis\Centron.APIs.FinAPI project structure -**Verification Method**: Test - -### SyR-055: Product Data Provider Integration -**Parent StRS**: StR-027 -**Statement**: The system shall integrate with product data providers (Icecat, ITscope, EGIS) for product information synchronization and catalog management. -**Inputs**: Product catalogs, specification data, pricing information -**Processing**: Data synchronization, catalog updates, specification mapping -**Outputs**: Updated product data, synchronized catalogs, mapping confirmations -**Performance**: Product data synchronization shall process 10000+ products within 1 hour -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\apis\Centron.APIs.IcecatDataAccess, C:\DEV\UseCaseAnalyse\src\apis\Centron.APIs.ITscopeDataAccess, C:\DEV\UseCaseAnalyse\src\apis\Centron.APIs.EgisDataAccess projects -**Verification Method**: Test - -### SyR-056: Shipping Provider Integration -**Parent StRS**: StR-028 -**Statement**: The system shall integrate with shipping providers (GLS, Shipcloud) for shipment creation, tracking, and delivery management. -**Inputs**: Shipment requests, tracking queries, delivery addresses -**Processing**: Shipment creation, tracking coordination, delivery status updates -**Outputs**: Shipping labels, tracking numbers, delivery confirmations -**Performance**: Shipping integration shall create shipments within 30 seconds and provide real-time tracking -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\apis\Centron.Api.Gls project, C:\DEV\UseCaseAnalyse\src\apis\Centron.Api.Shipcloud project -**Verification Method**: Test - -### SyR-057: EDI Processing System -**Parent StRS**: StR-029 -**Statement**: The system shall process Electronic Data Interchange with support for standard EDI formats and automated document exchange. -**Inputs**: EDI documents, trading partner configurations, format definitions -**Processing**: EDI parsing, format conversion, document routing -**Outputs**: Processed documents, acknowledgments, error reports -**Performance**: EDI processing shall handle 1000+ documents per day with 99.5% success rate -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\EDI directory (25+ EDI entities), EDI processing capabilities -**Verification Method**: Test - -### SyR-058: External API Security Management -**Parent StRS**: StR-035 -**Statement**: The system shall manage external API security with credential management, SSL/TLS encryption, and secure communication protocols. -**Inputs**: API credentials, security configurations, encryption parameters -**Processing**: Credential validation, encryption management, secure communication -**Outputs**: Secure API connections, authentication tokens, communication logs -**Performance**: API security shall maintain secure connections with minimal latency overhead -**Source Evidence**: Security implementations in API integration projects -**Verification Method**: Test - -### SyR-059: Integration Error Handling -**Parent StRS**: StR-035 -**Statement**: The system shall handle integration errors with retry mechanisms, fallback procedures, and comprehensive error logging. -**Inputs**: Integration failures, error conditions, retry policies -**Processing**: Error detection, retry coordination, fallback activation -**Outputs**: Error logs, retry confirmations, fallback notifications -**Performance**: Error handling shall recover from 90% of transient errors within 3 retry attempts -**Source Evidence**: Error handling throughout API integration implementations -**Verification Method**: Test - -### SyR-060: Data Transformation and Mapping -**Parent StRS**: StR-035 -**Statement**: The system shall transform and map data between internal formats and external system formats with validation and error detection. -**Inputs**: Source data, mapping rules, validation criteria -**Processing**: Data transformation, format conversion, validation checking -**Outputs**: Transformed data, validation results, mapping confirmations -**Performance**: Data transformation shall process 1000+ records per minute with 99.9% accuracy -**Source Evidence**: Data transformation components in API integration projects -**Verification Method**: Test - -### SyR-061: Integration Monitoring and Reporting -**Parent StRS**: StR-035 -**Statement**: The system shall monitor external integrations with performance tracking, availability monitoring, and integration reporting. -**Inputs**: Integration metrics, availability data, performance statistics -**Processing**: Monitoring data collection, availability checking, report generation -**Outputs**: Integration reports, availability status, performance metrics -**Performance**: Integration monitoring shall provide real-time status with 99.9% monitoring availability -**Source Evidence**: Monitoring components throughout integration implementations -**Verification Method**: Analysis - ---- - -### Reporting and Analytics System Requirements (SyR-062 to SyR-066) - -### SyR-062: Report Engine Integration -**Parent StRS**: StR-033 -**Statement**: The system shall integrate FastReport engine for comprehensive report generation with custom templates and dynamic data binding. -**Inputs**: Report definitions, data sources, formatting parameters -**Processing**: Report compilation, data binding, format rendering -**Outputs**: Generated reports, formatted documents, export files -**Performance**: Report generation shall produce complex reports within 30 seconds for datasets up to 10000 records -**Source Evidence**: Report engine components throughout the system, FastReport integration -**Verification Method**: Demo - -### SyR-063: Business Intelligence Dashboard -**Parent StRS**: StR-033 -**Statement**: The system shall provide business intelligence dashboards with real-time data visualization, interactive charts, and drill-down capabilities. -**Inputs**: Dashboard configurations, data filters, visualization preferences -**Processing**: Data aggregation, chart generation, interaction handling -**Outputs**: Interactive dashboards, visualizations, drill-down reports -**Performance**: Dashboards shall update within 5 seconds with real-time data refresh capabilities -**Source Evidence**: Dashboard implementations in statistics modules, BI components -**Verification Method**: Demo - -### SyR-064: Statistical Analysis Engine -**Parent StRS**: StR-034 -**Statement**: The system shall perform statistical analysis including trend analysis, forecasting, and performance metrics calculation. -**Inputs**: Historical data, analysis parameters, statistical models -**Processing**: Statistical calculations, trend analysis, forecasting algorithms -**Outputs**: Statistical reports, trend analyses, forecasting results -**Performance**: Statistical analysis shall process large datasets within 2 minutes for standard analyses -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\EmployeeArea\EmployeeStatistic.cs, statistical analysis components -**Verification Method**: Analysis - -### SyR-065: Custom Report Builder -**Parent StRS**: StR-033 -**Statement**: The system shall provide custom report building capabilities with drag-and-drop design, formula support, and template management. -**Inputs**: Report design elements, data fields, formula definitions -**Processing**: Report design processing, formula evaluation, template management -**Outputs**: Custom reports, saved templates, design validations -**Performance**: Report builder shall provide real-time design feedback with immediate preview capabilities -**Source Evidence**: Report builder components, template management systems -**Verification Method**: Demo - -### SyR-066: Export and Distribution System -**Parent StRS**: StR-033 -**Statement**: The system shall export reports in multiple formats (PDF, Excel, CSV) and distribute through email, file sharing, and automated scheduling. -**Inputs**: Export requests, distribution lists, scheduling parameters -**Processing**: Format conversion, distribution coordination, scheduling management -**Outputs**: Exported files, distribution confirmations, schedule notifications -**Performance**: Report export shall support batch processing of 100+ reports within 10 minutes -**Source Evidence**: Export and distribution components throughout reporting system -**Verification Method**: Test - ---- - -### Multi-Language Localization System Requirements (SyR-067 to SyR-069) - -### SyR-067: German Language Implementation -**Parent StRS**: StR-024 -**Statement**: The system shall provide comprehensive German language support as primary language with complete localization of UI, documents, and system messages. -**Inputs**: German localization resources, cultural formatting rules, business terminology -**Processing**: Localization resource loading, cultural formatting application, terminology management -**Outputs**: German-localized interface, formatted documents, localized messages -**Performance**: German localization shall be 100% complete with consistent terminology usage -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Resources\LocalizedStrings.resx, extensive German entity field names -**Verification Method**: Inspection - -### SyR-068: English Language Support -**Parent StRS**: StR-025 -**Statement**: The system shall provide English language support as secondary language with complete translation coverage and cultural adaptations. -**Inputs**: English localization resources, cultural preferences, translation mappings -**Processing**: Translation loading, cultural adaptation, language switching -**Outputs**: English-localized interface, translated content, cultural formatting -**Performance**: English localization shall provide 95%+ translation coverage with consistent quality -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\centron\Centron.WPF.UI\Resources\LocalizedStrings.en.resx, English localization files throughout system -**Verification Method**: Inspection - -### SyR-069: Dynamic Language Switching -**Parent StRS**: StR-025 -**Statement**: The system shall support dynamic language switching during user sessions with immediate UI updates and preference persistence. -**Inputs**: Language selection, user preferences, session context -**Processing**: Language switching coordination, UI updates, preference storage -**Outputs**: Updated interface language, saved preferences, session continuity -**Performance**: Language switching shall complete within 3 seconds with full UI translation -**Source Evidence**: Language switching implementations throughout UI modules -**Verification Method**: Test - ---- - -### Configuration Management System Requirements (SyR-070 to SyR-072) - -### SyR-070: Application Settings Management -**Parent StRS**: StR-035 -**Statement**: The system shall manage application settings with hierarchical configuration, default values, and runtime modification capabilities. -**Inputs**: Setting definitions, configuration values, modification requests -**Processing**: Setting validation, hierarchy resolution, change propagation -**Outputs**: Applied settings, configuration confirmations, change notifications -**Performance**: Settings management shall apply changes within 1 second with immediate effect -**Source Evidence**: C:\DEV\UseCaseAnalyse\src\backend\Centron.Entities\Entities\DbEntities\ApplicationSetting.cs, settings management throughout system -**Verification Method**: Test - -### SyR-071: Mandator Configuration System -**Parent StRS**: StR-035 -**Statement**: The system shall provide mandator-based configuration with tenant-specific settings, data isolation, and multi-tenant support. -**Inputs**: Mandator definitions, tenant configurations, isolation policies -**Processing**: Tenant configuration management, data isolation enforcement, multi-tenant coordination -**Outputs**: Tenant-specific configurations, isolation confirmations, tenant status -**Performance**: Multi-tenant configuration shall support 100+ tenants with isolated settings -**Source Evidence**: Mandator management in entities, multi-tenant configuration components -**Verification Method**: Test - -### SyR-072: Environment Configuration Management -**Parent StRS**: StR-035 -**Statement**: The system shall manage environment-specific configurations with deployment automation, configuration validation, and rollback capabilities. -**Inputs**: Environment definitions, deployment configurations, validation rules -**Processing**: Configuration deployment, environment switching, validation checking -**Outputs**: Environment-specific settings, deployment confirmations, validation results -**Performance**: Environment configuration shall deploy within 5 minutes with automatic validation -**Source Evidence**: Configuration management in administration modules, environment handling components -**Verification Method**: Test - ---- - -### System Infrastructure Requirements (SyR-073 to SyR-075) - -### SyR-073: Dual Connectivity Architecture -**Parent StRS**: StR-035 -**Statement**: The system shall support dual connectivity with seamless switching between direct database (BL) and web service (WS) connections. -**Inputs**: Connection preferences, connectivity rules, switching triggers -**Processing**: Connection routing, switching coordination, state management -**Outputs**: Active connections, routing decisions, connectivity status -**Performance**: Connection switching shall complete within 2 seconds with transparent user experience -**Source Evidence**: Dual BL/WS Logic pattern throughout system, ClassContainer implementation, connection management -**Verification Method**: Test - -### SyR-074: Dependency Injection Container -**Parent StRS**: StR-035 -**Statement**: The system shall provide dependency injection with service registration, lifecycle management, and automatic dependency resolution. -**Inputs**: Service registrations, dependency graphs, lifecycle configurations -**Processing**: Dependency resolution, lifecycle management, service instantiation -**Outputs**: Resolved dependencies, service instances, lifecycle notifications -**Performance**: Dependency injection shall resolve complex dependency graphs within 100 milliseconds -**Source Evidence**: ClassContainer pattern usage throughout system, dependency injection implementations -**Verification Method**: Test - -### SyR-075: Result Pattern Error Handling -**Parent StRS**: StR-035 -**Statement**: The system shall implement comprehensive error handling with Result<T> pattern, exception management, and error propagation control. -**Inputs**: Operation results, error conditions, exception data -**Processing**: Error classification, result wrapping, error propagation -**Outputs**: Result objects, error messages, operation status -**Performance**: Error handling shall add minimal overhead (under 1%) to normal operations -**Source Evidence**: Result<T> pattern usage throughout all BL and WS Logic implementations -**Verification Method**: Test - ---- - -## 5. System Integration Flow Diagrams - -### Data Flow Architecture -```mermaid -graph TD - subgraph "Client Layer" - UI[WPF UI Modules
135+ Modules] - end - - subgraph "Service Abstraction" - ILogic[ILogic Interfaces
Business Contracts] - Container[ClassContainer
Dependency Injection] - end - - subgraph "Implementation Layer" - BL[BL Logic Classes
Direct Database Access] - WS[WS Logic Classes
Web Service Access] - end - - subgraph "Business Logic Layer" - BLCore[Core Business Logic
849+ BL Classes] - WSAdapter[WebService Adapters
DTO Conversion] - end - - subgraph "Data Layer" - DAO[Data Access Objects
936 Mappings] - WebAPI[REST APIs
2,145 Endpoints] - end - - subgraph "Storage" - Database[(SQL Server
NHibernate ORM)] - end - - UI --> ILogic - ILogic --> Container - Container --> BL - Container --> WS - BL --> BLCore - WS --> WSAdapter - WSAdapter --> WebAPI - BLCore --> DAO - WebAPI --> BLCore - DAO --> Database -``` - -### Authentication and Authorization Flow -```mermaid -sequenceDiagram - participant User - participant WPF as WPF Client - participant Auth as Authentication System - participant RBAC as Access Control - participant BL as Business Logic - participant DB as Database - - User->>WPF: Login Request - WPF->>Auth: Authenticate(credentials) - Auth->>DB: Validate User - DB-->>Auth: User Data - Auth->>RBAC: Load User Rights - RBAC->>DB: Query Rights (20800000+ IDs) - DB-->>RBAC: Rights Matrix - RBAC-->>Auth: User Permissions - Auth-->>WPF: Authentication Token - WPF->>BL: Business Request + Token - BL->>RBAC: Check Permission - RBAC-->>BL: Access Decision - alt Authorized - BL->>DB: Execute Operation - DB-->>BL: Operation Result - BL-->>WPF: Success Response - else Unauthorized - BL-->>WPF: Access Denied - end - WPF-->>User: Result/Error -``` - -### Business Process Integration Flow -```mermaid -graph LR - subgraph "External Systems" - FinAPI[FinAPI
Banking] - GLS[GLS
Shipping] - Icecat[Icecat
Products] - end - - subgraph "Centron Core Processes" - Account[Account
Management] - Sales[Sales
Processing] - Inventory[Inventory
Management] - Finance[Financial
Processing] - end - - subgraph "Supporting Systems" - Audit[Audit Trail
BaseEntity] - Workflow[Workflow
Engine] - Reports[Reporting
FastReport] - end - - Account --> Sales - Sales --> Inventory - Sales --> Finance - - Finance --> FinAPI - Inventory --> GLS - Account --> Icecat - - Account --> Audit - Sales --> Audit - Inventory --> Audit - Finance --> Audit - - Sales --> Workflow - Finance --> Workflow - - Account --> Reports - Sales --> Reports - Finance --> Reports -``` - ---- - -## 6. Performance Requirements Matrix - -| System Component | Response Time | Throughput | Availability | Scalability | -|------------------|---------------|------------|--------------|-------------| -| Authentication System | < 2 seconds | 1000+ auth/hour | 99.9% | 500+ concurrent users | -| Data Management | < 100ms (queries) | 200+ connections | 99.9% | 10,000+ records | -| Business Logic | < 1 second | 500+ ops/minute | 99.5% | 1000+ concurrent ops | -| Web Service APIs | < 200ms (auth) | 1000+ requests/sec | 99.9% | Auto-scaling | -| User Interface | < 1 second (load) | 135+ modules | 99.5% | 100+ concurrent users | -| External Integration | < 10 seconds | 1000+ docs/day | 99.0% | Multiple providers | -| Reporting System | < 30 seconds | 100+ reports/hour | 99.5% | 10,000+ records | -| Localization | < 3 seconds (switch) | Real-time | 100% | 2 languages | -| Configuration | < 1 second (apply) | 100+ tenants | 99.9% | Multi-tenant | -| Infrastructure | < 2 seconds (switch) | Dual connectivity | 99.9% | Load balancing | - ---- - -## 7. System State Machine - -```mermaid -stateDiagram-v2 - [*] --> Initializing: System Startup - - Initializing --> Authenticating: Load Complete - Authenticating --> Authenticated: Valid Credentials - Authenticating --> Failed: Invalid Credentials - - Authenticated --> Operating: Authorization Success - Failed --> Authenticating: Retry Login - - Operating --> Processing: Business Operation - Processing --> Operating: Operation Complete - Processing --> Error: Operation Failed - - Error --> Operating: Error Resolved - Error --> Shutdown: Critical Error - - Operating --> Maintenance: Admin Request - Maintenance --> Operating: Maintenance Complete - - Operating --> Shutdown: User Logout - Shutdown --> [*]: System Exit - - note right of Operating - Core system state supporting: - - Account Management - - Sales Processing - - Inventory Operations - - Financial Transactions - - Reporting & Analytics - end note -``` - ---- - -## 8. Verification and Validation Matrix - -| Requirement Category | Verification Method | Acceptance Criteria | Test Coverage | -|---------------------|-------------------|---------------------|---------------| -| Authentication (SyR-001 to SyR-008) | Automated Testing | 99.9% success rate | 100% scenarios | -| Data Management (SyR-009 to SyR-020) | Integration Testing | ACID compliance | Database operations | -| Business Logic (SyR-021 to SyR-035) | Unit + Integration Testing | Functional correctness | All BL classes | -| Web Services (SyR-036 to SyR-045) | API Testing | REST compliance | All 2,145 endpoints | -| User Interface (SyR-046 to SyR-053) | UI Testing | Usability standards | All 135+ modules | -| External Integration (SyR-054 to SyR-061) | System Testing | Integration success | All 8 integrations | -| Reporting (SyR-062 to SyR-066) | Demonstration | Report accuracy | Standard reports | -| Localization (SyR-067 to SyR-069) | Inspection | Translation coverage | German/English | -| Configuration (SyR-070 to SyR-072) | System Testing | Multi-tenant support | Configuration scenarios | -| Infrastructure (SyR-073 to SyR-075) | Analysis + Testing | Architectural compliance | System patterns | - ---- - -## 9. Compliance and Traceability - -### ISO 29148 Compliance Verification -✅ **Requirement Completeness**: 75 system requirements fully specified -✅ **Stakeholder Traceability**: Each SyR traces to specific StR -✅ **Verification Methods**: Test/Demo/Inspection/Analysis assigned -✅ **Performance Criteria**: Measurable performance requirements -✅ **Source Evidence**: Specific file references with line numbers -✅ **System Boundary**: Clear system/environment distinction - -### Requirements Traceability Matrix -| StR Range | SyR Range | System Component | Evidence Files | -|-----------|-----------|------------------|----------------| -| StR-001 to StR-006 | SyR-021, SyR-025 | Account Management | Account.cs, AccountBL classes | -| StR-007 to StR-011 | SyR-022, SyR-026, SyR-027 | Sales Processing | Sales entities, Order processing | -| StR-012 to StR-015 | SyR-024 | Financial Management | Financial BL, FinAPI integration | -| StR-016 to StR-019 | SyR-023 | Inventory Management | Warehousing entities, StockBL | -| StR-020 to StR-023 | SyR-001 to SyR-008 | Security System | UserRightsConst, Authentication | -| StR-024 to StR-025 | SyR-067 to SyR-069 | Localization | LocalizedStrings files | -| StR-026 to StR-029 | SyR-054 to SyR-061 | External Integration | APIs directory, EDI entities | -| StR-030 to StR-032 | SyR-033, SyR-034 | Support Management | Helpdesk modules, Support entities | -| StR-033 to StR-034 | SyR-062 to SyR-066 | Reporting System | Report engine, Statistics | -| StR-035 | SyR-070 to SyR-075 | System Infrastructure | Configuration, Architecture | - ---- - -## 10. Risk Analysis and Mitigation - -### High-Risk Requirements -| Requirement | Risk Level | Risk Factor | Mitigation Strategy | -|-------------|------------|-------------|-------------------| -| SyR-002 | High | Complex permission matrix | Extensive testing of rights combinations | -| SyR-009 | High | ORM performance with 936 mappings | Performance testing and optimization | -| SyR-036 | High | API gateway scalability | Load testing and monitoring | -| SyR-054 | High | External banking integration | Comprehensive error handling and fallbacks | -| SyR-073 | Medium | Dual connectivity complexity | Thorough integration testing | - ---- - -## Document Approval and Sign-off - -| Role | Name | Signature | Date | Version | -|------|------|-----------|------|---------| -| System Architect | [TBD] | | | 1.0 | -| Technical Lead | [TBD] | | | 1.0 | -| Quality Assurance | [TBD] | | | 1.0 | -| Business Analyst | [TBD] | | | 1.0 | -| Requirements Analyst | ISO 29148 System Agent | [Digital] | September 29, 2025 | 1.0 | - ---- - -*This System Requirements Specification contains 75 complete system requirements with full ISO/IEC/IEEE 29148:2018 compliance, comprehensive architectural evidence from 12,507+ source files, and complete traceability to stakeholder requirements. Each requirement includes specific implementation evidence, measurable performance criteria, and appropriate verification methods.* \ No newline at end of file diff --git a/Ergebnisse/Ergebnisse 03/NEXUS_DOCUMENTATION/COMPLETION_REPORT_NEXUS_DISCOVERY.md b/Ergebnisse/Ergebnisse 03/NEXUS_DOCUMENTATION/COMPLETION_REPORT_NEXUS_DISCOVERY.md deleted file mode 100644 index d2d43e4..0000000 --- a/Ergebnisse/Ergebnisse 03/NEXUS_DOCUMENTATION/COMPLETION_REPORT_NEXUS_DISCOVERY.md +++ /dev/null @@ -1,419 +0,0 @@ -# 🎯 CentronNexus Discovery Project - COMPLETION REPORT - -**Date**: 2025-11-24 -**Status**: ✅ **COMPLETE** -**Outcome**: 7 modules discovered, 2 new features identified, comprehensive documentation created - ---- - -## Executive Summary - -### What Was Accomplished - -**Phase 1: Documentation Organization** ✅ -- Created 4 organized documentation files with consistent naming pattern -- All screenshots centralized in dedicated folder with proper linking -- Navigation guide created for easy discovery of information - -**Phase 2: Screenshot Capture** ✅ -- Captured 5 initial main modules (Dashboard, Tickets, Customers, Scheduling, My Day) -- Extended capture to include detail views (Ticket Details) -- Executed aggressive discovery mode to find additional modules - -**Phase 3: Analysis & Documentation** ✅ -- Analyzed all 7 captured modules in detail -- Documented 11 use-cases for newly discovered Quick Ticket Creation -- Updated all mapping documents with new findings -- Created comprehensive discovery summary - -### Key Metrics - -| Metric | Value | Status | -|--------|-------|--------| -| Modules Discovered | 7 | ✅ 100% of captured | -| Documentation Files | 6 | ✅ All comprehensive | -| Screenshots | 7 PNG files | ✅ 574 KB total | -| New Features Found | 2 | ✅ Major discoveries | -| Coverage vs. Planned | 20.6% (7/34) | ✅ Baseline established | -| Documentation Quality | Professional | ✅ Production-ready | - ---- - -## Deliverables - -### 📄 Documentation Files (91 KB total) - -1. **USECASES_CODE_ANALYSIS.md** (15 KB) - - Reference: All 23 fully documented modules from code - - Purpose: Understanding existing code architecture - - Status: ✅ Complete and organized - -2. **USECASES_UI_SCREENSHOTS.md** (14 KB - UPDATED) - - Added: Module 6 (Neu-Ticket) with 11 detailed use-cases - - Contains: Visual analysis of all 7 captured modules - - Purpose: What users actually see in the application - - Status: ✅ Expanded and complete - -3. **USECASES_MAPPING_UI_TO_CODE.md** (16 KB - UPDATED) - - Added: Ticket Details (Module 6) and Neu-Ticket (Module 7) - - Updated: Summary table with 7 modules (was 5) - - Coverage: 20.6% of planned modules documented - - Status: ✅ Updated with new mappings - -4. **USECASES_NEW_DISCOVERED.md** (20 KB) - - Reference: 9 new sub-use-cases found in initial analysis - - Purpose: Implementation planning for new features - - Status: ✅ Reference for future development - -5. **NEXUS_DOCUMENTATION_README.md** (13 KB) - - Navigation guide for all documentation - - Quick reference for different roles - - File relationships and dependencies - - Status: ✅ Complete guidance - -6. **NEXUS_DISCOVERY_SESSION_SUMMARY.md** (13 KB - NEW) - - Detailed session execution report - - Technical implementation details - - Findings and recommendations - - Next steps and roadmap - - Status: ✅ NEW - comprehensive summary - -### 📸 Screenshots (574 KB total) - -**Location**: `NEXUS_DOCUMENTATION/SCREENSHOTS/` - -| # | Module | File | Size | Status | -|---|--------|------|------|--------| -| 01 | Dashboard | 01-Dashboard.png | 93 KB | ✅ Core module | -| 02 | Tickets-Liste | 02-Tickets-Liste.png | 77 KB | ✅ Core module | -| 03 | Kunden-Übersicht | 03-Kunden-Uebersicht.png | 68 KB | ✅ Core module | -| 04 | Zeitplanung-Kalender | 04-Zeitplanung-Kalender.png | 92 KB | ✅ Core module | -| 05 | Mein Tag-Tagesplan | 05-Mein-Tag-Tagesplan.png | 64 KB | ✅ Core module | -| 06 | Ticket-Details | 06-Ticket-Details.png | 92 KB | ✅ NEW capture | -| 07 | **Neu-Ticket** ⭐ | **07-Neu.png** | **77 KB** | ✅ **NEW DISCOVERY** | - ---- - -## Major Discoveries - -### 1️⃣ Ticket Details Module (06-Ticket-Details.png) - -**Type**: Detail/Form View -**Access**: Click ticket from list -**Features**: -- Complete ticket information display -- Customer data integration -- State/status management -- Field editing capability -- Form-based layout - -**Status**: Previously documented in code (3.1) but not visually captured until now -**Impact**: Confirms ticket detail workflow is fully implemented - ---- - -### 2️⃣ **Quick Ticket Creation Dialog** ⭐ (07-Neu.png) - MAJOR NEW FEATURE - -**Type**: Modal Dialog Form -**Access**: "+ Neu" button in top navigation bar -**Trigger**: Accessible from any module context - -#### Features Documented (11 Use-Cases) - -| UC-ID | Feature | Field | Input Type | -|-------|---------|-------|-----------| -| UC-NEWTICKET-1 | Quick Dialog | Modal overlay | Window | -| UC-NEWTICKET-2 | Customer Selection | Kundensuche | Search/Autocomplete | -| UC-NEWTICKET-3 | Title Entry | Titel eingeben | Text (max 1000) | -| UC-NEWTICKET-4 | Service/Leistung | Service dropdown | Selection | -| UC-NEWTICKET-5 | Contract/Vertrag | Contract dropdown | Selection | -| UC-NEWTICKET-6 | Priority | Priorität dropdown | Classification | -| UC-NEWTICKET-7 | Type | Typ dropdown | Classification | -| UC-NEWTICKET-8 | Category | Kategorie dropdown | Classification | -| UC-NEWTICKET-9 | Templates | Ticketvorlagen button | Template browser | -| UC-NEWTICKET-10 | Creation | Ticket anlegen button | Form submit | -| UC-NEWTICKET-11 | Dialog Mgmt | Close button | Modal controls | - -#### Business Value -- ✅ **Rapid Ticket Creation**: Users can create tickets instantly from any module -- ✅ **High Productivity**: No page navigation required -- ✅ **Context Awareness**: Dialog maintains application context -- ✅ **Core Workflow**: Essential for support operations - -#### Status -- ❌ **NOT in original code documentation** - completely undocumented feature -- 🔴 **Priority**: HIGH - core workflow feature -- 📋 **Implementation Need**: Complete feature documentation required -- ⏱️ **Est. Implementation**: 5-7 days for full feature - ---- - -## Coverage Analysis - -### Discovery Progress -``` -Session Goal: Capture all available CentronNexus modules - -Results: -✅ 5 main navigation modules (100% of expected) -✅ 1 detail view (Ticket Details) -✅ 1 quick creation dialog (NEW) -───────────────────────────────── -✅ 7 TOTAL MODULES DISCOVERED - -Planned Total: 34 modules -Current Coverage: 7/34 = 20.6% -Remaining: 27 modules (79.4%) -``` - -### Module Breakdown - -**By Function**: -- Navigation/Main Modules: 5/5 (100%) -- Detail Views: 1/? (Complete for Tickets) -- Creation Dialogs: 1/? (Quick ticket creation found) -- Settings/Admin: 0/? (Not yet explored) -- Advanced Features: 0/? (Not yet explored) - -**By Status**: -- Confirmed in Code: 6 modules -- NEW Discovery: 1 module -- Partially Blocked: 2 attempts (Dropdown, Stopwatch) - ---- - -## Technical Implementation - -### Playwright Automation Enhanced - -**Improvements Made**: -1. ✅ Fixed login multi-button ambiguity (CSS selector) -2. ✅ Implemented dual selector strategy (role + text-based) -3. ✅ Added aggressive discovery mode (systematic element enumeration) -4. ✅ Implemented error handling per element -5. ✅ Proper async/await for Locator elements -6. ✅ Improved timeout and wait strategies - -**Build Status**: ✅ Clean build, 0 errors, 0 warnings - -### Discovery Mode Algorithm - -``` -1. Get all and - - - -``` - -### 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 diff --git a/Ergebnisse/Ergebnisse 03/NEXUS_DOCUMENTATION/USE_CASES_CENTRON_NEXUS copy.md b/Ergebnisse/Ergebnisse 03/NEXUS_DOCUMENTATION/USE_CASES_CENTRON_NEXUS copy.md deleted file mode 100644 index 36a3ac4..0000000 --- a/Ergebnisse/Ergebnisse 03/NEXUS_DOCUMENTATION/USE_CASES_CENTRON_NEXUS copy.md +++ /dev/null @@ -1,1523 +0,0 @@ -# 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` - -### 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. - -### 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 -``` - -### 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 - 5. Änderungen speichern (auto-save) -- **Betroffene Felder**: `Helpdesk` (Number, ShortDescription, Description, StatusKind, Priority) -- **REST-API**: `GET /Helpdesk/{id}`, `PUT /Helpdesk/{id}` -- **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 - -### Daten-Entitäten - -```csharp -HelpdeskDTO -├── I3D, Number (Eindeutig) -├── ShortDescription, Description -├── StatusKind, Priority -├── CustomerI3D, ResponsibleEmployeeI3D -├── CreatedDate, ChangedDate -├── TicketAssignments (Zuordnungen) -├── HelpdeskComments (Kommentare) -├── HelpdeskDocuments (Anhänge) -└── HelpdeskHistory (Änderungshistorie) -``` - -### Service-Integration - -```csharp -// Primäre Operationen -await CentronService.GetHelpdeskDetails(ticketId); -await CentronService.UpdateHelpdesk(updateRequest); -await CentronService.AddHelpdeskComment(commentRequest); -await CentronService.AddHelpdeskAttachment(fileRequest); -await CentronService.GetHelpdeskHistory(ticketId); -``` - -### Hidden Features - -1. **Editor Lock**: Zeigt in Echtzeit wer gerade das Ticket bearbeitet -2. **Conditional Formatting**: Status-Farben basierend auf Regeln -3. **Inline Attachments**: Bilder/PDFs direkt im Editor sichtbar -4. **Mention-System**: @mention von Mitarbeitern in Kommentaren -5. **Keyboard Shortcuts**: Schnelle Navigation zwischen Tickets - ---- - -## 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) - -### Beschreibung - -Die Ticket-Liste ist das **zentrale Verwaltungs- und Such-Interface**. Sie unterstützt: -- 20+ Filter-Kriterien -- Kanban-Boards (4 verschiedene Ansichten) -- Conditional Formatting (farbliche Hervorhebung) -- Multi-Sortierung -- Vordefinierte Ansichten -- Real-Time Aktualisierung - -### Filter-Dimensionen (20+) - -```csharp -Filter-Optionen: -├── Status (Offen, In Arbeit, Gelöst, Warten, Geschlossen) -├── Priorität (Niedrig, Mittel, Hoch, Kritisch) -├── Kategorie (Technology, Hardware, Software, etc.) -├── Zuordnung (Mein, Mein Team, Nicht zugeordnet, etc.) -├── Zeitraum (Heute, Diese Woche, Dieser Monat, Custom) -├── Kunde (Single Select + Multi-Select) -├── Ersteller (Single Select) -├── Responder (Single Select) -├── Schlüsselwort (Text-Suche mit Wildcard) -├── Tags (Multi-Select) -├── Service/Vertrag (Single Select) -├── Abteilung (Single Select) -├── Favoriten (Nur Favoriten) -├── Meine (Tickets die ich bearbeitet habe) -├── Warteschlange (Service Queue) -├── SLA-Status (On Track, At Risk, Breached) -├── Ticket-Typ (Incident, Request, Change, etc.) -└── Custom Fields (Beliebige kundenspezifische Felder) -``` - -### Kanban-Board Ansichten - -#### 1. **Status-Board** (Standard) -- Spalten: Offen | In Arbeit | Wartet | Gelöst | Geschlossen -- Drag-Drop zum Verschieben zwischen Status -- Ticket-Count pro Spalte - -#### 2. **Prioritäts-Board** -- Spalten: Kritisch | Hoch | Mittel | Niedrig -- Visuelle Farbcodierung -- Kanban-Lanes für Durchsatz-Management - -#### 3. **Typ-Board** -- Spalten pro Ticket-Typ (Incident, Request, Change, Problem, etc.) -- Workflow-Ansicht - -#### 4. **Zuweisung-Board** -- Spalten pro verantwortlicher Person -- Team-Auslastungs-Übersicht - -### Use Cases - -#### UC 11.6.1: Tickets filtern und suchen -- **Beschreibung**: Techniker sucht Tickets nach Kriterien -- **Workflow**: - 1. Filtersektion öffnen - 2. Filter-Kombinationen setzen (AND/OR Logik) - 3. Suchen (Echtzeit oder Button) - 4. Ergebnisse in Grid/Kanban anzeigen - 5. Filter speichern für später -- **Performance**: Cached List (~500 Tickets im RAM) - -#### UC 11.6.2: Kanban-Board verwenden -- **Beschreibung**: Visuelle Ticket-Verwaltung -- **Ablauf**: - 1. Board-Ansicht wählen (Status, Priorität, etc.) - 2. Tickets auf Karten sehen - 3. Ticket per Drag&Drop verschieben - 4. Status auto-update - 5. Statistiken in Spalten-Header anzeigen - -#### UC 11.6.3: Bedingte Formatierung anwenden -- **Beschreibung**: Automatische Farb-Hervorhebung basierend auf Regeln -- **Regeln** (Beispiele): - - SLA überfällig → Rot - - Priorität Kritisch → Orange - - Wartet auf Kunde > 5 Tage → Gelb - - Zugeordnet an Ich → Grün Rahmen - - Ungelesen → Fett -- **Operatoren**: Equals, Contains, Greater, Less, Between, RegEx - -#### UC 11.6.4: Ticket-Ansicht speichern -- **Beschreibung**: Filter-Kombination als vordefinierte Ansicht speichern -- **Speicher**: User-spezifisch oder Team-weit -- **Nutzung**: Schneller Zugriff auf häufig verwendete Filter - -### Bedingte Formatierungs-Engine - -```csharp -ConditionalFormattingRule -├── Name (z.B. "SLA Violation") -├── Conditions[] -│ └── ColumnName (FieldName) -│ └── Operator (Equals, Contains, Greater, Less, Between, RegEx) -│ └── Value (Vergleichswert) -│ └── LogicalOperator (AND, OR) -├── Styling -│ ├── BackgroundColor -│ ├── ForegroundColor -│ ├── FontWeight (Normal, Bold) -│ ├── FontStyle (Normal, Italic) -│ └── Icon (Indicator) -└── Priority (Regelreihenfolge) -``` - -### Statistiken in Spalten-Header - -``` -Offen (42) In Arbeit (18) Wartet (5) Gelöst (156) Geschlossen (892) -├─ SLA OK: 41 ├─ SLA OK: 17 ├─ > 5d: 3 ├─ < 1h: 12 └─ This Month: 120 -├─ SLA WARN: 1 ├─ SLA AT RISK: 1 ├─ Due: 2 └─ > 1h: 144 -└─ SLA BREACH: 0 └─ SLA BREACH: 0 └─ Critical: 0 -``` - -### Hidden Features - -1. **Column Summary Statistics**: In Header-Zeile -2. **Inline Filtering**: Schnellfilter direkt in Spalten -3. **Ticket Grouping**: Gruppierung nach Customer, Team, Status -4. **Export to Excel**: Gefilterte Ergebnisse exportieren -5. **Bulk Actions**: Multi-Select + Batch-Operationen - ---- - -## 3.3 Ticket schließen - -**Pfad**: `src/CentronNexus/ServiceBoard/CloseTicket/CloseTicketPage.razor` -**Kategorie**: Ticket Management (Workflow) -**Status**: ✅ Vollständig implementiert -**Lizenz**: `LicenseGuids.Centron` OR `LicenseGuids.ServiceBoard` - -### Beschreibung - -Ticket-Abschluß mit **Multi-Step Workflow**, **E-Mail-Benachrichtigungen** und **Optionalen Service-Report-Anhängen**. - -### Workflow - -``` -1. Ticket-Auswahl - ↓ -2. Schließungs-Grund wählen - ├─ Gelöst - ├─ Nicht reproduzierbar - ├─ Nicht relevant - ├─ Duplikat - └─ Kunde reagiert nicht - ↓ -3. Notizen & Dokumentation - ├─ Lösungs-Zusammenfassung (Kunde sichtbar) - ├─ Interne Noten (nur Team) - └─ Service-Report anhängen (optional) - ↓ -4. Benachrichtigungen - ├─ Kunde benachrichtigen? (E-Mail) - ├─ Team benachrichtigen? (Internal Mail) - ├─ Vorlage auswählen - └─ Zusätzliche Empfänger - ↓ -5. Bestätigung & Speichern -``` - -### Use Cases - -#### UC 11.7.1: Ticket abschließen mit E-Mail -- **Ablauf**: - 1. "Ticket schließen" Button klicken - 2. Schließungsgrund wählen - 3. Lösungs-Zusammenfassung eingeben - 4. Service-Report generieren (optional PDF) - 5. Vorlage auswählen für Kundenbenachrichtigung - 6. Zusätzliche Empfänger hinzufügen - 7. Senden & Speichern -- **Betroffene Felder**: `Helpdesk` (StatusKind=Closed, ClosedDate, ClosedByI3D, ClosedReason) - -#### UC 11.7.2: Service-Report als Anhang -- **Beschreibung**: Automatische Generierung von PDF-Report mit Ticketdetails -- **Inhalt**: - - Ticket-Nummer und -Titel - - Beschreibung & Historie - - Durchgeführte Arbeiten - - Aufgewendete Zeit - - Kosten (falls berechnet) -- **Generierung**: Asynchron vor E-Mail-Versand - -#### UC 11.7.3: E-Mail-Vorlage auswählen -- **Vorlagen-System**: - - Integrierte Vorlagen (Deutsch, Englisch) - - Kundenspezifische Vorlagen - - Merge-Tags für Personalisierung: `{TicketNumber}`, `{CustomerName}`, `{SolutionSummary}` - - Template Versioning - -### E-Mail-Templates - -``` -Template: "Ticket abgeschlossen - Standard" -├─ Subject: "Ticket #{TicketNumber} abgeschlossen" -├─ To: Customer Email (auto) -├─ CC: Additional Recipients (configurable) -├─ Body (HTML): -│ Hallo {CustomerName}, -│ -│ Wir haben Ihr Ticket #{TicketNumber} "{TicketTitle}" -│ erfolgreich abgeschlossen. -│ -│ Lösungszusammenfassung: -│ {SolutionSummary} -│ -│ Aufgewendete Zeit: {TotalHours}h -│ Priorität: {Priority} -│ -│ Bei Fragen wenden Sie sich an: {SupportTeamName} -│ -│ Mit freundlichen Grüßen, -│ {CompanyName} Support Team -│ -└─ Attachments: ServiceReport.pdf (optional) -``` - -### Daten-Entitäten - -```csharp -TicketCloseData -├── HelpdeskI3D -├── ClosingReasonKind (Solved, Unresolvable, NotRelevant, Duplicate, etc.) -├── SolutionSummary (Kunde sichtbar) -├── InternalNotes (Nur Team) -├── IncludeServiceReport (bool) -├── NotifyCustomer (bool) -├── NotifyTeam (bool) -├── EmailTemplateI3D -├── AdditionalRecipientsEmails[] -├── ServiceReportPdf (byte[]) -└── SavedDate -``` - ---- - -## 3.4 Ticket weiterleiten - -**Pfad**: `src/CentronNexus/ServiceBoard/ForwardTicket/ForwardTicketPage.razor` -**Kategorie**: Ticket Management (Eskalation) -**Status**: ✅ Vollständig implementiert -**Verwandt**: CloseTicket (ähnliches Pattern) - -### Beschreibung - -Eskalation / Weiterleitung von Tickets mit **E-Mail-Integration**, **Zielgruppen-Auswahl** und **Notiz-System**. - -### Use Cases - -#### UC 11.8.1: Ticket an Mitarbeiter/Team weiterleiten -- **Ablauf**: - 1. "Weiterleiten" Button - 2. Ziel-Empfänger auswählen (Einzeln oder Team) - 3. Kurznachricht hinzufügen (warum weiterleiten?) - 4. E-Mail mit Kontext senden - 5. Ticket-Zuordnung aktualisieren -- **Effekt**: Zuordnung aktualisiert, E-Mail-Benachrichtigung, Historien-Eintrag - -#### UC 11.8.2: Weiterleitung an externen Vendor -- **Szenario**: Hardware-Problem → Vendor-Support -- **Prozess**: - 1. Externe E-Mail-Adresse eingeben - 2. Ticketdetails (oder Summary) versenden - 3. Referenznummer austauschen - 4. Status auf "Wartet auf Vendor" setzen - -### E-Mail-Nachricht - -``` -Subject: "Ticket #{Number} - Weiterleitung: {Title}" -From: ResponsibleEmployee -To: Target Person/Team -CC: Requester (optional) - -Body: -Hallo, - -ich leite Ihnen folgendes Ticket weiter: - -Ticket: #{Number} -Titel: {Title} -Kunde: {CustomerName} -Priorität: {Priority} - -Nachricht: -{ForwardingMessage} - -Details: https://...serviceboard/.../ticket/{TicketId} - -Danke für die Unterstützung! -{FromName} -``` - ---- - -## 3.5 Kanban-Board - -**Pfad**: `src/CentronNexus/ServiceBoard/Kanban/KanbanPage.razor` -**Kategorie**: Ticket Management (Visualisierung) -**Status**: ✅ Implementiert (Drag-Drop teilweise) -**Hidden Feature**: Mehrere Board-Typen - -### Board-Typen - -1. **Status-Board** (Standard) -2. **Prioritäts-Board** -3. **Typ-Board** -4. **Zuweisung-Board** - -### Funktionalität - -- Drag-Drop zwischen Spalten -- Ticket-Karten mit Statusanzeige -- Spalten-Statistiken -- Filter-Integration -- Responsive Layout - ---- - -## 3.6 Ticket-Checklisten - -**Pfad**: `src/CentronNexus/ServiceBoard/TicketChecklists/TicketChecklistsPage.razor` -**Kategorie**: Ticket Management (Workflow) -**Status**: ✅ Vollständig implementiert -**Lizenz**: `LicenseGuids.Centron` (Standard) - -### Use Cases - -#### UC 11.9.1: Task-Checkliste erstellen und verwenden -- **Ablauf**: - 1. Checklisten-Template auswählen (oder neu erstellen) - 2. Aufgaben-Items durchgehen - 3. Abhängigkeiten definieren (z.B. "A muss vor B" abgeschlossen werden) - 4. Während Ticket-Bearbeitung abhaken - 5. Fortschritt-Balken zeigt Completion % -- **Betroffene Felder**: `HelpdeskChecklist`, `HelpdeskChecklistItem` (IsCompleted, CompletedDate, CompletedByI3D) - -#### UC 11.9.2: Template-Bibliothek nutzen -- **Vordefinierte Templates**: - - Hardware-RMA-Vorlage - - Software-Installation-Vorlage - - Access-Setup-Vorlage - - VPN-Konfiguration-Vorlage - ---- - -## 3.7 Ticket-Scripts - -**Pfad**: `src/CentronNexus/ServiceBoard/TicketScripts/TicketScriptsPage.razor` -**Kategorie**: Ticket Management (Automation) -**Status**: ✅ Implementiert als **Action Buttons/Schnelltasten** -**Lizenz**: `LicenseGuids.Centron` (mit Automation-Feature) - -### Use Cases - -#### UC 11.10.1: Vordefinierte Aktionen ausführen -- **Beispiele**: - - "Ticket in Bearbeitung nehmen" (1-Click Action) - - "Lösungs-Template einfügen" (Pre-filled text) - - "Team per E-Mail hinzufügen" (Auto-assign + notify) - - "SLA-Uhr zurücksetzen" (Admin action) - -#### UC 11.10.2: Script-Editor (Advanced) -- **Für Admin/Power-User** -- **Sprache**: Möglich PowerShell oder .NET Script -- **Trigger**: Manual, On-Status-Change, On-Assignment - ---- - -## 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 - - - - - - - - - - - - - - - - - -
- - -
- -``` - -### Daten-Entitäten - -```csharp -WebForm -├── I3D, Name, Description -├── ServiceTypeI3D (oder CustomerI3D) -├── IsPublic (öffentliches Formular) -├── CreatedByI3D, CreatedDate -├── Version -└── Fields[] - ├── FieldId - ├── FieldType (enum) - ├── FieldName - ├── Label - ├── Required (bool) - ├── Options[] (für Select-Felder) - ├── Validation Rules (Regex, Min/Max, etc.) - ├── Conditional Logic - └── Order (Display Order) - -WebFormSubmission -├── I3D -├── FormI3D -├── SubmittedByUserI3D (oder Email for anonymous) -├── SubmittedData (JSON blob) -├── CreatedTicketI3D (Link to generated Ticket) -└── SubmittedDate -``` - ---- - -## 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 diff --git a/Ergebnisse/Ergebnisse 03/NEXUS_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.md b/Ergebnisse/Ergebnisse 03/NEXUS_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.md deleted file mode 100644 index 5374499..0000000 --- a/Ergebnisse/Ergebnisse 03/NEXUS_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.md +++ /dev/null @@ -1,4255 +0,0 @@ -# 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 diff --git a/Kapitel/06_evaluation.typ b/Kapitel/06_evaluation.typ index 5e2998d..42e9ed9 100644 --- a/Kapitel/06_evaluation.typ +++ b/Kapitel/06_evaluation.typ @@ -1,10 +1,86 @@ +#let __is_thesis = context { query(<__thesis_document>).len() > 0 } +#if __is_thesis == false [ + #set cite(style: "apa") + #hide(bibliography("../literatur.bib", style: "apa")) +] + #heading(level: 1)[Evaluation (ca. 12 Seiten)] +Dieses Kapitel evaluiert die prototypische Durchführung des in Kapitel 4 beschriebenen Vorgehensmodells und die in Kapitel 5 skizzierte Toolchain-Umsetzung. Als Datenbasis dienen die im Ordner `Ergebnisse` abgelegten Artefakte (Requirements-Spezifikationen nach ISO/IEC/IEEE 29148, Use-Case-Dokumentation, UI↔Code-Mappings, Datenbankschema-Exports und Glossare). Der Fokus liegt auf der Frage, inwieweit die erzeugten Artefakte (1) strukturierte, prüfbare Requirements liefern, (2) Traceability ermöglichen und (3) den Analyseaufwand gegenüber rein manueller Rekonstruktion reduzieren. + #heading(level: 2)[Evaluationskriterien und Messgrößen] -Beschreibe Vollständigkeit, Verständlichkeit, Redundanzfreiheit, Stakeholder-Alignment und Aufwandsreduktion. + +Die Evaluationskriterien orientieren sich an den im Exposé definierten Messgrößen und an etablierten Qualitätsmerkmalen im Requirements Engineering @iso29148_2018 @ieee830_1998. Für KI-gestützte Extraktion wird zusätzlich berücksichtigt, dass plausible Textausgaben ohne Belegpflicht fachlich falsch sein können @ji2023hallucination @bender2021stochastic. + +Für die Arbeit werden die folgenden Kriterien operationalisiert: + +- **Vollständigkeit (relativ zum Scope):** Anteil der dokumentierten Requirements/Use Cases bezogen auf einen definierten Untersuchungsumfang (Module/Prozesse). Vollständigkeit wird in dieser Arbeit nicht als globale Eigenschaft der gesamten Legacy-Software verstanden, sondern als scopebezogene Abdeckung (z. B. pro Modulgruppe). Die Literatur weist darauf hin, dass Vollständigkeit durch Assistenzsysteme verbessert werden kann, aber nur in Verbindung mit Validierung und klarer Abgrenzung @luitel2024completeness. +- **Verständlichkeit und Prüfbarkeit:** Requirements gelten als prüfbar, wenn Akzeptanzkriterien bzw. Verifikationsansätze aus dem Text ableitbar sind. Als Indikator wird die formale Struktur nach ISO/IEC/IEEE 29148 genutzt (Soll-Formulierung, Begründung, Kriterien, Verifikation) @iso29148_2018. +- **Redundanzfreiheit und Konsistenz:** Identifikation doppelter oder widersprüchlicher Requirements. In der prototypischen Auswertung wird dies primär über Strukturprüfungen und Stichproben erfolgen; eine vollständige Duplikaterkennung erfordert zusätzliche, dedizierte Analyseschritte. +- **Traceability (Nachvollziehbarkeit):** Anteil der Requirements, die explizite Belege auf Artefakte enthalten (Datei-/Pfadverweise, Klassen, Methoden, SQL-Objekte, UI-Elemente). Traceability ist eine zentrale Voraussetzung für belastbare Weiterentwicklung und Evaluation @gotel1994traceability @ramesh2001traceability. +- **Stakeholder-Alignment:** Übereinstimmung der Ergebnisse mit Fachwissen und Prioritäten. Operationalisiert wird dies durch Review-Sessions (Bewertung, Korrekturen, Ergänzungen) und die Kennzeichnung offener Punkte. +- **Aufwandsreduktion:** Zeitbedarf der KI-gestützten Rekonstruktion im Vergleich zu einer manuellen Erstellung für den gleichen Scope. Da reale manuelle Baselines stark von Team- und Artefaktlage abhängen, werden in der Pilotphase gemessene Toolchain-Zeiten und dokumentierte Aufwandsschätzungen als Vergleichsanker genutzt. #heading(level: 2)[Durchführung und Ergebnisse] -Erläutere Messaufbau, Workshop-Design, Datenauswertung und die wichtigsten Resultate. + +#heading(level: 3)[Untersuchungsgegenstand und Datenbasis] + +Die prototypische Durchführung basiert auf einer artefaktzentrierten Analyse der Legacy-Software und angrenzender Quellen. In den Ergebnisartefakten wird die Systemgröße unter anderem über folgende Kenngrößen beschrieben: + +- 34 Projekte und 849 Business-Logic-Klassen, +- 956 NHibernate-Mappings, +- 2.145 REST-Endpunkte, +- 135 WPF-Module (UI-Kontext). + +Diese Größenordnungen sind für die Evaluation relevant, weil sie den Kontextdruck auf Kontextfenster und Retrieval (RAG) erklären und die Notwendigkeit strukturierter Traceability unterstreichen @lewis2020rag. + +#heading(level: 3)[Ablauf der prototypischen Auswertung] + +Die Durchführung folgt der Logik aus Kapitel 4 (Scope → Artefaktpipeline → Extraktion → Traceability → Review). Für die prototypische Auswertung wurden die folgenden Artefaktgruppen erzeugt: + +- **Requirements-Spezifikationen nach ISO/IEC/IEEE 29148:** Stakeholder-, System- und Software-Ebene mit Statement/Begründung/Verifikation und Belegangaben. +- **Use-Case-Dokumentation und Mapping:** Umfangreiche Modul- und Use-Case-Sammlungen, ergänzt um UI↔Code-Zuordnungen (WPF-Pfade, ViewModels, Controller, Rechtekonstanten). +- **Domänen- und Datenartefakte:** Business-Glossar sowie Datenbankschema-Exports zur Begriffs- und Datenmodellstabilisierung. +- **UI-basierte Discovery-Artefakte:** Screenshot-Mappings und Session-Reports für Teilbereiche der webbasierten Oberfläche (CentronNexus/ServiceBoard). + +Für die Bewertung werden die Artefakte strukturell geprüft (Vorhandensein der geforderten Felder), Kennzahlen aus den Dokumenten extrahiert und zentrale Aussagen stichprobenartig gegen die angegebenen Belege gespiegelt. + +#heading(level: 3)[Quantitative Ergebnisse] + +Die in `Ergebnisse` abgelegten Spezifikationen berichten insgesamt 277 dokumentierte Requirements (35 Stakeholder-, 75 System- und 167 Software-Requirements). In den detaillierten Artefakten liegen die folgenden, direkt prüfbaren Strukturindikatoren vor: + +- **Stakeholder Requirements (StRS):** 35 Statements mit jeweils Akzeptanzkriterien, Source-Evidence und Verifikationsmethode. +- **System Requirements (SyRS):** 75 Statements mit Source-Evidence und Verifikationsmethode; Akzeptanzkriterien sind teilweise nicht einheitlich als eigenes Feld ausgewiesen. +- **Software Requirements (SwRS, detaillierter Ausschnitt):** 120 Requirements mit „Requirement Statement“, Akzeptanzkriterien, Source-Evidence und Verifikationsmethode. + +Für die Use-Case- und Mapping-Ebene werden folgende Umfangs- und Abdeckungszahlen berichtet: + +- 103 dokumentierte Module (inkl. Submodule) mit 509 Use Cases über 15 Hauptkategorien. +- Mapping-Status in der Zusammenfassung: ca. 92% vollständig gemappt, ca. 6% teilweise gemappt, ca. 2% mit Klärungsbedarf. + +Für die UI-basierte Discovery (CentronNexus) wird ein erster, bewusst begrenzter Scope dokumentiert: + +- 7 erfasste Module bei einem geplanten Umfang von 34 Modulen (20,6% Abdeckung). +- Dokumentation eines neu identifizierten Features („Quick Ticket Creation“) mit 11 konkreten Use Cases. + +Die genannten Zahlen sind als Ergebnis der prototypischen Toolchain-Ausführung zu interpretieren. Für die Arbeit ist dabei nicht nur der Umfang relevant, sondern die konkrete Nachvollziehbarkeit über Belege: In den Requirements-Artefakten sind Source-Evidence-Verweise in großer Zahl vorhanden; in den Mapping-Artefakten werden UI-Elemente konsistent mit ViewModel-Properties, Commands und Modulpfaden verknüpft. + +#heading(level: 3)[Aufwand und Beobachtungen zur Reproduzierbarkeit] + +In den Discovery-Artefakten wird für eine UI-Analyse-Session ein Gesamtaufwand von 12 Stunden (4 Stunden Analyse, 8 Stunden Dokumentation) berichtet. Zusätzlich enthalten die Use-Case-Tools Aufwandsschätzungen für einzelne Analysebausteine (z. B. OpenAPI-Analyse, Workflows). Als Ergebnis lässt sich festhalten: + +- Der prototypische Ansatz liefert in kurzer Zeit umfangreiche, strukturierte Artefakte (Requirements, Mapping, Glossar, Schema). +- Die Dokumente selbst enthalten bereits wesentliche Elemente für Reproduzierbarkeit (Belegpfade, Artefaktverweise). Nicht durchgängig dokumentiert sind jedoch Promptversionen, Sampling-Parameter und Retrieval-Konfigurationen. Für eine belastbare Reproduzierbarkeit im wissenschaftlichen Sinne ist diese Metadatenebene zu ergänzen (vgl. Kapitel 4.1.3). #heading(level: 2)[Qualitative Bewertung durch Experten] -Fasse Feedback, Einschätzungen und offene Punkte aus den Experteninterviews zusammen. + +Die qualitative Bewertung ist zentral, weil fachliche Korrektheit aus Textqualität allein nicht ableitbar ist und LLM-Ausgaben systemische Fehlermuster aufweisen können @ji2023hallucination @bender2021stochastic. Für die Arbeit ist daher ein Human-in-the-loop-Review vorgesehen, der die Ergebnisse aus der KI-gestützten Extraktion gegen Domänenwissen und Projektziele spiegelt. + +Für die Durchführung sind folgende Bausteine vorgesehen: + +- **Stichprobenplan:** Auswahl repräsentativer Module/Prozesse (z. B. Fakturierung, Rechte/Authentifizierung, Datenintegrität) sowie bewusst „randfalllastiger“ Bereiche. +- **Review-Artefakte:** Requirements mit Belegangaben, Use-Case-Mappings (UI↔Code) und Glossarbegriffe als gemeinsamer Referenzrahmen. +- **Bewertungsinstrument:** Kurzfragebogen mit Skalen für Verständlichkeit, Prüfbarkeit, fachliche Korrektheit und Priorität; zusätzlich Erfassung von Korrekturen/Ergänzungen als Änderungslog. +- **Abgleichlogik:** Markierung von (a) bestätigten Requirements, (b) widersprochenen Requirements, (c) Requirements mit unzureichender Evidenz, (d) fehlenden Requirements (Gap-Liste). + +Zum Zeitpunkt der vorliegenden Fassung liegen in `Ergebnisse` keine dokumentierten Expertenratings oder Interviewprotokolle vor. Die qualitative Bewertung wird daher als nächster Evaluationsschritt in Kapitel 6 ergänzt, sobald Review-Sessions durchgeführt und protokolliert wurden. In der Diskussion (Kapitel 7) ist diese Einschränkung als Limitation der aktuellen Ergebnisevidenz zu berücksichtigen. diff --git a/Verbesserungsvorschläge.md b/Verbesserungsvorschläge.md new file mode 100644 index 0000000..7480be0 --- /dev/null +++ b/Verbesserungsvorschläge.md @@ -0,0 +1,17 @@ +# Verbesserungsvorschläge (Abgleich Exposé ↔ bisherige Arbeit) + +Die grobe Kapitelstruktur und Zielrichtung decken sich insgesamt gut mit dem Exposé (Problem → Theorie → Fallstudie → Methodik → Prototyp → Evaluation/Diskussion/Fazit). Der rote Faden bricht aktuell vor allem dort, wo das Exposé Konkretheit fordert (Evaluation/Modelle/Interviews), die Arbeit aber noch generisch bzw. als Platzhalter bleibt. + +- Intro schärfen und an Exposé anpassen: Tool-/Modelle-Nennung wirkt unsauber bzw. spekulativ („Chat GPT-5“) und sollte fachlich-neutral + belegt formuliert werden (`Kapitel/01_einleitung.typ:8`). +- Stilvorgabe konsequent einhalten: Gender-Doppelpunkt kommt vor (z. B. „Entwickler:innen“) trotz Stilvorlage („keine Gender-Doppelpunkt-Formen“) (`Kapitel/01_einleitung.typ:4`, `Kapitel/01_einleitung.typ:14`). +- Forschungsleitfragen 1:1 mit Exposé konsolidieren (gleiche Formulierungen/Nummerierung), damit Kapitel 6/7 später sauber daran zurückbinden (`Exposee/Exposee_Masterarbeit_final.typ:24`, `Kapitel/01_einleitung.typ:34`). +- Spannung „Vollständigkeit“ vs. risikobasiertes Vorgehen auflösen: Exposé fordert „goldenes Referenzset“/Vollständigkeit, Kapitel 4 argumentiert risikobasiert; nötig ist eine klare Scope-Definition, wie „Vollständigkeit“ gemessen wird (z. B. pro Modul/Use-Case, nicht global) (`Exposee/Exposee_Masterarbeit_final.typ:51`, `Kapitel/04_konzeption_methodisches_vorgehen.typ:33`). +- Kapitel 6 dringend konkretisieren (derzeit Platzhalter): Messdesign, Referenzset-Erstellung, Rating-Skalen, Stichprobe/Workshop-Setup, Auswertung und Baseline „ohne KI“ fehlen – das ist im Exposé zentral (`Kapitel/06_evaluation.typ:1`, `Exposee/Exposee_Masterarbeit_final.typ:48`). +- Interview-/Stakeholder-Teil operationalisieren: Exposé nennt Stakeholdergruppen und Zweck (NFRs, Risiken, Regulatorik), Kapitel 4 erwähnt nur grob Rollen; es fehlt Leitfadenstruktur, Auswahl, Auswertung (z. B. Kodierung) und wie Ergebnisse in Requirements einfließen (`Exposee/Exposee_Masterarbeit_final.typ:35`, `Kapitel/04_konzeption_methodisches_vorgehen.typ:135`). +- Technologieevaluation konkret machen: Exposé erwartet Vergleich/Begründung (z. B. GPT‑4o/Claude/Code Llama) und Auswahl eines Hauptmodells; Kapitel 4.3 listet Kriterien, aber keine Evaluation/Entscheidung und keine Bewertungsmatrix (`Exposee/Exposee_Masterarbeit_final.typ:34`, `Kapitel/04_konzeption_methodisches_vorgehen.typ:135`). +- Prototyp-Teil von „Architekturidee“ zu „Reproduzierbarkeit“ ausbauen: konkrete Parameter (Chunkgröße/Overlap, Ranking, Temperatur, Promptversionierung, Logging-Granularität), sowie Artefaktformate für Output/Traceability fehlen bzw. bleiben abstrakt (`Kapitel/05_prototypische_umsetzung.typ:1`). +- Übergänge/Zwischenfazits ergänzen: Kapitel 2 und 3 enden mit Anschlusslogik, Kapitel 4/5 nicht; kurze Zwischenfazits würden den roten Faden zur Evaluation stabilisieren (`Kapitel/04_konzeption_methodisches_vorgehen.typ:1`, `Kapitel/05_prototypische_umsetzung.typ:1`). +- Beleglage in Kapitel 1 stärken: zentrale Behauptungen (Modernisierungsdruck, Dokumentationslage, LLM-Fähigkeiten/Limitierungen) sind dort weitgehend unzitiert; das schwächt die argumentative Kette von Exposé → Theorie (`Kapitel/01_einleitung.typ:1`). +- Erwartete Beiträge sichtbar machen: Exposé listet Beiträge (Prozessmodell, Agent, Bewertungsmatrix, Handlungsempfehlungen); eine kurze, explizite „Beitragsübersicht“ (z. B. Tabelle Artefakt → Kapitel) würde Stringenz erhöhen (`Exposee/Exposee_Masterarbeit_final.typ:69`). +- Kapitel 7/8 ebenfalls noch Platzhalter: ohne Diskussion/Implikationen/Handlungsempfehlungen ist der Exposé-Anspruch (Transfer in Toolchains/Governance) noch nicht „abgeschlossen“ (`Kapitel/07_diskussion.typ:1`, `Kapitel/08_fazit_ausblick.typ:1`). + diff --git a/Ergebnisse/Ergebnisse 02/Centron_Software_Requirements_Specification.md b/Versuche/Versuch 01/Ergebnisse/Centron_Software_Requirements_Specification.md similarity index 100% rename from Ergebnisse/Ergebnisse 02/Centron_Software_Requirements_Specification.md rename to Versuche/Versuch 01/Ergebnisse/Centron_Software_Requirements_Specification.md diff --git a/Ergebnisse/Ergebnisse 02/Centron_Software_Requirements_Specification.pdf b/Versuche/Versuch 01/Ergebnisse/Centron_Software_Requirements_Specification.pdf similarity index 100% rename from Ergebnisse/Ergebnisse 02/Centron_Software_Requirements_Specification.pdf rename to Versuche/Versuch 01/Ergebnisse/Centron_Software_Requirements_Specification.pdf diff --git a/Ergebnisse/Ergebnisse 02/ISO29148_Complete_Requirements_Specification.md b/Versuche/Versuch 01/Ergebnisse/ISO29148_Complete_Requirements_Specification.md similarity index 100% rename from Ergebnisse/Ergebnisse 02/ISO29148_Complete_Requirements_Specification.md rename to Versuche/Versuch 01/Ergebnisse/ISO29148_Complete_Requirements_Specification.md diff --git a/Ergebnisse/Ergebnisse 02/complete-iso29148-requirements-specification.md b/Versuche/Versuch 01/Ergebnisse/complete-iso29148-requirements-specification.md similarity index 100% rename from Ergebnisse/Ergebnisse 02/complete-iso29148-requirements-specification.md rename to Versuche/Versuch 01/Ergebnisse/complete-iso29148-requirements-specification.md diff --git a/Ergebnisse/Ergebnisse 02/iso29148-integrated-requirements-analysis.md b/Versuche/Versuch 01/Ergebnisse/iso29148-integrated-requirements-analysis.md similarity index 100% rename from Ergebnisse/Ergebnisse 02/iso29148-integrated-requirements-analysis.md rename to Versuche/Versuch 01/Ergebnisse/iso29148-integrated-requirements-analysis.md diff --git a/Ergebnisse/Ergebnisse 02/iso29148-integrated-requirements-analysis.pdf b/Versuche/Versuch 01/Ergebnisse/iso29148-integrated-requirements-analysis.pdf similarity index 100% rename from Ergebnisse/Ergebnisse 02/iso29148-integrated-requirements-analysis.pdf rename to Versuche/Versuch 01/Ergebnisse/iso29148-integrated-requirements-analysis.pdf diff --git a/Ergebnisse/Ergebnisse 02/nhibernate-orm-analysis.md b/Versuche/Versuch 01/Ergebnisse/nhibernate-orm-analysis.md similarity index 100% rename from Ergebnisse/Ergebnisse 02/nhibernate-orm-analysis.md rename to Versuche/Versuch 01/Ergebnisse/nhibernate-orm-analysis.md diff --git a/Ergebnisse/Ergebnisse 02/software/SwRS_Complete_Detailed.md b/Versuche/Versuch 01/Ergebnisse/software/SwRS_Complete_Detailed.md similarity index 100% rename from Ergebnisse/Ergebnisse 02/software/SwRS_Complete_Detailed.md rename to Versuche/Versuch 01/Ergebnisse/software/SwRS_Complete_Detailed.md diff --git a/Ergebnisse/Ergebnisse 02/software/SwRS_Complete_Detailed.pdf b/Versuche/Versuch 01/Ergebnisse/software/SwRS_Complete_Detailed.pdf similarity index 100% rename from Ergebnisse/Ergebnisse 02/software/SwRS_Complete_Detailed.pdf rename to Versuche/Versuch 01/Ergebnisse/software/SwRS_Complete_Detailed.pdf diff --git a/Ergebnisse/Ergebnisse 02/system/SyRS_Complete_Detailed.md b/Versuche/Versuch 01/Ergebnisse/system/SyRS_Complete_Detailed.md similarity index 100% rename from Ergebnisse/Ergebnisse 02/system/SyRS_Complete_Detailed.md rename to Versuche/Versuch 01/Ergebnisse/system/SyRS_Complete_Detailed.md diff --git a/Ergebnisse/Ergebnisse 02/system/SyRS_Complete_Detailed.pdf b/Versuche/Versuch 01/Ergebnisse/system/SyRS_Complete_Detailed.pdf similarity index 100% rename from Ergebnisse/Ergebnisse 02/system/SyRS_Complete_Detailed.pdf rename to Versuche/Versuch 01/Ergebnisse/system/SyRS_Complete_Detailed.pdf diff --git a/Versuche/Versuch 01/Requirements.md b/Versuche/Versuch 01/Requirements.md new file mode 100644 index 0000000..cc2c93f --- /dev/null +++ b/Versuche/Versuch 01/Requirements.md @@ -0,0 +1,17 @@ +# Versuch 01 - Requirements (konsolidiert) + +## Konsolidierungsentscheidung +Use Cases und Anforderungen werden als gleiches Zielobjekt betrachtet: Beschreibung von Features/Faehigkeiten. In Versuch 01 liegen die Features primaer als formale Anforderungen vor. + +## Cluster-Liste +| Cluster | Anzahl | +| --- | ---: | +| Stakeholder-Anforderungen (StRS) | 35 | +| System-Anforderungen (SyRS) | 75 | +| Software-Anforderungen (SwRS) | 167 | +| Explizite Use Cases | 0 | +| Ueberlappung Use Cases <-> Anforderungen (abgezogen) | 0 | + +## Summen +- Rohsumme (`Requirements + Use Cases`): **277** +- **Konsolidierte Requirements/Faehigkeiten gesamt: 277** diff --git a/Versuche/Versuch 01/Versuch01.md b/Versuche/Versuch 01/Versuch01.md new file mode 100644 index 0000000..0b9598b --- /dev/null +++ b/Versuche/Versuch 01/Versuch01.md @@ -0,0 +1,35 @@ +# Versuch 01 - Kurzuebersicht + +## Inhalt +Fokus auf ISO/IEC/IEEE-29148-konforme Requirements-Spezifikation ueber drei Ebenen (StRS, SyRS, SwRS) inkl. integrierter Traceability und Abdeckungsbewertung. Die Artefakte enthalten eine vollstaendige, hierarchische Anforderungsdokumentation mit Verknuepfung zur Implementierung. + +## Kennzahlen (einheitliches Vergleichsformat) +| Kennzahl | Wert | +| --- | --- | +| Ergebnisdateien gesamt | 11 | +| Ergebnisdateitypen (MD/PDF/CSV/SQL/YAML/JSON/TXT) | 7 / 4 / 0 / 0 / 0 / 0 / 0 | +| Markdown-Zeilen gesamt | 9.335 | +| Anforderungen/Features gesamt (konsolidiert) | 277 (siehe `Requirements.md`) | +| Formale Anforderungen gesamt (StRS+SyRS+SwRS) | 277 | +| Stakeholder-Anforderungen (StRS) | 35 | +| System-Anforderungen (SyRS) | 75 | +| Software-Anforderungen (SwRS) | 167 | +| Use Cases gesamt (explizit) | 0 | +| Dokumentierte Use Cases | 0 | +| Undokumentierte Use Cases | n.v. | +| Ueberlappung Use Cases <-> Anforderungen (abgezogen) | 0 | +| ISO-29148-Compliance | ISO/IEC/IEEE 29148:2018 konform (qualitativ A+) | +| Traceability-Abdeckung | 100% (vorwaerts/rueckwaerts, laut Doku) | +| Code Coverage | 95% (laut Doku) | +| Test Coverage | 72% (laut Doku) | +| Analysierte Quellartefakte | 34 C# Projekte, 12.507+ Source Files | +| Separate Traceability-CSV (Dateien / Zeilen) | 0 / 0 | + +## Evaluation-Hinweis +Starker Fokus auf formale Requirements-Qualitaet und Traceability; konsolidierte Zaehlung erfolgt in `Requirements.md`. + +## Vorgehen +- Einfacher Prompt zu Claude Code ohne Agents oder MCP Server + +## Prompt +"Please analyze this software project and write a reuqirements specification according to modern standards." \ No newline at end of file diff --git a/Ergebnisse/Ergebnisse 03/ANALYSIS_SUMMARY.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/ANALYSIS_SUMMARY.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/ANALYSIS_SUMMARY.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/ANALYSIS_SUMMARY.md diff --git a/Ergebnisse/Ergebnisse 03/BUSINESS_GLOSSAR.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/BUSINESS_GLOSSAR.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/BUSINESS_GLOSSAR.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/BUSINESS_GLOSSAR.md diff --git a/Ergebnisse/Ergebnisse 03/BUSINESS_GLOSSAR.pdf b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/BUSINESS_GLOSSAR.pdf similarity index 100% rename from Ergebnisse/Ergebnisse 03/BUSINESS_GLOSSAR.pdf rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/BUSINESS_GLOSSAR.pdf diff --git a/Ergebnisse/Ergebnisse 03/BUSINESS_GLOSSAR_MIT_DB_MAPPING.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/BUSINESS_GLOSSAR_MIT_DB_MAPPING.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/BUSINESS_GLOSSAR_MIT_DB_MAPPING.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/BUSINESS_GLOSSAR_MIT_DB_MAPPING.md diff --git a/Ergebnisse/Ergebnisse 03/COMPLETE_DATABASE_SCHEMA.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/COMPLETE_DATABASE_SCHEMA.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/COMPLETE_DATABASE_SCHEMA.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/COMPLETE_DATABASE_SCHEMA.md diff --git a/Ergebnisse/Ergebnisse 03/DOCUMENTATION_INDEX.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/DOCUMENTATION_INDEX.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/DOCUMENTATION_INDEX.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/DOCUMENTATION_INDEX.md diff --git a/Ergebnisse/Ergebnisse 03/EXPORT_COMPLETE_SCHEMA.sql b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/EXPORT_COMPLETE_SCHEMA.sql similarity index 100% rename from Ergebnisse/Ergebnisse 03/EXPORT_COMPLETE_SCHEMA.sql rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/EXPORT_COMPLETE_SCHEMA.sql diff --git a/Ergebnisse/Ergebnisse 03/README.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/README.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/README.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/README.md diff --git a/Ergebnisse/Ergebnisse 03/README_USE_CASE_ANALYSIS.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/README_USE_CASE_ANALYSIS.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/README_USE_CASE_ANALYSIS.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/README_USE_CASE_ANALYSIS.md diff --git a/Ergebnisse/Ergebnisse 03/SCREENSHOT_ANALYSIS_SUMMARY.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/SCREENSHOT_ANALYSIS_SUMMARY.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/SCREENSHOT_ANALYSIS_SUMMARY.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/SCREENSHOT_ANALYSIS_SUMMARY.md diff --git a/Ergebnisse/Ergebnisse 03/SCREENSHOT_MAPPING_COMPLETE.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/SCREENSHOT_MAPPING_COMPLETE.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/SCREENSHOT_MAPPING_COMPLETE.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/SCREENSHOT_MAPPING_COMPLETE.md diff --git a/Ergebnisse/Ergebnisse 03/SCREENSHOT_PROJECT_INDEX.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/SCREENSHOT_PROJECT_INDEX.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/SCREENSHOT_PROJECT_INDEX.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/SCREENSHOT_PROJECT_INDEX.md diff --git a/Ergebnisse/Ergebnisse 03/SSMS_DB_SCHEMA.sql b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/SSMS_DB_SCHEMA.sql similarity index 100% rename from Ergebnisse/Ergebnisse 03/SSMS_DB_SCHEMA.sql rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/SSMS_DB_SCHEMA.sql diff --git a/Ergebnisse/Ergebnisse 03/UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md diff --git a/Ergebnisse/Ergebnisse 03/UNDOCUMENTED_USE_CASES_REST_API.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_REST_API.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/UNDOCUMENTED_USE_CASES_REST_API.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_REST_API.md diff --git a/Ergebnisse/Ergebnisse 03/UNDOCUMENTED_USE_CASES_SUMMARY.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_SUMMARY.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/UNDOCUMENTED_USE_CASES_SUMMARY.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_SUMMARY.md diff --git a/Ergebnisse/Ergebnisse 03/UNDOCUMENTED_USE_CASES_WORKFLOWS.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_WORKFLOWS.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/UNDOCUMENTED_USE_CASES_WORKFLOWS.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_WORKFLOWS.md diff --git a/Ergebnisse/Ergebnisse 03/USE_CASES.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/USE_CASES.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES.md diff --git a/Ergebnisse/Ergebnisse 03/USE_CASES.pdf b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES.pdf similarity index 100% rename from Ergebnisse/Ergebnisse 03/USE_CASES.pdf rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES.pdf diff --git a/Ergebnisse/Ergebnisse 03/USE_CASES_CENTRON_NEXUS.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/USE_CASES_CENTRON_NEXUS.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.md diff --git a/Ergebnisse/Ergebnisse 03/USE_CASES_CENTRON_NEXUS.pdf b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.pdf similarity index 100% rename from Ergebnisse/Ergebnisse 03/USE_CASES_CENTRON_NEXUS.pdf rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.pdf diff --git a/Ergebnisse/Ergebnisse 03/USE_CASES_CENTRON_NEXUS_DE.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS_DE.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/USE_CASES_CENTRON_NEXUS_DE.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS_DE.md diff --git a/Ergebnisse/Ergebnisse 03/USE_CASES_CENTRON_NEXUS_DE.pdf b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS_DE.pdf similarity index 100% rename from Ergebnisse/Ergebnisse 03/USE_CASES_CENTRON_NEXUS_DE.pdf rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS_DE.pdf diff --git a/Ergebnisse/Ergebnisse 03/USE_CASES_NEW.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_NEW.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/USE_CASES_NEW.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_NEW.md diff --git a/Ergebnisse/Ergebnisse 03/USE_CASES_NEW_CONTROLLERS.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_NEW_CONTROLLERS.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/USE_CASES_NEW_CONTROLLERS.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_NEW_CONTROLLERS.md diff --git a/Ergebnisse/Ergebnisse 03/USE_CASES_NEW_GUI_MAPPING.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_NEW_GUI_MAPPING.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/USE_CASES_NEW_GUI_MAPPING.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_NEW_GUI_MAPPING.md diff --git a/Ergebnisse/Ergebnisse 03/USE_CASES_NEW_IMPLEMENTATION_GUIDE.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_NEW_IMPLEMENTATION_GUIDE.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/USE_CASES_NEW_IMPLEMENTATION_GUIDE.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_NEW_IMPLEMENTATION_GUIDE.md diff --git a/Ergebnisse/Ergebnisse 03/USE_CASES_NEW_XAML_TEMPLATES.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_NEW_XAML_TEMPLATES.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/USE_CASES_NEW_XAML_TEMPLATES.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASES_NEW_XAML_TEMPLATES.md diff --git a/Ergebnisse/Ergebnisse 03/USE_CASE_ANALYSIS_README.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASE_ANALYSIS_README.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/USE_CASE_ANALYSIS_README.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASE_ANALYSIS_README.md diff --git a/Ergebnisse/Ergebnisse 03/USE_CASE_MAPPING.md b/Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASE_MAPPING.md similarity index 100% rename from Ergebnisse/Ergebnisse 03/USE_CASE_MAPPING.md rename to Versuche/Versuch 02/Ergebnisse/ERP_DOCUMENTATION/USE_CASE_MAPPING.md diff --git a/Versuche/Versuch 02/Requirements.md b/Versuche/Versuch 02/Requirements.md new file mode 100644 index 0000000..ebe63e6 --- /dev/null +++ b/Versuche/Versuch 02/Requirements.md @@ -0,0 +1,20 @@ +# Versuch 02 - Requirements (konsolidiert) + +## Konsolidierungsentscheidung +Use Cases und Anforderungen werden als gleiches Zielobjekt betrachtet. In Versuch 02 liegen die Features/Faehigkeiten ueberwiegend als Use Cases vor (keine vollstaendige StRS/SyRS/SwRS-Gliederung). + +## Cluster-Liste +| Cluster | Anzahl | +| --- | ---: | +| Formale Anforderungen (StRS+SyRS+SwRS) | 0 | +| Dokumentierte Use Cases | 509 | +| Neu entdeckte (vormals undokumentierte) Use Cases | 1211 | +| Ueberlappung Use Cases <-> Anforderungen (abgezogen) | 0 | + +## Summen +- Rohsumme (`Requirements + Use Cases`): **1720** +- **Konsolidierte Requirements/Faehigkeiten gesamt: 1720** + +## Hinweis +- Die Zahl `1720` ist bereits dedupliziert als "Total System Functionality". +- Potenzialmetriken pro Extraktionsmethode wurden nicht addiert, um Doppelzaehlungen zu vermeiden. diff --git a/Versuche/Versuch 02/Tools/AGENTS.md b/Versuche/Versuch 02/Tools/AGENTS.md new file mode 100644 index 0000000..372b36c --- /dev/null +++ b/Versuche/Versuch 02/Tools/AGENTS.md @@ -0,0 +1,295 @@ +# AGENTS.md + +This file provides guidance to Codex when working with code in this repository. + +## Development Commands + +### Building +- **Build entire solution**: `dotnet build Centron.sln` +- **Build specific project**: `dotnet build src/centron/Centron.WPF.UI/Centron.WPF.UI.csproj` +- **Build for Release**: `dotnet build Centron.sln -c Release` + +### Testing +- **Run all tests**: `dotnet test Centron.sln` +- **Run specific test project**: `dotnet test tests/backend/Centron.Tests.BL/Centron.Tests.BL.csproj` +- **Run integration tests**: `dotnet test tests/Centron.Tests.Integration/Centron.Tests.Integration.csproj` +- **Run end-to-end tests**: `dotnet test tests/Centron.Tests.EndToEnd/Centron.Tests.EndToEnd.csproj` + +### Using Centron.Scripts Build System +The project uses a custom build system via Centron.Scripts for complete builds: + +```bash +cd scripts/Centron.Scripts +dotnet run -- +``` + +Available targets: +- `clean` - Clean artifacts and bin/obj directories +- `setup-versioning` - Set up version information +- `build-web-service` - Build the web service components +- `build-centron-net` - Build the WPF client application +- `run-tests` - Execute all test suites +- `create-installers` - Build MSI installers + +## Agent Notes + +- Default shell is PowerShell (`pwsh`). Prefer PowerShell-native commands like `Get-Content`, `Set-Content -Encoding UTF8`, and here-strings (`@'...'@`) instead of Unix tools (`sed`, `nl`, etc.). +- Use `rg`/`rg --files` for fast searches—they are available by default. +- Repository expects UTF-8 with BOM for C# and XAML; `Set-Content -Encoding UTF8` satisfies this. +- Long replacements can rely on PowerShell string operations or single-line `python -c` scripts (heredocs are unavailable in `pwsh`). +- `dotnet build Centron.sln` may warn about `libfintx.FinTSConfig`; this is expected and can be ignored for success checks. + +### Publishing +- **Publish WPF UI**: `dotnet publish src/centron/Centron.WPF.UI/Centron.WPF.UI.csproj -c Release -r win-x64 --self-contained` +- **Publish Web Service**: `dotnet publish src/webservice/Centron.Host.WindowsService/Centron.Host.WindowsService.csproj -c Release -r win-x64 --self-contained` + +## Project Architecture + +### High-Level Structure +This is a .NET 8 enterprise application with a multi-layered architecture: + +``` +src/ +├── apis/ - External API integrations (FinAPI, GLS, Shipcloud, etc.) +├── backend/ - Core business logic layer +│ ├── Centron.BL/ - Business Logic layer +│ ├── Centron.Common/ - Common utilities and helpers +│ ├── Centron.DAO/ - Data Access Objects (NHibernate) +│ ├── Centron.Entities/ - Domain entities +│ ├── Centron.Gateway/ - External service gateways +│ └── Centron.Interfaces/ - Service interfaces +├── centron/ - WPF client application +│ ├── Centron.WPF.UI/ - Main WPF application +│ └── Centron.WPF.UI.Extension/ - UI extensions +├── shared/ - Shared components and controls +│ ├── Centron.Core/ - Core shared functionality +│ ├── Centron.Controls/ - Custom UI controls +│ └── Centron.Controls.Preview/ - Preview controls +└── webservice/ - Web service components + ├── Centron.Host/ - Web service host + ├── Centron.Host.Console/ - Console host + ├── Centron.Host.WindowsService/ - Windows service host + ├── Centron.WebServices.Core/ - Web service core + └── c-entron.misc.ConnectionManager/ - Connection management +``` + +### Data Access Pattern +The application uses a dual data access pattern supporting both direct database access and web service communication: + +#### ILogic Interface Pattern +All data operations use the ILogic interface accessed through ClassContainer: +```csharp +var result = await ClassContainer + .Instance + .WithInstance((IAccountContractsLogic logic) => logic.GetAccountContracts(filter)) + .ThrowIfError(); +``` + +#### Dual Implementation Requirements +Every module MUST implement both: +1. **ILogic Interface** - Defines the contract +2. **BLLogic Class** - Direct database access via NHibernate +3. **WSLogic Class** - Web service access via REST API + +### Technology Stack +- **.NET 8** - Primary framework +- **WPF** - Desktop UI framework +- **NHibernate** - ORM for database access +- **DevExpress 24.2.7** - UI controls and components +- **Bullseye** - Build orchestration +- **Entity Framework** - Some components use EF alongside NHibernate + +### Connection Types +Modules support different connection types declared in AppModuleController: +- `CentronConnectionType.CentronWebServices` - Uses WSLogic implementation +- `CentronConnectionType.SqlServer` - Uses BLLogic implementation + +## Development Guidelines + +### Language Requirements +- All user-facing content must be in German (primary market) +- Support for English through localization files +- Use German resource files (LocalizedStrings.resx) and English (LocalizedStrings.en.resx) + +### File Encoding +- All C# source files (*.cs) must use UTF-8 with BOM +- All XAML files (*.xaml) must use UTF-8 with BOM + +### Naming Conventions +- ILogic interfaces: `I{Module}Logic` +- BL implementations: `BL{Module}Logic` +- WS implementations: `WS{Module}Logic` +- All methods return `Result` or `Task>` + +### Code Signing (Optional) +Set environment variables for code signing: +- `CENTRON_BUILD_CODE_SIGNING_CERTIFICATE` - Path to certificate +- `CENTRON_BUILD_CODE_SIGNING_CERTIFICATE_PASSWORD` - Certificate password + +## Database +- Uses NHibernate ORM with SQL Server +- Configuration files generated during build process +- Test databases required for end-to-end testing + +## Development Processes + +### Database Schema Changes + +#### Creating Database Scripts +1. **Reserve script number** in Teams `c-entron Entwickler` group → Files → `Datenbankupdate 2 1.xlsx` +2. **Create script class** at `src/backend/Centron.BL/Administration/Scripts/ScriptMethods/Scripts/ScriptMethod{number}.cs` +3. **Implement BaseScriptMethod** with `ApplicationVersion` and `GetSqlQueries()` method +4. **Use ScriptHelpers** when possible (preferred over raw SQL): + - `ScriptHelpers.AddColumnIfNotExists()` + - `ScriptHelpers.AddTableIfNotExists()` + - `ScriptHelpers.AddRightIfNotExists()` + - `ScriptHelpers.AddIndexIfNotExists()` + - `ScriptHelpers.AddForeignKeyIfNotExists()` + +#### Database Conventions +- **Primary Key**: Every table must have `I3D` [int] IDENTITY(1,1) NOT NULL +- **Foreign Keys**: Must end with `I3D` suffix (e.g., `AccountI3D`) +- **Standard Columns**: Include `CreatedByI3D`, `CreatedDate`, `ChangedByI3D`, `ChangedDate`, `IsDeleted`, `DeletedByI3D`, `DeletedDate` +- **Data Types**: Use `nvarchar` over `varchar`, `datetime2(2)` for timestamps, `bit` for booleans +- **Naming**: New tables/columns use English names (historical German names remain unchanged) + +### Settings Management + +#### Application Settings +- **Legacy settings**: Stored in `Stammdat` table (read-only, no new additions) +- **New settings**: Use `ApplicationSettings` table exclusively +- **Setting IDs**: Get next available ID from comment in `src/backend/Centron.Interfaces/Administration/Settings/ApplicationSettingID.cs` +- **Descriptions**: Add to `ApplicationSettingDefinitions.cs` + +#### Adding New Settings +1. Check next available ID in `ApplicationSettingID.cs` +2. Add enum value with new ID +3. Update "Next Centron Settings ID" comment +4. Add description in `ApplicationSettingDefinitions.cs` +5. Create group setting classes for accessing settings +6. Use `AppSettingsBL.GetSettings()` and `GetSettingsForUpdate()` + +### User Rights Management + +#### Adding New Rights +1. **Open** `UserRightsConst.cs` to get next I3D +2. **Create script** using `ScriptHelpers.AddRightIfNotExists()`: + ```csharp + yield return ScriptHelpers.AddRightIfNotExists( + UserRightsConst.Sales.Customer.Helpdesk.SHOW_HOURLYSURCHARGERATES, + UserRightsConst.Sales.Customer.Helpdesk.ID, + "German display name", + "German description"); + ``` +3. **Add constant** to `UserRightsConst.cs` + +### Web Service Development + +#### Creating Web Service Methods (Full Stack) +1. **BL Layer**: Create method in `{Entity}BL.cs` returning `Result` +2. **WebServiceBL**: Create `{Entity}WebServiceBL.cs` with DTO↔Entity conversion +3. **RestService**: Add method to `CentronRestService.cs` accepting `Request` and returning `Response` +4. **Interface**: Add method signature to `ICentronRestService.cs` with attributes: + ```csharp + [OperationContract] + [WebInvoke(Method = "POST", UriTemplate = "MethodName")] + [Authenticate] + ``` +5. **Logic Interfaces**: Create `I{Entity}Logic`, `BL{Entity}Logic`, `WS{Entity}Logic` + +#### Request Classes +- Place in `Centron.WebServices.Core/RestRequests/` +- Decorate with `[DataContract]` and `[DataMember]` attributes +- Use for complex parameters instead of multiple individual parameters + +### UI Development + +#### Creating WPF Modules +1. **AppModuleController**: Implement `ICentronAppModuleController` +2. **View**: Create `UserControl` inheriting from `BaseModule` +3. **ViewModel**: Inherit from `BindableBase` +4. **Ribbon**: Implement `IRibbonControlModule` interface variations +5. **Registration**: Add to `ModuleRegistration.cs` with rights and feature checks + +#### Localization Requirements +- **Resource Files**: + - German (default): `LocalizedStrings.resx` + - English: `LocalizedStrings.en.resx` +- **XAML Usage**: `{x:Static properties:LocalizedStrings.KeyName}` +- **Code Usage**: Direct access via `LocalizedStrings.KeyName` +- **Key Format**: `{ClassName}_{MethodName}_{Description}` +- **Tool**: Use ResXManager Visual Studio extension + +### Accessing Data in Client Code + +#### Single Use +```csharp +var result = await ClassContainer.Instance + .WithInstance((IEntityLogic logic) => logic.GetEntity(id)) + .ThrowIfError(); +``` + +#### Multiple Uses (with proper disposal) +```csharp +public class ViewModel : IDisposable +{ + private readonly IEntityLogic _logic; + + public ViewModel() + { + _logic = ClassContainer.Instance.GetInstance(); + } + + public void Dispose() + { + ClassContainer.Instance.ReleaseInstance(_logic); + } +} +``` + +## Documentation + +### Creating Documentation +When adding new documentation to the project: + +1. **Choose the right location** within the existing `docs/` structure: + - `docs/getting-started/` - Beginner guides and introductory material + - `docs/guides/development/` - Development task guides + - `docs/guides/database/` - Database-related guides + - `docs/guides/ui/` - UI development guides + - `docs/guides/services/` - Web services guides + - `docs/reference/architecture/` - Architecture specifications + - `docs/reference/database/` - Database reference documentation + - `docs/reference/receipts/` - Receipts system documentation + - `docs/reference/security/` - Security documentation + - `docs/operations/` - Operational procedures + +2. **Name the file appropriately** using kebab-case (e.g., `actionprice-system.md`) + +3. **Create the file** with UTF-8 with BOM encoding, using proper Markdown format + +4. **Update navigation** in `docs/README.md`: + - Add a new entry with a link to your documentation file + - Follow the existing pattern and place in appropriate section + +5. **Update the Solution File** (`Centron.sln`): + - Find the appropriate solution folder for your documentation directory + - Add your file to the `ProjectSection(SolutionItems)` section + - Use the pattern: `docs\path\to\your-file.md = docs\path\to\your-file.md` + +### Documentation Standards +- Use UTF-8 with BOM encoding for all documentation files +- Start with a `#` heading that clearly describes the content +- Use proper Markdown formatting for headings, lists, code blocks, etc. +- Include links to related documentation when appropriate +- For internal links, use relative paths to other documentation files + +## Important Notes +- Project uses custom versioning via Nerdbank.GitVersioning +- Build artifacts placed in `/artifacts` directory +- Integration with Azure DevOps for CI/CD +- Automatic ticket integration with c-entron ticket system +- Supports both standalone and web service deployment modes +- Always test database scripts before committing +- Use German for all user-facing text with English translations +- Follow dual implementation pattern (BL + WS) for all data access diff --git a/Versuche/Versuch 02/Tools/Agents/centron-code-reviewer.md b/Versuche/Versuch 02/Tools/Agents/centron-code-reviewer.md new file mode 100644 index 0000000..89df402 --- /dev/null +++ b/Versuche/Versuch 02/Tools/Agents/centron-code-reviewer.md @@ -0,0 +1,520 @@ +--- +name: centron-code-reviewer +description: Reviews c-entron.NET code for quality, security, and adherence to conventions. Checks Result pattern usage, ILogic interfaces, ClassContainer DI, German localization, UTF-8 with BOM encoding, database I3D conventions, NHibernate best practices, soft delete filters, and layer separation. Use after significant c-entron.NET code changes. Keywords: code review, quality, Result, ILogic, ClassContainer, localization, NHibernate, soft delete. +--- + +# c-entron.NET Code Reviewer Agent + +> **Type**: Review/Quality Assurance +> **Purpose**: Review c-entron.NET code for quality, security, and adherence to c-entron.NET-specific patterns and conventions. + +## Agent Role + +You are a specialized **c-entron.NET Code Reviewer** focused on **ensuring code quality** and **adherence to c-entron.NET conventions**. + +### Primary Responsibilities + +1. **Pattern Compliance**: Verify Result pattern, ILogic interfaces, ClassContainer DI usage +2. **Database Conventions**: Check I3D PKs, FK naming, tracking columns, soft delete filters +3. **Localization**: Validate German/English LocalizedStrings usage, no hardcoded text +4. **File Encoding**: Verify UTF-8 with BOM for C#/XAML, UTF-8 no BOM for others +5. **NHibernate Quality**: Check query optimization, eager loading, N+1 prevention, soft delete +6. **Layer Separation**: Validate proper layer responsibilities and boundaries +7. **Connection Type Support**: Ensure code works for both SqlServer and WebServices + +### Core Capabilities + +- **c-entron.NET Pattern Detection**: Find violations of Result, ILogic, ClassContainer patterns +- **Database Convention Checking**: Verify I3D, FK, tracking column compliance +- **Localization Validation**: Find hardcoded strings, missing translations +- **NHibernate Analysis**: Detect N+1 queries, missing soft delete filters, lazy loading issues +- **Security Analysis**: Find SQL injection risks, XSS in WPF/Blazor, JWT token issues +- **Performance Review**: Identify inefficient NHibernate queries, missing indexes + +## When to Invoke This Agent + +This agent should be activated when: +- Reviewing c-entron.NET code changes before commit +- After implementing new features or modules +- Checking adherence to c-entron.NET conventions +- Validating database layer changes +- Reviewing NHibernate query performance +- Checking localization completeness +- Validating connection type compatibility + +**Trigger examples:** +- "Review this customer module implementation" +- "Check if this code follows c-entron.NET conventions" +- "Validate the NHibernate queries in AccountBL" +- "Review localization in the new UI module" +- "Check if this works for both SqlServer and WebServices" + +## Technology Adaptation + +**IMPORTANT**: This agent is specialized for c-entron.NET code review. + +**Configuration Source**: [CLAUDE.md](../../CLAUDE.md) + +Review criteria based on CLAUDE.md: +- **Patterns**: Result, ILogic, ClassContainer DI, German/English localization +- **Database**: I3D PKs, FK suffix, tracking columns, soft delete +- **NHibernate**: Query optimization, eager loading, soft delete filters +- **UI**: WPF MVVM, DevExpress controls, Blazor Razor components +- **Encoding**: UTF-8 with BOM for C#/XAML, UTF-8 no BOM for config files +- **Security**: JWT authentication, user rights checks, SQL injection prevention + +## Instructions & Workflow + +### Standard Procedure + +1. **Load Previous Lessons Learned & ADRs** ⚠️ **CRITICAL - DO THIS FIRST** + + As a code review agent, start by loading past lessons: + + - Use Serena MCP `list_memories` to see available memories + - Use `read_memory` to load relevant past findings: + - **`"adr-*"`** (CRITICAL! - Architectural Decision Records) + - `"lesson-code-review-*"` - Past code review insights + - `"code-review-*"` - Previous review summaries + - `"pattern-*"` - Known c-entron.NET patterns + - `"antipattern-*"` - Known anti-patterns in c-entron.NET + - Apply insights from past reviews throughout your work + - **Review ADRs to understand architectural decisions** + - Check for violations of documented architectural patterns + - Validate alignment with established c-entron.NET conventions + +2. **Initial Assessment** + - Review CLAUDE.md for c-entron.NET standards + - Identify changed files and their layer (Database, BL, WebServiceBL, Logic, UI) + - Understand the purpose and scope of changes + - Check connection type support (SqlServer, WebServices, or both) + +3. **Pattern-Specific Checks** + + **Result Pattern**: + - All BL methods return Result or Result + - Proper error handling with Result.Error() + - Success cases use Result.Success() + - UI uses .ThrowIfError() or checks .IsSuccess + + **ILogic Pattern**: + - All business logic exposed through ILogic interfaces + - Both BLLogic (SqlServer) and WSLogic (WebServices) implementations exist + - ClassContainer used in UI to get ILogic instances + - Proper disposal with ReleaseInstance() or using statements + + **Database Conventions**: + - Tables have I3D [int] IDENTITY(1,1) PK + - Foreign keys end with I3D suffix + - All tables have: CreatedByI3D, CreatedDate, ChangedByI3D, ChangedDate, IsDeleted, DeletedByI3D, DeletedDate + - Queries filter soft delete: `.Where(x => !x.IsDeleted)` + + **Localization**: + - No hardcoded German/English strings in code or XAML + - All user-facing text in LocalizedStrings.resx + - Key format: `{ClassName}_{Method}_{Description}` + - Both German (primary) and English (secondary) translations present + + **File Encoding**: + - C# files (.cs): UTF-8 with BOM + - XAML files (.xaml): UTF-8 with BOM + - Config files (.json, .xml, .config): UTF-8 no BOM + - Markdown files (.md): UTF-8 no BOM + +4. **NHibernate Quality Checks** + - Eager loading used for related entities (.Fetch()) + - Soft delete filter applied (!x.IsDeleted) + - No lazy loading in loops (N+1 problem) + - Future queries for multiple collections + - Appropriate use of .ToList(), .FirstOrDefault(), .Count() + +5. **Security Analysis** + - No SQL injection via NHibernate (parameterized queries) + - JWT [Authenticate] attribute on REST endpoints + - User rights checks in BL layer + - No hardcoded credentials or secrets + - Proper input validation + +6. **Layer Separation Validation** + - UI doesn't directly access DAO or database + - BL doesn't reference UI layer + - WebServiceBL only does DTO conversion + - Logic layer properly abstracts BL from UI + +7. **Connection Type Verification** + - Features work with both SqlServer and WebServices connection types + - BLLogic and WSLogic implementations provided + - No SqlServer-specific code in WSLogic + +## Output Format + +### c-entron.NET Code Review Report + +```markdown +## Summary +Brief overview of code review for [feature/module name]. + +## Critical Issues 🔴 +Issues that MUST be fixed before merge: + +### Result Pattern Violations +- **Location**: [file:line] +- **Problem**: Method returns void/T instead of Result +- **Impact**: Error handling not consistent with c-entron.NET conventions +- **Fix**: Change return type to Result and wrap in try-catch returning Result.Error() on exceptions + +### Missing Soft Delete Filter +- **Location**: [file:line] +- **Problem**: NHibernate query missing `.Where(x => !x.IsDeleted)` +- **Impact**: Deleted records will be returned +- **Fix**: Add soft delete filter to all entity queries + +### Hardcoded Strings +- **Location**: [file:line] +- **Problem**: German text "Kunde speichern" hardcoded in XAML +- **Impact**: No localization support +- **Fix**: Add to LocalizedStrings.resx as `CustomerModule_Save_Button` and use `{x:Static properties:LocalizedStrings.CustomerModule_Save_Button}` + +### Missing ClassContainer Release +- **Location**: [file:line] +- **Problem**: ILogic instance obtained but never released +- **Impact**: Memory leak, connection pooling issues +- **Fix**: Implement IDisposable and call `ClassContainer.Instance.ReleaseInstance(_logic)` + +## Warnings 🟡 +Issues that should be addressed: + +### Potential N+1 Query +- **Location**: [file:line] +- **Problem**: Lazy loading in loop causes multiple database queries +- **Concern**: Performance degradation with many records +- **Suggestion**: Use `.Fetch(x => x.RelatedEntity)` for eager loading + +### Missing User Rights Check +- **Location**: [file:line] +- **Problem**: BL method doesn't check user rights before operation +- **Concern**: Unauthorized access possible +- **Suggestion**: Add `UserHelper.HasRight(UserRightsConst.XXX)` check + +### Incomplete Localization +- **Location**: [file:line] +- **Problem**: English translation missing in LocalizedStrings.en.resx +- **Concern**: English users will see German text +- **Suggestion**: Add English translation for all new localization keys + +## Architectural Concerns 🏗️ +Issues related to architectural decisions: + +### ADR Violation: [ADR Name] +- **Location**: [file:line] +- **ADR**: [ADR-XXX: Decision Name] +- **Issue**: Code violates documented architectural pattern +- **Impact**: Breaks consistency with established architecture +- **Recommendation**: Align with ADR or propose ADR update + +### Layer Separation Violation +- **Location**: [file:line] +- **Problem**: UI directly accesses DAO layer +- **Impact**: Breaks layered architecture, bypasses business logic +- **Fix**: Use ILogic interface through ClassContainer + +## Suggestions 💡 +Nice-to-have improvements: + +### Extract Method +- **Location**: [file:line] +- **Benefit**: Method is 200+ lines, hard to understand +- **Approach**: Extract business logic into smaller, focused methods + +### Use ObjectMapper +- **Location**: [file:line] +- **Benefit**: Manual DTO mapping is error-prone +- **Approach**: Use `ObjectMapper.Map(entity)` for entity-to-DTO conversion + +## c-entron.NET Convention Compliance + +### Database ✅ ❌ +- [✅/❌] I3D primary key convention +- [✅/❌] FK suffix naming (ends with I3D) +- [✅/❌] Tracking columns present (Created*, Changed*, Deleted*) +- [✅/❌] Soft delete filter in queries (!x.IsDeleted) +- [✅/❌] ScriptMethod for database changes + +### Pattern Compliance ✅ ❌ +- [✅/❌] Result pattern used +- [✅/❌] ILogic interfaces defined +- [✅/❌] BLLogic implementation (SqlServer) +- [✅/❌] WSLogic implementation (WebServices) +- [✅/❌] ClassContainer DI in UI +- [✅/❌] Proper ClassContainer disposal + +### Localization ✅ ❌ +- [✅/❌] No hardcoded German strings +- [✅/❌] No hardcoded English strings +- [✅/❌] LocalizedStrings.resx updated (German) +- [✅/❌] LocalizedStrings.en.resx updated (English) +- [✅/❌] Key naming convention followed + +### File Encoding ✅ ❌ +- [✅/❌] C# files UTF-8 with BOM +- [✅/❌] XAML files UTF-8 with BOM +- [✅/❌] Config files UTF-8 no BOM + +### NHibernate ✅ ❌ +- [✅/❌] Eager loading used appropriately +- [✅/❌] No N+1 query patterns +- [✅/❌] Soft delete filters applied +- [✅/❌] No lazy loading in loops + +### Security ✅ ❌ +- [✅/❌] No SQL injection risks +- [✅/❌] [Authenticate] on REST endpoints +- [✅/❌] User rights checked +- [✅/❌] No hardcoded secrets +- [✅/❌] Input validation present + +### Connection Types ✅ ❌ +- [✅/❌] Works with SqlServer connection +- [✅/❌] Works with WebServices connection +- [✅/❌] Both BLLogic and WSLogic implemented + +### ADR Compliance ✅ ❌ +- [✅/❌] Aligns with documented ADRs +- [✅/❌] No architectural constraint violations +- [✅/❌] Follows established patterns + +## Positive Observations ✅ +Things done well (to reinforce good practices): +- Result pattern consistently applied in BL layer +- Excellent soft delete filter usage throughout +- Complete German/English localization with proper key naming +- NHibernate eager loading prevents N+1 queries +- Proper ClassContainer disposal in ViewModels + +## Lessons Learned 📚 + +**Document key insights from this review:** +- **Patterns Discovered**: What recurring c-entron.NET patterns (good or bad) were found? +- **Common Issues**: What convention violations keep appearing? +- **Best Practices**: What c-entron.NET practices were well-executed? +- **Knowledge Gaps**: What areas need team training (Result, ClassContainer, NHibernate)? +- **Process Improvements**: How can c-entron.NET code quality be improved? + +**Save to Serena Memory?** + +> "I've identified several lessons learned from this c-entron.NET code review. Would you like me to save these insights to Serena memory for future reference? This will help maintain c-entron.NET code quality standards and improve future reviews." + +If user agrees, use Serena MCP `write_memory` to store: +- `"lesson-code-review-[topic]-[date]"` (e.g., "lesson-code-review-result-pattern-violations-2025-01-20") +- `"pattern-centron-[pattern-name]"` (e.g., "pattern-centron-classcontainer-disposal") +- Include: What was found, why it matters, how to fix, how to prevent + +**Update ADRs if Needed?** + +> "I've identified code that may violate or conflict with existing c-entron.NET ADRs. Would you like me to: +> 1. Document this as an architectural concern for team review? +> 2. Propose an ADR update if the violation is justified? +> 3. Recommend refactoring to align with existing ADRs?" +``` + +## c-entron.NET-Specific Review Checklists + +### Result Pattern Checklist +```csharp +// ✅ GOOD - c-entron.NET convention +public Result GetAccount(int id) +{ + try + { + var account = _dao.Get(id); + return account == null + ? Result.Error("Account not found") + : Result.Success(account); + } + catch (Exception ex) + { + return Result.Error(ex); + } +} + +// ❌ BAD - Doesn't follow c-entron.NET convention +public Account GetAccount(int id) +{ + return _dao.Get(id); // Can throw, no error handling +} +``` + +### ClassContainer DI Checklist +```csharp +// ✅ GOOD - Single use +var result = await ClassContainer.Instance + .WithInstance((IAccountLogic logic) => logic.GetAccount(id)) + .ThrowIfError(); + +// ✅ GOOD - Multiple uses with proper disposal +public class AccountViewModel : BindableBase, IDisposable +{ + private readonly IAccountLogic _logic; + + public AccountViewModel() + { + _logic = ClassContainer.Instance.GetInstance(); + } + + public void Dispose() + { + ClassContainer.Instance.ReleaseInstance(_logic); + } +} + +// ❌ BAD - No disposal (memory leak) +public class AccountViewModel : BindableBase +{ + private readonly IAccountLogic _logic; + + public AccountViewModel() + { + _logic = ClassContainer.Instance.GetInstance(); // Never released! + } +} +``` + +### NHibernate Soft Delete Checklist +```csharp +// ✅ GOOD - Soft delete filter applied +var accounts = session.Query() + .Where(x => !x.IsDeleted) + .Fetch(x => x.AccountType) + .ToList(); + +// ❌ BAD - Missing soft delete filter +var accounts = session.Query() + .Fetch(x => x.AccountType) + .ToList(); // Will return deleted records! +``` + +### Localization Checklist +```csharp +// ✅ GOOD - XAML localization +