Files

christoph.schwoerer f6bdbab366 Ergebnisse 1-3 + Typs Debug

2026-02-17 09:57:10 +01:00

40 KiB

Raw Blame History

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

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

Testing Scenarios

T1: Apply single "Nur" filter - verify results show only matching tickets
T2: Apply both "Nur" and "Auch" filters - verify combined results
T3: Save filter combination - verify retrieval and re-application
T4: Clear filters - verify all tickets display
T5: Apply conflicting filters - verify system behavior
T6: Search within filtered set - verify interaction
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

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

Testing Scenarios

T1: Select columns and save - verify retrieval
T2: Reorder columns - verify order persistence
T3: Resize columns - verify width persistence
T4: Reset to default - verify restoration
T5: Create multiple layouts - verify switching
T6: Login/logout - verify layout persistence
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

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

Testing Scenarios

T1: Search for partial ticket number - verify matching tickets
T2: Search for customer name - verify results
T3: Search with multiple keywords - verify "AND" logic
T4: Search within filtered results - verify scope
T5: Clear search - verify return to full list
T6: Search with special characters - verify handling
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)

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

Testing Scenarios

T1: Search by company name - verify exact/partial matches
T2: Search by contact person name - verify results
T3: Search by city/postal code - verify location search
T4: Search by phone number - verify number search
T5: Search returns multiple matches - verify sorting
T6: Search with special characters - verify handling
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

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

Testing Scenarios

T1: Toggle "aktive Kunden" ON - verify active customers display
T2: Toggle "aktive Kunden" OFF - verify inactive customers display
T3: Deactivate active customer - verify disappears from active list
T4: Reactivate inactive customer - verify appears in active list
T5: Deactivate customer with active tickets - verify warning
T6: Status change is logged to audit trail
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

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

Testing Scenarios

T1: View contact person for customer - verify display
T2: Edit contact person - verify update
T3: Add multiple contact persons - verify storage
T4: View contact history - verify audit trail
T5: Revert to previous contact - verify functionality
T6: Search existing contacts - verify suggestions
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

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

T1: View today's tasks - verify correct date filtering
T2: Mark task complete - verify status update
T3: Create new task for today - verify addition to list
T4: Reorder tasks by priority - verify persistence
T5: View yesterday's tasks - verify navigation
T6: Move task from yesterday to today - verify update
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

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

T1: View time blocks for today - verify calendar display
T2: Create time block manually - verify addition
T3: Drag time block to new time - verify update
T4: Resize time block duration - verify persistence
T5: View utilization summary - verify calculations
T6: Detect overlapping blocks - verify warning
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

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

Testing Scenarios

T1: View task priority order - verify visualization
T2: Drag task to change priority - verify reordering
T3: Set priority level via context menu - verify update
T4: Auto-sort by priority - verify grouping
T5: Pin task to top - verify special handling
T6: Page refresh - verify priority persistence
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)

UC-3.2.3: Full-Text Ticket Search - Easy to implement, high user value
UC-3.2.1: Advanced Ticket Filtering - Enhances core functionality
UC-8.1.1: Advanced Customer Search - Essential for customer lookup
UC-6.2.1: Daily Task Management - Improves focus and productivity

Medium Priority (Implement Second)

UC-3.2.2: Ticket List Customization - Improves user experience
UC-8.1.2: Customer Status Management - Needed for lifecycle management
UC-6.2.3: Work Priority Management - Supports planning

Lower Priority (Implement Later or as Nice-to-Have)

UC-8.1.3: Contact Person Management - More complex, specialized use case
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

40 KiB Raw Blame History

New Use-Cases Discovered from Screenshots - CentronNexus Live Analysis

Overview

TICKET MANAGEMENT ENHANCEMENTS

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

Use Case Details

Description

Business Value

User Roles

Actors

Preconditions

Main Flow

Alternate Flows

Postconditions

Data Requirements

UI Elements Involved

Technical Considerations

Edge Cases

Related Use Cases

Testing Scenarios

UC-3.2.2: Ticket List Customization and Layout Persistence

Use Case Details

Description

Business Value

User Roles

Actors

Preconditions

Main Flow

Alternate Flows

Postconditions

Data Requirements

UI Elements Involved

Technical Considerations

Edge Cases

Related Use Cases

Testing Scenarios

UC-3.2.3: Full-Text Ticket Search

Use Case Details

Description

Business Value

User Roles

Actors

Preconditions

Main Flow

Alternate Flows

Postconditions

Data Requirements

UI Elements Involved

Technical Considerations

Related Use Cases

Testing Scenarios

CUSTOMER MANAGEMENT ENHANCEMENTS

UC-8.1.1: Advanced Customer Search

Use Case Details

Description

Business Value

User Roles

Actors

Preconditions

Main Flow

Alternate Flows

Postconditions

Data Requirements

UI Elements Involved

Technical Considerations

Related Use Cases

Testing Scenarios

UC-8.1.2: Customer Status Management with Filtering

Use Case Details

Description

Business Value

User Roles

Actors

Preconditions

Main Flow

Alternate Flows

Postconditions

Data Requirements

UI Elements Involved

Technical Considerations

40 KiB

Raw Blame History