gay
This commit is contained in:
Hymmel
parent
ae3b96d3bb
commit
94170330c7
4 changed files with 120 additions and 238 deletions
|
|
@ -1,169 +0,0 @@
|
||||||
# Technische Dokumentation: Frontend Architektur (IHK/Ausbildung)
|
|
||||||
|
|
||||||
## 1. Einleitung & Technologiewahl
|
|
||||||
Diese Dokumentation beschreibt die Frontend-Architektur des IT-Ticketsystems. Ziel ist es, die Funktionsweise, die verwendeten Patterns und die TypeScript-spezifische Implementierung für die IHK-Abschlussprüfung verständlich darzulegen.
|
|
||||||
|
|
||||||
**Techn Stack:**
|
|
||||||
- **Framework**: Next.js (React)
|
|
||||||
- *Begründung*: Next.js bietet "Server-Side Rendering" (SSR) und einfaches Routing, was die Performance und SEO verbessert. Es strukturiert React-Anwendungen klar.
|
|
||||||
- **Sprache**: TypeScript
|
|
||||||
- *Begründung*: Typsicherheit minimiert Laufzeitfehler. Interfaces (`User`, `Ticket`) definieren klare Datenstrukturen, was besonders bei Teamarbeit und Wartung essenziell ist.
|
|
||||||
- **State Management**: React Context API
|
|
||||||
- *Begründung*: Vermeidung von "Prop Drilling" (Weiterreichen von Daten über viele Ebenen). Zustände wie `user` oder `tickets` werden global verfügbar gemacht.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 2. Projektstruktur & Scopes
|
|
||||||
|
|
||||||
Die Dateien sind logisch getrennt:
|
|
||||||
- `app/`: Enthält die **Seiten (Pages)** und **Routen**. (Next.js App Router).
|
|
||||||
- `components/`: Enthält wiederverwendbare **UI-Elemente** (Buttons, Cards, Tabellen).
|
|
||||||
- `lib/`: Enthält **Logik**, **Typen** und **Konfigurationen** (z.B. `auth-context.tsx`, `types.ts`).
|
|
||||||
|
|
||||||
### TypeScript Besonderheit: Interfaces (`lib/types.ts`)
|
|
||||||
In JavaScript wüssten wir nicht, welche Eigenschaften ein "Ticket" hat. In TypeScript definieren wir einen Bauplan (Interface):
|
|
||||||
|
|
||||||
```typescript
|
|
||||||
// lib/types.ts
|
|
||||||
export type TicketStatus = "OPEN" | "IN_PROGRESS" | "CLOSED" // Union Type: Nur diese 3 Werte sind erlaubt
|
|
||||||
|
|
||||||
export interface User {
|
|
||||||
id: number;
|
|
||||||
name: string;
|
|
||||||
role: "LEHRKRAFT" | "RAUMBETREUER"; // Enforced Role
|
|
||||||
supervisedRooms?: Room[]; // Optionales Array (?): Nicht jeder User hat Räume
|
|
||||||
}
|
|
||||||
|
|
||||||
export interface Ticket {
|
|
||||||
id: number;
|
|
||||||
description: string;
|
|
||||||
status: TicketStatus; // Verwendet den Type von oben
|
|
||||||
owner: User; // Referenziert das User Interface
|
|
||||||
}
|
|
||||||
```
|
|
||||||
**Warum?** Wenn ich nun `ticket.statu` schreibe, warnt mich VS Code sofort ("Did you mean 'status'?"). Das verhindert Tippfehler und Logikfehler.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 3. Kernlogik: Der AuthContext (`lib/auth-context.tsx`)
|
|
||||||
|
|
||||||
Das "Gehirn" der Anwendung. Hier passiert die Kommunikation mit dem Backend.
|
|
||||||
|
|
||||||
### Konzept: Provider Pattern
|
|
||||||
Der `AuthProvider` ist eine Komponente, die um die gesamte App gewickelt wird. Alle Komponenten *innerhalb* dieses Providers können auf seine Daten zugreifen.
|
|
||||||
|
|
||||||
**Code-Analyse (vereinfacht):**
|
|
||||||
|
|
||||||
```typescript
|
|
||||||
// Definition des Context-Typs (Was bietet der Context an?)
|
|
||||||
interface AuthContextType {
|
|
||||||
user: User | null; // Kann null sein, wenn ausgeloggt
|
|
||||||
tickets: Ticket[];
|
|
||||||
login: (e: string, p: string) => Promise<boolean>; // Asynchrone Funktion, gibt true/false zurück
|
|
||||||
}
|
|
||||||
|
|
||||||
// Erstellen des Contexts
|
|
||||||
const AuthContext = createContext<AuthContextType | null>(null);
|
|
||||||
|
|
||||||
// Der Provider (Die Komponente, die Daten bereitstellt)
|
|
||||||
export function AuthProvider({ children }: { children: ReactNode }) {
|
|
||||||
// Lokaler State im Provider
|
|
||||||
const [user, setUser] = useState<User | null>(null); // Generics: <User | null>
|
|
||||||
|
|
||||||
// Funktion zum Daten holen
|
|
||||||
const fetchTickets = useCallback(async (authHeader: string) => {
|
|
||||||
// API Call
|
|
||||||
const res = await fetch(\`\${process.env.NEXT_PUBLIC_API_URL}/tickets\`, {
|
|
||||||
headers: { Authorization: authHeader }
|
|
||||||
});
|
|
||||||
const data = await res.json();
|
|
||||||
setTickets(data); // TypeScript weiß: data muss Ticket[] sein
|
|
||||||
}, []); // Empty dependency array: Funktion wird nicht ständig neu erstellt
|
|
||||||
|
|
||||||
// Diese Werte werden "nach unten" gegeben
|
|
||||||
return (
|
|
||||||
<AuthContext.Provider value={{ user, tickets, login, /*...*/ }}>
|
|
||||||
{children}
|
|
||||||
</AuthContext.Provider>
|
|
||||||
);
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
**Erklärung für die Doku:**
|
|
||||||
1. **State**: Wir nutzen `useState`, um Daten zu speichern. TypeScript sorgt dafür, dass wir in `tickets` nur echte Tickets speichern können.
|
|
||||||
2. **Generics**: `useState<User | null>` sagt: "Dieser State darf nur ein User-Objekt oder null sein".
|
|
||||||
3. **Hooks**:
|
|
||||||
- `useEffect`: "Mach das, wenn die App lädt" (z.B. User prüfen).
|
|
||||||
- `useCallback`: Speichert eine Funktion, damit sie nicht bei jedem Neuladen der Seite neu erstellt wird (Performance).
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 4. Komponenten-Logik (Beispiel: `SupervisorDashboard`)
|
|
||||||
|
|
||||||
Hier sehen wir, wie die Daten konsumiert werden.
|
|
||||||
|
|
||||||
```typescript
|
|
||||||
export function SupervisorDashboard() {
|
|
||||||
// 1. Hook nutzen: Zugriff auf globale Daten
|
|
||||||
const { user, tickets } = useAuth();
|
|
||||||
|
|
||||||
// 2. Optional Chaining (?.)
|
|
||||||
// Wenn user null ist, stürzt die App nicht ab, sondern gibt undefined zurück.
|
|
||||||
// || [] bedeutet: Wenn undefined/null, nutze leeres Array.
|
|
||||||
const supervisedRooms = user?.supervisedRooms || [];
|
|
||||||
|
|
||||||
// 3. Computed Values (useMemo)
|
|
||||||
// Berechne 'roomTickets' nur neu, wenn sich 'tickets' oder 'supervisedRooms' ändern.
|
|
||||||
const roomTickets = useMemo(() => {
|
|
||||||
if (!supervisedRooms.length) return [];
|
|
||||||
|
|
||||||
// Array Methoden: map() und filter()
|
|
||||||
const roomIds = supervisedRooms.map(r => r.id); // [101, 102]
|
|
||||||
return tickets.filter((t) => roomIds.includes(t.room.id));
|
|
||||||
}, [tickets, supervisedRooms]);
|
|
||||||
|
|
||||||
return (
|
|
||||||
<div>
|
|
||||||
{/* Conditional Rendering: Zeige Badge nur wenn count > 0 */}
|
|
||||||
{stats.open > 0 && <Badge>{stats.open}</Badge>}
|
|
||||||
</div>
|
|
||||||
);
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
**Wichtige Konzepte:**
|
|
||||||
- **Destructuring**: `const { user } = useAuth()` zieht nur die `user`-Variable aus dem Context.
|
|
||||||
- **Array High-Order Functions**: `map`, `filter`, `reduce` sind Standard in modernem JS/TS, um Daten umzuwandeln.
|
|
||||||
- **Dependency Arrays**: `[tickets, supervisedRooms]` sagt React: "Führe diese Berechnung nur aus, wenn sich EINE dieser Variablen geändert hat".
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 5. Authentifizierung (NextAuth & Middleware)
|
|
||||||
|
|
||||||
**Ablauf:**
|
|
||||||
1. User gibt Daten ein -> `signIn("credentials", ...)`
|
|
||||||
2. NextAuth sendet Request an unser Backend (`route.ts`).
|
|
||||||
3. Backend antwortet: "OK, hier ist der User".
|
|
||||||
4. Frontend speichert User in der **Session**.
|
|
||||||
5. Der `NextAuthSessionProvider` in `layout.tsx` hält die Session aktiv.
|
|
||||||
|
|
||||||
**Code (`route.ts`):**
|
|
||||||
```typescript
|
|
||||||
async authorize(credentials) {
|
|
||||||
// API Anfrage an eigenes Java Backend
|
|
||||||
const res = await fetch(API_URL + "/login", { ...body });
|
|
||||||
|
|
||||||
if (res.ok) {
|
|
||||||
const user = await res.json();
|
|
||||||
return user; // NextAuth speichert diesen User
|
|
||||||
}
|
|
||||||
return null; // Login fehlgeschlagen
|
|
||||||
}
|
|
||||||
```
|
|
||||||
Wir nutzen NextAuth als "Mittelsmann". Es kümmert sich um Cookies und Security, während unser Backend die eigentliche Prüfung macht.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Zusammenfassung für die Präsentation
|
|
||||||
|
|
||||||
"Die Architektur basiert auf einer klaren Trennung von UI (Components) und Logik (Context/Hooks). Durch den Einsatz von TypeScript werden Datenstrukturen wie User und Tickets strikt typisiert, was die Fehleranfälligkeit drastisch reduziert. Das State Management erfolgt effizient über React Context, wodurch alle Komponenten stets synchronen Zugriff auf den aktuellen Anwendungszustand haben, ohne dass Daten mühsam durchgereicht werden müssen (`Prop Drilling`)."
|
|
||||||
|
|
@ -1,69 +0,0 @@
|
||||||
# Frontend Erklärung (für Einsteiger)
|
|
||||||
|
|
||||||
Dieses Dokument erklärt die Logik und Struktur des Frontends. Es basiert auf **Next.js** (einem React Framework) und **TypeScript**.
|
|
||||||
|
|
||||||
## 1. Grundkonzept: Komponenten
|
|
||||||
Die gesamte Anwendung besteht aus kleinen, wiederverwendbaren Bausteinen, sogenannten **Komponenten**.
|
|
||||||
Stell dir das wie Lego vor: Ein "Knopf" ist ein Stein, ein "Formular" ist eine kleine Platte aus Steinen, und die "Seite" ist das fertige Haus.
|
|
||||||
|
|
||||||
**Warum?**
|
|
||||||
- Übersichtlichkeit: Man muss nicht 1000 Zeilen Code auf einmal verstehen, sondern nur kleine Teile.
|
|
||||||
- Wiederverwendbarkeit: Ein Knopf wird einmal programmiert und überall benutzt.
|
|
||||||
|
|
||||||
## 2. Der Startpunkt: `layout.tsx` und `page.tsx`
|
|
||||||
|
|
||||||
### `app/layout.tsx` (Der Rahmen)
|
|
||||||
Dies ist die "Hülle" um jede Seite.
|
|
||||||
- Hier wird HTML, Body und CSS geladen.
|
|
||||||
- **Wichtig:** Hier sitzt der `NextAuthSessionProvider`. Das ist wie ein unsichtbarer "Rucksack", der die Login-Informationen (Session) trägt und sie überall in der App verfügbar macht.
|
|
||||||
|
|
||||||
### `app/page.tsx` (Der Inhalt)
|
|
||||||
Dies ist die Startseite. Sie entscheidet, was angezeigt wird:
|
|
||||||
1. **Nicht eingeloggt?** -> Zeige den Login-Screen (`AuthScreen`).
|
|
||||||
2. **Eingeloggt als Lehrer?** -> Zeige das Lehrer-Dashboard.
|
|
||||||
3. **Eingeloggt als Raumbetreuer?** -> Zeige das Betreuer-Dashboard.
|
|
||||||
|
|
||||||
**Warum?**
|
|
||||||
So haben wir eine einzige URL (Startseite), die sich aber intelligent an den Nutzer anpasst ("Conditional Rendering").
|
|
||||||
|
|
||||||
## 3. Das Gehirn der App: `lib/auth-context.tsx`
|
|
||||||
|
|
||||||
Hier liegt die wichtigste Logik. Wir nutzen einen **React Context**.
|
|
||||||
Normalerweise müsstest du Daten (z.B. "Wer ist eingeloggt?") von oben nach unten durch alle Komponenten durchreichen ("Prop Drilling"). Das ist mühsam.
|
|
||||||
Der Context ist wie ein **globaler Speicher**, auf den jede Komponente direkt zugreifen kann.
|
|
||||||
|
|
||||||
**Was passiert hier?**
|
|
||||||
- **Zustand (State)**: Hier merken wir uns:
|
|
||||||
- `user`: Wer ist gerade da?
|
|
||||||
- `tickets`: Liste aller Tickets.
|
|
||||||
- `rooms`: Liste aller Räume.
|
|
||||||
- **Aktionen**: Hier liegen die Funktionen wie `login()`, `createTicket()`, `updateTicketStatus()`.
|
|
||||||
- Diese Funktionen sprechen mit dem Backend (dem Server) über `fetch`.
|
|
||||||
|
|
||||||
**Beispiel:**
|
|
||||||
Wenn du auf "Ticket erstellen" klickst, ruft die Komponente `createTicket()` im Context auf. Der Context sendet die Daten an den Server und lädt danach die Ticketliste neu (`fetchTickets`). Alle Komponenten, die die Ticketliste anzeigen, aktualisieren sich dann automatisch.
|
|
||||||
|
|
||||||
## 4. Die Verbindung zum Backend: Authentifizierung
|
|
||||||
|
|
||||||
Wir nutzen **NextAuth.js**.
|
|
||||||
- **Frontend**: Wenn du dich einloggst, schicken wir Benutzername/Passwort an NextAuth.
|
|
||||||
- **Backend (Java)**: Unser Backend prüft die Daten und gibt einen "Token" (Ausweis) zurück.
|
|
||||||
- **Session**: NextAuth speichert diesen "Ausweis" sicher. Bei jeder Anfrage an den Server (z.B. "Lade Tickets") zeigen wir diesen Ausweis vor (`Authorization` Header).
|
|
||||||
|
|
||||||
## 5. Warum TypeScript?
|
|
||||||
|
|
||||||
TypeScript ist JavaScript mit "Typen".
|
|
||||||
Statt einfach eine Variable `data` zu haben (wo alles drin sein könnte: Text, Zahl, oder nichts), definieren wir genau:
|
|
||||||
`interface Ticket { id: number; title: string; status: 'OPEN' | 'CLOSED'; }`
|
|
||||||
|
|
||||||
**Warum?**
|
|
||||||
- **Fehlerschutz**: Wenn du versuchst, einem Ticket einen Namen statt einer ID zu geben, unterstreicht TypeScript das rot – *bevor* du das Programm überhaupt startest.
|
|
||||||
- **Autovervollständigung**: Der Code-Editor weiß genau, welche Eigenschaften ein Ticket hat und schlägt sie dir vor. Das macht das Programmieren viel schneller und sicherer.
|
|
||||||
|
|
||||||
## Zusammenfassung
|
|
||||||
1. Der Nutzer öffnet die Seite (`page.tsx`).
|
|
||||||
2. Der `AuthContext` prüft: "Kenne ich dich?".
|
|
||||||
3. Nein? -> Login Formular.
|
|
||||||
4. Ja? -> Dashboard anzeigen.
|
|
||||||
5. Das Dashboard holt sich Daten (Tickets) aus dem `AuthContext`.
|
|
||||||
6. Der `AuthContext` hat die Daten vorher vom Server geladen.
|
|
||||||
118
abgabe.md
Normal file
118
abgabe.md
Normal file
|
|
@ -0,0 +1,118 @@
|
||||||
|
# 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.
|
||||||
|
|
@ -10,6 +10,8 @@ services:
|
||||||
- postgres_data:/var/lib/postgresql/data
|
- postgres_data:/var/lib/postgresql/data
|
||||||
networks:
|
networks:
|
||||||
- ticketsystem-network
|
- ticketsystem-network
|
||||||
|
ports:
|
||||||
|
- "6767:5432"
|
||||||
restart: unless-stopped
|
restart: unless-stopped
|
||||||
|
|
||||||
backend:
|
backend:
|
||||||
|
|
|
||||||
Loading…
Add table
Reference in a new issue