# New Use-Cases Discovered from Screenshots - CentronNexus Live Analysis

**Date**: 2025-11-24
**Source**: Live screenshot analysis from 5 authenticated CentronNexus modules
**Backend**: https://erp.c-entron.de/demo
**Data Samples Analyzed**: 10+ customers, 7+ tickets, comprehensive UI patterns

---

## Overview

This document details **9 new sub-use-cases** discovered through visual analysis of authenticated screenshots from CentronNexus. Each use-case extends existing documented functionality with specific features and workflows that were not explicitly documented in the main USE_CASES.md file.

---

# TICKET MANAGEMENT ENHANCEMENTS

## UC-3.2.1: Advanced Ticket Filtering with Dual-Tier System

### Use Case Details

**ID**: 3.2.1
**Category**: Ticket Management
**Base UseCase**: 3.2 Ticket-Liste
**Complexity**: Medium
**Priority**: High

### Description

Users can apply multiple filter criteria using a dual-tier filtering system:
- **"Nur" (Only)**: Positive filters - show tickets matching these criteria
- **"Auch" (Also)**: Inclusive filters - additionally include tickets matching these criteria

This allows complex filtering like: "Show open high-priority tickets AND also show all tickets from customer X" or "Show my assigned tickets BUT exclude test tickets."

### Business Value

- Faster ticket discovery for specific scenarios
- Reduced need for multiple searches
- Support for complex reporting queries
- Improves productivity for technicians switching between ticket subsets

### User Roles

- **Primary**: Technicians, Support Agents
- **Secondary**: Team Leads, Managers
- **Tertiary**: Customers (if enabled)

### Actors

```
1. Technician/Support Agent
   - Can apply multiple filters
   - Can combine "Nur" and "Auch" filters
   - Can save filter combinations

2. System
   - Evaluates filter combinations
   - Returns matching ticket set
   - Persists filter preferences
```

### Preconditions

- User is authenticated
- User has Ticket-Liste access rights
- At least 2 filter criteria are available

### Main Flow

```
1. User navigates to Ticket-Liste
2. User opens filter panel
3. User selects "Nur" (Only) filters:
   - Status: "offen" (Open)
   - Priority: "hoch" (High)
4. User selects "Auch" (Also) filters:
   - Category: "Test"
5. System applies both filter sets
6. System displays combined results
7. User can save this filter combination for future use
```

### Alternate Flows

**AF1: Clear and Reset Filters**
```
1. User clicks filter reset button
2. System clears all "Nur" and "Auch" selections
3. System displays all tickets (with standard defaults)
```

**AF2: Save Filter Combination**
```
1. User applies "Nur" and "Auch" filters
2. User clicks "speichern" (Save)
3. System prompts for filter name
4. System saves combination to user preferences
5. Combination appears in sidebar for quick access
```

**AF3: Load Saved Filter**
```
1. User sees saved filter in sidebar
2. User clicks saved filter name
3. System applies all associated filter criteria
4. System displays filtered ticket set
```

### Postconditions

- Filtered ticket list is displayed
- All matching tickets are visible
- Filter state is preserved for session
- Optionally saved for future use

### Data Requirements

**Input**:
- Filter criteria selections
- Filter combination logic (AND/OR)
- User preferences storage

**Output**:
- Filtered ticket dataset
- Count of matching tickets
- Applied filter summary

### UI Elements Involved

- Sidebar filter categories
- Toggle switches for "Nur"/"Auch"
- Checkboxes for filter values
- Save button
- Filter reset button
- Applied filters indicator

### Technical Considerations

**Backend Requirements**:
- Dynamic query building from filter combinations
- Efficient filtering on large ticket sets
- Filter preference persistence (user settings)
- Real-time result count updates

**Performance**:
- Client-side: Filter UI response < 100ms
- Server-side: Query execution < 500ms for 10,000 tickets
- Cache saved filter combinations

### Edge Cases

- User selects conflicting "Nur"/"Auch" criteria (e.g., "Nur: open" and "Auch: closed")
  - **Resolution**: System treats as union of both sets
- Very large result sets (10,000+ tickets)
  - **Resolution**: Implement pagination/virtual scrolling
- Empty result sets
  - **Resolution**: Show "No tickets match filters" message

### Related Use Cases

- 3.2 Ticket-Liste (parent)
- 3.2.3 Ticket Search (search within filters)
- 3.1 Ticket-Details (drill down from filtered list)

### Testing Scenarios

1. **T1**: Apply single "Nur" filter - verify results show only matching tickets
2. **T2**: Apply both "Nur" and "Auch" filters - verify combined results
3. **T3**: Save filter combination - verify retrieval and re-application
4. **T4**: Clear filters - verify all tickets display
5. **T5**: Apply conflicting filters - verify system behavior
6. **T6**: Search within filtered set - verify interaction
7. **T7**: Change sort order on filtered set - verify independence

---

## UC-3.2.2: Ticket List Customization and Layout Persistence

### Use Case Details

**ID**: 3.2.2
**Category**: Ticket Management
**Base UseCase**: 3.2 Ticket-Liste
**Complexity**: Medium
**Priority**: Medium

### Description

Users can customize which columns are displayed in the ticket list table and save these layout preferences. This allows each user to have a personalized view focused on the data most relevant to their role.

### Business Value

- Reduced cognitive load by showing only relevant columns
- Role-specific views (e.g., technician vs manager)
- Faster data scanning with relevant information visible
- Professional appearance with clean, focused interface

### User Roles

- **Primary**: All ticket list users (Technicians, Support Agents, Managers, Customers)
- **Secondary**: Admin users (setting default layouts)

### Actors

```
1. User
   - Can select/deselect columns
   - Can reorder columns
   - Can resize columns
   - Can save layout
   - Can load saved layouts

2. System
   - Persists layout preferences
   - Applies layout on page load
   - Maintains column metadata
```

### Preconditions

- User is viewing Ticket-Liste
- At least 1 column must remain visible

### Main Flow

```
1. User clicks "Layout" or "View Options" button
2. System shows column selection dialog/panel
3. User checks/unchecks columns to customize view:
   - Toggle "Kundennummer" (Customer Number)
   - Toggle "Erstellt am" (Created Date)
   - Toggle "Fällig z..." (Due Date)
   - Others as applicable
4. User can drag columns to reorder (optional)
5. User clicks "speichern" (Save) button
6. System persists layout to user preferences
7. Layout is applied immediately
8. Layout persists across sessions
```

### Alternate Flows

**AF1: Reset to Default Layout**
```
1. User clicks "Reset Layout" button
2. System shows confirmation dialog
3. User confirms reset
4. System restores default column set
5. System applies default layout
```

**AF2: Multiple Saved Layouts**
```
1. User creates layout "Technical View" (tech-focused columns)
2. User creates layout "Manager View" (summary-focused columns)
3. User can switch between layouts quickly
4. System labels layouts with descriptive names
```

**AF3: Export Current Layout**
```
1. User right-clicks layout name
2. User selects "Export Settings"
3. System generates layout configuration file
4. User can share with team members
```

### Postconditions

- Custom layout is displayed
- Layout is saved to user profile
- Layout persists across sessions
- Other users are not affected

### Data Requirements

**Input**:
- Column visibility preferences
- Column order sequence
- Column width preferences
- Layout name (if saved multiple layouts)

**Output**:
- Customized ticket list display
- Saved layout configuration
- Layout switcher interface (if multiple layouts)

### UI Elements Involved

- "Layout" or "View Options" button
- Column selection checklist
- Drag-and-drop column reordering
- Column width resize handles
- "speichern" (Save) button
- "Reset to Default" button
- Layout selector dropdown (if multiple layouts supported)

### Technical Considerations

**Backend Requirements**:
- User preference storage (column visibility, order, width)
- Layout versioning (schema changes)
- Default layout management
- Performance impact on page load

**Frontend**:
- Column metadata storage
- Persistent table state
- Responsive column widths
- Column resize interactions

**Performance**:
- Layout retrieval on page load < 100ms
- Column reordering/resizing smooth at 60fps
- Storage: ~1KB per layout

### Edge Cases

- User deletes all columns (prevented - at least 1 required)
- Screen resolution change (responsive columns)
- Table data changes (column headers update automatically)
- Columns added/removed by system update
  - **Resolution**: Auto-add new columns to default position, keep hidden if not in saved preference

### Related Use Cases

- 3.2 Ticket-Liste (parent)
- 3.2.1 Advanced Ticket Filtering (works with layout)
- 3.2.3 Ticket Search (works with layout)

### Testing Scenarios

1. **T1**: Select columns and save - verify retrieval
2. **T2**: Reorder columns - verify order persistence
3. **T3**: Resize columns - verify width persistence
4. **T4**: Reset to default - verify restoration
5. **T5**: Create multiple layouts - verify switching
6. **T6**: Login/logout - verify layout persistence
7. **T7**: Customize on different screen sizes - verify responsiveness

---

## UC-3.2.3: Full-Text Ticket Search

### Use Case Details

**ID**: 3.2.3
**Category**: Ticket Management
**Base UseCase**: 3.2 Ticket-Liste
**Complexity**: Low-Medium
**Priority**: High

### Description

Users can search for tickets using a full-text search field "In Liste suchen..." (Search in list) that searches across visible ticket fields in real-time, providing instant search results.

### Business Value

- Fast ticket lookup without navigating multiple views
- Reduces time to find specific tickets
- Improves user satisfaction
- Alternative to filter-based search

### User Roles

- **Primary**: All ticket list users
- **Secondary**: Customers (if enabled)

### Actors

```
1. User
   - Types search query
   - Reviews search results
   - Clicks result to view ticket

2. System
   - Performs full-text search
   - Returns results in real-time
   - Highlights search terms
```

### Preconditions

- User is viewing Ticket-Liste
- At least 1 ticket exists

### Main Flow

```
1. User navigates to Ticket-Liste
2. User clicks search field "In Liste suchen..."
3. User types search query (e.g., "printer problem")
4. System filters tickets in real-time
5. System displays matching tickets below search field
6. System highlights search term in results
7. User clicks matching ticket from results
8. System navigates to ticket details
```

### Alternate Flows

**AF1: Search Within Filtered Results**
```
1. User applies filters (e.g., "Open tickets only")
2. User types search query in search field
3. System searches only within filtered set
4. System displays matching tickets from filtered set
```

**AF2: Clear Search**
```
1. User clicks "X" button in search field
2. System clears search query
3. System returns to full ticket list (or filtered list if filters applied)
```

**AF3: Search Suggestions**
```
1. User starts typing search query
2. System shows auto-complete suggestions:
   - Recent searches
   - Popular search terms
   - Suggested ticket fields
3. User clicks suggestion
4. System performs search for suggested term
```

### Postconditions

- Filtered list of matching tickets is displayed
- Search state is displayed (query visible in field)
- User can navigate to matching tickets

### Data Requirements

**Input**:
- Search query string
- Current filter state (if applicable)
- Current column set (if applicable)

**Output**:
- Filtered ticket list
- Result count
- Highlighted matches
- Search result metadata

### UI Elements Involved

- Search input field with placeholder "In Liste suchen..."
- Clear ("X") button
- Search result indicators
- Result counter ("5 tickets found")
- Highlighted search terms
- Search history (optional)

### Technical Considerations

**Search Scope**:
- Ticket number
- Ticket title/subject
- Customer name
- Ticket description
- Tags/categories

**Performance**:
- Real-time search (< 200ms latency)
- Index-backed search for large ticket sets
- Client-side filtering for small datasets
- Debounce search input (wait 300ms after typing stops)

**Edge Cases**:
- Search query with special characters (escape/sanitize)
- Empty search query (show all results)
- Very broad search results (10,000+ matches)
  - **Resolution**: Show top 100, offer refining search
- Search query with wildcards or regex
  - **Resolution**: Support if backend allows, otherwise literal search

### Related Use Cases

- 3.2 Ticket-Liste (parent)
- 3.2.1 Advanced Ticket Filtering (complementary)
- 3.2.2 Ticket List Customization (works with layout)

### Testing Scenarios

1. **T1**: Search for partial ticket number - verify matching tickets
2. **T2**: Search for customer name - verify results
3. **T3**: Search with multiple keywords - verify "AND" logic
4. **T4**: Search within filtered results - verify scope
5. **T5**: Clear search - verify return to full list
6. **T6**: Search with special characters - verify handling
7. **T7**: Empty search field - verify all results

---

# CUSTOMER MANAGEMENT ENHANCEMENTS

## UC-8.1.1: Advanced Customer Search

### Use Case Details

**ID**: 8.1.1
**Category**: Customer Management
**Base UseCase**: 8.1 Kundendaten
**Complexity**: Low-Medium
**Priority**: High

### Description

Users can search for customers using the "Kunden suchen..." (Customer search) field, which performs full-text search across customer data fields including company name, contact person, address, and phone number.

### Business Value

- Rapid customer lookup
- Reduces time to find customer information
- Enables quick customer-related ticket creation
- Improves customer service response time

### User Roles

- **Primary**: Support staff, Sales team, Admin
- **Secondary**: Technicians (for ticket assignment)

### Actors

```
1. User
   - Enters search query
   - Reviews search results
   - Selects customer

2. System
   - Performs customer search
   - Returns matching customers
   - Highlights matches
```

### Preconditions

- User has access to Kunden-Übersicht
- At least 1 customer record exists

### Main Flow

```
1. User navigates to Kunden-Übersicht
2. User clicks search field "Kunden suchen..."
3. User types search query (e.g., "ABC GmbH" or "Werner")
4. System searches customer fields in real-time:
   - Firmenname (Company name)
   - Ansprechpartner (Contact person)
   - Straße (Street address)
   - Kundennummer (Customer number)
   - Telefon (Phone number)
5. System displays matching customers below search field
6. System highlights search term in results
7. User clicks matching customer
8. System displays customer details
```

### Alternate Flows

**AF1: Search by Phone Number**
```
1. User types partial phone number (e.g., "28359")
2. System searches phone field
3. System returns matching customer
4. User selects customer
```

**AF2: Search by Contact Person Name**
```
1. User types contact person name (e.g., "Werner Brösel")
2. System searches "Ansprechpartner" field
3. System returns customers with matching contact
4. User selects customer
```

**AF3: Search with Geographic Location**
```
1. User types city name (e.g., "Bremen")
2. System searches Stadt (City) field
3. System returns customers in that city
4. User selects customer
```

### Postconditions

- Matching customers are displayed
- User can select customer to view details
- Search state is preserved

### Data Requirements

**Input**:
- Search query string
- Current filter state (active/inactive)

**Output**:
- Filtered customer list
- Result count
- Highlighted search terms

### UI Elements Involved

- Search field "Kunden suchen..." with placeholder
- Clear button
- Search results display
- Result counter
- Highlighted search terms
- Customer link/selection

### Technical Considerations

**Search Scope**:
- Company name (Firmenname)
- Contact person (Ansprechpartner)
- Street address (Straße)
- Postal code (PLZ)
- City (Stadt)
- Phone (Telefon)
- Customer number (Kundennummer)
- Matchcode

**Performance**:
- Real-time search (< 200ms)
- Index-backed search for large customer base
- Debounce: 300ms after typing stops
- Cache customer search results

**Edge Cases**:
- Duplicate customer entries
- Partial address matches
- Phone number formatting variations
- Empty search (show all active/inactive based on filter)

### Related Use Cases

- 8.1 Kundendaten (parent)
- 8.1.2 Customer Status Management (works with status filter)
- 3.2 Ticket-Liste (linked when creating tickets)

### Testing Scenarios

1. **T1**: Search by company name - verify exact/partial matches
2. **T2**: Search by contact person name - verify results
3. **T3**: Search by city/postal code - verify location search
4. **T4**: Search by phone number - verify number search
5. **T5**: Search returns multiple matches - verify sorting
6. **T6**: Search with special characters - verify handling
7. **T7**: Case-insensitive search - verify "ABC" matches "abc"

---

## UC-8.1.2: Customer Status Management with Filtering

### Use Case Details

**ID**: 8.1.2
**Category**: Customer Management
**Base UseCase**: 8.1 Kundendaten
**Complexity**: Low
**Priority**: Medium

### Description

Users can toggle between viewing active and inactive customers using the "aktive Kunden" (Active customers) filter switch. This allows management of customer lifecycle while preserving historical data through soft-delete patterns.

### Business Value

- Manage customer lifecycle without data loss
- Separate active business from historical records
- Support dormant/inactive customer scenarios
- Compliance with data retention policies
- Flexible customer status management

### User Roles

- **Primary**: Admin, Sales management
- **Secondary**: Support staff
- **Tertiary**: Technicians (read-only active customers)

### Actors

```
1. User/Admin
   - Toggles active/inactive filter
   - Can mark customers as inactive
   - Can reactivate customers

2. System
   - Filters customer list by status
   - Manages customer status field
   - Logs status changes
```

### Preconditions

- User has access to Kunden-Übersicht
- At least 1 active customer exists
- User has rights to change customer status

### Main Flow

```
1. User navigates to Kunden-Übersicht
2. System displays active customers by default
3. Toggle "aktive Kunden" is ON (showing active)
4. User can toggle switch OFF to see inactive customers
5. System displays inactive customers instead
6. User can toggle back ON to see active customers again
7. User can toggle ON and OFF to compare lists
```

### Alternate Flows

**AF1: Deactivate a Customer**
```
1. User right-clicks on active customer in list
2. User selects "Deactivate" from context menu
3. System prompts for confirmation
4. User confirms deactivation
5. System marks customer as inactive (IsDeleted = true)
6. Customer disappears from active list
7. Customer appears in inactive list (if viewing)
8. System logs deactivation event
```

**AF2: Reactivate a Customer**
```
1. User toggles to show inactive customers
2. User finds customer to reactivate
3. User right-clicks inactive customer
4. User selects "Reactivate" from context menu
5. System marks customer as active (IsDeleted = false)
6. Customer disappears from inactive list
7. Customer reappears in active list
8. System logs reactivation event
```

**AF3: Show All Customers (Admin Only)**
```
1. Admin has additional "Show Archived" toggle
2. Admin toggles to see all customers (active + inactive)
3. System displays complete customer history
4. Admin can query/report on all customers
```

### Postconditions

- Filtered customer list is displayed
- Filter state is preserved for session
- Status changes are logged to audit trail

### Data Requirements

**Input**:
- Customer status (active/inactive)
- Filter toggle state
- Status change timestamp
- User who made change

**Output**:
- Filtered customer list
- Status indicator
- Change history/audit trail

### UI Elements Involved

- Toggle switch "aktive Kunden" (ON/OFF)
- Status indicator per customer row
- Context menu (deactivate/reactivate)
- Confirmation dialog
- Status history view (optional)

### Technical Considerations

**Database**:
- Customer.IsDeleted field
- Customer.DeletedDate field
- Customer.DeletedByI3D field (audit trail)
- Status-based query filtering

**Data Integrity**:
- Cannot delete customer if active tickets exist
- Linked ticket data remains queryable
- Historical reports include all customers
- Soft-delete pattern (no physical deletion)

**Performance**:
- Separate indexes on Customer.IsDeleted
- Efficient status toggle queries
- Change logging doesn't block UI

**Edge Cases**:
- Customer has active tickets
  - **Resolution**: Prevent deactivation, show warning
- Reactivate customer with duplicate name
  - **Resolution**: Allow (different record)
- Mass deactivation scenario
  - **Resolution**: Bulk deactivation feature

### Related Use Cases

- 8.1 Kundendaten (parent)
- 8.1.1 Advanced Customer Search (works with status)
- 3.2 Ticket-Liste (tickets link to customers)

### Testing Scenarios

1. **T1**: Toggle "aktive Kunden" ON - verify active customers display
2. **T2**: Toggle "aktive Kunden" OFF - verify inactive customers display
3. **T3**: Deactivate active customer - verify disappears from active list
4. **T4**: Reactivate inactive customer - verify appears in active list
5. **T5**: Deactivate customer with active tickets - verify warning
6. **T6**: Status change is logged to audit trail
7. **T7**: Page refresh preserves filter state

---

## UC-8.1.3: Contact Person Management and Tracking

### Use Case Details

**ID**: 8.1.3
**Category**: Customer Management
**Base UseCase**: 8.1 Kundendaten
**Complexity**: Medium
**Priority**: Medium

### Description

The system tracks and manages primary contact persons ("Ansprechpartner") for each customer, enabling better communication routing and relationship management. Support staff can assign and modify contact information.

### Business Value

- Ensures correct communication with appropriate decision-makers
- Improves ticket routing accuracy
- Tracks relationship changes
- Supports multi-level communication
- Enables relationship continuity

### User Roles

- **Primary**: Sales, Account management, Support
- **Secondary**: Admin, Technicians

### Actors

```
1. Account Manager
   - Views contact person for customer
   - Updates contact person information
   - Tracks contact person changes

2. Technician
   - Views assigned contact person
   - May suggest contact person updates

3. System
   - Stores contact person per customer
   - Logs contact person changes
   - Routes tickets to contact person
```

### Preconditions

- User has access to customer record
- User has rights to modify customer data
- At least 1 customer exists

### Main Flow

```
1. User opens customer details page
2. System displays "Ansprechpartner" (Contact Person) field
3. System shows current contact person information:
   - Name
   - Phone
   - Email (if available)
4. User can click to edit contact person
5. User selects from existing contacts or adds new
6. User saves changes
7. System updates contact person record
8. System logs change in audit trail
9. Future tickets from/to this customer route to new contact
```

### Alternate Flows

**AF1: Add Multiple Contact Persons**
```
1. User clicks "Add Contact" button
2. System adds new contact person field
3. User enters second contact person details
4. System marks one as "Primary"
5. System saves multiple contacts
6. System allows routing to any contact
```

**AF2: Contact Person History**
```
1. User clicks "Contact History" button
2. System displays timeline of contact person changes:
   - Date, old contact, new contact, changed by
3. User can view historical routing
4. User can revert to previous contact if needed
```

**AF3: Contact Person Search**
```
1. User starts typing contact name
2. System shows suggestions from:
   - This customer's past contacts
   - Other customers' contacts
   - Company directory
3. User selects from suggestions
4. System auto-fills contact details
```

### Postconditions

- Contact person is updated
- Change is logged to audit trail
- New contact appears in system
- Tickets route to new contact if configured

### Data Requirements

**Input**:
- Contact person name (Ansprechpartner)
- Contact person phone
- Contact person email
- Primary/secondary designation

**Output**:
- Updated customer record
- Contact history audit trail
- Contact verification status

### UI Elements Involved

- Contact person display field
- Edit contact button
- Contact name input field
- Phone field
- Email field
- Primary/secondary radio buttons
- Add contact button
- Contact history button
- Suggestions dropdown

### Technical Considerations

**Database Schema**:
- Customer.PrimaryContactI3D (FK to Contact)
- Contact table with name, phone, email
- Contact history audit trail
- Support for multiple contacts per customer

**Data Integrity**:
- Validate phone number format
- Validate email format
- Track all contact changes
- Support contact person lookup

**Performance**:
- Contact information fetched with customer
- Contact history limited to recent changes
- Efficient contact search/suggestions

**Edge Cases**:
- Contact person leaves company
  - **Resolution**: Mark as inactive, assign new contact
- Same contact person at multiple customers
  - **Resolution**: Support multiple references to same person
- Contact person email/phone changes
  - **Resolution**: Update versioning and history
- Delete contact person record
  - **Resolution**: Soft delete, preserve history

### Related Use Cases

- 8.1 Kundendaten (parent)
- 3.1 Ticket-Details (contact routing)
- 8.3 Kundendetails (extended contact management)

### Testing Scenarios

1. **T1**: View contact person for customer - verify display
2. **T2**: Edit contact person - verify update
3. **T3**: Add multiple contact persons - verify storage
4. **T4**: View contact history - verify audit trail
5. **T5**: Revert to previous contact - verify functionality
6. **T6**: Search existing contacts - verify suggestions
7. **T7**: Validate contact information - verify validation rules

---

# DAILY PLANNING ENHANCEMENTS

## UC-6.2.1: Daily Task Management

### Use Case Details

**ID**: 6.2.1
**Category**: Daily Planning
**Base UseCase**: 6.2 Mein Tag (MyDay)
**Complexity**: Medium
**Priority**: High

### Description

Users can view, create, and manage tasks scheduled specifically for today. The system provides a focused, today-scoped view of work activities separate from the general ticket list, enabling users to focus on immediate priorities.

### Business Value

- Improved focus on immediate work priorities
- Reduced context switching between today's work and all tickets
- Better time management
- Daily planning capability
- Work tracking for the current day

### User Roles

- **Primary**: All staff (Technicians, Support agents, Managers)
- **Secondary**: Customers (if enabled for ticketed items)

### Actors

```
1. Employee/Technician
   - Views today's tasks
   - Marks tasks complete
   - Creates new tasks for today
   - Reorders task priority

2. Manager
   - Views team's daily tasks
   - Adjusts daily assignments

3. System
   - Generates daily task view
   - Filters tickets/tasks for today
   - Tracks completion status
```

### Preconditions

- User is authenticated
- User has work assigned for today or previous days

### Main Flow

```
1. User navigates to "Mein Tag" (My Day) view
2. System displays today's scheduled tasks
3. System shows tasks from:
   - Tickets assigned to user with today's due date
   - Scheduled time blocks/activities
   - Personal tasks/reminders
4. Each task shows:
   - Task name/description
   - Estimated duration
   - Priority level
   - Related ticket/customer
5. User can mark task complete
6. System updates task status
7. User can create new task for today
8. System adds task to today's list
```

### Alternate Flows

**AF1: Add Task to Today**
```
1. User clicks "Add Task" button
2. System shows new task form
3. User enters task description
4. User sets estimated duration
5. User selects priority (low/medium/high)
6. User clicks save
7. System adds task to today's list
```

**AF2: View Yesterday's Tasks**
```
1. User clicks "Yesterday" navigation
2. System displays yesterday's completed/incomplete tasks
3. User can see what was accomplished
4. User can move incomplete tasks to today
```

**AF3: Drag Tasks to Reorder Priority**
```
1. User sees task list in priority order
2. User drags task to new position
3. System reorders tasks
4. System updates priority ranking
5. New order persists across sessions
```

### Postconditions

- Today's task list is displayed
- Tasks can be marked complete
- Task state is persisted
- New tasks are added to list

### Data Requirements

**Input**:
- User ID
- Current date
- Task completion status
- Priority ranking
- Time estimates

**Output**:
- Filtered task list
- Completion percentage
- Time allocation summary
- Task history

### UI Elements Involved

- Day navigation (Today, Yesterday, Tomorrow)
- Task list display
- Task checkbox (complete/incomplete)
- Add task button
- Priority indicator
- Time estimate display
- Drag-and-drop reordering
- Delete task button

### Technical Considerations

**Data Filtering**:
- Filter tickets with due date = today
- Filter scheduled time blocks for today
- Filter personal tasks for today
- Combine from multiple sources

**Performance**:
- Task list load < 200ms
- Mark complete / update immediately
- Drag-and-drop smooth at 60fps

**Edge Cases**:
- 100+ tasks for a single day
  - **Resolution**: Implement search within today's tasks
- Tasks carried over from previous days (incomplete)
  - **Resolution**: Show overflow indicator, allow moving to today
- Task time estimates exceed 24 hours
  - **Resolution**: Show warning, allow for context

### Related Use Cases

- 6.2 Mein Tag (parent)
- 6.1 Dashboard (displays "Mein Tag" summary)
- 4.1 Zeiterfassung (time tracking)
- 3.1 Ticket-Details (linked from tasks)

### Testing Scenarios

1. **T1**: View today's tasks - verify correct date filtering
2. **T2**: Mark task complete - verify status update
3. **T3**: Create new task for today - verify addition to list
4. **T4**: Reorder tasks by priority - verify persistence
5. **T5**: View yesterday's tasks - verify navigation
6. **T6**: Move task from yesterday to today - verify update
7. **T7**: Multiple incomplete tasks - verify organization

---

## UC-6.2.2: Time Block Planning

### Use Case Details

**ID**: 6.2.2
**Category**: Daily Planning
**Base UseCase**: 6.2 Mein Tag (MyDay)
**Complexity**: Medium
**Priority**: Medium

### Description

Users can visualize their daily work as time blocks with specific durations, enabling visual time allocation planning. Time blocks represent scheduled work activities with start/end times or duration estimates.

### Business Value

- Visual time management
- Clear time allocation visibility
- Better utilization tracking
- Context switching reduction
- Prevents overallocation

### User Roles

- **Primary**: Technicians, Support staff
- **Secondary**: Managers (team view)

### Actors

```
1. Technician
   - Views time blocks for today
   - Creates time blocks
   - Adjusts time block duration
   - Views time utilization

2. System
   - Displays visual time block calendar
   - Tracks time allocation
   - Warns about conflicts
```

### Preconditions

- User has tasks/tickets with duration estimates
- Current date is within working hours

### Main Flow

```
1. User navigates to "Mein Tag" (My Day) view
2. System displays time-based calendar for today
3. System shows time blocks for:
   - Scheduled tasks (with duration)
   - Assigned tickets (with estimated time)
   - Time tracking entries (with logged time)
4. Each block shows:
   - Start time
   - Duration/end time
   - Task name
   - Color coding by category/priority
5. User can see gaps/free time
6. User can drag block to adjust time
7. System updates scheduling
```

### Alternate Flows

**AF1: Create Time Block Manually**
```
1. User clicks on empty time slot
2. System shows time block creation form
3. User enters task name
4. User sets start time and duration
5. User sets priority/category
6. User saves block
7. System adds to calendar
```

**AF2: View Time Utilization Summary**
```
1. User views time blocks for day
2. System calculates utilization:
   - Total work time: 8 hours
   - Scheduled blocks: 6.5 hours
   - Free time: 1.5 hours
3. System displays utilization percentage
4. System shows overallocation warning if > 8 hours
```

**AF3: Move/Resize Time Blocks**
```
1. User sees time block on calendar
2. User drags block to new start time
3. System updates block start time
4. User can resize block handle to change duration
5. System updates duration
6. Changes persist to schedule
```

### Postconditions

- Time blocks are displayed
- Visual calendar shows time allocation
- User can see free time
- Scheduling conflicts are visible

### Data Requirements

**Input**:
- Task/ticket information
- Start time
- Duration
- Category/priority
- Resource requirements

**Output**:
- Visual time block calendar
- Utilization summary
- Conflict warnings
- Free time slots

### UI Elements Involved

- Time-based calendar view (8am-6pm typical)
- Time blocks with color coding
- Block drag-and-drop
- Block resize handles
- Time slot labels
- Free time indicator
- Utilization summary
- Conflict warning badge

### Technical Considerations

**Calendar Display**:
- Hour-based grid layout
- 15-minute or 30-minute slot granularity
- Visual conflict detection
- Responsive to screen size

**Data Integration**:
- Fetch all tasks/tickets for today
- Get time estimates from tickets
- Combine with time tracking data
- Calculate availability windows

**Performance**:
- Calendar render < 300ms
- Drag-and-drop smooth at 60fps
- Conflict detection real-time

**Edge Cases**:
- Overlapping time blocks
  - **Resolution**: Highlight conflict, prevent overlap
- Task duration > remaining day
  - **Resolution**: Show warning about overallocation
- No time blocks for day
  - **Resolution**: Show empty calendar, encourage planning
- Daylight saving transitions
  - **Resolution**: Handle correctly for clock changes

### Related Use Cases

- 6.2 Mein Tag (parent)
- 6.2.1 Daily Task Management (task list view)
- 4.1 Zeiterfassung (time tracking)
- 4.2 Stoppuhren (timer integration)

### Testing Scenarios

1. **T1**: View time blocks for today - verify calendar display
2. **T2**: Create time block manually - verify addition
3. **T3**: Drag time block to new time - verify update
4. **T4**: Resize time block duration - verify persistence
5. **T5**: View utilization summary - verify calculations
6. **T6**: Detect overlapping blocks - verify warning
7. **T7**: Free time slots visible - verify calculation

---

## UC-6.2.3: Work Priority Management

### Use Case Details

**ID**: 6.2.3
**Category**: Daily Planning
**Base UseCase**: 6.2 Mein Tag (MyDay)
**Complexity**: Low-Medium
**Priority**: Medium

### Description

Users can prioritize and reorder their daily work activities to focus on high-priority items first. The system supports drag-and-drop reordering, priority level assignment, and visual priority indicators.

### Business Value

- Ensures high-priority work is completed first
- Reduces important items being overlooked
- Improves task completion rates
- Enables flexible priority adjustment
- Supports agile/dynamic work planning

### User Roles

- **Primary**: Technicians, Support staff, All employees
- **Secondary**: Managers (overriding priorities)

### Actors

```
1. Employee
   - Views task priorities
   - Reorders tasks
   - Sets priority levels
   - Focuses on high-priority items

2. Manager
   - Can override/force task priority
   - Can set team priorities

3. System
   - Tracks priority order
   - Persists priority ranking
   - Visually indicates priority
```

### Preconditions

- User has multiple tasks for today
- At least 2 tasks available

### Main Flow

```
1. User views "Mein Tag" task list
2. System displays tasks in current priority order
3. System uses visual indicators:
   - High: Red/bold header
   - Medium: Orange/normal header
   - Low: Gray/subtle header
4. User can drag task to new position
5. System reorders tasks
6. System updates priority ranking
7. New order persists across sessions
8. Tasks are completed in priority order
```

### Alternate Flows

**AF1: Set Priority Level**
```
1. User right-clicks on task
2. User selects "Set Priority" from context menu
3. System shows priority options (High/Medium/Low)
4. User selects new priority level
5. System updates task priority
6. System may reorder task based on priority
7. System saves priority change
```

**AF2: Auto-Sort by Priority**
```
1. User clicks "Sort by Priority" button
2. System automatically reorders tasks:
   - High priority first
   - Medium priority second
   - Low priority last
3. Within same priority, maintains order
4. User can still manually reorder if desired
```

**AF3: Pin Important Task**
```
1. User right-clicks task
2. User selects "Pin to Top"
3. System moves task to very top (above priorities)
4. Task stays at top regardless of priority
5. User can unpin to remove special status
```

### Postconditions

- Task priority order is updated
- Priority visualization is applied
- User can focus on high-priority items
- Priority changes persist

### Data Requirements

**Input**:
- Task ID
- Priority level (High/Medium/Low)
- Priority order sequence

**Output**:
- Reordered task list
- Priority indicators
- Priority change history

### UI Elements Involved

- Task list with drag-and-drop
- Priority color indicators
- Priority context menu
- Set priority dialog
- Sort by priority button
- Pin/unpin button
- Priority label per task

### Technical Considerations

**Priority Algorithms**:
- Simple numeric priority field
- Support for tiebreakers (time, category)
- Drag-and-drop updates priority
- Maintains explicit order

**Data Persistence**:
- Store priority order per user per day
- Track priority changes in audit log
- Support priority history/undo

**Performance**:
- Drag-and-drop smooth at 60fps
- Priority reordering < 100ms
- Instant visual feedback

**Edge Cases**:
- Manager changes priority (override)
  - **Resolution**: Shows indicator of manager override
- Tasks added after priority set
  - **Resolution**: Insert at appropriate priority level
- Delete high-priority task
  - **Resolution**: Remove from order, next task becomes focus
- 50+ tasks with same priority
  - **Resolution**: Use secondary sort criteria

### Related Use Cases

- 6.2 Mein Tag (parent)
- 6.2.1 Daily Task Management (task list)
- 6.2.2 Time Block Planning (time-based priority)

### Testing Scenarios

1. **T1**: View task priority order - verify visualization
2. **T2**: Drag task to change priority - verify reordering
3. **T3**: Set priority level via context menu - verify update
4. **T4**: Auto-sort by priority - verify grouping
5. **T5**: Pin task to top - verify special handling
6. **T6**: Page refresh - verify priority persistence
7. **T7**: Multiple users - verify independent priorities

---

# Summary Table: New Use-Cases

| ID | Name | Base | Complexity | Priority | Type |
|----|------|------|-----------|----------|------|
| 3.2.1 | Advanced Ticket Filtering | 3.2 | Medium | High | Enhancement |
| 3.2.2 | Ticket List Customization | 3.2 | Medium | Medium | Enhancement |
| 3.2.3 | Full-Text Ticket Search | 3.2 | Low-Med | High | Enhancement |
| 8.1.1 | Advanced Customer Search | 8.1 | Low-Med | High | Enhancement |
| 8.1.2 | Customer Status Management | 8.1 | Low | Medium | Enhancement |
| 8.1.3 | Contact Person Management | 8.1 | Medium | Medium | Enhancement |
| 6.2.1 | Daily Task Management | 6.2 | Medium | High | Enhancement |
| 6.2.2 | Time Block Planning | 6.2 | Medium | Medium | Enhancement |
| 6.2.3 | Work Priority Management | 6.2 | Low-Med | Medium | Enhancement |

---

## Recommendations for Implementation

### High Priority (Implement First - High Business Value)
1. **UC-3.2.3**: Full-Text Ticket Search - Easy to implement, high user value
2. **UC-3.2.1**: Advanced Ticket Filtering - Enhances core functionality
3. **UC-8.1.1**: Advanced Customer Search - Essential for customer lookup
4. **UC-6.2.1**: Daily Task Management - Improves focus and productivity

### Medium Priority (Implement Second)
1. **UC-3.2.2**: Ticket List Customization - Improves user experience
2. **UC-8.1.2**: Customer Status Management - Needed for lifecycle management
3. **UC-6.2.3**: Work Priority Management - Supports planning

### Lower Priority (Implement Later or as Nice-to-Have)
1. **UC-8.1.3**: Contact Person Management - More complex, specialized use case
2. **UC-6.2.2**: Time Block Planning - Advanced feature for mature users

---

**Generated**: 2025-11-24
**Source**: Live screenshot analysis
**New Use-Cases**: 9 detailed specifications
**Status**: Ready for development planning