bwl21 · bwl21 · Apr 16, 2026 · Apr 16, 2026 · Apr 16, 2026 · Apr 16, 2026
diff --git a/AGENTS.md b/AGENTS.md
@@ -39,6 +39,31 @@ churchtoolsClient.get("/api/endpoint", { params: { param1: "value1" } })
 - OpenAPI spec shows `{ data: [...], meta: {...} }` but client unwraps this
 - Use `response` directly, not `response.data`
 
+## Base URL Pattern ⚠️
+
+**Always use centralized `getChurchtoolsBaseUrl()` function for URL building:**
+
+✅ **Correct** (in `src/services/churchtools.ts`):
+
+```typescript
+import { getChurchtoolsBaseUrl } from '../../services/churchtools'
+
+const baseUrl = getChurchtoolsBaseUrl()
+const url = new URL(baseUrl)
+url.searchParams.set('q', 'churchcal')
+// ... build URL
+```
+
+❌ **Wrong** (repeating logic):
+
+```typescript
+const baseUrl = import.meta.env.DEV
+  ? import.meta.env.VITE_BASE_URL
+  : window.location.origin
+```
+
+**Why**: Centralized function ensures consistency across dev/prod and avoids duplication. Works with `npm run dev` (VITE_BASE_URL) and production (window.location.origin).
+
 ## Component Structure
 
 Follow this pattern for new modules:

diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -7,6 +7,33 @@ und dieses Projekt folgt [Semantic Versioning](https://semver.org/spec/v2.0.0.ht
 
 ## [Unreleased]
 
+## [1.1.0] - 2026-04-17
+
+### ✨ Added
+
+- **Room Booking Requests Module** - Complete management interface for ChurchTools room bookings
+  - Dashboard card with booking statistics
+  - Admin panel with full CRUD operations
+  - Booking detail view modal
+  - Conflict details modal with creator information
+  - Advanced filtering (date range, room, conflict status, booking status)
+  - Full-text search across booking fields
+  - Sortable columns
+  - Bulk operations (approve, reject, delete)
+  - Automatic email notifications on rejection
+  - Soft-delete support (statusId 99)
+  - Recurring series handling with deduplication
+  - Conflict detection with time-overlap validation
+  - Type-safe TypeScript composable (`useRoomBookings.ts`)
+  - Permission integration (`churchresource.administer bookings`)
+
+### 📚 Documentation
+
+- `docs/raumbuchungsanfragen/ANFORDERUNG.md` - Requirements specification
+- `docs/raumbuchungsanfragen/API_ANALYSE.md` - API analysis and integration patterns
+- `docs/raumbuchungsanfragen/IMPLEMENTATION_CHECKLIST.md` - Feature checklist
+- `docs/raumbuchungsanfragen/COMPLETION_SUMMARY.md` - Implementation summary
+
 ## [1.0.5] - 2025-09-26
 
 ### 🐛 Fixed

diff --git a/docs/ANFORDERUNG_Raumbuchungsanfragen.md b/docs/ANFORDERUNG_Raumbuchungsanfragen.md
@@ -0,0 +1,258 @@
+# Anforderungsdokument: Raumbuchungsanfragen Management
+
+## 📋 Übersicht
+
+Neue Dashboard-Sektion zur Verwaltung von Raumbuchungsanfragen mit Konflikt-Erkennung und Genehmigungsworkflow.
+
+## 🎯 Motivation & Probleme im bisherigen Prozess
+
+### Problem 1: Unzureichende Kommunikation bei Ablehnung
+
+**Aktuell**: Bemerkungen bei Ablehnung einer Ressourcenbuchung werden nicht in der Ablehnungsmail übermittelt  
+**Folge**: Admin muss zusätzlich noch manuell kommunizieren, warum eine Buchung abgelehnt wurde  
+**Lösung**:
+
+- Bemerkungen direkt in die Ablehnungsmail übernehmen
+- Hinweis in Mail: "Weitere Details zur Ablehnung finden Sie in der Ressourcen-Buchung"
+- Direktlink zur Buchung in der Mail (wenn technisch möglich)
+
+### Problem 2: Manuelle Konflikt-Erkennung ist fehleranfällig
+
+**Aktuell**: Admin sieht auf der Startseite eine Liste mit 100+ offenen Einträgen und muss jeden einzeln öffnen, um Konflikte zu erkennen  
+**Folge**: Zeitaufwendig, fehleranfällig, Konflikte werden leicht übersehen  
+**Lösung**: Dediziertes Dashboard mit Konflikt-Highlighting auf Listenlevel
+
+### Problem 3: Filter sind zu breit
+
+**Aktuell**:
+
+- Filter "offene Bestätigungen" zeigt ALLE Räume, nicht nur die mit offenen Anfragen
+- Konflikte sind in der Filteransicht nicht sichtbar
+  **Folge**: Admin muss trotzdem weitere Filterung und Klicks machen, um relevante Buchungen zu finden  
+  **Lösung**:
+- Nur Räume/Ressourcen anzeigen, für die offene Anfragen existieren
+- Konflikte direkt in der Listenansicht sichtbar
+- Filterung nach Konflikten (mit/ohne)
+
+### Problem 4: Batch-Processing nicht möglich
+
+**Aktuell**: Jede Raumbuchung muss einzeln bestätigt werden, keine Bulk-Aktion  
+**Folge**: Viele Zeit für repetitive Aktionen (z.B. eine Woche mit unkritischen Buchungen bestätigen)  
+**Lösung**: Zeilen-Auswahl und Bulk-Operationen (Bestätigen/Ablehnen mehrerer Buchungen gleichzeitig)
+
+### Problem 5: Unklare Termine für Bucher
+
+**Aktuell**: Nutzer sehen manchmal nur "unbekannter Termin" im Kalender, weil sie die Berechtigung zum Einsehen haben  
+**Folge**: Nutzer verstehen nicht, warum ihre Buchung abgelehnt wurde; Konfusion beim Buchen  
+**Lösung**:
+
+- Klare Fehlermedlung/Hinweis beim Buchen, wenn Termin nicht sichtbar ist
+- Evtl. in Ablehnungsmail erwähnen: "Der geplante Termin war für Sie nicht einsehbar"
+- (Ggfs. im Rahmen separater Verbesserung an Buchungsoberfläche)
+
+## 🎯 Funktionale Anforderungen
+
+### 1. Raumbuchungsanfragen Übersicht (Dashboard Card)
+
+- **Anzeige**: Alle offenen Raumbuchungsanfragen
+- **Spalten**:
+  - Raum / Ressource
+  - Datum / Uhrzeit
+  - Ersteller / Person (im Auftrag von)
+  - Status (offen / wartend)
+  - Konflikte (falls vorhanden)
+  - Aktionen
+
+- **Filterung**:
+  - Nach Status
+  - Nach Raum/Ressource
+  - Nach Datum
+  - Nach Konflikten (nur mit Konflikten / ohne Konflikte / alle)
+  - Freitext-Suche (durchsucht: Raum, Ersteller, Person, Bemerkungen)
+
+- **Sortierung**:
+  - Spalten sind sortierbar (Klick auf Spalten-Header)
+  - Standardsortierung: Datum aufsteigend
+
+### 2. Konflikterkennung
+
+- **Konflikt-Definition**: Überschneidende Buchungen zum gleichen Raum/gleicher Ressource im gleichen Zeitfenster
+- **Visuelles Highlighting**:
+  - Zeile mit Konflikt-Indikator (z.B. rotes Icon/Badge)
+  - Liste der konfliktierenden Buchungen anzeigen
+  - Verantwortliche Person aus konfligierenden Buchungen identifizieren
+
+- **Konflikt-Details**:
+  - Welche andere Buchung(en) konfligieren
+  - Wer ist die verantwortliche Person (Ersteller/im Auftrag von) der Konflikt-Buchung(en)
+
+### 3. Admin-Panel (Verwaltungsbereich)
+
+- **Detailansicht** für jede Anfrage mit:
+  - Vollständige Buchungsdetails
+  - Konflikt-Informationen (falls vorhanden)
+  - Bemerkungen-Feld
+
+- **Zeilen-Auswahl**:
+  - Checkbox in jeder Zeile zur Markierung
+  - "Select All" Checkbox im Header (mit Status-Anzeige: "3 von 10 ausgewählt")
+  - Toggle Select All auch für gefilterte Liste
+
+- **Individuelle Aktionen** (pro Zeile):
+  - ✅ **Bestätigen**: Anfrage akzeptieren, Status → genehmigt
+  - ❌ **Ablehnen**:
+    - Bemerkungsfeld (erforderlich)
+    - Bestätigungs-Dialog
+    - E-Mail-Versand triggern
+
+- **Bulk-Operationen** (für markierte Zeilen):
+  - ✅ **Mehrere Anfragen bestätigen**: Alle markierten genehmigen
+  - ❌ **Mehrere Anfragen ablehnen**: Dialog mit gemeinsamer Bemerkung oder individuelle Bemerkungen
+  - 🗑️ **Löschen**: Markierte Anfragen löschen (nur in bestimmtem Status)
+  - Bulk-Aktion wird deaktiviert, wenn keine Zeile markiert ist
+  - Erfolgs-Feedback nach Bulk-Operation (z.B. "3 Anfragen genehmigt")
+
+### 4. E-Mail-Benachrichtigungen (bei Ablehnung)
+
+#### Standard-Ablehnung:
+
+- **Empfänger**:
+  - Ersteller der Anfrage
+  - Oder: Person "im Auftrag von" (falls angegeben)
+- **Inhalt**:
+  - Raum/Ressource, Datum, Uhrzeit
+  - Begründung/Bemerkung vom Admin
+  - Optional: Alternativ-Zeiten vorschlagen
+
+#### Ablehnung mit Konflikt:
+
+- **Empfänger**:
+  - Ersteller/Person der abgelehnten Anfrage
+  - **PLUS**: Verantwortliche Person(en) aus konfligierenden Buchung(en)
+- **Inhalt**:
+  - Begründung: "Konflikt mit Buchung von [Name]"
+  - Details der konfliktierenden Buchung(en)
+  - Bemerkung vom Admin
+
+## 🏗️ Technische Struktur
+
+Folgt dem Muster bestehender Module:
+
+```
+src/components/room-bookings/
+├── RoomBookingsCard.vue          # Dashboard Card
+├── RoomBookingsAdmin.vue         # Admin Panel
+└── useRoomBookings.ts            # Composable mit API-Logik
+```
+
+## 📊 Datenmodelle
+
+### RoomBooking
+
+```typescript
+{
+  id: string
+  room: string
+  date: string          // ISO-Date
+  startTime: string
+  endTime: string
+  createdBy: string     // Person-ID
+  createdByName: string
+  onBehalfOf?: string   // Person-ID (optional)
+  onBehalfOfName?: string
+  status: 'open' | 'approved' | 'rejected'
+  remarks?: string
+  conflicts?: ConflictInfo[]
+}
+```
+
+### ConflictInfo
+
+```typescript
+{
+  conflictingBookingId: string
+  room: string
+  date: string
+  startTime: string
+  endTime: string
+  conflictingPerson: string // Ersteller oder "im Auftrag von"
+  conflictingPersonId: string
+  conflictingPersonEmail: string
+}
+```
+
+## 🔌 API-Integration (ChurchTools)
+
+- [TBD] Endpoint für Raumbuchungsanfragen abrufen
+- [TBD] Endpoint für Raumbuchung akzeptieren
+- [TBD] Endpoint für Raumbuchung ablehnen
+- [TBD] E-Mail-Service Integration (bestehend oder neu)
+
+## 🎨 UI/UX
+
+- Nutze **BaseCard** für Dashboard-Ansicht
+- Nutze **AdminTable** für Admin-Panel (nach Muster Tags/AutomaticGroups)
+- ChurchTools Design Classes (ct-btn, ct-card, ct-select, ct-modal)
+- Konflikt-Highlighting: Rot/Orange Badge oder Icon
+
+## ✅ Akzeptanzkriterien
+
+### Grundfunktionalität
+
+- [ ] Dashboard zeigt alle offenen Raumbuchungsanfragen
+- [ ] Konflikte werden erkannt und angezeigt
+
+### Filterung & Sortierung
+
+- [ ] Filterung nach Status funktioniert
+- [ ] Filterung nach Raum/Ressource funktioniert
+- [ ] Filterung nach Datum funktioniert
+- [ ] Filterung nach Konflikten (mit/ohne) funktioniert
+- [ ] Freitext-Suche durchsucht alle relevanten Felder
+- [ ] Spalten sind sortierbar
+- [ ] Sortierindikatoren sichtbar (Pfeil im Header)
+
+### Zeilen-Auswahl & Bulk-Operationen
+
+- [ ] Checkboxes in jeder Zeile funktionieren
+- [ ] Select All Checkbox wählt/deselektiert alle Zeilen
+- [ ] Select All Checkbox arbeitet mit gefilterten Daten
+- [ ] Anzeige: "X von Y ausgewählt" ist korrekt
+- [ ] Bulk-Buttons nur aktiv, wenn Zeilen markiert sind
+- [ ] Bulk Bestätigung funktioniert
+- [ ] Bulk Ablehnung funktioniert
+- [ ] Erfolgs-Feedback nach Bulk-Operation angezeigt
+
+### Individuelle Aktionen
+
+- [ ] Admin kann einzelne Anfrage bestätigen
+- [ ] Admin kann einzelne Anfrage mit Bemerkung ablehnen
+- [ ] Bestätigungs-Dialog vor kritischen Aktionen
+
+### E-Mail-Versand
+
+- [ ] E-Mail wird an korrekten Empfänger versandt
+- [ ] E-Mail enthält vollständige Informationen
+- [ ] Konflikt-Info ist in E-Mail enthalten (falls zutreffend)
+
+### Code-Qualität
+
+- [ ] Komponenten folgen bestehendem Design-Pattern (BaseCard, AdminTable)
+- [ ] TypeScript korrekt typisiert
+- [ ] Code lässt sich mit `npm run lint` prüfen
+- [ ] Keine Warnings/Errors beim Build
+
+## 📝 Nächste Schritte
+
+1. [x] Anforderungsdokument erstellen
+2. [ ] Verfeinern & Clarification mit Stakeholder
+3. [ ] ChurchTools API-Endpoints identifizieren
+4. [ ] E-Mail-Template definieren
+5. [ ] Module implementieren
+6. [ ] Testen
+
+---
+
+**Status**: Entwurf  
+**Erstellt**: 2026-04-16  
+**Letzte Änderung**: 2026-04-16