# Bug Fix: Bestätigungs-E-Mail vor Verifikation

## 🐛 Problem

Termine wurden teilweise direkt als "bestätigt" angezeigt, obwohl keine E-Mail-Verifikation durchgeführt wurde. Kunden erhielten:
1. **ZUERST**: Bestätigungs-E-Mail (mit allen Buchungsdetails)
2. **DANACH**: Verifikations-E-Mail (zum Bestätigen der Buchung)

Dies führte zu Verwirrung, da die E-Mails in der falschen Reihenfolge ankamen.

## 🔍 Ursache

Es gab **ZWEI Probleme**:

### Problem 1: Falsche E-Mail-Reihenfolge

In `src/Service/AppointmentService.php` gab es eine alte Methode `bookAppointment()` (Zeile 75-123), die:
1. Einen Appointment ohne Status-Überprüfung erstellt hat
2. **SOFORT** eine Bestätigungs-E-Mail gesendet hat (Zeile 119)
3. Zusätzlich eine Confirmation-Message über Messenger dispatcht hat (Zeile 122)

```php
// ALT - FALSCH:
$this->entityManager->flush();
$this->emailService->sendAppointmentConfirmation($appointment);  // ❌ Zu früh!
$this->bus->dispatch(new SendAppointmentMailMessage($appointment->getId(), 'confirmation'));
```

### Problem 2: Termine direkt als "bestätigt" markiert (HAUPTPROBLEM)

**Datenbank-Beweis** (Abfrage am 22.10.2025):
```sql
SELECT a.id, a.status, a.email_sent, a.created_at, l.name as location 
FROM appointment a 
JOIN availability av ON a.availability_id = av.id 
JOIN location l ON av.location_id = l.id 
WHERE (a.status = 'confirmed' OR a.status = 'verified') 
AND a.email_sent = 0
```

**Ergebnis:**
| ID  | Status    | email_sent | Erstellt am      | Standort |
|-----|-----------|------------|------------------|----------|
| 986 | confirmed | 0          | 2025-10-15 10:12 | **Mobi** |
| 976 | confirmed | 0          | 2025-10-13 10:09 | **Mobi** |

➡️ Diese Termine wurden direkt als `confirmed` angelegt, **OHNE** dass eine Verifikations-E-Mail gesendet wurde!

**Ursache:** Im Admin-Endpoint `createAppointmentAdmin` (Zeile 2268) war der Standard-Status `'confirmed'`:

```php
$status = $request->request->get('status', 'confirmed'); // ❌ Falsch!
```

Wenn jemand einen Termin manuell über den Admin-Bereich erstellt (z.B. am Telefon), wird dieser DIREKT als bestätigt markiert, aber das System sendet trotzdem später eine Verifikations-E-Mail, was zu Verwirrung führt.

### Problem 3: E-Mail-Template enthielt Verifikations-Link

**In den E-Mail-Templates gab es ein weiteres Verwirrungsproblem:**

`templates/email/appointment_confirmation.html.twig` (Zeile 137-139):
```html
<p>Sie können Ihre Buchung auch unter folgendem Link verifizieren:</p>
<div class="actions">
    <a href="{{ verifyUrl }}" class="button">Termin verifizieren</a>  <!-- ❌ FALSCH -->
</div>
```

Und `src/Service/EmailService.php` (Zeile 108-110, 126):
```php
// In sendAppointmentConfirmation() - ❌ FALSCH
$verifyUrl = $this->urlGenerator->generate('appointment_verify', [
    'token' => $appointment->getBookingToken()
], UrlGeneratorInterface::ABSOLUTE_URL);

$placeholders = $this->getAllPlaceholders($appointment, [
    'ValidierungsLink' => $verifyUrl,  // ❌ FALSCH
    // ...
]);
```

**Das Problem:**
- Die **Bestätigungs-E-Mail** wird NACH erfolgreicher Verifikation gesendet
- Sie sollte KEINEN Verifikations-Link mehr enthalten
- Das war verwirrend für Kunden: "Warum muss ich nochmal verifizieren?"

## ✅ Lösung

### Geänderte Dateien:

#### 1. `src/Service/AppointmentService.php`
**Entfernt** (Zeile 118-122):
```php
// Send confirmation email using EmailService
$this->emailService->sendAppointmentConfirmation($appointment);

// Send confirmation email using Messenger
$this->bus->dispatch(new SendAppointmentMailMessage($appointment->getId(), 'confirmation'));
```

**Grund**: Die Bestätigungs-E-Mail soll NUR nach erfolgreicher Verifikation gesendet werden.

#### 2. `src/Controller/AppointmentController.php`

**Problem:** Standard-Status war `'confirmed'` (Zeile 2268):
```php
$status = $request->request->get('status', 'confirmed'); // ❌ FALSCH
```

**Geändert:** (Zeile 2268 & 2346-2350):
```php
// Zeile 2268: Standard-Status ist jetzt 'pending'
$status = $request->request->get('status', 'pending'); // ✅ RICHTIG

// Zeile 2346-2350: Status nur setzen, wenn explizit übergeben wurde
if ($request->request->has('status')) {
    $appointment->setStatus($status);
}
```

**Grund**: 
- Admin-erstellte Termine starten jetzt auch mit `'pending'`
- Nur wenn explizit ein Status übergeben wird, wird dieser verwendet
- Verhindert versehentliches Markieren als `'confirmed'` ohne Verifikation

#### 3. `src/Service/EmailService.php`

**Entfernt:** Verifikations-Link aus Bestätigungs-E-Mail (Zeile 108-110, 126):
```php
// VORHER - FALSCH:
$verifyUrl = $this->urlGenerator->generate('appointment_verify', ...);
$placeholders = [..., 'ValidierungsLink' => $verifyUrl, ...];

// JETZT - RICHTIG:
// Verifikations-Link wird NICHT mehr generiert
$placeholders = [..., 'ValidierungsLink' => null, ...]; // ✅
```

**Grund**: 
- Bestätigungs-E-Mail wird NUR nach erfolgreicher Verifikation gesendet
- Verifikations-Link ist zu diesem Zeitpunkt überflüssig und verwirrend
- Kunden sollten nicht nochmal zur Verifikation aufgefordert werden

#### 4. `templates/email/appointment_confirmation.html.twig`

**Entfernt:** Verifikations-Button aus Template (Zeile 137-139):
```html
<!-- VORHER - FALSCH: -->
<p>Sie können Ihre Buchung auch unter folgendem Link verifizieren:</p>
<div class="actions">
    <a href="{{ verifyUrl }}" class="button">Termin verifizieren</a>
</div>

<!-- JETZT - RICHTIG: -->
{# ENTFERNT: Verifikations-Link nicht nötig, da bereits verifiziert #}
```

**Grund**: Template-Konsistenz mit E-Mail-Service

## 📧 Korrekter E-Mail-Ablauf

### Nach dem Fix:

1. **Kunde bucht Termin** → Status: `pending`
2. **Verifikations-E-Mail** wird gesendet (asynchron via Messenger)
3. **Kunde klickt auf Verifikations-Link**
4. **Status** wechselt zu `confirmed`
5. **Bestätigungs-E-Mail** wird gesendet

### E-Mail-Typen:

| Typ | Wann | Inhalt |
|-----|------|--------|
| **Verifikation** | Sofort nach Buchung | Link zum Bestätigen der E-Mail-Adresse |
| **Bestätigung** | Nach Verifikation | Alle Buchungsdetails, Kalender-Eintrag |

## 🧪 Testen

### 1. Neue Buchung testen:

```bash
# Frontend-Buchung simulieren
curl -X POST http://localhost:8444/appointments/book \
  -H "Content-Type: application/json" \
  -d '{
    "firstName": "Max",
    "lastName": "Test",
    "email": "max@example.com",
    "courseId": 1
  }'
```

**Erwartetes Ergebnis:**
- Status: `pending`
- Nur Verifikations-E-Mail wird gesendet

### 2. Verifikation testen:

```bash
# Verifikations-Link aufrufen (Token aus E-Mail)
curl http://localhost:8444/appointments/verify/{TOKEN}
```

**Erwartetes Ergebnis:**
- Status wechselt zu: `confirmed`
- Bestätigungs-E-Mail wird gesendet

### 3. Logs prüfen:

```bash
# Prüfe E-Mail-Reihenfolge
tail -f var/log/dev.log | grep "email"
```

**Erwartete Log-Reihenfolge:**
```
[...] Dispatching verification email via Messenger
[...] Starting appointment verification email process
[...] Verification email sent successfully
[...] Appointment verified, status changed to confirmed
[...] Starting appointment confirmation email process
[...] Confirmation email sent successfully
```

## 🔄 Migration bestehender Termine

Wenn es Termine gibt, die fälschlicherweise als `confirmed` gespeichert wurden, aber nicht verifiziert sind:

```bash
# SQL-Query zum Finden betroffener Termine
php bin/console dbal:run-sql "
  SELECT id, created_at, status, email_sent 
  FROM appointment 
  WHERE status = 'confirmed' 
  AND email_sent = 0
  ORDER BY created_at DESC
"
```

**Optional**: Diese Termine auf `pending` zurücksetzen und Verifikation erneut senden.

## ⚠️ Wichtige Hinweise

1. **Alte Methode**: `bookAppointment()` sollte nicht mehr verwendet werden
   - Verwenden Sie stattdessen: `createAppointment()`

2. **E-Mail-Reihenfolge ist kritisch**:
   - Verifikation MUSS vor Bestätigung kommen
   - Bestätigung nur bei Status = `confirmed`

3. **Messenger Worker muss laufen**:
   - Verifikations-E-Mails werden asynchron versendet
   - Starten Sie: `php bin/console messenger:consume async`

## 📊 Betroffene Standorte

Der Benutzer berichtete, dass das Problem **"stark den Standort Mobi"** betrifft. 

**Bestätigt durch Datenbank-Analyse:**
- ID 986 & 976: Beide Termine am Standort **Mobi**
- Status: `confirmed` ohne E-Mail-Verifikation
- Datum: 13.10. und 15.10.2025

**Warum betraf es gerade "Mobi" stärker?**

Vermutlich wurden Termine für den Standort Mobi häufiger **manuell über den Admin-Bereich** erstellt (z.B. nach Telefonbuchungen), während andere Standorte mehr Online-Buchungen hatten.

Der Admin-Endpoint hatte den Standard-Status `'confirmed'`, was bedeutet:
1. Admin erstellt Termin manuell → Status: `confirmed` (ohne Verifikation)
2. System sendet später Verifikations-E-Mail → Kunde ist verwirrt
3. Kunde erhält Bestätigungs-E-Mail BEVOR Verifikation → Falsche Reihenfolge

**Nach dem Fix:**
- Auch Admin-erstellte Termine starten mit `'pending'`
- Admin kann explizit `'confirmed'` auswählen, wenn bereits telefonisch bestätigt
- Keine automatische Verifikations-E-Mail bei Admin-erstellten Terminen

## ✅ Zusammenfassung

**Was wurde geändert:**
- ✅ Entfernt: Direkte Bestätigungs-E-Mail aus `bookAppointment()`
- ✅ Korrigiert: Admin-Endpoint Standard-Status von `'confirmed'` → `'pending'`
- ✅ Entfernt: Verifikations-Link aus Bestätigungs-E-Mail (Service + Template)
- ✅ Dokumentiert: Korrekter E-Mail-Ablauf

**Ergebnis:**
- Kunden erhalten zuerst die Verifikations-E-Mail
- Bestätigungs-E-Mail kommt erst nach erfolgreicher Verifikation
- Status-Management ist konsistent
- Keine Verwirrung mehr durch falsche E-Mail-Reihenfolge

## 🔗 Verwandte Dateien

- `src/Service/AppointmentService.php` - Entfernt: E-Mail-Dispatch aus `bookAppointment()`
- `src/Controller/AppointmentController.php` - Geändert: Standard-Status zu `'pending'`
- `src/Service/EmailService.php` - Entfernt: Verifikations-Link aus `sendAppointmentConfirmation()`
- `templates/email/appointment_confirmation.html.twig` - Entfernt: Verifikations-Button
- `templates/email/appointment_verification.html.twig` - Unverändert (korrekt)
- `src/MessageHandler/SendAppointmentMailMessageHandler.php` - Unverändert