Grundlegende Information

• Siehe doku/AufbauUndTesting.adoc für eine Strukturbeschreibung

• Siehe doku/Walkthrough.adoc für eine Anleitung

Kritische Entscheidungen

Spring Security

Wir haben uns entschieden Spring Security zu benutzen, da wir uns das Umgehen mit Cookies sparen wollten und Spring Security uns auch direkt den eingeloggten Benutzer zurückgeben kann. Dadurch wird auch die Eindeutigkeit und Validität des Benutzernames gewährleistet. Passwörter werden in der Datenbank im Klartext gespeichert, um den Entwicklungsprozess zu erleichtern. Leider hatten wir nicht genug Zeit am Ende um die Passwörter zu hashen.

Interaktion mit Propay

Wir haben uns entschieden direkt bei Antragsstellung (Verkauf oder Leih) die benötigten Beträge (Kautinon + Gesamtmiete / Verkaufspreis) auf Propay zu blockieren. Der einzige Nachteil bei dieser Vorgehensweise ist, dass ein Artikeleigentümer durch enthaltung der Entscheidung, ob er akzeptiert oder nicht, dem Antragssteller unbefristet blockiert. Das haben wir mit einem Antrag stornieren Button gelöst, der bis zum Akzeptieren des Antrags vom Antragssteller gedrückt werden kann. Demnach werden die Geldbeträge mit release bzw. punish dem richtigen Benutzer zugewiesen.
Falls Propay nicht erreichbar ist werden sämtliche Links (Propayübersicht, Reservierungserstellen, kaufen, Akzeptieren, Ablehnen, etc.) durch Propay-Error-Buttons mit eine kurzen Fehlermeldung ersetzt.

Ganztägige Reservierungen

Um den Prozess leichter zu machen, haben wir uns entschieden nur ganztägige Reserveriungen zuzulassen und verlangen immer den vollen Tagespreis. Das reservierte Artikel steht somit genau zum Startdatum zu Verfügung und muss auch am Enddatum zurückgegeben werden (Eintagige Reservierungen müssen am selben Tag zurückgegeben werden, an dem sie abgeholt wurden).

Reservierungsmiete immer für den Gesamten Zeitraum bezahlen

Wir erlauben zwar, dass ein Leihender seinen Artikel frühzeitig zurückgeben kann, aber verlangen immernoch die volle Miete. Abgesehen davon, dass es für uns leichter zu implementieren ist, ist es auch Sinnvoll, da der Eigentümer durch nicht vollständig benutzten Reservierungszeitraum an potenziellen neuen Leihenden verliert. Somit wollen wir verhindern, dass Leihende unüberlegt zu lange reservieren.

Verkaufsartikel einbauen

Wir haben einfach eine neue Klasse (Entität) mit eigener Repo erstellt die anstelle von Kaution und Miete, den Verkaufspreis hat. Ein Benutzer kann auf der Startseite entweder einen Artikel zum Verleih oder Verkauf anlegen. Danach werden seperate HTML Sichten erzeugt. Zusätzlich wurden die Controller auch erweitert um mit den Verkaufsartikeln analog umzugehen. Unsere Lösung ist sicher nicht die Eleganteste, aber es fehlte uns an Zeit so etwas wie eine Abstrakte Artikel Oberklasse zu implementieren.

Nicht mehr als 10 JPG Bilder

Es können Bilder beim Artikel erstellen hochgeladen werden. Diese sind aber durch Anzahl (max. 10), Größe (insgesamt 10MB) und Format (nur JPG) beschränkt. Da Bilder hochladen optional ist, wird falls keins hochgeladen wird, ein Default-Kein-Bild-Vorhanden Bild gezeigt.

Benutzerrollen

Die Startseite unter http://localhost:8080/ listet für alle Besucher die momentan aktiven Artikel und enthält Links zum Einloggen und Registrieren. Weiter interaktion, wie Artikeldetails ansehen, verlangt einen eingeloggten User. Jeder eingeloggte User kann auf alles zugreifen, bis auf die Admin-Clearingstelle für Beschwerden (durch Spring Security gesichert).

Kein Databaseinitializer

Wir haben anfangs mit einem Faker gearbeitet zum generieren von Testdaten, da aber öfters überschneidende Reserviungen erstellt wurden haben wir uns entschieden alle finalen Daten per Hand anzulegen (durch Benutzung der Anwendung selbst).

Commitanzahl Erklärung

Viele Commits vom Teammitglied Florian (flfis102) haben keine Message und sind teilweise nur minimale Änderungen. Der Grund dafür ist, dass die Anwendung auf seinem Windows 10 Laptop nicht einwandfrei funktioniert und er deswegen mit einem Ubuntu Server arbeitet. Die Einfachste möglichkeit Updates auf den Server zu bringen ist durch Git Commits. Deswegen musste er selbst kleine Änderungen pushen, um so testen zu können.

Kein Editieren

Wir haben uns entschieden, dass man Artikel nur erstellen kann (Verkaufsartikel können aber auch gelöscht werden). Dies verhindert, dass änderungen an Artikeln zukünfitge Reservierungen auch beeinflussen. Falls ein Eigentümer was ändern möchten, muss er den Artikel deaktivieren und einen Neuen mit eventuell geänderten Angaben erstellen. Dabei sind zukünfitge Reservierungen von dem deaktivierten Artikel immernoch gültig und müssen vom Eigentümer durchgeführt werden (ansonsten an die Clearingstelle wenden).

Clearingstelle

Da der Admin in seiner Entscheidung nur die Kaution einem der beiden Benutzer zuordnen kann, wird die Miete trotzdem dem Artikeleigentümer bezahlt. Nachdem der Admin per Knopfdruck (nach Email verkehr) seine Entscheidung getroffen hat, gilt die Reservierung als abgeschlossen, d.h. es wird angenommen, der Artikel befindet sich wieder beim Eigentümer.

BenutzerKonten

Table 1. Benutzerkonten mit Zugangsdaten

Benutzername	Email	Passwort	Rolle
Florian	[email protected]	f	User
Marvin	[email protected]	m	User
Philipp	[email protected]	p	User
Kurt	[email protected]	k	User
Jana	[email protected]	j	User
Fred	[email protected]	f	User
Admin	[email protected]	admin	Admin