118 lines
8.1 KiB
Markdown
118 lines
8.1 KiB
Markdown
# Abgabe-Dokumentation
|
|
|
|
## Benutzerverwaltung
|
|
|
|
* **Registrierung von Nutzern möglich? Wo?**
|
|
* Ja, die Registrierung ist möglich.
|
|
* **Frontend**: `Frontend/components/auth/register-form.tsx` (Das Formular).
|
|
* **Backend**: `Backend/src/main/java/de/itsolutions/ticketsystem/controller/AuthController.java` (Endpoint `/api/auth/register`).
|
|
|
|
* **Pflichtfelder korrekt umgesetzt? (Name, Email, Passwort, Rolle) Wo?**
|
|
* Ja, die Pflichtfelder werden sowohl im Frontend als auch im Backend geprüft.
|
|
* **Frontend**: Im `RegisterForm` sind die `Input`-Felder mit `required` markiert und eine TypeScript-Validierung verhindert das Absenden leerer Felder.
|
|
* **Backend**: In `Backend/src/main/java/de/itsolutions/ticketsystem/service/AuthService.java` (Methode `register`) wird explizit geprüft, ob Vorname und Nachname vorhanden sind. Die Datenbank-Entität `User.java` setzt `nullable = false` für diese Felder.
|
|
|
|
* **Raumauswahl bei Registrierung für Raumbetreuer? Wo?**
|
|
* Ja, wenn die Rolle "Raumbetreuer" gewählt wird, erscheint eine Checkbox-Liste aller verfügbaren Räume.
|
|
* **Frontend**: `Frontend/components/auth/register-form.tsx` (Zeilen 233-259, bedingtes Rendering: `{role === "RAUMBETREUER" && ...}`).
|
|
|
|
* **Anmelden mit Email und Passwort funktioniert? Wo?**
|
|
* Ja.
|
|
* **Frontend**: `Frontend/components/auth/login-form.tsx` sendet die Daten an `next-auth`, welches den Backend-Endpoint aufruft.
|
|
* **Backend**: `Backend/src/main/java/de/itsolutions/ticketsystem/controller/AuthController.java` (Endpoint `/api/auth/login`).
|
|
|
|
* **Persistente Anmeldung (keine Neuanmeldung bei jeder Nutzung)? Wie?**
|
|
* Ja, durch die Verwendung von **NextAuth.js** im Frontend und JWT (implizit via Session/Header Verwaltung in `auth-context`).
|
|
* **Frontend**: `Frontend/lib/auth-context.tsx` nutzt den `useSession` Hook von NextAuth. Ein `useEffect` Hook (Zeilen 64-77) synchronisiert den Sitzungsstatus beim Laden der Seite automatisch, sodass der Nutzer eingeloggt bleibt. Zusätzlich prüft `validateSession` bei jeder Navigation die Gültigkeit beim Backend.
|
|
|
|
## Ticketfunktionen Lehrer
|
|
|
|
* **Ticket kann erstellt werden? Wo?**
|
|
* Ja, über das "Ticket erstellen" Formular im Dashboard.
|
|
* **Frontend**: `Frontend/components/tickets/create-ticket-form.tsx`.
|
|
* **Backend**: `Backend/src/main/java/de/itsolutions/ticketsystem/controller/TicketController.java` (POST `/api/tickets`).
|
|
|
|
* **Pflichtangaben (Raum, Titel, Beschreibung)? Wo?**
|
|
* Ja.
|
|
* **Backend**: `Backend/src/main/java/de/itsolutions/ticketsystem/entity/Ticket.java` definiert `room`, `title`, und `owner` mit `@Column(nullable = false)`.
|
|
* **Service**: `Backend/src/main/java/de/itsolutions/ticketsystem/service/TicketService.java` prüft, ob der Raum existiert.
|
|
|
|
* **Automatische Speicherung von Erstellungsdatum und Status "offen"? Wo?**
|
|
* Ja.
|
|
* **Backend**: In `Backend/src/main/java/de/itsolutions/ticketsystem/entity/Ticket.java`:
|
|
* `createdAt` wird initialisiert mit `LocalDateTime.now()` (Zeile 34).
|
|
* `status` wird initialisiert mit `"OPEN"` (Zeile 37).
|
|
|
|
* **Eigene Tickets werden tabellarisch angezeigt? Wo?**
|
|
* Ja.
|
|
* **Frontend**: `Frontend/components/dashboard/teacher-dashboard.tsx` nutzt die Komponente `<TicketTable tickets={myTickets} />`.
|
|
|
|
* **Sortierung nach Erstellungsdatum (absteigend)? Wo?**
|
|
* Ja.
|
|
* **Backend**: `Backend/src/main/java/de/itsolutions/ticketsystem/service/TicketService.java` nutzt `ticketRepository.findByOwnerIdOrderByCreatedAtDesc(user.getId())` (Zeile 75).
|
|
|
|
## Ticketfunktionen Raumbetreuer
|
|
|
|
* **Anzeige aller Tickets der betreuten Räume? Wo?**
|
|
* Ja.
|
|
* **Frontend**: `Frontend/components/dashboard/supervisor-dashboard.tsx` filtert und zeigt Tickets für die betreuten Räume an.
|
|
* **Backend**: `Backend/src/main/java/de/itsolutions/ticketsystem/service/TicketService.java` ermittelt die `roomIds` des Betreuers und lädt passende Tickets (Zeilen 76-83).
|
|
|
|
* **Ticketinfos vollständig dargestellt? Wo?**
|
|
* Ja, die Tabelle (`TicketTable`) zeigt Titel, Raum, Status, Datum und Aktionen an. Details können (implizit durch die Struktur) eingesehen werden.
|
|
|
|
* **Sortierung nach Erstellungsdatum (absteigend)? Wo?**
|
|
* Ja.
|
|
* **Backend**: `TicketService.java` nutzt `ticketRepository.findByRoomIdInOrderByCreatedAtDesc(roomIds)` (Zeile 83).
|
|
|
|
* **Änderung des Ticketstatus? Wo?**
|
|
* Ja, direkt in der Tabelle im Dashboard.
|
|
* **Frontend**: `Frontend/components/dashboard/supervisor-dashboard.tsx` übergibt `showStatusUpdate={true}` an die `TicketTable`.
|
|
* **Backend**: `Backend/src/main/java/de/itsolutions/ticketsystem/controller/TicketController.java` (PATCH `/api/tickets/{id}/status`).
|
|
|
|
* **Statuswechsel wird korrekt gespeichert? Wo?**
|
|
* Ja.
|
|
* **Backend**: `Backend/src/main/java/de/itsolutions/ticketsystem/service/TicketService.java` Methode `updateTicketStatus` lädt das Ticket, setzt den neuen Status und speichert es mit `ticketRepository.save(ticket)`.
|
|
|
|
## Navigation & Bedienlogik
|
|
|
|
* **Rollenabhängiger Zugriff auf Funktionen? Wo und Wie?**
|
|
* Ja.
|
|
* **Frontend**: In `Frontend/lib/auth-context.tsx` und den Dashboard-Komponenten (`teacher-dashboard.tsx` vs `supervisor-dashboard.tsx`) wird basierend auf `user.role` entschieden, welche Inhalte angezeigt werden. Das `AppShell` zeigt z.B. das "Admin"-Badge nur für Admins.
|
|
* **Backend**: `TicketService` liefert je nach Rolle (`LEHRKRAFT`, `RAUMBETREUER`, `ADMIN`) unterschiedliche Ticket-Listen zurück.
|
|
|
|
* **Fehlermeldung bei falscher Eingabe? Wo und Wie?**
|
|
* Ja.
|
|
* **Frontend**: `Frontend/components/auth/register-form.tsx` nutzt einen `error` State, um z.B. "Registrierung fehlgeschlagen" oder "Bitte akzeptieren Sie die Datenschutzerklärung" anzuzeigen. In anderen Teilen wird der `useToast` Hook verwendet, um Popups anzuzeigen.
|
|
|
|
## Datenschutz & Sicherheit
|
|
|
|
* **Passwörter werden als Hash gespeichert? Wo und Wie?**
|
|
* Ja, mittels BCrypt.
|
|
* **Backend**: `Backend/src/main/java/de/itsolutions/ticketsystem/service/AuthService.java` nutzt `passwordEncoder.encode(request.getPassword())` vor dem Speichern (Zeile 56).
|
|
* **Konfiguration**: `Backend/src/main/java/de/itsolutions/ticketsystem/config/SecurityConfig.java` definiert die `BCryptPasswordEncoder` Bean.
|
|
|
|
* **Checkbox zur Datenschutzeinwilligung mit Datenschutzrichtlinien? Wo und Wie?**
|
|
* Ja.
|
|
* **Frontend**: `Frontend/components/auth/register-form.tsx` enthält eine Checkbox ("Ich akzeptiere die Datenschutzerklärung"), die angehakt sein muss, bevor der "Registrieren"-Button funktioniert (Zeilen 206-231).
|
|
|
|
## Technische Qualität & Wartbarkeit
|
|
|
|
* **Saubere Backendstruktur? (Spring Boot, JPA)**
|
|
* Ja, das Projekt folgt einer klassischen Schichtenarchitektur:
|
|
* **Controller Layer** (`de.itsolutions.ticketsystem.controller`): Handhabt HTTP-Requests (REST).
|
|
* **Service Layer** (`de.itsolutions.ticketsystem.service`): Beinhaltet die Geschäftslogik (z.B. `TicketService`, `AuthService`).
|
|
* **Repository Layer** (`de.itsolutions.ticketsystem.repository`): Interface für Datenbankzugriffe (Spring Data JPA).
|
|
* **Entity Layer** (`de.itsolutions.ticketsystem.entity`): Bildet Datenbanktabellen als Java-Klassen ab (JPA/Hibernate).
|
|
* **DTOs** (`de.itsolutions.ticketsystem.dto`): Kapselt Daten für den Datentransfer, um Entitäten nicht direkt zu exponieren.
|
|
|
|
* **REST-API konsistent und JSON basiert? Wo und Wie?**
|
|
* Ja.
|
|
* Alle Controller sind mit `@RestController` annotiert.
|
|
* Endpoints nutzen Standard-Methoden (`GET`, `POST`, `PUT`, `DELETE`).
|
|
* Daten werden als JSON gesendet (`@RequestBody`) und empfangen (`ResponseEntity<User>`, `ResponseEntity<Ticket>`).
|
|
* Beispiel: `AuthController` (Authentifizierung), `TicketController` (Ticket-Verwaltung).
|
|
|
|
* **Anwendung stabil und reproduzierbar lauffähig?**
|
|
* Ja, da die Anwendung vollständig containerisiert ist via **Docker**.
|
|
* `docker-compose.yml` definiert die Services (Frontend, Backend, Datenbank), was eine konsistente Umgebung unabhängig vom Host-System garantiert.
|