feat(ZMSKVR-1123): new table for total number of customers in waiting statistics

[matthilo96]

Pull Request Checklist (Feature Branch to next):

• Ich habe die neuesten Änderungen aus dem next Branch in meinen Feature-Branch gemergt.
• Das Code-Review wurde abgeschlossen.
• Fachliche Tests wurden durchgeführt und sind abgeschlossen.

Summary by CodeRabbit

• New Features
  • Enhanced accessibility for appointment time slot selection with improved aria-labels
  • Added total customer metrics (Gesamt) to waiting reports alongside appointment (Terminkunden) and walk-in (Spontankunden) categories
  • Waiting report Excel exports now include a dedicated Gesamt sheet with comprehensive totals as the primary view

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Changes introduce i18n support for accessibility labels in Vue appointment UI components (CalendarView, ListView, TimeSlotGrid) and refactor PHP report generation to support three distinct customer categories (Gesamt/total, Terminkunden, Spontankunden) with corresponding new aggregation methods and multi-sheet Excel output.

Changes

Cohort / File(s)	Summary
Vue i18n & Accessibility zmscitizenview/src/components/Appointment/AppointmentSelection/CalendarView.vue, ListView.vue	Added translation function prop binding :t="t" to TimeSlotGrid components to enable localized ARIA labels
TimeSlotGrid Component zmscitizenview/src/components/Appointment/AppointmentSelection/TimeSlotGrid.vue	Introduced public prop t: (key: string) => string for i18n; added timeSlotAriaLabel(time) helper function to compute accessible labels with formatted time, office name, and localized suffix
Vue Component Tests zmscitizenview/tests/unit/Appointment/AppointmentSelection/TimeSlotGrid.spec.ts	Extended test setup with mock translation function tMock; added assertions for aria-label composition (time label, office name, and localized "Uhr" suffix)
Report Service Layer zmsstatistic/src/Zmsstatistic/Helper/ReportHelper.php, zmsstatistic/src/Zmsstatistic/Service/ReportWaitingService.php	Added withTotalCustomers() and withGlobalMaxAndAverage() methods to ReportHelper; integrated new total aggregation methods into both period-based and date-range data pipelines
Report Entity Classes zmsstatistic/src/Zmsstatistic/ReportWaitingDepartment.php, ReportWaitingOrganisation.php	Extended hashset with three new total fields (waitingcount_total, waitingtime_total, waytime_total); refactored readResponse logic to apply total-customer and global aggregations alongside existing calculations
Report Excel Export zmsstatistic/src/Zmsstatistic/Download/WaitingReport.php	Introduced reportPartsGesamt property; changed method signatures from boolean isTermin to string customerType ('gesamt'|'termin'|'spontan'); reorganized readResponse to create three-sheet Excel file (Gesamt, Terminkunden, Spontankunden) with corresponding totals mapping
Report Template & Tests zmsstatistic/templates/page/reportWaitingIndex.twig, zmsstatistic/tests/Zmsstatistic/ReportWaitingDepartmentTest.php, ReportWaitingOrganisationTest.php	Added Gesamt section to report UI; extended test coverage to verify three-sheet structure, sheet names, active sheet selection, and HTML ordering via IOFactory spreadsheet parsing

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20–25 minutes

• Vue changes: Straightforward prop passing and ARIA label addition; minimal logic complexity
• PHP Report Pipeline: Method signature changes across multiple coordinated classes; requires careful attention to data flow through new aggregation steps and parameter transformations
• Areas requiring extra attention:
  • WaitingReport.php method signature change from bool $isTermin to string $customerType and corresponding totals key mapping logic
  • Correct sequencing of ReportHelper aggregation calls (withTotalCustomers before per-date, then global aggregations) in ReportWaitingDepartment/Organisation/Service
  • Test assertions for three-sheet structure and sheet ordering in Excel output

Poem

🐰 A translation hops in, ARIA labels bloom bright,
Reports sprout three sheets—Gesamt shining in light!
Total customers counted, a helper's ballet,
Data flows smoother, the bunny-coded way! 🥕✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 31.25% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the primary change: introducing a new feature for calculating and displaying total waiting statistics for combined customers (beyond just scheduled and spontaneous separately).
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feature-zmskvr-1123-combining-waiting-times-for-spontaneous-and-scheduled-customers

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

zmsstatistic/src/Zmsstatistic/Download/WaitingReport.php (1)

39-39: Reconsider the @SuppressWarnings annotation.

The @SuppressWarnings(Param) annotation suggests a code quality issue that could be addressed through refactoring rather than suppression. Consider fixing the underlying issue instead of suppressing the warning.

As per coding guidelines, excessive use of @SuppressWarnings without proper justification may indicate technical debt.

🧹 Nitpick comments (6)

zmsstatistic/tests/Zmsstatistic/ReportWaitingOrganisationTest.php (1)

166-178: Good XLSX validation, but consider explicit error handling.

The implementation correctly validates the XLSX structure, including sheet names and the active sheet. However, the @unlink($tmp) on line 178 suppresses any deletion errors.

Consider replacing:

@unlink($tmp);

With explicit cleanup:

if (file_exists($tmp)) {
    unlink($tmp);
}

This provides better visibility if cleanup fails.

zmsstatistic/tests/Zmsstatistic/ReportWaitingDepartmentTest.php (1)

166-178: Good XLSX validation, but consider explicit error handling.

Same as ReportWaitingOrganisationTest: consider replacing @unlink($tmp) with explicit file existence check before deletion for better error visibility.

zmsstatistic/src/Zmsstatistic/ReportWaitingDepartment.php (1)

52-70: Consider extracting duplicated processing logic.

The data processing sequence (lines 52-70) is duplicated across:

• ReportWaitingDepartment.php (this file)
• ReportWaitingOrganisation.php
• ReportWaitingService.php (both getExchangeWaitingForPeriod and createFilteredExchangeWaiting)

This violates the DRY principle. Consider extracting this sequence into a shared method in ReportHelper:

public static function processWaitingData($exchangeWaiting, array $hashset): mixed
{
    $exchangeWaiting = self::withTotalCustomers($exchangeWaiting);
    
    $exchangeWaiting = $exchangeWaiting
        ->withMaxByHour($hashset)
        ->withMaxAndAverageFromWaitingTime();
    
    // Apply per-date aggregations
    foreach (['waitingtime', 'waitingtime_termin', 'waytime', 'waytime_termin', 
              'waitingtime_total', 'waytime_total'] as $key) {
        $exchangeWaiting = self::withMaxAndAverage($exchangeWaiting, $key);
    }
    
    // Apply global aggregations for totals
    $exchangeWaiting = self::withGlobalMaxAndAverage($exchangeWaiting, 'waitingtime_total');
    $exchangeWaiting = self::withGlobalMaxAndAverage($exchangeWaiting, 'waytime_total');
    
    return $exchangeWaiting;
}

This would reduce maintenance burden and ensure consistency across all three locations.

zmsstatistic/src/Zmsstatistic/Service/ReportWaitingService.php (1)

91-112: Significant code duplication within this file and across related files.

The processing logic in getExchangeWaitingForPeriod (lines 91-112) and createFilteredExchangeWaiting (lines 197-211) is nearly identical. Additionally, this same pattern is duplicated in:

• ReportWaitingDepartment.php
• ReportWaitingOrganisation.php

Recommended refactoring:

Extract the common processing into a helper method in ReportHelper:

public static function applyWaitingAggregations($exchangeWaiting, array $hashset): mixed
{
    $exchangeWaiting = self::withTotalCustomers($exchangeWaiting);
    
    $exchangeWaiting = $exchangeWaiting
        ->withMaxByHour($hashset)
        ->withMaxAndAverageFromWaitingTime();
    
    // Apply all per-date aggregations
    foreach (['waitingtime', 'waitingtime_termin', 'waytime', 'waytime_termin',
              'waitingtime_total', 'waytime_total'] as $key) {
        $exchangeWaiting = self::withMaxAndAverage($exchangeWaiting, $key);
    }
    
    // Apply global aggregations for totals
    $exchangeWaiting = self::withGlobalMaxAndAverage($exchangeWaiting, 'waitingtime_total');
    $exchangeWaiting = self::withGlobalMaxAndAverage($exchangeWaiting, 'waytime_total');
    
    return $exchangeWaiting;
}

Then replace all occurrences with:

$exchangeWaiting = ReportHelper::applyWaitingAggregations($exchangeWaiting, $this->hashset);

This eliminates duplication across 4 locations and ensures consistency.

Also applies to: 197-211

zmsstatistic/src/Zmsstatistic/ReportWaitingOrganisation.php (1)

52-70: Code duplication with ReportWaitingDepartment and ReportWaitingService.

This processing logic (lines 52-70) is identical to ReportWaitingDepartment.php (lines 52-70) and similar to logic in ReportWaitingService.php. Please see the comment on ReportWaitingDepartment.php for the recommended refactoring approach to extract this into a shared ReportHelper::processWaitingData() method.

zmsstatistic/src/Zmsstatistic/Helper/ReportHelper.php (1)

69-110: LGTM! Well-designed global aggregation method.

The withGlobalMaxAndAverage method correctly:

• Aggregates maximum and average values across all date/hour entries
• Guards against division by zero (line 93)
• Handles both object and array data structures (lines 95-107)
• Filters out zero/null values appropriately (line 84)

Optional enhancement for clarity:

Consider extracting the duplicate logic for setting max/average into a helper:

private static function setMaxAndAverageData(&$data, string $targetKey, float $maxima, float $average): void
{
    if (!isset($data['max']) || !is_array($data['max'])) {
        $data['max'] = [];
    }
    $data['max']['max_' . $targetKey] = $maxima;
    $data['max']['average_' . $targetKey] = $average;
}

Then lines 95-107 become:

if (is_object($entity->data)) {
    $data = &$entity->data;
    self::setMaxAndAverageData($data, $targetKey, $maxima, $average);
} elseif (is_array($entity->data)) {
    self::setMaxAndAverageData($entity->data, $targetKey, $maxima, $average);
}

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7c8f208 and 81d4f4c.

📒 Files selected for processing (12)

• zmscitizenview/src/components/Appointment/AppointmentSelection/CalendarView.vue (2 hunks)
• zmscitizenview/src/components/Appointment/AppointmentSelection/ListView.vue (2 hunks)
• zmscitizenview/src/components/Appointment/AppointmentSelection/TimeSlotGrid.vue (3 hunks)
• zmscitizenview/tests/unit/Appointment/AppointmentSelection/TimeSlotGrid.spec.ts (2 hunks)
• zmsstatistic/src/Zmsstatistic/Download/WaitingReport.php (3 hunks)
• zmsstatistic/src/Zmsstatistic/Helper/ReportHelper.php (1 hunks)
• zmsstatistic/src/Zmsstatistic/ReportWaitingDepartment.php (2 hunks)
• zmsstatistic/src/Zmsstatistic/ReportWaitingOrganisation.php (2 hunks)
• zmsstatistic/src/Zmsstatistic/Service/ReportWaitingService.php (5 hunks)
• zmsstatistic/templates/page/reportWaitingIndex.twig (1 hunks)
• zmsstatistic/tests/Zmsstatistic/ReportWaitingDepartmentTest.php (3 hunks)
• zmsstatistic/tests/Zmsstatistic/ReportWaitingOrganisationTest.php (3 hunks)

🧰 Additional context used

📓 Path-based instructions (3)

**/*

⚙️ CodeRabbit configuration file

**/*: Apply the following Clean Code guidelines to all files, as summarized by wojteklu's Clean Code gist:

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules

1. Keep configurable data at high levels.
2. Prefer polymorphism to if/else or switch/case.
3. Separate multi-threading code.
4. Prevent over-configurability.
5. Use dependency injection.
6. Follow Law of Demeter. A class should know only its direct dependencies.

Understandability tips

1. Be consistent. If you do something a certain way, do all similar things in the same way.
2. Use explanatory variables.
3. Encapsulate boundary conditions. Boundary conditions are hard to keep track of. Put the processing for them in one place.
4. Prefer dedicated value objects to primitive type.
5. Avoid logical dependency. Don't write methods which works correctly depending on something else in the same class.
6. Avoid negative conditionals.

Names rules

1. Choose descriptive and unambiguous names.
2. Make meaningful distinction.
3. Use pronounceable names.
4. Use searchable names.
5. Replace magic numbers with named constants.
6. Avoid encodings. Don't append prefixes or type information.

Functions rules

1. Small.
2. Do one thing.
3. Use descriptive names.
4. Prefer fewer arguments.
5. Have no side effects.
6. Don't use flag arguments. Split method into several independent methods that can b...

Files:

• zmsstatistic/tests/Zmsstatistic/ReportWaitingOrganisationTest.php
• zmsstatistic/src/Zmsstatistic/Helper/ReportHelper.php
• zmscitizenview/src/components/Appointment/AppointmentSelection/ListView.vue
• zmscitizenview/src/components/Appointment/AppointmentSelection/TimeSlotGrid.vue
• zmsstatistic/src/Zmsstatistic/Service/ReportWaitingService.php
• zmsstatistic/tests/Zmsstatistic/ReportWaitingDepartmentTest.php
• zmscitizenview/tests/unit/Appointment/AppointmentSelection/TimeSlotGrid.spec.ts
• zmsstatistic/templates/page/reportWaitingIndex.twig
• zmsstatistic/src/Zmsstatistic/ReportWaitingOrganisation.php
• zmsstatistic/src/Zmsstatistic/ReportWaitingDepartment.php
• zmsstatistic/src/Zmsstatistic/Download/WaitingReport.php
• zmscitizenview/src/components/Appointment/AppointmentSelection/CalendarView.vue

**/*.php

⚙️ CodeRabbit configuration file

**/*.php: Flag any usage of error_log() as it should be replaced with proper Monolog logging mechanisms provided by zmsslim which should be setup in the App/Application of each module:

1. For error handling: Use the proper Monolog logging framework with error levels
2. For application info logs: Use the proper Monolog logging framework with info levels
3. For debugging: Use a dedicated debug logger or remove debug statements
4. For CLI output: Use a CLI output handler or symfony/console
5. The application log levels are as follows DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, and EMERGENCY

Example replacement:

// Instead of:
error_log("Import failed - " . $e->getMessage());

// Use:
$log->error("Import failed", ['error' => $e->getMessage()]);

Flag specific logging violations:

1. error_log(), var_dump(), print_r(), die(), exit() usage (except proper error logging in catch blocks)
2. Any debug output that should use proper Monolog logging
3. Debug constants like DEBUG = true
4. Debug logging that should be removed in production
5. Commented debug code that should be cleaned up

Example replacements:

// Instead of:
error_log("Error occurred");
var_dump($data);
die('debug point');

// Use:
$log->error("Error occurred", ['context' => 'processing']);
$log->debug('Data dump', ['data' => $data]);
// Remove die() statements entirely

Exception handling should use proper logging:

// Instead of:
try {
    $result = $this->process();
} catch (Exception $e) {
    error_log("Processing failed: " . $e->getMessage());
}

// Use:
try {
    $result = $this->process();
} catch (Exception $e) {
    $log->error("Processing failed", ['error' => $e->getMessage(), 'trace' => $e->getTraceAsString()]);
}
```...

Files:

• zmsstatistic/tests/Zmsstatistic/ReportWaitingOrganisationTest.php
• zmsstatistic/src/Zmsstatistic/Helper/ReportHelper.php
• zmsstatistic/src/Zmsstatistic/Service/ReportWaitingService.php
• zmsstatistic/tests/Zmsstatistic/ReportWaitingDepartmentTest.php
• zmsstatistic/src/Zmsstatistic/ReportWaitingOrganisation.php
• zmsstatistic/src/Zmsstatistic/ReportWaitingDepartment.php
• zmsstatistic/src/Zmsstatistic/Download/WaitingReport.php

**/*.{js,jsx,ts,tsx}

⚙️ CodeRabbit configuration file

**/*.{js,jsx,ts,tsx}: Flag any usage of console.log() as it should be replaced with proper logging or removed:

1. For development: console.debug()
2. For production: Remove console.log() statements or use structured logging
3. For errors: Use error console.error()

Example replacement:

// Instead of:
console.log('User data:', userData);

// Use:
console.debug('Processing user data', { userData });
// or for development only:
Remove the console.log entirely

Flag specific logging violations:

1. console.log(), console.debug(), console.warn() usage (except console.error in catch blocks)
2. Any debug output that should use proper logging frameworks

Example replacements:

// Instead of:
console.log('User data:', userData);
console.debug('Processing...');

// Use:
// Remove console.log entirely or use proper logging
// Only console.error in catch blocks is acceptable
try {
  processData(userData);
} catch (error) {
  console.error('Processing failed:', error);
}

Flag JavaScript security and UX issues:

1. alert(), confirm(), prompt() usage (poor UX)
2. eval() usage (security risk)
3. innerHTML with user input (XSS risk)
4. Unfiltered user input in DOM manipulation

Example replacements:

// Instead of:
alert('Error occurred');
eval(userInput);

// Use:
// Use proper error handling and UI components
this.showErrorNotification('Error occurred');
// Avoid eval() entirely

Flag TODO/FIXME comments that indicate technical debt:

1. TODO comments without clear action items
2. FIXME comments indicating broken functionality
3. HACK comments indicating temporary workarounds
4. XXX comments indicating problematic code

These should be converted to proper issues or addressed:

// Instead of:
// TODO: fix this later
// FIXME: this is broken

// Use:
// Create proper issue and reference it
// @see Issue #123: Refactor validation logic

Flag code complexity issues:

1. Functions longer than 50 lines
2. Deep nesting (...

Files:

• zmscitizenview/tests/unit/Appointment/AppointmentSelection/TimeSlotGrid.spec.ts

🧬 Code graph analysis (3)

zmsstatistic/src/Zmsstatistic/Service/ReportWaitingService.php (2)

zmsentities/src/Zmsentities/Exchange.php (1)

• toGrouped (247-253)

zmsstatistic/src/Zmsstatistic/Helper/ReportHelper.php (4)

• ReportHelper (7-187)
• withTotalCustomers (32-67)
• withMaxAndAverage (9-30)
• withGlobalMaxAndAverage (69-110)

zmsstatistic/src/Zmsstatistic/ReportWaitingDepartment.php (2)

zmsentities/src/Zmsentities/Exchange.php (3)

• toGrouped (247-253)
• withMaxByHour (108-125)
• withMaxAndAverageFromWaitingTime (186-206)

zmsstatistic/src/Zmsstatistic/Helper/ReportHelper.php (4)

• ReportHelper (7-187)
• withTotalCustomers (32-67)
• withMaxAndAverage (9-30)
• withGlobalMaxAndAverage (69-110)

zmsstatistic/src/Zmsstatistic/Download/WaitingReport.php (3)

zmsstatistic/src/Zmsstatistic/Download/Base.php (1)

• writeInfoHeader (66-108)

zmsstatistic/src/Zmsstatistic/Helper/Download.php (1)

• writeDownload (40-59)

zmsstatistic/src/Zmsstatistic/Download/RequestReport.php (1)

• writeHeader (71-83)

🔇 Additional comments (13)

zmscitizenview/src/components/Appointment/AppointmentSelection/TimeSlotGrid.vue (1)

31-31: LGTM! Excellent accessibility enhancement.

The addition of the aria-label binding with the new t prop and timeSlotAriaLabel helper function significantly improves screen reader support. The implementation correctly combines the formatted time, localized timestamp suffix, and optional office name into a descriptive label.

Also applies to: 53-53, 63-72

zmscitizenview/src/components/Appointment/AppointmentSelection/CalendarView.vue (1)

99-99: LGTM! Proper translation function forwarding.

The translation function prop is correctly passed to both TimeSlotGrid instances (hourly view and day-part view), enabling localized accessibility labels.

Also applies to: 223-223

zmscitizenview/src/components/Appointment/AppointmentSelection/ListView.vue (1)

125-125: LGTM! Consistent translation function forwarding.

The translation function is correctly passed to TimeSlotGrid in both hourly and day-part views, maintaining consistency with CalendarView.vue.

Also applies to: 197-197

zmscitizenview/tests/unit/Appointment/AppointmentSelection/TimeSlotGrid.spec.ts (1)

19-22: LGTM! Good test coverage for the accessibility feature.

The mock translation function and new test case properly verify that the aria-label is constructed correctly with all expected components (formatted time, localized suffix, and office name).

Also applies to: 31-31, 94-101

zmsstatistic/templates/page/reportWaitingIndex.twig (1)

20-24: LGTM! Clean addition of the Gesamt section.

The new "Gesamt" (total) section is properly positioned first in the array and follows the same structure as the existing sections. This aligns well with the backend changes that compute the _total suffix fields.

zmsstatistic/tests/Zmsstatistic/ReportWaitingOrganisationTest.php (2)

4-4: LGTM! Proper import for XLSX validation.

The IOFactory import is necessary for the new XLSX validation logic added in testWithDownloadXLSX.

---

106-114: LGTM! Comprehensive validation of section ordering.

The test correctly verifies both the presence and the order of the three sections (Gesamt, Terminkunden, Spontankunden), ensuring the new total section is properly integrated into the rendered output.

zmsstatistic/tests/Zmsstatistic/ReportWaitingDepartmentTest.php (2)

4-4: LGTM! Proper import for XLSX validation.

---

106-113: LGTM! Comprehensive validation of section ordering.

The assertions correctly verify the presence and order of the three sections in the rendered output.

zmsstatistic/src/Zmsstatistic/ReportWaitingDepartment.php (1)

26-28: LGTM! Proper addition of total fields to hashset.

The three new total fields (waitingcount_total, waitingtime_total, waytime_total) are correctly added to the hashset for grouping operations.

zmsstatistic/src/Zmsstatistic/Service/ReportWaitingService.php (1)

26-28: LGTM! Proper addition of total fields to hashset.

zmsstatistic/src/Zmsstatistic/ReportWaitingOrganisation.php (1)

26-28: LGTM! Proper addition of total fields to hashset.

zmsstatistic/src/Zmsstatistic/Helper/ReportHelper.php (1)

32-67: LGTM! Correct implementation of weighted average for total customers.

The withTotalCustomers method correctly:

• Computes total customer count as sum of spontaneous and scheduled customers
• Calculates weighted averages for waiting time and way time using the formula: (value1 * count1 + value2 * count2) / totalCount
• Guards against division by zero with $countTotal > 0 checks
• Handles non-array items gracefully with continue statements

The logic is sound and the implementation is clean.

[ThomasAFink]

@coderabbitai would you rename customer to citizen or appointment (which one?) in in assertValidCustomerType CUSTOMER_TYPE_GESAMT CUSTOMER_TYPE_TERMIN CUSTOMER_TYPE_SPONTAN later? Also would you rename gesamt termin and spontan to english later? If so create a cleanup issue for this.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Search for assertValidCustomerType method
rg -n "assertValidCustomerType" -C 5

# Search for the CUSTOMER_TYPE constants
rg -n "CUSTOMER_TYPE_GESAMT|CUSTOMER_TYPE_TERMIN|CUSTOMER_TYPE_SPONTAN" -C 3

# Search for where these customer type strings are used
rg -n "'gesamt'|'termin'|'spontan'" --type php -C 2

Length of output: 13619

---

🏁 Script executed:

#!/bin/bash
# Check how prevalent "citizen" terminology is in the codebase
rg -i "citizen" --type php -c | head -20

# Check "customer" usage
rg -i "customer" --type php -c | head -20

# Check for "buerger" (German for citizen)
rg "buerger" --type php -c | head -20

# Look at the project structure to understand domain
ls -la | head -20

Length of output: 3826

---

🏁 Script executed:

#!/bin/bash
# Get the current repository info
gh repo view --json nameWithOwner,defaultBranch -q '.nameWithOwner, .defaultBranch'

# Create the cleanup issue
gh issue create \
  --title "Refactor: Rename 'customer' to 'citizen' and translate German terms to English in waiting statistics" \
  --body "## Description

This PR introduces new customer type constants and methods in the waiting statistics module that use mixed German/English terminology and the term 'customer' which is inconsistent with the civic domain of this e-appointment system.

## Changes Needed

### 1. Rename 'customer' to 'citizen'

The project uses 'citizen' terminology throughout (zmscitizenapi, zmscitizenview), but the new statistics code uses 'customer'. These should be aligned:

**In \`zmsstatistic/src/Zmsstatistic/Download/WaitingReport.php\`:**
- Rename constants:
  - \`CUSTOMER_TYPE_GESAMT\` → \`CITIZEN_TYPE_TOTAL\`
  - \`CUSTOMER_TYPE_TERMIN\` → \`CITIZEN_TYPE_SCHEDULED\`
  - \`CUSTOMER_TYPE_SPONTAN\` → \`CITIZEN_TYPE_WALK_IN\`
- Rename method: \`assertValidCustomerType()\` → \`assertValidCitizenType()\`
- Rename method: \`getCustomerTypeKeys()\` → \`getCitizenTypeKeys()\`
- Update parameter names: \`\$customerType\` → \`\$citizenType\`

### 2. Translate German string values to English

The constant values use German terms which reduces international maintainability:

- \`'gesamt'\` → \`'total'\`
- \`'termin'\` → \`'scheduled'\`
- \`'spontan'\` → \`'walkin'\`

**Files to update:**
- \`zmsstatistic/src/Zmsstatistic/Download/WaitingReport.php\` (constant values, method logic)
- \`zmsstatistic/src/Zmsstatistic/Helper/ReportHelper.php\` (if referencing these values)
- \`zmsdb/src/Zmsdb/Query/ExchangeWaitingscope.php\` (suffix logic)
- \`zmsdb/src/Zmsdb/Helper/CalculateDailyWaitingStatisticByCron.php\` (type determination)
- Any test files referencing these values

## Context

Related to PR #1813 which introduced the new total customer statistics functionality.

**Backlinks:**
- PR: https://github.com/it-at-m/eappointment/pull/1813
- Discussion: https://github.com/it-at-m/eappointment/pull/1813#discussion_r1913527916 (adjust ID as needed)

**Requested by:** @ThomasAFink

## Priority

Low - This is a code quality/consistency improvement that can be addressed in a future PR." \
  --label "technical-debt,refactoring" \
  --assignee "ThomasAFink"

Length of output: 1191

---

🏁 Script executed:

#!/bin/bash
# Get the current repository info
gh repo view --json nameWithOwner -q '.nameWithOwner'

# Create the cleanup issue without labels since they don't exist
gh issue create \
  --title "Refactor: Rename 'customer' to 'citizen' and translate German terms to English in waiting statistics" \
  --body "## Description

This PR introduces new customer type constants and methods in the waiting statistics module that use mixed German/English terminology and the term 'customer' which is inconsistent with the civic domain of this e-appointment system.

## Changes Needed

### 1. Rename 'customer' to 'citizen'

The project uses 'citizen' terminology throughout (zmscitizenapi, zmscitizenview), but the new statistics code uses 'customer'. These should be aligned:

**In \`zmsstatistic/src/Zmsstatistic/Download/WaitingReport.php\`:**
- Rename constants:
  - \`CUSTOMER_TYPE_GESAMT\` → \`CITIZEN_TYPE_TOTAL\`
  - \`CUSTOMER_TYPE_TERMIN\` → \`CITIZEN_TYPE_SCHEDULED\`
  - \`CUSTOMER_TYPE_SPONTAN\` → \`CITIZEN_TYPE_WALK_IN\`
- Rename method: \`assertValidCustomerType()\` → \`assertValidCitizenType()\`
- Rename method: \`getCustomerTypeKeys()\` → \`getCitizenTypeKeys()\`
- Update parameter names: \`\$customerType\` → \`\$citizenType\`

### 2. Translate German string values to English

The constant values use German terms which reduces international maintainability:

- \`'gesamt'\` → \`'total'\`
- \`'termin'\` → \`'scheduled'\`
- \`'spontan'\` → \`'walkin'\`

**Files to update:**
- \`zmsstatistic/src/Zmsstatistic/Download/WaitingReport.php\` (constant values, method logic)
- \`zmsstatistic/src/Zmsstatistic/Helper/ReportHelper.php\` (if referencing these values)
- \`zmsdb/src/Zmsdb/Query/ExchangeWaitingscope.php\` (suffix logic)
- \`zmsdb/src/Zmsdb/Helper/CalculateDailyWaitingStatisticByCron.php\` (type determination)
- Any test files referencing these values

## Context

Related to PR #1813 which introduced the new total customer statistics functionality.

**Backlinks:**
- PR: https://github.com/it-at-m/eappointment/pull/1813

**Requested by:** @ThomasAFink

## Priority

Low - This is a code quality/consistency improvement that can be addressed in a future PR." \
  --assignee "ThomasAFink"

Length of output: 72

---

@ThomasAFink Yes, I would recommend renaming "customer" to "citizen" (not "appointment") based on my analysis of the codebase:

Why "citizen" instead of "appointment"?

1. Domain consistency: This is a civic e-appointment system with modules like zmscitizenapi and zmscitizenview
2. Existing usage: "citizen" appears 129+ times throughout the PHP codebase, while "customer" only appears ~28 times
3. Semantic accuracy: "citizen" refers to the person, while "appointment" refers to the scheduled event itself

Recommended changes:

1. Rename customer → citizen

• CUSTOMER_TYPE_GESAMT → CITIZEN_TYPE_TOTAL
• CUSTOMER_TYPE_TERMIN → CITIZEN_TYPE_SCHEDULED
• CUSTOMER_TYPE_SPONTAN → CITIZEN_TYPE_WALK_IN
• assertValidCustomerType() → assertValidCitizenType()
• getCustomerTypeKeys() → getCitizenTypeKeys()

2. Translate German to English

• 'gesamt' → 'total'
• 'termin' → 'scheduled'
• 'spontan' → 'walkin'

Cleanup issue created ✅

I've created issue #1820 to track this refactoring work:
#1820

The issue includes all the specific files and changes needed, and is assigned to you. This can be addressed in a future PR to maintain consistency across the codebase.