lehoffma / memo Goto Github PK

Hängt mit #6 zusammen.

Als extra-Tab auf der Profilseite?

Im Frontend wird ein Fehler am Ende der Registrierung angezeigt, auch wenn die registrierung abgeschlossen wurde.

Wenn man angemeldet ist und dann auf "MeinenAccount" geht sollte man seine eigenen Daten ändern. Dort werden jedoch keine Daten angezeigt.

Schritt für Schritt:

1. Account erstellen
2. mit diesem Account sich anmelden
3. auf "Dein Account" gehen

Gewünschtes Ergebnis: bereits gefüllt Felder, die geändert werden können

Wirkliches Ergebnis: alle Felder sind leer

• GET

• POST

• PUT

• DELETE

Workflow zum Reproduzieren des Fehlers:

• neu registrieren
• Email und Passwort angeben
• persönliche Daten angeben
• "neue Adresse hinzufügen" wählen
• Adresse eingeben und auf speichern drücken

Gewünschtes Ergebnis:

Adresse wird in Datenbank abgespeichert und die ID im User gespeichert. Anschließend wird man zurück zur "User erstellen"-Ansicht geleitet.

Wirkliches Ergebnis:

Adresse wird in Datenbank abgespeichert. Keine Weiterleitung

Notizen:

• Vorerst nur für Merchandise Artikel
• Später: Unterschiedliche Kategorien (Getränke, Essen, etc.)
• Bestand-Übersicht:
  • Für jeden Merch Artikel:
    • Tabelle: Für jede Farben + Größen Kombination ein Eintrag (Einträge mit 0 werden ausgeblendet?)
• Verlinkung zu der Detailseite des jeweiligen Artikels (und andersherum?)

Die beiden Event-Properties (meetingPoint + destination) sollen zu einem Routen-Objekt zusammengefasst werden. Eventuell könnte man sogar ein Array daraus machen, um Zwischenziele zu ermöglichen?

Des Weiteren sollten die Routen-Stoppunkte zusätzlich jeweils die Längen- und Breitengrade mitspeichern, da diese für die Darstellung der Touren-Karten benötigt werden.

Schritte zum Reproduzieren

1. Falls Bundle noch nicht vorhanden: npm build ausführen
2. Tomcat starten
3. Im Frontend von der Startseite wegnavigieren
4. Den Browser aktualisieren

Gewünschtes Ergebnis

Die Seite, zu der man hin navigiert hat, wird aktualisiert.

Wirkliches Ergebnis

Es wird ein 404-Errorcode zurückgegeben.

How to (probably) fix

Wenn es sich ähnlich wie bei Spring Boot verhält (is ja eigentlich auf den gleichen Technologien aufgebaut), muss man dafür nur ein Servlet erstellen, welches die Routen, die von Angular verwendet werden (z.b. "/calendar"), matcht und weiter zur Index.html forwarded.

Da ein hochgeladenes Bild im FormData/MultipartFile Format vorliegt und dementsprechend nicht in einem "rutsch" mit den anderen JSON daten in den POST request geschickt werden kann (HTTP unterstützt mehrere Content-Types innerhalb eines Requests anscheinend nicht so gut), sollten wir einen seperaten ImageServlet anlegen.

Für das Backend sieht das eigentlich ganz gut aus aufn ersten blick:
https://stackoverflow.com/questions/2422468/how-to-upload-files-to-server-using-jsp-servlet

Beinhaltet:

• Suchleiste in der NavigationBar (Button im Mobile, welcher sich zur leiste ausweitet)
• ListView von Suchergebnissen
• Sortier/Filter Optionen

Beispiel (über dem ersten Eintrag sollte noch ein Mengenindikator stehen, also sowas wie "121 Touren" oder so)

Es gibt in CSS n Property dafür:

overflow: ellipsis 

Wenn dem Warenkorb etwas hinzugefügt wird (von 0 items zu 1+ items) oder wenn etwas gelöscht wird (von 1+ items zu 0 items), könnte eine Animation abgespielt werden.
Eine Option dafür wäre direkt die Angular Animations API zu benutzen.

Ein paar Links:
https://angular.io/docs/ts/latest/guide/animations.html
https://egghead.io/lessons/angular-2-define-an-angular-2-trigger-and-state

"Dropdown" mäßig, also man klickt auf den button und es werden einem mehrere Optionen zum Sharen gezeigt.

Beispiele:

• WhatsApp
• Telegram
• Facebook
• Twitter

Dazu gehört:

• Übersichtstabelle
  • Generelles Design
    • Auf mobile: Nicht Card-like (also kein platz lassen an den seiten), um mehr Platz für Infos zu haben?
  • Filtern
    • date-range picker
    • evtl. andere Kriterien?
• Detailansicht
  • Ansehen
  • Erstellen/Editieren
    • Kostenarten treten nur in einer von ~5 unterschiedlichen Arten auf (Ticketsausgaben/-einnahmen, Fahrtkosten, Spritkosten, Mietwagenkosten, Verpflegung)

neue Properties:

Geschlecht
Eintrittsdatum
Wölfeclubmitglied
Dauerkarteninhaber

• Datepicker konfigurieren
• Google-Maps Autofill Komponente
• Modify Permissions Komponente
• User-Edit-Items erstellen
  • Profil-Bild Komponente (die Komponente aus dem SignUp Prozess wiederverwendbar machen)
  • Text: Vorname, Nachname, Telefon, Email? (Passwort lieber auslagern)

• GET
• POST
• PUT
• DELETE

• Size Table hinzufügen

• Participants und co auf eigene APIs verlegen

Hier muss zuerst ein passendes Design überlegt werden (also ob es einfach eine Liste/ein Grid der Vorschau Objekte ist, welche im Prinzip ähnlich wie die Suchergebnisse mit eingestellter Kategorie Filterung aussehen oder doch eher anders)

Die Bankdaten werden zwar erfasst aber nicht mitgeschickt. Eigener API Call?

• Versandadresse auswählen (man kann sie da auch gleich ändern/eine neue hinzufügen)
• Zahlungsart auswählen (ändern/hinzufügen)
• Übersicht bevor Zahlung abgeschlossen wird
• man kann zwischen den drei Ansichten hin und her switchen

Bisher werden die Farben lediglich als String-Wert gespeichert, was es jedoch schwierig macht, diese dynamisch im Frontend zu verwenden (z.B. bei den Suchergebnissen).

Besser wäre sowas wie:

merch.colors = [
    {
         hex: "#ffffff",
         name: "Weiss"
    },
    ...
]

Das Datenmodell muss ein Permissions-System beinhalten, welches eine feinere Konfiguration ermöglicht, als es anhand der Clubrollen möglich ist.

Mögliche Implementation

Jedes ShopObjekt (also Merch/Tour/Party. User und Entries werden einfach stumpf ausgeblendet, wenn die Rolle nicht passt) bekommt eine Liste von UserIds zugewiesen, die dieses Objekt ansehen/anlegen/bearbeiten können.
Also quasi

Event.permissions = {
    read: [0,1,5,7,8],
    write: [0,1]
}

Frontendseitig würde dann mit jeder Http Request die UserId mitgeschickt werden (wenn der User nicht bereits aus dem Authentification Token (siehe #22) heraus identifiziert werden kann). Falls die übergebene UserId nicht in im read-Array vorkommt, wird ein 403 Code zurückgeschickt. Falls doch, wird das Event zusammen mit einem Indikator, ob der User denn das Event editieren/modifizieren darf (also ob die ID im write-Array vorkommt) zurückgeschickt.

Die EventServlet Architektur ist nicht dafür ausgelegt zusätzlich zu den Eventdaten noch Participants bzw. Stockinformation zurückzugeben.
Mögliche Lösung:

Auslagern in

• ParticipantsAPI
• SizeAPI
• SizeTableAPI

Darüber könnte man auch einfacher und fehlerunanfälliger die Daten updaten ohne das Item anfassen zu müssen.

Speichert die vom User ausgewählten Merchandise Artikel / Touren / Events.

Holt die Daten aus dem LocalStorage/Cookie beim Einloggen/refreshen

Schritte zum reproduzieren

1. Tomcat starten
2. Im Frontend z.B. zum Bestand navigieren
3. Auf hinzufügen drücken
4. Formular ausfüllen und auf erstellen drücken

Gewünschtes Ergebnis

Das Item wird in der Datenbank angelegt/modifiziert.

Wirkliches Ergebnis

Es wird ein 500er HttpStatus zurückgegeben mit NumberFormatExceptions.

Beispiel-Stacktrace:

java.lang.NumberFormatException: For input string: "1999-10-18T22:00:00.000Z"
	java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	java.lang.Long.parseLong(Long.java:589)
	java.lang.Long.parseLong(Long.java:631)
	com.google.gson.JsonPrimitive.getAsLong(JsonPrimitive.java:238)
	memo.EventServlet.doPost(EventServlet.java:135)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:661)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
	org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)

Login

• Sende Logindaten an Server
• Falls login-daten korrekt: speichere Auth. token im local storage
• Falls inkorrekt: display error

Sign up

Implementiere restliche Registrierungs Blöcke:

• Email/Passwort
• Name, Geburtsdatum, Telefonnummer, (Adresse?)
• Bezahlmethoden (kann übersprungen werden)
• Profilbild (kann übersprungen werden)

Workflow zum Reproduzieren des Fehlers:

• neu registrieren
• Email und Passwort angeben
• persönliche Daten angeben
• "neue Adresse hinzufügen" wählen
• bereits vergebene Adresse eingeben und auf speichern drücken

Gewünschtes Ergebnis:

Adresse wird mit Inhalt der Datenbank verglichen und der bereits vorhandene Eintrag zurückgegeben

Wirkliches Ergebnis:

Adresse wird in Datenbank abgespeichert. Doppelte Einträge

Shopitems, die über workarounds direkt in die datenbank injektiert werden, werden im nicht angemeldeten zustand nicht angezeigt

Es sollte direkt nach dem ersten screen einmal abgefragt werden, ob es diese Email bereits gibt. Lösung wäre ein GET für User mit email als parameter

• GET
• POST
• PUT
• DELETE

• klären was bei Delete passieren soll

Sichten für:

• Touren
• Partys
• Merch

-Autoveröffentlichung

-div emails

Beim BankAccount kann aus der BIC das Bankinstitut raus gesucht werden und geprüft werden ob es das Institut gibt.

1. Addresses sollte mit zwei D geschrieben werden
2. der Birthday ist immer der 1. Januar 1970, egal was beim signup gesendet wurde.
3. Die ClubRole ist komplett leer. Falls dem User keine Rolle zugewiesen wurde, sollte die Rolle "0" oder "None" sein
4. Ich finde die Bank accounts sollte man auch nich unbedingt bei jedem GET mitschicken, ich würde das eher über nen seperaten API aufruf regeln

Unterschiedliche Eingabemethoden für unterschiedliche Felder

Beispiele

• Geburtsdatum: Datepicker
• Rest: Ein oder mehrere Textfelder

Im Moment gibt es noch keine richtige Möglichkeit dem Backend zu sagen, dass gerade etwas bestellt wurde. Und andersrum gibt es auch keine "getOrdersByUserId" Funktion, die wir für den "Deine Bestellungen" Menüpunkt wahrscheinlich brauchen werden.

Ich würde ne eigene API vorschlagen. Dafür müsste dementsprechend auch die Datenbank angepasst werden, da die Bestellungen im Moment soweit ich weiß noch nicht enthalten sind.

Vielleicht irgendwie sowas?

@Entity
@Table(name="ORDERS")
public class Order implements Serializable {

    @Expose
    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    private Integer id;

    @Expose
    @Column(nullable=false)
    private Integer userId //also als fremdschlüssel oder so

    @Expose
    @Column(nullable=false)
    private PaymentMethod method; //enum von den möglichen Payment methoden

    @Expose
    @Column(nullable=false)
    private Map<Event, Integer> orderedItems; //der Integer soll dabei die Anzahl sein.
// Aber vllt macht ne extra Klasse (und dann ne Liste davon statt ner Map) doch eher Sinn,
// man muss ja auch die ausgewählte Größe/Farbe irgendwie speichern 

   //...get/set/equals blabla
}

die API könnte dann ungefähr so aussehen?

Methode: GET
URL: /api/order
mögliche queryParameter:

• orderId
• userId: um alle Orders eines Users zu bekommen

Methode: POST
URL: /api/order
mögliche queryParameter:

• paymentMethod: siehe oben
• cartContent: Array von

{
    event: <Event>
    amount: <number>
    options: {
        color: <color>
        size: <string>
    }
}

• userId
• data: Bezahldaten die eingegeben wurden?

Die Pipe soll cent werte in euro umwandeln und führende 0en einfügen, wenn nötig.

Beispiel:

<span>{{2000 | price}}</span>

resultiert in

<span>20,00€<span>

Die funktionen stehen im Wiki.

• GET

• POST

• PUT

• DELETE

Note: bitte im Code überall Address (mit doppel-D) verwenden.

• GET

• POST

• PUT

• DELETE

Jede Tour, Party und Merchandise Detailseite sollte die Möglichkeit bieten, Kommentare zu hinterlassen.

Ich würde dafür folgende Datenstruktur vorschlagen

class Comment{
   public int eventId;
   public int id;   //globale unique ID
   public Date timeStamp;   //muss jetzt unbedingt nich 'Date' sein, aber halt nen Datumstyp
   public int authorId;
   public String text;
}

Damit müsste zumindest der grundlegende Teil abgedeckt sein.

Ich würde dann auch eine eigene Comments API vorschlagen, die aus folgenden funktionen besteht

• GET: getCommentsOfEvent(int eventId) => {comments: Comment[]}
• POST: addCommentToEvent(int eventId, Comment comment) => void?
• PUT: editCommentOfEvent(int eventId, Comment comment) => void?
• DELETE: deleteCommentOfEvent(int eventId, int commentId) => void?

Eine Erweiterungsmöglichkeit wäre, dem Comment-Objekt ein Parent-attribute (sowas wie public int parentId) oder ein children-attribute (public List<Integer> children) hinzuzufügen, womit wir dann richtige comment-threads haben könnten (wie bei facebook oder so).

Weitere Ideen/Verbesserungsvorschläge?

Das Backend gibt ein 202 Accepted zurück und trotzdem meldet das Frontend, dass die Daten falsch sind.

Dropdowns

• männer/frauen/oneSize
• farbe

Weitere Infos

• Größentabelle pro frau/Mann/oneSize in s,m,l,xl
• material

Zuerst muss sich auf eine Authentifizierungsmethode geeinigt werden. Eine Möglichkeit wäre beispielsweise, JSON Web Tokens zu verwenden.

Daraufhin müssen die HTTP Calls des Frontends an die ausgesuchte Methode angepasst werden.
Für JWTs würde dies folgendermaßen aussehen:

let token = localStorage.getItem('token')
let headers = new Headers({ 'Authorization': 'Bearer ' + token });
let requestOptions = new RequestOptions({ headers: headers });
this.http.post(url, requestOptions)
    .subscribe(...)

Backendseitig muss dann dementsprechend geprüft werden, ob der Token korrekt ist und anhand dessen entscheiden, was zurückgegeben wird (nen 403 code oder das gewünschte Resultat)

Im Moment wird in unserem Code die Annahme getroffen, dass immer alle Merchandise-Artikel, Fahrten und Veranstaltungen im Speicher liegen. Da dies aber bei größeren Mengen an Daten irgendwann dazu führt, dass Nutzer ewig lang warten müssen, bis alles geladen ist, und dazu wahrscheinlich noch Unmengen an Datenvolumen verbrauchen müssen, müssen wir das ganze ein wenig umbauen.

Das heißt, die getDataByID(id)-Methode der Stores muss eine dazu passende serverseitige API aufrufen statt auf die interne Datenmap zuzugreifen.

Unvollständige Liste von Funktionen die wir anpassen bzw. falls sie noch nicht vorhanden sind, implementieren müssen:

1. getItemById(id) (heißt bisher getDataById)
2. search(searchTerm) => sollte auch fuzzy searching unterstützen.
   Mögliche Erweiterungen für search: Filtering/Sorting
3. get(category, amount)
category: Entweder Merchandise, Tour oder Party

Notizen:

• Liste besteht nicht nur aus Meilenwölfe Mitgliedern.
• Userrollen sollten in der Liste vertreten sein

geht z.b. so:

<a href="mailto:[email protected]">Message</a>

Offene Fragen:

Unterstützte Dateiformate

• PDF?
• CSV?
• was anderes?

Format

• Wie viele Informationen sollen im Export mit drin stehen?
• Sollen die Informationen bestimmt angeordnet werden?
  • ich würde mal davon ausgehen dass sie default-mäßig einfach chronologisch geordnet werden sollen aber vllt soll der User das ja am Ende auch auswählen können

Manche Werte werden nicht an das Backend gesendet, teilweise auch unzuverlässig.
u.a. folgende values:

• Adresse (siehe #38 )
• Birthday
• manchmal Email & Password
• Dauerkarte und Wölfeclub ist immer false
• Gender ist immer "Keine Angabe" | besser wäre (m,w,null)

Mögliche Library:

https://github.com/SebastianM/angular2-google-maps