---
# System prepended metadata

title: 'Student Reconnect: Source Code Dokumentation'

---

<style>
  h4 + p {
  text-indent: 0px;
  margin-left: 20px;
  }
  h5 {
  text-indent: 20px;
  }

  h5 + p {
    margin-left: 40px;
  }

  h6 {
    margin-left: 40px;
  }
  </style>

Student Reconnect: Source Code Dokumentation
===


# Zugriffsdaten -> TODO!!
Zugriffsdaten für Marie Becker (Standard User)
Zugriffsdaten für Admin

# Applikationsstruktur

## Grober Ablauf
1. Die Webapplikation wird über index.php aufgerufen, dabei werden standardmäßig zwei Argumente über die URL übergeben. 1) der Systemtyp und 2) der Request. Das Format hierzu sieht bspw. so aus: `index.php/t=frontend&request=register`. `t` ist hierbei der Identifier für den Systemtyp und `request` für den Request. Falls die Argumente nur teilweise und nicht angegeben werden, wird eine Standardseite aufgerufen.
2. In der `index.php` wird eine Applikationsinstanz erzeugt, wobei Instanzen für u.a. Router, Request, Response, Controller und View erzeugt werden.
3. Die `run()`-Methode der Appliaktion wird ausgeführt, diese ruft daraufhin die resolve()-Methode des Routers der Applikation auf, um dessen Inhalt auszugeben.
4. Aufruf `resolve()`-Methode:
    1. Callback-Funktion definieren
        1. Prüfen, ob der Aufruf valide ist. Dazu wird in der Applikation geprüft, ob der Aufrufe in der Routemap definiert ist.
        2. Falls der Aufruf nicht in der Routemap definiert ist, setzte `$callback` auf `false`.
        3. Falls der Aufruf in der Routemap definiert wurde, setzte `$callback` auf die in der Routemap definierten Callback-Funktion.
    2. Callback auflösen
        1. Falls `$callback == false`: Setzte und render 404-Error mit renderView(). Diese View wird dann zurückgegeben und in `run()` gerendert.
        2. Falls `$callback` ein String ist: Rufe renderView mit dem String auf. Diese View wird dann zurückgegeben und in `run()` gerendert.
        3. Falls `$callback` ein Array ist: Erstelle eine neue Controllerinstanz des Typs, der in der Routetable definiert wurde, und speichere diesen in der Applikationsinstanz. Setze $callback gleich der Controllerinstanz und rufe die im Aufruf definierte Methode (Request) der Controllerinstanz auf und gebe diese zurück.

### Visualisierung


```flow
st=>start: Website Aufruf
e=>end: End
index=>operation: index.php
run=>operation: Application.run()
resolve=>operation: Request.resolve()
cond=>condition: Aufruf valide?
yes=>operation: $callback = Callback in der Routemap
no=>operation: $callback = false
404=>operation: Render 404 Error
cond_callback=>condition: Callback String?
string_yes=>operation: renderView(String)
cond_array=>condition: Callback Array?
array_yes=>operation: Führe die spezifizierte Methode 
des spezifierten Controllers aus 



st->index->run->resolve->cond
cond(no)->no->404->e
cond(yes)->yes->cond_callback
cond_callback(yes)->string_yes->e
cond_callback(no)->cond_array
cond_array(yes)->array_yes->e
```
### Die Applikationen
Student Reconnect lässt sich in zwei Subsysteme unterteilen:
1. Usersystem (Student Reconnect Webseite für den 'normalen Nutzer')
2. Administrationssystem (Student Reconnect Webseite für Administrationszwecke)
   
Dabei ist zu beachten, dass diese beiden Subsysteme dasselbe Kernsystem verwenden und über die selbe URL (`index.php`) aufrufbar sind. 
Es kann zwischen den Subsystemen unterschieden werden, indem der Systemtyp in der URL als Parameter übergeben wird.

### Rollensystem

Bei Student Reconnect wird zwischen drei Rollen unterschieden: 
1. User
2. Moderatoren
3. Administratoren

Dies ist hierarchisch aufgebaut, sprich: Jeder Moderator hat die Rechte der User und Administratoren haben zusätzlich die Rechte der Moderatoren.

#### Rechteverteilung



| User     | Moderatoren | Administratoren |
| -------- | -------- | -------- |
| Nutzung der Kernfunktionen wie z.B.: Matching, Eventerstellung, Visitenkartenaustausch etc.| Zugriff zum Moderationsbereich und somit: Akzeptieren bzw. Ablehnen von Event/User Reports     | Zugriff zum Administrationsbereich und somit zur Administration von Usern und deren Interessen, Events und deren Teilnehmer sowie die Interessen selbst     |
| | + Rechte von Usern | + Rechte von Moderatoren |

#### Wo sind die Rollen definiert?

Die jeweilige Rolle der User sind in der Datenbank im Attribut `id_role` definiert. 
Dabei entspricht `1 = User`, `2 = Moderator` und `3 = Administrator`.

#### Wie werden die Zugriffsberechtigungen für die einzelnen Bereiche definiert?
Die Zugriffsberechtigung wird für jede einzelne Webseitenanfrage (`Route`) definiert. Sodass diese sehr genau festgelegt werden kann. 
> Siehe `Router -> Methoden -> setRoute() -> permissionNeed`.




# Kernsystem

> Das nachfolgende Kernsystem basiert auf einem PHP-MVC-Framework, welches von [TheCodeholic](https://github.com/thecodeholic) entwickelt wurde. Link: [https://github.com/thecodeholic/tc-php-mvc-core](https://github.com/thecodeholic/tc-php-mvc-core). Dieses wurde in Teilen erweitert/abgeändert, um die eigenen Anforderungen an der Webseite und der Systemumgebung zu erfüllen. Ein wichtiger Bestandteil, der erweitetert wurde, ist z.B. das Berechtigungssystem.

## index.php
Die index.php ist immer der Entrypoint für Student Reconnect, unabhängig davon, ob die standard Benutzeroberfläche aufgerufen wird oder der Administrationsbereich.

### Was passiert hier?
1. Notwendige Klassen (hauptsächlich Controller) werden eingebunden
1. Eine `Application`-Instanz wird erstellt
1. Erlaubte Routen mit deren Callback werden definiert über `$app->router->setRoute(method, systype, request, callback, permissionNeed)`
1. Applikation wird gestartet über `$app->run()`

## `Application`
Die `Application`-Klasse ist die Hauptklasse der Applikation. Hier werden alle notwendigen Objekte des Kernsystems erstellt und initialisiert.

### Attribute
1. `$router`: Der Router der Applikation (`Router`-Klasse)
2. `$request`: Der Request der Applikation (`Request`-Klasse)
3. `$response`: Die Response der Applikation (`Response`-Klasse)
4. `$controller`: Der Controller der Applikation (`Controller`-Klasse)
5. `$view`: Die View der Applikation (`View`-Klasse)
6. `$app`: Die Applikation selbst als statisches Objekt (`Application`-Klasse)
7. `$ROOT_DIR`: Der Root-Verzeichnispfad
8. `$systemType`: Der Systemtyp der Applikation (frontend (standard Benutzeroberfläche) oder backend (Administrationsbereich))
9. `$layout`: Das Layout der Applikation (standardmäßig = 'main')

### Methoden

#### `__construct()`
Konstruktor der Applikation. Hier werden alle notwendigen Objekte erstellt und initialisiert.  Außerdem wird hier die Session gestartet.
#### `run()`
"Startet" die Applikation und ruft die `resolve()`-Methode des Routers auf.

## `Router`

### Attribute
1. `$routes`: Die Routemap der Applikation (`Array`)
2. `$request`: Der Request der Applikation (`Request`-Klasse)
3. `$response`: Die Response der Applikation (`Response`-Klasse)

### Methoden

#### `__construct(Request, Response)`
Konstruktor der Router-Klasse. Hier werden Request und Response der Applikation übergeben und initalisiert.
#### `setRoute(method, systype, request, callback, permissionNeed)`
Fügt eine neue Route zur Routemap hinzu und definiert dafür die Callback-Funktion und die benötigten Rechte.

##### Parameter
1. `method` (String): Die Methode des Aufrufs (`get`/`post`)
2. `systype` (String): Der Systemtyp (`frontend` (standard Benutzeroberfläche) oder `backend` (Administrationsbereich))
3. `request` (String): Der Request. Beispiele: (`index`/`login`/`logout`/`register`/`admin`/`404`)
4. `callback` (String/Array): Die Callback-Funktion mit Controller-Klasse. Beispiele: `[SiteController::class, 'home']` oder `[EventsController::class, 'events']`
5. `permissionNeed` (int): Die benötigte Berechtigung für den Aufruf. Erlaubte Werte:
    * `0`: Keine Berechtigung benötigt (z.B. für Landingpage, Login oder Registrierung)
    * `1`: Benutzer-Berechtigung
    * `2`: Moderator-Berechtigung
    * `3`: Admin-Berechtigung

#### `resolve()`
Hier wird der Request aufgelöst und die entsprechende Callback-Funktion aufgerufen. 
Dazu wird zunächst geprüft, ob der Request in der Routemap vorhanden ist und ob der User die entsprechende Berechtigung dafür hat.
Der weitere Ablauf hängt von diesem Prüfergebnis ab:
* Falls der Request nicht in der Routemap vorhanden ist, wird eine 404-Fehlerseite ausgegeben.
* Falls der User die entsprechende Berechtigung nicht hat, wird eine 403-Fehlerseite ausgegeben.
* Fall der Callback nur ein String ist, wird die View mit dem Namen des Strings ausgegeben.
* Falls der Callback ein Array ist, finden weitere Prüfungen abhängig vom Login-Status statt und der benötigten Berechtigung statt:
    * Falls der User nicht eingeloggt ist und die benötigte Berechtigung > 0 ist, wird der User auf die Login-Seite weitergeleitet.
    * Falls der User eingeloggt ist und die benötigte Berechtigung = 0 ist, wird der User auf die Matching-Seite weitergeleitet.
    * Falls der User eingeloggt ist und die benötigte Berechtigung größer als die vorhandene Berechtigung ist, wird die 403-Fehlerseite ausgegeben.
    * Ansonsten wird die im Callback definierte Methode der spezifizierten Controller-Klasse mit `call_user_func($callback, $request)` aufgerufen und zurückgegeben.


##### `@return` (`String`): String mit dem HTML-/JS-Code der View.

#### `renderView(String $view, Array $params)`
Es wird die Methode `View::renderView($view, Application::$systemType, $params)` aufgerufen und zurückgegeben.
Dabei wird der Systemtyp der Applikation als Parameter ausgelesen und übergeben.

##### `@return` (`String`): String mit dem HTML-/JS-Code der View.

#### `renderViewContent($view, $params = [])`
Es wird die Methode `View::renderViewContent($view, Application::$systemType, $params)` aufgerufen und zurückgegeben.
Dabei wird der Systemtyp der Applikation als Parameter ausgelesen und übergeben.
Diese Methode kann genutzt werden, wenn eine View ohne ein Layout ausgegeben werden soll.

##### `@return` (`String`): String mit dem HTML-/JS-Code der View.

## `Request`

### Attribute
1. `$systype`: Der Systemtyp (`frontend` (standard Benutzeroberfläche) oder `backend` (Administrationsbereich))
2. `$request`: Der Request. Z.B. `index`/`login`/`logout`/`register`/`admin`/`404` (`String`)
3. `method` (String): Die Methode des Aufrufs (`get`/`post`)
4. `$param`: Die Parameter des Requests (`Array`)

### Methoden

#### `__construct()`
Konstruktor der Request-Klasse. Hier wird der Request ausgelesen und initalisiert.

#### `getMethod()`
Gibt die Methode des Requests zurück (kleinbuchstaben).
##### `@return` (`String`): Die Methode des Requests.

#### `fetchSysType()`
Gibt den Systemtyp zurück. Falls kein Systemtyp angegeben ist, wird der Standardwert `frontend` zurückgegeben.
##### `@return` (`String`): Der Systemtyp.

#### `fetchRequest()`
Gibt den Request (aus der URL) zurück. Falls kein Request angegeben ist, wird der Standardwert `landingpage` zurückgegeben.
##### `@return` (`String`): Der Request.

#### `getBody()`
Gibt den Request-Body in `$key => $value`-Paaren zurück.
Bei einer POST-Anfrage können zudem zweidimensionale Arrays mit den Parametern des Requests ausgelesen werden.

##### `@return` (`Array`): Array mit den Request-Body-Parametern. Format: `[$key => $value]` oder auch `[$key => [$key => $value]]`.

## `Controller`
Controller Basis Klasse. Alle anderen Controller-Klassen müssen von dieser Klasse erben.

### Attribute
1. `$layout`: Der Layout-Name (`String`)

### Methoden

#### `setLayout(String $layout)`
Setzt das `$this->layout`-Attribut.

#### `render(String $view, Array $params)`
Ruft im Router die Methode `renderView($view, $params)` auf und gibt das Ergebnis zurück.
##### `@return` (`String`): String mit dem HTML-/JS-Code der View.

#### `renderContent($view, $params = [])`
Ruft im Router die Methode `renderViewContent($view, $params)` auf und gibt das Ergebnis zurück.
Diese Methode kann genutzt werden, wenn eine View ohne ein Layout ausgegeben werden soll.
##### `@return` (`String`): String mit dem HTML-/JS-Code der View.

#### `isLoggedIn()`
Gibt `true` zurück, wenn der User eingeloggt ist, ansonsten `false`.
##### `@return` (`Boolean`): `true` oder `false`.

#### `isModerator()`
Gibt `true` zurück, wenn der User eingeloggt ist und ein Moderator ist, ansonsten `false`.
##### `@return` (`Boolean`): `true` oder `false`.

#### `isAdmin()`
Gibt `true` zurück, wenn der User eingeloggt ist und ein Administrator ist, ansonsten `false`.
##### `@return` (`Boolean`): `true` oder `false`.

#### `getUserRole()`
Gibt die Benutzerrolle des Benutzers, spezifiziert in `$_SESSION['user']['id_role']` zurück.

##### `@return` (`int`): ID der Benutzerrolle.

#### `isRoleSet()`
Gibt `true` zurück, wenn eine Benutzerrolle in `$_SESSION['user']['id_role']` gesetzt ist, ansonsten `false`.
##### `@return` (`Boolean`): `true` oder `false`.

#### `setRoleZero()`
Setzt die Benutzerrolle in `$_SESSION['user']['id_role']` auf 0.


## `Model`
Model Basis Klasse. Alle anderen Model-Klassen müssen von dieser Klasse erben. In der Klasse werden u.a. verschiedene
Regeln definiert, die für die Validierung von Daten genutzt werden können.

### Attribute
1. `$errors`: Array mit Fehlern. Format: `[$key => $value]`

### Definierte Regeln
1. `RULE_REQUIRED`: Der Wert muss gesetzt sein.
2. `RULE_EMAIL`: Der Wert muss eine gültige Email-Adresse sein.
3. `RULE_EMAIL_UNI`: Der Wert muss eine gültige Email-Adresse der Uni-Bamberg sein sein.
4. `RULE_MIN`: Der Wert muss mindestens eine bestimmte Anzahl an Zeichen lang sein.
5. `RULE_MAX`: Der Wert darf maximal eine bestimmte Anzahl an Zeichen lang sein.
6. `RULE_MATCH`: Der Wert muss mit einem anderem String übereinstimmen. Bei der Verwendung von `RULE_MATCH` muss der Wert übergeben werden.
7. `RULE_WRONG_PASSWORD`: Wird nur für die Fehlermeldung bei falschem Passwort benötigt.
8. `RULE_EMAIL_UNIQUE`: Der String muss eine Email-Adresse sein, die noch nicht in der Datenbank vorhanden ist.

### Methoden

#### `loadData(Array $data)`
Lädt die Daten aus dem Array `$data` in die Model-Klasse, sofern der entsprechende Key als Property in der Klasse vorhanden ist.
Lädt keine `null`-Werte.

#### `checkEmailNotUnique(String $email)`
Prüft, ob die Email-Adresse `$email` schon in der Datenbank vorhanden ist.
##### `@return` (`Boolean`): `true` oder `false`.

#### `rules()`
Abstrakte Methode, die die Regeln für die Validierung der Daten zurückgibt.
##### `@return` (`Array`): Array mit den Regeln.

#### `validate()`
Prüft, ob die Daten in `$this->data` gemäß den Regeln in `$this->rules()` gültig sind.
Falls nicht, wird eine Fehlermeldung mit `$this->addError()` einem Array hinzugefügt (je nicht eingehaltener Regel) und nach vollständiger Prüfung 
zurückgegeben.
##### `@return` (`Boolean`): `true` oder `false`. Wenn `false`, dann ist `$this->errors` sind Fehler in der Validierung aufgetreten.

#### `addError(String $attribute, String $rule, Array $params)`
Fügt eine Fehlermeldung anhand `$this->errorMessages()` zu `$this->errors` hinzu.

#### `addErrorManual(String $attribute, String $errorMsg)`
Manuell eine Fehlermeldung zu `$this->errors` hinzufügen.

#### `errorMessages()`
Methode in der die einzelnen Fehlermeldungen zu den Regeln definiert sind und diese als Array zurückgibt.
##### `@return` (`Array`): Array mit den Fehlermeldungen.

#### `hasError(string $attribute)`
Gibt `true` zurück, wenn ein Fehler in `$this->errors` für das Attribut `$attribute` vorhanden ist, ansonsten `false`.
##### `@return` (`Boolean`): `true` oder `false`.

#### `getError(String $attribute)`
Gibt die erste Fehlermeldung zu dem Attribut `$attribute` zurück.
##### `@return` (`String`): Fehlermeldung

## `View`
View Basis Klasse. Alle anderen View-Klassen müssen von dieser Klasse erben.

### Methoden

#### `renderView(String $view, String, $systemType, array $params)`
Rendert die View `$view` und gibt den HTML-Code zurück. Daten die über `$params` übergeben werden, werden in die View eingebunden und können dort genutzt werden. Der View-Content wird über die Methode `renderViewContent($view, $systemType, $params)` erzeugt.
Das Layout und der Content werden mit Output-Buffering geladen. Damit der Content richtig in das Layout 
geladen werden kann, muss im Layout im Zielbereich das Tag `{{content}}` eingefügt werden. Dieser Tag wird dann durch den Content ersetzt.
##### `@return` (`String`): HTML-Code der View.

#### `renderViewContent(String $view, String $systemType, array $params)`
Rendert den Content der View `$view` und gibt den HTML-Code zurück. Daten die über `$params` übergeben werden, werden in die View eingebunden und können dort genutzt werden.
View wird mit Output-Buffering geladen.
##### `@return` (`String`): HTML-Code der View.


### Layout
Das Layout ist das HTML-Grundgerüst, in welches später die Views eingebunden werden.
Dies kann z.B. den Header und die Navbar enthalten. Außerdem können hier die notwendigen CSS- und JavaScript-Dateien eingebunden werden.
Es können verschiedene Layouts definiert werden. Die Layouts werden in `app/frontend/views/layouts` bzw. `app/backend/views/layouts` mit der Endung `.php` gespeichert.

## Response
Response Klasse, um Responses für den Browser zu erzeugen.

### Methoden

#### `setStatusCode(Int $code)`
Setzt den HTTP-Status-Code.

#### `redirect(String $url)`
Leitet den Browser auf die URL `$url` weiter.


## `Database`
Database Klasse, um Datenbank-Zugriffe zu ermöglichen.

### Attribute
1. `$pdo`: Die PDO-Datenbank-Verbindung.
2. `$config`: Die Konfiguration der Datenbank.

### Methoden

#### `__construct()`
Initialisiert die Datenbank-Verbindung.

#### `prepare(String $sql)`
Erzeugt ein PDOStatement und gibt dieses zurück.
#####  `@return` (`PDOStatement`): PDOStatement

## `config`
Datenbank-Konfiguration.

### Attribute
1. `$DB_ENABLED`: Soll die Datenbank verwendet werden?
2. `$DB_DSN`: Datenbank-URL mit Port und Datenbankname.
3. `$DB_USER`: Datenbank-Benutzername.
4. `$DB_PASSWORD`: Datenbank-Passwort.


# Usersystem

## Controller

### `AuthController`

#### Attribute

#### Methoden


##### `__construct()`
Initialisiert den Controller.

##### `login()`
Erstellt ein neues `LoginModel` und rendert das Login-Formular mit dem `LoginModel` als Parameter.

###### `@return` (`String`): HTML-Code der View.	

##### `logout()`
Löscht den User aus der Session und leitet den Browser auf die Startseite zurück.

##### `handleLogin(Request $request)`
Erstellt ein neues `LoginModel` und prüft mittels `validate()`, ob die Daten im Request gültig sind. Wenn ja, wird versucht, den User mittels `login()` zu authentifizieren. Wenn der User authentifiziert wurde, wird er in die Session gespeichert und der Browser auf die Profilseite weitergeleitet. Falls der User nicht authentifiziert werden konnte, wird eine Fehlermeldung in das `LoginModel` geschrieben und das Login-Formular wird erneut aufgerufen, wo nun der Fehler ausgegeben wird.

###### `@return` (`Mixed/String`): HTML-Code der View oder `null` wenn der User authentifiziert werden konnte.

##### `register(Request $request)`
Erstellt ein neues `RegisterModel` und rendert das Register-Formular mit dem `RegisterModel` als Parameter.

###### `@return` (`String`): HTML-Code der View.

##### `handleRegister(Request $request)`	
Erstellt ein neues `RegisterModel` und prüft mittels `validate()`, ob die Daten im Request gültig sind. Wenn ja, wird versucht, den User mittels `register()` zu registrieren. Wenn der User registriert wurde, wird er auf die Loginseite weitergeleitet. Falls der User nicht registriert werden konnte, wird eine Fehlermeldung in das `RegisterModel` geschrieben und das Register-Formular wird erneut aufgerufen, wo nun der Fehler ausgegeben wird.

###### `@return` (`Mixed/String`): HTML-Code der View oder `null` wenn der User registriert wurde.

##### `pwReset()`
Erstellt ein neues `PwResetModel` und rendert das Passwort-Reset-Formular.

###### `@return` (`String`): HTML-Code der View.

##### `handlePWResetEmail(Request $request)`
Wird verwendet um einen Verifikationscode zum Passwort Reset an die angegebene Email-Adresse zu senden.
Erstellt ein neues `PwResetEmailModel` und prüft mittels `validate()`, ob die Daten im Request gültig sind. Wenn ja, wird der Verifikationscode an die angegebene Email-Adresse gesendet und im `PwResetEmailModel` gespeichert. Wenn der Verifikationscode gesendet wurde, wird der User auf die Passwort-Reset-Seite weitergeleitet. Falls der Verifikationscode nicht gesendet werden konnte, wird die `error_email_not_sent`-Seite angezeigt. Wenn die eingegebene Email-Adresse nicht validiert werden konnte, wird die `error_email_validation`-Seite angezeigt.

###### `@return` (`String`): HTML-Code der jeweiligen View


##### `handlePWReset(Request $request)`
Wird verwendet um das Passwort für den User zu ändern und prüft dazu den angegbenen Verifikationscode.
Erstellt ein neues `PwResetModel` und prüft mittels `isVerifCodeSet()`, ob der Verifikationscode in der Session gespeichert ist. Falls das nicht der Fall ist, wird die Seite `error-verifcode_not_set` angezeigt. Ansonsten wird mittels `validate()` geprüft ob die angebenen Daten aus dem Request gültig sind. Wenn nicht, wird ein Fehler in das `PwResetModel` geschrieben und das Passwort-Reset-Formular wird erneut aufgerufen, wo nun der Fehler ausgegeben wird. Wenn die Daten gültig sind, wird der Verifikationscode mittels `loadVerifCode()` geladen und versucht das Passwort zu ändern. Wenn das Passwort geändert wurde, wird dies dem User angezeigt. Wenn nicht, wird eine Fehlermeldung in das `PwResetModel` geschrieben und das Passwort-Reset-Formular wird erneut aufgerufen, wo nun der Fehler ausgegeben wird.

###### `@return` (`String`): HTML-Code der jeweiligen View

### `EventsController`

#### Attribute

1. `$eventFeedModel` (`EventFeedModel`): Model für den Event-Feed.

#### Methoden

##### `__construct()`
Initialisiert das EventFeedModel.

##### `events()`
Rendert den Event-Feed.

###### `@return` (`String`): HTML-Code der jeweiligen View

##### `eventcreation()`
Erstellt ein neues EventModel und rendert das `eventcreation`-Formular.

###### `@return` (`String`): HTML-Code der jeweiligen View

##### `handleEventCreation(Request $request)`
Verarbeitet die Eventerstellung (Aufgerufen vom `eventcreation`-Formular).
Erstellt ein neues EventModel und prüft mittels `validate()`, ob die Daten im Request gültig sind. Wenn ja, wird versucht, das Event zu erstellen. Wenn das Event erstellt wurde, wird der User auf die Event-Feed weitergeleitet. Falls das Event nicht erstellt werden konnte, wird eine Fehlermeldung in das `EventModel` geschrieben und das `eventcreation`-Formular wird erneut aufgerufen, wo nun der Fehler ausgegeben wird.
###### `@return` (`String`): HTML-Code der jeweiligen View mit den Fehlern oder `void, da Redirect.

##### `API_getAllEvents()`
Liefert alle Events als HTML Code.
###### `@return` (`String`): HTML-Code der Event-Cards

##### `API_getEventDetails(Request $request)`
Liefert ein JSON-Objekt mit den Details eines Events.
Das Event wird über das Keyword `eid` im `Request` identifiziert.
Es werden auch zwei weitere Flags übergeben: `attendeeRated` und `hostRated`.
Diese drücken aus, ob die Teilnehmer oder der Host bereits bewertet wurden/wurde, sodass im Frontend nicht nochmals ein Bewertungsformular angezeigt werden muss.

###### `@return` (`String`): JSON-Objekt

##### `API_toggleSignOnForEvent(Request $request)`
Aktiviert/deaktiviert den Anmeldestatus des eingeloggten Users für das angefragte Event.
Das Event wird über das Keyword `eid` im `Request` identifiziert.

##### `API_getMyEvents(Request $request)`
Liefert alle Events, die der eingeloggte User erstellt hat.

###### `@return` (`String`): HTML-Code der Event-Cards

##### `renderEventCards($events)`
Rendert für alle Events im Array `$events` die View `eventcard` über `renderContent` und gibt diese View direkt aus.

##### `API_deleteEvent(Request $request)`
Löscht ein Event.
Das Event wird über das Keyword `eid` im `Request` identifiziert.
Es wird gleichzeitig geprüft, ob der eingeloggte User die Berechtigung hat, das Event zu löschen.
Gibt ein JSON-Objekt über den Erfolg aus `success = {true,false}` und falls `success = false`, wird noch eine Errornachricht ausgegeben.

##### `API_getAttendees(Request $request)`
Rendert die Teilnehmerliste eines Events mit den `attendeelistitem`-Views.
Das Event wird über das Keyword `eid` im `Request` identifiziert.

##### `API_toggleAcceptance(Request $request)`
Aktiviert/deaktiviert die Akzeptierung eines Users für ein Event.
Das Event wird über das Keyword `eid` im `Request` identifiziert und der User über `uid`.
Es wird ein JSON-Objekt ausgegeben. Bei Erfolg: `['success' = 'true', 'newStatus' = $newStatus]`. Bei Misserfolg: `['success' = 'false', 'error' = 'Du bist nicht der Ersteller dieses Events!']`. 

##### `API_searchEvents(Request $request)`
Sucht nach Events anhand eines Suchbegriffes und rendert die gefundenen Events über `renderEventCards()`.
Der Suchbegriff wird im `Request` über `searchTerm` identifiziert.


### `MatchingController`

#### Attribute
1. `$id_myself` (`int`): ID des eigenen Users.
2. `$UserMyself` (`UserModel`): UserModel des eigenen Users.
3. `$UserMatchModel` (`UserMatchModel`): UserMatchModel
4. `$UserAllBase` (`array`): Array mit UserModels der vollständigen Usermenge.
5. `$UserAll` (`array`): Array mit UserModels die im Matching angezeigt werden.
6. `$hasInterestModel` (`HasInterestModel`): HasInterestModel mit den Interessen der Usern.
7. `$matchingInstanceModel` (`MatchingInstanceModel`): MatchingInstanceModel mit allen Matching Instanzen.
8. `$interestModel` (`InterestModel`): InterestModel mit allen Interessen.
9. `$matchModel` (`MatchModel`): MatchModel mit allen Matchen.
10. `$interestFilter` (`array`): Array der Interessen IDs nach denen gefiltert werden soll.
11. `$flag_noInterestOverlaps` (`bool`): Flag, ob User mit überschneidenden Interessen gefunden wurden. 

#### Methoden

##### `__construct() `
Initialisiert die Attribute und bereitet die UserModels in `$UserAll` vor. Sprich UserModels werden erstellt, Interessen hinzugefügt, MatchingInstances geladen und alte MatchingInstances aus der Liste gelöscht.


##### `matching() `
Standard Methode zum Rendern der Matching-Seite. Interessensüberschneidungen werden gezählt, User ohne solche entfernt und es wird ein Zufälliger User gerendert.
###### `@return` (`String`): HTML-Code der View mit dem User.

##### `filter() `
Alternative Methode zum Rendern der Matching-Seite. Diese Methode wird aufgerufen, wenn der User auf den Filter-Button klickt.
Es wird dabei geprüft ob Filter in `$_POST['interests']` gesetzt sind, falls js wird dieser Filter berücksichtigt und in der Session gespeichert.  
###### `@return` (`String`): HTML-Code der View mit dem User.

##### `resetFilter()`
Methode zum Zurücksetzen des Filters. Filter werden auf die Standardwerte des Users zurückgesetzt.

##### `clearFilter() `
Filter werden gelöscht bzw. alle Interessen werden dem Filter hinzugefügt.

##### `saveInterestFilter() `
Methode zum Speichern des Filters. Filter werden in `$_SESSION['interestFilter']` gespeichert.

##### `fetchInterestFilter() `
Methode zum Laden des Filters. Filter werden aus `$_SESSION['interestFilter']` geladen.

##### `deleteInterestFilter() `
Methode zum Löschen des Filters. Filter werden aus `$_SESSION['interestFilter']` gelöscht.

##### `isInterestFilterSet() `
Methode zum Prüfen ob ein Filter gesetzt ist.
###### `@return` (`bool`): True, falls Filter gesetzt ist, False, falls nicht.

##### `fetchMyself() `
Methode zum Laden des eigenen Users und speichert diesen in `$UserMyself`.

##### `fetchAllUser() `
Methode zum Laden aller User außer dem eigenen und speichert diese in `$UserAllBase`. `$UserAll` wird aus `$UserAllBase` erstellt.

##### `setOriginalInterests() `
Setz den Interessensfilter auf die Interessen des eigenen Users.

##### `addAllInterestsToUsers() `
Methode zum Hinzufügen aller Interessen zu den UserModels.

##### `fetchMatchingInstances() `
Methode zum Laden aller MatchingInstances in Bezug auf den eigenen User und speichert diese in `$UserMyself->matchingInstancesOld`.

##### `deleteOldMatchesFromUserList() `
Methode zum Löschen aller alten MatchenInstances aus `$UserAll` und `$UserAllBase`.

##### `printUserListCount() `
Gibt die Anzahl der Elemente in `$UserAll` aus.

##### `countInterestOverlap() `
Zählt die Interessensüberschneidungen aller User in Bezug auf den eigenen User und speichert den Wert in `$user->interestOverlapScore`.

##### `printSortedUserList() `
Debug Methode zum Ausgeben der UserListe sortiert nach der Anzahl der Interessensüberschneidungen.

##### `deleteUsersWithNoInterestOverlap() `
Methode zum Löschen aller User ohne Interessensüberschneidungen aus `$UserAll`.
Falls keine User übrig bleiben, wird `$flag_noInterestOverlaps` auf `true` gesetzt und `$UserAll` auf `$UserAllBase`. 

##### `renderRandomUser() `
Wählt einen zufälligen User aus `$UserAll` aus und rendert `matching` mit dem User.

###### `@return` (`String`): HTML-Code der View mit dem User.

##### `renderUserByID($id_user) `
Debug Methode zum Rendern eines speziellen Users. 
###### `@return` (`String`): HTML-Code der View mit dem User.

##### `printMatchingInstances() `
Debug Methode zur Ausgabe aller MatchingInstances.

##### `addMatchingInstancePositive() `
Fügt eine positive Matching Instanz in die Datenbank ein und prüft gleichzeitig, ob ein Match erstellt werden kann.


##### `addMatchingInstanceNegative() `
Fügt eine negative Matching Instanz in die Datenbank ein. 


### `ModerationController`

### `NotificationsController`
### Attribute
1. `$id_myself`
2.  `NotificationModel` `($NotificationModel)`
3.  `VisitenkartenModel ($VisitenkartenModel)`
4.  `EventModel ($EventModel)`
5.  `EventSignOnModel ($EventSignOnModel)`
6.  `UserModel ($UserModel)`
7.  `public ShowProfileModel ($ShowProfileModel)`

### Methoden
##### `__construct`
Initialisiert die Attribute.

##### `notifications()`
Rendert die Notifications Seite
##### `@return` (`String`): HTML der Notificationsseite

##### `markAsReadNotification(Request $request)`
Übergibt dem `NotificationModel` die Anweisung, die Benachrichtigung für das übergebene Match mittels `id_user_match`, als gelesen zu markieren. 
Danach wird die `NotificationsSeite`aufgerufen

##### `showVisitenkarte(Request $request)`
Rendert die Profile Page und zeigt die Visitenkarte des Profiles des übergebene Matches.
###### `@return` (`String`): HTMl der ProfileSeite

##### `handleHostRating(Request $request)`
Setzt das rating Score für einen Host, mittels dessen `UserID`, in der Datenbank. Initiliaisert ein `EventSignOnModel`. Erhält die Informationen `rating`, `id_event` und die `id_user_rated` aus dem `Request`. Ruft mit diesen Parametern das `EventModel` und dessen Funktion `updateHostRating()`auf. Dieses Funktion speichert das gegebene Rating in der Datenbank.
Anschließend wird das abgegebene Rating mit dem bisherigen Hostrating verrechnet und der finale Host Score in der DB hinterlegt. Dies geschieht über das `ShowProfileModel` und dessen Funktion `updateScoreHost`. Bei erfolgreichem Durchführen wird die Notifications Seite neu geladen.
###### `@return` (`String`): HTMl der Notificationsseite

##### `handleAttendeeRating(Request $request)`
Setzt zuerst mit Initliaisierung eines `EventSignOnModel` das Rating `attendee_rating` für alle Eventteilnehmer, mittels `id_user` in der Datenbank.
Anschließend wird ein `ShowProfileModel` initialisiert und mithilfe diesem das abgegebene Rating `attendeeRating` mit dem bereits vorhanden `scoreAttendee` der jeweiligen Event Teilnehmer verrechnet.
Diese findet mithilfe der `updateScoreAttendee()` Funktion im `ShowProfileModel` statt. Bei erfolgreicher Durchführung wird die Notifications Seite neugeladen. 

##### `dismissReport(Request $request)`
Führt im entsprechenden `ModerationModel` die Funktion `dismissReport()` aus.

##### `acceptReport(Request $request)`
Führt im entsprechenden `ModerationModel` die Funktion `acceptReport()` aus.


### `ProfileController`
#### Attribute
1. `$visitenkartenModel` (`VisitenkartenModel`): Instanz des `VisitenkartenModel`
2. `$interestModel` (`InterestModel`): Instanz des `InterestModel`
3. `$hasInterestModel` (`HasInterestModel`): Instanz des `HasInterestModel`
4. `$ShowProfileModel` (`ShowProfileModel`): Instanz des `ShowProfileModel`
5. `$EditProfileModel` (`EditProfileModel`): Instanz des `EditProfileModel` 
6. `$EditProfilePicModel` (`EditProfilePicModel`): Instanz des `EditProfilePicModel`
7. `$id_user` (`int`) 
8. `$interestArray` (`array`)

#### Methoden
##### `__construct()`
Initialisiert die Attribute mit der ID des angemeldeten Users.

##### `profile()`
Ruft die Funktion `fetchAllInterests()` und rendert die Profile Seite.
##### `@return` (`String`): HTML-Code der View des Profiles

##### `profileedit()`
Rendert Profile Edit Seite.
##### `@return` (`String`): HTML-Code der View des ProfilesEdit

##### `handleProfileEditing(Request $request)`
Bearbeitet eine Bearbeitung eines Nutzerprofiles.
Initialisiert ein `EditProfileModel` und erhält aus der `$request` die Informationen zum Profil. Die Interessen eines Profiles werden dabei in einem Array `interestArray` gespeichert. Nachdem die Eingabe aus der `$request` validiert wurden, werden diese gespeichert und der Nutzer wird zur `Profil Seite` zurückgeleitet.
##### `@return` (`String`): HTML-Code der View des ProfilesEdit 

##### `handleProfilePicEditing(Request $request)`
Behandelt die Bearbeitung eines Nutzerprofiles. Initalisiert ein `EditProfilePicModel`. Prüft ob ein Bild hochgeladen wurde. Wenn ja, wird dieses gespeichert. Anschließend wird der Nutzer zur `Profil Seite` zurückgeleitet und das Profile gerendert.
##### `@return` (`String`): HTML-Code der View des Profiles

##### `removeProfilePic(Request $request)`
Löscht das Profilbild des Nutzers.
##### `@return` (`String`): HTML-Code der View des Profiles

### `SettingsController`

#### Methoden

##### `settings()`
Rendert die Settings Seite.
##### `@return` (`String`): HTML-Code der View des Settings

##### `impressum()`
Rendert die Impressums Seite.
##### `@return` (`String`): HTML-Code der View des Impressums

### `SiteController`


#### Methoden

##### `home()`
Rendert die Landing Page.
##### `@return` (`String`): HTML-Code der View der Landing Page

### `VisitenkartenController`
#### Attribute
1. `$visitenkartenModel` (`VisitenkartenModel`): Instanz des `VisitenkartenModel`
 
#### Methoden

##### `API_getVisitenkarte(Request $request)`
Gibt eine Visitenkarte des Nutzers, der über die `$request` identifiziert wird, zurück.
Initalisiert ein `VisitenkartenModel`. Gibt das `VisitenkarteModel` als JSON zurück.

##### `API_getVisitenkartenContent(Request $request)`
Gibt den Inhalt einer Visitenkarte des Nutzers, der über die `$request` identifiziert wird, zurück. Initalisiert ein `VisitenkartenModel`. Initalisiert ein `InterestModel`, fetched alle Interessen des Nutzers. Initalisiert ein `UserModel`. Initalisiert ein `EditProfilePicModel`. Übergibt diesen Models jeweils die `User_ID`, und rendert das `VisitenkartenModal`



## Models

### NotificationModel

#### Attribute
1. `$db` (`Database`)
2. `$id_myself` (`int`)
3. `$id_User_1` (`int`) 
4. `$id_User_2` (`int`) 
5. `$timestamp` (`int`) 
6. `$name` (`string`) 
7. `$description` (`string`) 
8. `$location_rough` (`string`) 
9. `$eventDate` (`string`)
10. `$notificationRead` (`int`)
11. `$matches` (`array`) 

##### `__construct($id_myself)`
Initialisiert die Attribute. `id_myself` enthält die `User_id` vom angemeldeten User.
Initialisiert `$this->fetchMatches()` und `$this->getAcceptedEvents($id_myself)`.

##### `rules()`
Legt Regeln für die Attribute des Models fest.

###### `@return` (`array`):  Regeln des Models

#### `fetchMatches()` 
Initialisiert einen SQL Befehl, welcher alle Matches für den angemeldeten User `id_myself` ausgibt.
Speichert die Informationen `id_user` `timestamp` und `notificationsRead` dieser Matches im Array `Matches`.

#### `setNotifcationToRead($id_user_Match)`
Setzt in der Datenbank für das gegebene `id_user_Match` in der Tabelle `matches`, das Attribut `NotificationRead` auf true.

#### `getAcceptedEvents($id_user)`
Gibt alle Events des übergebene `$id_user` zurück, bei denen die Teilnahme des Users vom Event Host aktzeptiert wurde. Speichert die Eventinformationen in dem Array `$this->eventsSignedIn`


### `EditProfileModel`

#### Attribute

1. `$db` (`Database`)
2. `$hasInterestModel` (`HasInterestModel`): Instanz des HasInterest-Models.
3. `$id_user` (`int`)
4. `$firstname` (`string`)
5. `$lastname` (`string`)
6. `$description` (`string`)
7. `$contactInformation` (`string`)
8. `$interests` (`array`)

#### Methoden

##### `__construct()`
Initialisiert die Attribute mit der ID des angemeldeten Users.

##### `rules()`
Legt Regeln für die Attribute des Models fest.

###### `@return` (`array`):  Regeln des Models

##### `saveChanges()`
Speichert die Attribute des Models in der Datenbank.

###### `@return` (`bool`):  True bei Erfolg


### `EditProfilePicModel`

#### Attribute

1. `$db` (`Database`)
2. `$id_user` (`int`)

#### Methoden

##### `__construct($userID)`
Initialisiert die Attribute unter Berücksichtigung der übergebenen ID.


##### `rules()`
Legt Regeln für die Attribute des Models fest.

###### `@return` (`array`):  Regeln des Models

##### `uploadProfileImg()`
Lädt die angegebene Datei in den Profilbild-Ordner hoch.

###### `@return` (`string`):  Dateiname bei Erfolg
###### `@return` (`bool`):  False bei Fehlschlag

##### `renameFile($target_dir, $imageFileType)`
Erstellt einen randomisierten numerischen Namen für die Datei.

###### `@return` (`string`):  Dateiname

##### `saveNewImageRef()`
Löscht das vorherige Profilbild und ersetzt es durch das Neue.

###### `@return` (`bool`):  True bei Erfolg

##### `getProfileImagePath()`
Gibt den Pfad zum Profilbild des Users aus.

###### `@return` (`string`):  Pfad

##### `removeProfileImage()`
Entfernt das aktuelle Profilbild des Users und ersetzt es durch einen Platzhalter.

###### `@return` (`bool`):  True bei Erfolg


### `EventFeedModel`

#### Attribute

1. `$events` (`array`)
2. `$db` (`Database`)

#### Methoden

##### `__construct()`
Initialisiert die Attribute.

##### `rules()`
Legt Regeln für die Attribute des Models fest.

###### `@return` (`array`):  Regeln des Models

##### `initEvents($queryResult)`
Initialisiert `events` mit den übergebenen Events.

##### `fetchAllEvents()`
Liest alle Events der Datenbank aus,

###### `@return` (`array`):  Events

##### `getEventById($eid)`
Sucht Event mit der übergebenen ID heraus.

###### `@return` (`event`):  Event
###### `@return` (`bool`):  False falls kein Ergebnis

##### `getMyEvents($uid)`
Sucht die Events, die vom übergebenen User erstellt wurden, heraus.

###### `@return` (`array`):  Events

##### `deleteEvent($eid)`
Löscht das Event mit der übergebenen ID.

##### `searchEvents($searchTerm)`
Sucht nach Events, die den Suchbegriff in ihrem Namen beinhalten.

###### `@return` (`array`):  Suchergebnisse

##### `removePastEvents()`
Entfernt alle vergangenen Events aus `events`.


### `EventModel`

#### Attribute

1. `$id_event` (`int`)
2. `$name` (`string`)
3. `$description` (`string`)
4. `$location` (`string`): Genauer Veranstaltungsort.
5. `$location_rough` (`string`): Grober Veranstaltungsort.
6. `$id_userCreator` (`int`)
7. `$eventDate` (`string`)
8. `$createdTimestamp` (`string`): Zeitpunkt der Eventerstellung.
9. `$numberAttendees` (`int`): Maximale Teilnehmeranzahl.
10. `$signOns` (`array`): Teilnehmer des Events.

#### Methoden

##### `rules()`
Legt Regeln für die Attribute des Models fest.

###### `@return` (`array`):  Regeln des Models

##### `createEvent()`
Erstellt mittels der Attribute ein neues Event.

###### `@return` (`bool`):  True bei Erfolg

##### `save()`
Speichert die Attribute im Event mit der entsprechenden `id_event`.

###### `@return` (`bool`):  True bei Erfolg

##### `delete()`
Löscht das Event.

##### `fetchAndSetSignOns()`
Speichert die Anmeldungen des Events in `signOns`.

##### `deleteSignOns()`
Löscht alle Anmeldungen.

##### `countSignOns()`
Zählt die Anmeldungen.

###### `@return` (`int`):  Anzahl der Anmeldungen

##### `countSignOnsAccepted()`
Zählt die akzeptierten Teilnehmer.

###### `@return` (`int`):  Anzahl der Teilnehmer

##### `getSignOn($uid)`
Sucht nach der Anmeldung des übergebenen Users.

###### `@return` (`signOn`):  Anmeldungsdaten des Users
###### `@return` (`bool`):  False falls keine Anmeldung vorliegt

##### `deleteSignOn($uid)`
Löscht die Anmeldung des übergebenen Users.

##### `toggleSignOn($uid)`
Schaltet den Anmeldungsstatus des übergebenen Users um.

##### `toggleAcceptance($uid)`
Schaltet den Akzeptanzstatus des übergebenen Users um.

##### `getSignOnStatus($uid)`
Sucht nach dem Anmeldungsstatus des übergebenen Users.

###### `@return` (`bool`):  True falls eine Anmeldung vorliegt

##### `getIDUserCreator()`
Sucht nach `id_userCreator`.

###### `@return` (`int`):  `id_userCreator`


### `EventSignOnModel`

#### Attribute

1. `$id_Event` (`int`)
2. `$id_User` (`int`)
3. `$signOnDate` (`string`): Datum der Anmeldung.
4. `$ratingHost` (`int`): Bewertung für den Veranstalter (0-5, -1 falls unbewertet).
5. `$ratingAttendee` (`int`): Bewertung vom Veranstalter (0-5, -1 falls unbewertet).
6. `$accepted` (`int`): 1 falls angenommen, sonst 0.

#### Methoden

##### `__construct()`
Initialisiert die Attribute, initialisiert `signOnDate` mit dem aktuellen Datum.

##### `rules()`
Legt Regeln für die Attribute des Models fest.

###### `@return` (`array`):  Regeln des Models

##### `getSignOnsByEventId($id_event)`
Sucht die Anmeldungen des Events mit der übergebenen ID heraus.

###### `@return` (`array`):  Anmeldungen

##### `getSignOnIdsByEventId($id_event)`
Sucht die IDs der angemeldeten User des Events mit der übergebenen ID heraus.

###### `@return` (`array`):  User IDs

##### `setSignOnsByEventId($id_event)`
Setzt die Attribute entsprechend des Events mit der übergebenen ID.

##### `save() : bool`
Erstellt einen neuen Eintrag mittels der Attribute.

###### `@return` (`bool`):  True bei Erfolg

##### `delete()`
Löscht die Anmeldung von `id_user` bei `id_event`.

##### `update()`
Speichert alle Attribute.

###### `@return` (`bool`):  True bei Erfolg

##### `updateHostRating()`
Speichert `ratingHost` von `id_user` bei `id_event`.

###### `@return` (`bool`):  True bei Erfolg

##### `updateAttendeeRating()`
Speichert `ratingAttendee` von `id_user` bei `id_event`.
``
###### `@return` (`bool`):  True bei Erfolg


### `HasInterestModel`

#### Attribute

1. `$hasInterests` (`array`): Beinhaltet, welcher User welche Interessen hat.
2. `$db` (`Database`)

#### Methoden

##### `__construct()`
Initialisiert die Datenbank.

##### `rules()`
Legt Regeln für die Attribute des Models fest.

###### `@return` (`array`):  Regeln des Models

##### `fetchAllHasInterests()`
Füllt `hasInterests` mit allen Interessen-User Beziehungen.

##### `fetchInterestsForUserID(int $userID)`
Füllt `hasInterests` mit den Interessen des übergebenen Users.

##### `getInterestsForUserID(int $UserID)`
Sucht die IDs der Interessen des übergebenen Users heraus.

###### `@return` (`array`):  Interessen IDs

##### `setInterestsForUserID(int $UserID, $interests)`
Speichert die übergebenen Interessen für den übergebenen User.


### `InterestModel`

#### Attribute

1. `$interests` (`array`)
2. `$db` (`Database`)

#### Methoden

##### `__construct()`
Initialisiert die Attribute.

##### `rules()`
Legt Regeln für die Attribute des Models fest.

###### `@return` (`array`):  Regeln des Models

##### `fetchAllInterests()`
Füllt `interests` mit allen Interessen.

##### `getInterestName(int $id_interest)`
Sucht den zugehörigen Namen zur übergebenen Interessen-ID heraus.

###### `@return` (`string`):  Name der Interesse

##### `getInterestID(string $name)`
Sucht die zugehörige ID zum übergebenen Interessennamen heraus.

###### `@return` (`int`):  ID der Interesse
###### `@return` (`int`):  -1 falls der Interessenname nicht existiert


### `LoginModel`

#### Attribute

1. `$db` (`Database`)
2. `$email` (`string`)
3. `$password` (`string`)
4. `$id_role` (`int`): 0 = guest, 1 = user, 2 = moderator, 3 = admin.

#### Methoden

##### `__construct()`
Initialisiert die Attribute.

##### `rules()`
Legt Regeln für die Attribute des Models fest.

###### `@return` (`array`):  Regeln des Models

##### `login()`
Verifiziert das Passwort und sucht den User zur angegebenen E-Mail Adresse heraus.

###### `@return` (`user`):  Userdaten bei Erfolg
###### `@return` (`bool`):  False bei Fehlschlag


### `MatchingInstanceModel`

#### Attribute

1. `$matchingInstances` (`array`): Matches ausgehend vom User.
2. `$matchingInstancesReceived` (`array`): Eingehende Matches.
3. `$UserIDMyself` (`int`)
4. `$db` (`Database`)

#### Methoden

##### `__construct(int $UserIDMyself)`
Initialisiert die Attribute unter Berücksichtigung der übergebenen ID.

##### `fetchAllMatchingInstancesForUser()`
Füllt `matchingInstances` mit den ausgehenden und `matchingInstancesReceived` mit den eingehenden Matches des Users.

##### `rules()`
Legt Regeln für die Attribute des Models fest.

###### `@return` (`array`):  Regeln des Models

##### `addMatchingInstance(int $UserIDReceived, int $score)`
Fügt ein Match des Users mit dem übergebenen User und der übergebenen Bewertung (Score) in die Datenbank ein.

##### `checkForPositiveMatchingScore(int $UserID)`
Überprüft, ob der übergebene User den momentan eingeloggten User positiv bewertet hat.

###### `@return` (`bool`):  True falls positiv


### MatchModel

#### Attribute

1. `$db` (`Database`) 
2. `$id_myself` (`int`)
3. `$matches` (`array`): Beinhaltet die User IDs, mit denen der User gematcht wurde.

#### Methoden

##### `__construct(int $id_myself)`
Initialisiert die Attribute unter Berücksichtigung der übergebenen ID.

##### `rules()`
Legt Regeln für die Attribute des Models fest.

###### `@return` (`array`):  Regeln des Models

##### `fetchMatches()`
Sucht alle ein- bzw. ausgehenden Matches des Users heraus und füllt `matches` mit den IDs der jeweils gematchten anderen User.

##### `isMatchedWith(int $id_user)`
Überprüft, ob sich der übergebene User in `matches` befindet.

###### `@return` (`bool`):  True falls ja

##### `createMatch(int $id_user)`
Erstellt einen ausgehenden Matching-Eintrag des Users mit dem übergebenen User.

###### `@return` (`bool`):  True bei Erfolg


### `ModerationModel`

#### Attribute

1. `$reports` (`array`): Beinhaltet die Meldungen aller User.
2. `$db` (`Database`)

#### Methoden

##### `__construct()`
Initialisiert die Attribute.

##### `rules()`
Legt Regeln für die Attribute des Models fest.

###### `@return` (`array`):  Regeln des Models

##### `initReports($reportsQuery)`
Füllt `reports` mit den Meldungen aus der übergebenen Anfrage.

##### `fetchAllReports()`
Sucht alle Meldungen heraus.

###### `@return` (`array`):  Meldungen

##### `dismissReport($id_report)`
Setzt die übergebene Meldung in der Datenbank auf "abgelehnt".

##### `getReport($id_report)`
Sucht die Meldung zur übergebenen ID heraus.

###### `@return` (`report`):  Meldung

##### `acceptReport($id_report)`
Setzt die übergebene Meldung in der Datenbank auf "akzeptiert" und löscht das jeweilige Event bzw. den User mit den relevanten Beziehungen.


### `NotificationModel`

#### Attribute

1. `$db` (`Database`)
2. `$id_myself` (`int`)
3. `$matches` (`array`)

#### Methoden

##### `__construct(int $id_myself)`
Initialisiert die Attribute.

##### `rules()`
Legt Regeln für die Attribute des Models fest.

###### `@return` (`array`):  Regeln des Models

##### `fetchMatches()`
Füllt `matches` mit den Matches des Users.

##### `setNotificationToRead($id_user_match)`
Setzt die Nachricht über das Match des Users mit dem übergebenen User auf "gelesen".

##### `getAcceptedEvents($id_user)`
Sucht alle Events, bei denen der übergebene User Teilnehmer ist bzw. war, heraus.


### `PWResetEmailModel`

#### Attribute

1. `$db` (`Database`)
2. `$email` (`string`)
3. `$verifcode` (`int`): Randomisierter Verifizierungscode

#### Methoden

##### `__construct()`
Initialisiert die Attribute.

##### `rules()`
Legt Regeln für die Attribute des Models fest.

###### `@return` (`array`):  Regeln des Models

##### `sendEmail()`
Versendet eine E-Mail, die den Verifizierungscode enthält an die E-Mail Adresse des Users.

###### `@return` (`bool`):  True bei Erfolg

##### `printVerifCode()`
Gibt den Verifizierungscode auf der Konsole aus.

###### `@return` (`bool`):  True

##### `saveVerificationCode()`
Übergibt `email` und `verifcode` an die Session-Variable.


### `PWResetModel`

#### Attribute

1. `$db` (`Database`)
2. `$email` (`string`)
3. `$newpassword` (`string`)
4. `$passwordrepeat` (`string`)
5. `$verifcode` (`int`)
6. `$enteredcode` (`int`)
7. `$success` (`bool`)

#### Methoden

##### `__construct()`
Initialisiert die Attribute.

##### `rules()`
Legt Regeln für die Attribute des Models fest.

###### `@return` (`array`):  Regeln des Models

##### `resetPassword()`
Ändert das Passwort auf den eingegebenen Wert, falls `enteredcode` und `verifcode` übereinstimmen. Setzt `success` auf true bei Erfolg.

###### `@return` (`bool`):  True bei Erfolg

##### `isVerifCodeSet()`
Überprüft, ob `verifcode` gesetzt wurde.

###### `@return` (`bool`):  True falls ja

##### `isVerifCodeCorrect(int $verifcodeInput)`
Überprüft, ob der eingegebene Code korrekt ist.

###### `@return` (`bool`):  True falls ja

##### `loadVerifCode()`
Lädt `verifcode` und `email` aus der Session-Variable.


### `RegisterModel`

#### Attribute
1. `$db` (`Database`)
2. `$firstname` (`string`) 
3. `$lastname` (`string`) 
4. `$email` (`string`)
5. `$password` (`string`)
6. `$passwordrepeat` (`string`) 
7. `$gender` (`string`)
8. `$birthdate` (`string`) 
10. `$id_role` (`int`)

#### Methoden
##### `__construct()`
Initliasiert die Attribute.

##### `rules(): array`
Legt Regeln für die Attrbiute des Models fest.
##### `@return` (`String`): Regeln des Models

##### `register()`
Speichert alle Attribute.
##### `@return` (`bool`): True bei Erfolg

### `ReportModel`

#### Attribute
1. `$id_report` (`int`) 
2. `$description` (`string`) 
3. `$status` (`string`): Report Status (0=pending, 1=accepted, 2=rejected)
4. `$type` (`string`): Report Type(0=not set, e=event, u=user)
5. `$id_userReporter` (`int`)
6. `$id_objectReported` (`int`) 
7. `$id_userModerator` (`int`) 

#### Methoden
##### `rules() : array`
Legt Regeln für die Attribute des Models fest.
##### `@return` (`String`): Regeln des Models

##### `save() : bool`
Erstellt einen neuen Report-Eintrag mittels der Attribute.
##### `@return` (`bool`): True bei Erfolg

##### `dismiss()`
Lehnt den Report ab und setzt den Status des Reports auf 2 (rejected). 

##### `accept()`
Akzeptiert den Report und setzt den Status des Reports auf 1 (accepted).

### `ShowProfileModel`
#### Attribute
1. `$id_user` (`int`)
2. `$firstname` (`String`)
3. `$lastname` (`String`) 
4. `$description` (`String`) 
5. `$gender` (`String`)
6. `$scoreAttendee` (`int`)
7. `$scoreHost` (`int`)
8. `$birthdate` (`string`) 
9. `$contactInformation` (`string`) 
10. `$interests` (`array`)
11. `$hasInterestModel` (`HasInterestModel`): Instanz des `HasInterestModel` 
12. `$db` (`Database`): 

#### Methoden
##### `__construct(int $id_user)`
Initialisiert die Attribute unter Berücksichtigung der übergebenen ID.

##### `rules() : array`
Legt Regeln für die Attribute des Models fest.
##### `@return` (`String`): Regeln des Models

##### `getProfileDataByUserId (int $userID)`
Gibt die Profiledaten des Users mit der übergebenen ID zurück.
##### `@return` (`String`): Profiledaten des Users

##### `updateScoreHost()`
Aktualisiert den Hostscore des Users.
##### `@return` (`bool`): True bei Erfolg

##### `updateScoreAttendee()`
Aktualisiert den Attendeescore des Users.
##### `@return` (`bool`): True bei Erfolg

### `UserMatchModel`
#### Attribute
1. `$db` (`Database`)

#### Methoden
##### `rules() : array`
Legt Regeln für die Attribute des Models fest.

##### `__construct()`
Initialisiert die Datenbank.

##### `fetchAllUser(int $id_myself)`
Gibt alle User, außer dem angemeldeten User, zurück.
##### `@return` (`array`): Array mit allen Userdaten

##### `fetchUserByID(int $id)`
Gibt die Userdaten des Users mit der übergebenen ID zurück.
##### `@return` (`String`): Userdaten des Users

### UserModel
#### Attribute
1. `$id_user` (`int`)
2. `$firstname` (`string`)
3. `$lastname` (`string`)
4. `$description` (`string`)
5. `$gender` (`string`)
6. `$interests` (`array`)
7. `$birthdate` (`string`)
8. `$matchingInstancesOld` (`array`)
9. `$interestOverlapScore` (`int`)

#### Methoden
##### `rules() : array`
Legt Regeln für die Attribute des Models fest.

##### `__construct()`
Initialisiert `$this->description` mit einem leeren String.

##### `getUserById($id_user) : UserModel`
Gibt den User mit der übergebenen ID zurück.
##### `@return` (`UserModel`): Gibt das UserModel zurück.

##### `getUserNameByID($id_user) : String`
Gibt den Vor und Nachnamen eines Users mit der übergebenen `$id_user` zurück.
##### `@return` (`String`): Gibt den Vor- und Nachnamen des Users zurück.

##### `delete()`
Löscht den User aus allen relevanten Tabellen in der DB. Die relevanten Tabellen sind `user`, `event`, `eventSignOn`, `hasInterest`, `matches` und `matching_instance`.

### VisitenkartenModal
#### Attribute
1. `$id_user` (`int`)
2. `$firstname` (`string`)
3. `$lastname` (`string`)
4. `$description` (`string`)
5. `$contactInformation` (`string`)
6. `$scoreHost` (`int`)
7. `$scoreAttendee` (`int`)
8. `$interests` (`array`)
9. `$interestsWithNames` (`array`)
10. `$hasInterestModel` (`HasInterestModel`): Instanz des `HasInterestModel`
11. `$interestModel` (`InterestModel`): Instanz des `InterestModel`
12. `$db` (`Database`)

#### Methoden
##### `__construct(int $id_user)`
Intialisiert die Attribute unter Berücksichtigung der übergebenen ID. Gibt für jede `interest_id`, des übergebenen Nutzers `$id_user`, den `ìnterest_name` aus.

##### `rules() : array`
Legt Regeln für die Attribute des Models fest.

##### `getVisitenkartenByUserID(int $userID)`
Gibt die Daten für eine Visitenkarte des Users mit der übergebenen ID zurück.
##### `@return` (`String`): Gibt die Daten für eine Visitenkarte des Users zurück.


## Views
### Notification

#### `openVisitenkarten(id_user)`
Bei erfolgreichen Match gibt es die Möglichkeit die Visitenkarte des Matches anzusehen. Diese Visitenkarte des Matches wird per Click auf `Visitenkarte` geöffnet und dabei die `User_id` des Matches übergeben. Die Anzeige geschieht über das `visitenkartenModal`.  Alle relevanten Visitenkarteninformationen werden über die `API_getVisitenkarte` im `VisitenkartenController` zur Verfügung gestellt.

#### `openEventDetails(event_id)`
Wenn der User an einem Event aktzeptiert wurde, gibt es die Möglichkeit die Event Details anzusehen. Diese Event Details des Matches wird per Click auf `Details` geöffnet und dabei die `Event_id` des Matches übergeben.  Die Anzeige geschieht über das `EventDetailsModal`. Alle relevanten Event Details werden über die `API_getEventDetails` im `EventController` zur Verfügung gestellt.

#### `EventSignOff`
Ermöglicht das Abmelden von einem Event. Dieser Event wird per Click auf `Abmelden` geöffnet und dabei die `Event_id` des Matches übergeben. Die `API_toggleSignOnForEvent` im `EventController` wird aufgerufen und entfernt den User aus dem Event.

#### `reportUser`
Ermöglicht das Reporten eines Users. Dieser Report wird per Click auf `Melden` geöffnet. Dabei wird auf die Seite `reportUser` verwiesen und die `User_ID` des zu reportenden User übergeben.

#### `RatingHost(event_id)`
Ermöglicht das Bewerten eines Hosts. Dieser Bewertung wird per Click auf `Host Bewerten` geöffnet. Der Button `Host Bewerten` wird nur angezeigt, wenn der derzeitige User nicht Host sondern Teilnehmer ist. Das Modal `hostRatingModal` wird geöffnet. Auf einer Skala von 0 - 5 kann der Host bewertet werden. Die `API_getEventDetails` verarbeitet das Bewerten des Hosts und speichert das Bewertungsattribut in der Datenbank. Dieses Attribut wird dann in der Datenbank für den Host gespeichert. Eine zweifach Bewertung pro User wird ausgeschlossen.

#### `RatingAttendee(event_id)`
Ermöglicht das Bewerten aller Teilnehmer eines Events. Diese Bewertung wird per Click auf `Teilnehmer Bewerten` geöffnet. Der Button `Teilnehmer Bewerten` wird nur angezeigt, wenn der derzeitige User Host des Events ist. Das Modal `attendeeRatingModal` wird geöffnet. Auf einer Skala von 0 - 5 kann der Teilnehmer bewertet werden. Die `API_getEventDetails` verarbeitet das Bewerten des Teilnehmers und speichert das Bewertungsattribut in der Datenbank. Dieses Attribut wird dann in der Datenbank für den Teilnehmer gespeichert. Eine zweifach Bewertung pro User wird ausgeschlossen.


# Administrationssystem

## Controller

Bei den Controllern des Administrationssystems wird der Namespräfix `A_` verwendet, um mögliche Konflikte mit Controllern des Usersystems zu vermeiden und um diese leichter zu erkennen.

### `A_EventsController`

#### Attribute

1. `$eventAdministrationModel` (`A_EventAdministrationModel`)

#### Methoden

##### `__construct()`
Setzt den `Application::$systemType` auf `backend` und initialisiert die Attribute.

##### `home()`
Rendert die EventsAdministrationsseite. 

###### `@return` (`String`): HTMl der EventsAdministrationsseite

##### `API_getEventByID(Request $request` 
Liefert das Event mit der angegebenen ID (`eid`) als JSON zurück.

###### `@return` (`JSON`) Eventobjekt

##### `API_editEvent(Request $request)`
Aktualisiert ein Event in der Datenbank. Das bestimmte Event wird mit dem Identifier `id_event` referenziert. Danach wird die Eventseite neu geladen.

##### `API_getAttendeesByEventId(Request $request)`
Gibt die JSON-Objekte mit den Teilnehmern zurück (unabhängig, ob akzepiert oder nicht). Das bestimmte Event wird mit dem Identifier `eid` referenziert. 

###### `@return` (`JSON`): Teilnehmer

##### `API_toggleAttendeeAcceptance(Request $request)`
Akzeptiert bzw. lehnt eine Teilnahme eines Users (`uid`) an einem Event (`eid`) an bzw. ab. 

###### `@return` (`JSON`): Aktualisierte Teilnahmeliste

### `A_InterestsController`

#### Attribute

1. `$interestModel` (`A_InterestModel`): Instanz des Interest-Models.
2. `$hasInterestModel` (`A_HasInterestModel`): Instanz des HasInterest-Models.

#### Methoden

##### `__construct()`
Setzt den `Application::$systemType` auf `backend` und initialisiert die Attribute.

##### `home()` 
Rendert die Interessenadministrationsseite.
###### `@return` (`String`): HTML-Code der View

##### `API_getInterest(Request $request)`
Gibt die Daten für eine bestimmte Interessen ID zurück. Diese muss als Parameter mit dem Identifier `iid` im `$request` vorhanden sein.

###### `@return` (`JSON`)

##### `API_editInterest(Request $request)`
Aktualisiert eine Interesse. Dafür muss eine Interessen ID im `$request` mit dem Identifier `id_interest` übergeben werden. Danach  wird die Interessenseite neu geladen. 

##### `API_addInterest(Request $request)`
Erstellt eine neue Interesse. Der Name wird über `$request` mit dem Identifier `interest-add-name` übergeben. Danach wird die Interessenseite neu geladen.

##### `API_deleteInterest(Request $request`
Löscht eine Interesse. Die zu lösche Interesse wird über `$request` mit dem Identifier `iid` übergeben. Danach wird die Interessenseite neu geladen.

### `A_UsersController`

#### Attribute

1. `$userAdministrationModel` (`A_UserAdministrationModel`): Instanz des UserAdministration-Models.
2. `$interestModel` (`A_InterestModel`): Instanz des Interest-Models.

#### Methoden

##### `__construct()`
Setzt den `Application::$systemType` auf `backend` und initialisiert die Attribute.

##### `home()`
Rendert die Useradministrationsseite.

##### `API_getUserByID(Request $request)`
Gibt die Daten für einen bestimmten User zurück. Dieser User wird über den Identifier `uid` im `$request` übergeben.

###### `@return` (`JSON`)

##### `API_editUser(Request $request)`
Aktualisiert einen User. Dafür muss neben den Attributen des Users eine User ID im `$request` mit dem Identifier `id_user` übergeben werden. Danach wird die Useradministrationsseite neu geladen.

##### `API_deleteUser(Request $request)`
Löscht einen User. Der zu löschende User wird über `$request` mit dem Identifier `id_user` übergeben. Danach wird die Useradministrationsseite neu geladen.

## Models

### `A_EventAdministrationModel`

#### Attribute 

1. `$events` (`Array`)
2. `$db` (`Database`)

#### Methoden

##### `__construct()`
Initialisiert die Attribute.

##### `getEvents()`
Liefert alle Events aus der Datenbank zurück.

###### `@return` (`Array`): Alle Events als PDO Ergebnisse

##### `createEventModels($eventQuery)` 
Erstellt ein Array mit Event-Modellen aus einem PDO-Query.

##### `getEventById($id_event)`
Liefert das Event mit der angegebenen ID.

###### `@return` (`A_EventModel`): Event-Modell

##### `toggleAttendeeAcceptance($id_event, $id_user)`
Prüft für eine Eventanmeldung den Status, ob der User akzeptiert wurde oder nicht und negiert diesen Status.

##### `deleteAttendee($id_event, $id_user)`
Löscht einen Teilnehmer aus einer Eventanmeldung (`eventSignOn`).

### `A_EventModel`

#### Attribute
1. `$id_event` (`Integer`): ID des Events.
2. `$name` (`String`): Name des Events.
3. `$description` (`String`): Beschreibung des Events.
4. `$location` (`String`): Ort des Events.
5. `$location_rough` (`String`): Grober Ort des Events.
6. `$id_userCreator` (`Integer`): ID des Erstellers.
7. `$eventDate`: Datum des Events.
8. `$createdTimestamp`: Zeitpunkt des Erstellens.
9. `$numberAttendees` (`Integer`): Maximale Anzahl an Teilnehmern.
10. `$signOns` (`Array`): Array mit Teilnehmern.

#### Methoden

##### `save()` 
Aktualisiert das Event in der Datenbank.

###### `@return` (`Boolean`): Erfolgsstatus

##### `delete()`
Löscht das Event aus der Datenbank.

##### `fetchAndSetSignOns()`
Lädt die Teilnehmer aus der Datenbank, erstellt ein `A_EventSignOnModel` für jede Anmeldung und speichert diese in das Attribut `$signOns`.

##### `deleteSignOns()`
Löscht alle Anmeldungen aus der Datenbank.

### `A_EventSignOnModel`

#### Attribute
1. `$id_Event` (`Integer`): ID des Events.
2. `$id_User` (`Integer`): ID des Teilnehmers.
3. `$accepted` (`Boolean`): Status der Anmeldung.
4. `$signOnDate` (`String`): Datum der Anmeldung.
5. `$ratingHost` (`Interger`): Bewertung des Teilnehmers für den Eventhost.
6. `$ratingAttendee` (`Interger`): Bewertung des Eventhosts für den Teilnehmer.

#### Methoden

##### `getSignOnsByEventId($id_event)`
Lädt alle Anmeldungen zu einem Event aus der Datenbank.

###### `@return` `(`Array`): PDO-Ergebnis mit Anmeldungen

##### `setSignOnsByEventId($id_event)`
Initialisiert alle `$signOns` für ein Event aus der Datenbank.

### `A_HasInterestModel`

#### Attribute
1. `$hasInterests` (`Array`): Array mit hasInterests-Beziehungen
2. `$db` (`Database`): Datenbank

#### Methoden

##### `__construct()`
Initialisiert die Datenbankverbindung.

##### `fetchAllHasInterests()`
Lädt die vollständige `hasInterests`-Tabelle aus der Datenbank und speichert diese in `hasInterests`.

##### `fetchInterestsForUserID($userID)`
Lädt nur die `hasInterests`-Einträge für den User mit `$userID` und speichert diese in `$hasInterests`.

##### `getInterestsForUserID($UserID)`
Findet alle Interessen-IDs aus `$hasInterests` für einen bestimmten User.

###### `@return` (`Array`): Array mit den Interessen-IDs.

##### `setInterestsForUserID($UserID, $interests)`
Setzt die Interessen für einen User.

##### `deleteByInterestId($id_interest)`
Löscht alle `hasInterests`-Einträge für ein bestimmtes Interesse.

### `A_InterestModel`

#### Attribute
1. `$interests` (`Array`): Array der Interessens.
2. `$db` (`Database`): Datenbank

#### Methoden

##### `__construct()`
Initialisiert die Datenbankverbindung.

##### `fetchAllInterests()`
Lädt die vollständige `interests`-Tabelle aus der Datenbank und speichert diese in `interests`.

##### `getInterestName($id_interest)`
Liefert den Namen einer Interesse.

###### `@return` (`String`): Name der Interesse

##### `getInterestID($name)`
Liefert die ID einer Interesse.

###### `@return` (`Integer`): ID der Interesse oder `-1` wenn keine Interesse gefunden wurde.

##### `getInterestById($id_interest)`
Liefert die Interesse mit der angegebenen ID.

###### `@return` (`Array`): Format: [`id_interest`, `name`]

##### `save($id_interest)`
Aktualisiert eine Interesse in der Datenbank.

##### `add($name)`
Fügt eine neue Interesse in die Datenbank ein.

##### `delete($id_interest)`
Löscht eine Interesse aus der Datenbank.

### `A_UserAdministrationModel`

#### Attribute
1. `$db` (`Database`): Datenbank
2. `$user` (`Array`): Array mit `A_UserModel`
3. `$hasInterestModel` (`A_HasInterestModel`): Instanz der `A_HasInterestModel`

#### Methoden

##### `__construct()`
Initialisiert die Attribute und lädt die Interessen in die UserModels

##### `getUsers()` 
Lädt alle User aus der Datenbank.

###### `@return` (`Array`): PDO-Ergebnis mit Usern 

##### `createUserModels($userQuery)`
Erstellt ein `A_UserModel` für jeden User aus `$userQuery`.

##### `getUserById($id_user)`
Liefert den User mit der angegebenen ID.

##### `addInterestsToUsers()` 
Fügt die Interessen zu den Usern (`$user->interests`) hinzu.

### `A_UserModelModel`

#### Attribute
1. `$id_user` (`Integer`): ID des Users.
2. `$firstname` (`String`): Vorname des Users.
3. `$lastname` (`String`): Nachname des Users.
4. `$email` (`String`): Email-Adresse des Users.
5. `$gender` (`String`): Gender des Users.
6. `$birthdate`: Geburtsdatum des Users. 
7. `$image`: Profilbild
8. `$description` (`String`): Profilbeschreibung
9. `$contactInformation` (`String`): Kontaktinformationen
10. `$scoreHost` (`Integer`): Bewertung als Eventhost.
11. `$scoreAttendee` (`Integer`): Bewertung als Teilnehmer.
12. `$interests` (`Array`): Interessen des Users.
13. `$id_role` (`Integer`): User-Rolle.

#### Methoden

##### `save()`
Aktualisiert den User in der Datenbank.

##### `delete()`
Löscht den User aus der Datenbank.

## Views

### Layouts

#### `main`
Standard Layout für alle Views mit Navigationsleiste.

### `EventsAdministration`
View für die Event-Administration. Beinhaltet eine `DataTable` mit den Events. Die Events können über den Button `Edit` in einem Modal bearbeitet werden. In dem Modal wird zusätzlich die Liste mit den `EventSignOns`angezeigt, welche jeweils gelöscht und deren Akzeptierungsstatus verändert werden können.

#### JavaScript Funktionen

##### `loadAttendeeList(id_event)`
Lädt die Teilnehmerliste eines Events, indem via AJAX der Request `API_getAttendeesByEventId` aufgerufen wird. Die Daten im JSON-Format werden dann ausgelesen und `DataTable` `EventAttendeeList` hinzugefügt.

##### `loadEventList()`
Lädt die Eventliste, indem via AJAX der Request `API_getEvents` aufgerufen wird. Die einzelnen Events werden dann der `DataTable` hinzugefügt.

##### `deleteEvent(id_event)`
Löscht ein Event, indem via AJAX der Request `API_deleteEvent` aufgerufen wird.

#### Genutzte Schnittstellen
1. `API_getAttendeesByEventId`: Liefert die Teilnehmer für ein Event.
2. `API_getEvents`: Liefert alle Events.
3. `API_deleteEvent`: Löscht ein Event.
4. `API_toggleAttendeeAcceptance`: Aktiviert/Deaktiviert den Akzeptierungsstatus des Teilnehmers.
5. `API_deleteAttendee`: Entfernt einen Teilnehmer aus der Teilnehmerliste.
6. `API_editEvent`: Aktualisiert sein Event. 

### `landingpage`
Landingpage des Adminbereichs.

### `InterestAdministration`
View für die Interessenadministration. Beinhaltet eine `DataTable` mit den Interessen. Die Interessen können über den Button `Edit` in einem Modal bearbeitet werden und gelöscht werden.
Außerdem können neue Interessen hinzugefügt werden.
Die Tabelle mit den Interessen wird hier bereits Serverseitig erstellt.

#### Genutzte Schnittstellen

1. `API_getInterest`: Liefert eine Interesse anhand der ID.
2. `API_editInterest`: Aktualisiert eine Interesse.
3. `API_deleteInterest`: Löscht eine Interesse.
4. `API_addInterest`: Fügt eine neue Interesse hinzu.

### `UserAdministration`
View für die User-Administration. Beinhaltet eine `DataTable` mit allen Usern. Die Usern können über den Button `Edit` in einem Modal bearbeitet werden. In dem Modal können zusätzlich die Interessen des Users bearbeitet werden.
Die Liste der User und die Liste der Interessen im Modal werden bereits Serverseitig befüllt. 
Wenn man auf den `edit`-Button klickt werden die Daten des bestimmten Users via AJAX vom Server geladen, sowie die ID's der ausgewählten Interessen. Diese Interessen werden dann in der existierenden Interessen listen nur als `checked` markiert. 

#### Genutzte Schnittstellen
1. `API_getUser`: Liefert einen User anhand der ID.
2. `API_editUser`: Aktualisiert einen User.
3. `API_deleteUser`: Löscht einen User.

# Nicht umgesetzte Funktionen

# Fehlerdokumentation

# Erweiterungsmöglichkeiten
## Genauere Datumsangaben bei den Events
Dies würde beinhalten, dass das Eventdatum mit Uhrzeit in der Datenbank gespeichert wird (ggfs. als UNIX-Timestamp). 
Des Weiteren könnte ein Endtermin (mit Datum und Uhrzeit) hinzugefügt werden. 
Mit diesen Funktionen könnten auch genauere Filterfunktionen für den Eventfeed erstellt werden, sodass Nutzer z.B. speziell
nach Event an einem bestimmten Tag und bestimmten Uhrzeit suchen können.
## Erweiterte Login-Möglichkeiten
Es könnte realisiert werden, dass man sich mit einem Google- oder Apple-Account anmelden kann, sodass 1. der Nutzer
keinen neuen Account erstellen muss und 2. Student Reconnect keine Login-Daten verwalten muss. Dies ist auch Sicherheitstechnisch ein Vorteil.
## Nachträgliche Eventbearbeitung
Für erstellte Events könnte eine Eventbearbeitungsfunktion umgesetzt werden, sodass die Event-Hosts die eigenen Events
nachträglich bearbeiten können, um z.B. einen aktualisierten Termin bekannt zu machen. Zusätzlich könnte nach einer 
Eventbearbeitung eine Benachrichtung an die bereits angemeldeten Nutzer gesendet werden. 

## Erweiterte Moderations- bzw. Reportfunktionen
Für die einzelnen Reports könnte eine Möglichkeit geschaffen werden, Screenshots hochzuladen, um spezifischere 
Informationen für den Moderator und seine Entscheidung bereitzustellen. Diese Screenshots müssten dann auch im Moderationsbereich einsehbar sein.

## Nutzerfreundlicherer Bildupload
Die Profilbildbearbeitung könnte technisch dahingehend erweitert werden, sodass hochgeladene Bilder erstens in einer maximalen Auflösung gespeichert werden, mit den Vorteilen, dass weniger Speicherplatz benötigt wird und die Bilder auf der Seite schneller laden. Zweitens könnte ein schlanke Funktion eingebaut werden, bei der die Nutzer die Bild auf das gewünschte Format zuschneiden können und den richtigen Bildbereich auswählen können. 