1. Nutzer muss angemeldet sein
2. Nutzer navigiert zum gewünschten Ereignis (welches den Status „abrechnen“ hat)
   • Ausgabe der offenen Beträge
   • Optionen zur Anzeige der eventl. Zahlungsinformationen, oder den Betrag als beglichen markieren

1. Nutzer muss angemeldet sein
2. Nutzer navigiert zum gewünschten Ereignis (welches den Status „abrechnen“ hat)
3. Nutzer markiert den offenen, zu erhaltenden Betrag als eingegangen

1. Benutzer meldet sich im System an
2. Benutzer navigiert zu dem ausgewählten Ereignis
3. Benutzer bekommt eine Ausgabenübersicht zu seinem Ereignis
4. Benutzer bestätigt die Korrektheit der Ausgaben und klickt auf "Abrechnen"
5. Das Ereignis wird abgeschlossen, es können keine Kosten mehr angemeldet werden
6. Alle Teilnehmer des Ereignisses bekommen eine Meldung, dass sie für dieses Ereignis den Betrag zahlen müssen oder eine Zahlung erhalten.

1. Benuter meldet sich im System an
2. Benutzer navigiert über Ereignisliste zu einem Ereignis an dem er teilnimmt
3. Benutzer sieht seine bisherigen Ausgaben
4. Benutzer sieht Gesamtausgaben
5. Benutzer sieht seine aktuelle vorläufige Abrechnung

Main Success Scenario:

1. User navigiert zur Registrierungsseite
2. User findet Registrierungsformular mit Benutzername, Email und Passwort
3. User wählt einen Benutzernamen, der nicht vergeben ist
4. User gibt gültige Email-Addresse ein
5. User wählt ein Passwort
   • Passwort muss zweimal eingegeben werden
6. User gibt Zahlungsinformationen an
7. User sendet Formular ab
8. User bekommt per Mail ein Bestätigung der erfolgreichen Registration
   • User kann sich einloggen

Extensions:

• Benutzername vergeben, oder Email-Addresse ungültigen Formates, oder Passwörter stimmen nicht überein
  • Nutzer bekommt eine Meldung diesbezüglich
  • Das Absenden des Formulars hat kein Effekt
• Aktivierungslink verschicken

1. Benuter meldet sich im System an
2. Benutzer navigiert über Ereignisliste zu einem Ereignis (Benutzer klickt auf Posten hinzufügen, falls das Formular nicht ohnehin schon auf der Seite sichtbar ist)

3.Benutzer gibt in Textfeld name des Posten an
4.Benutzer gibt in anderem Feld Preis an
5.Benutzer klickt auf Posten hinzufügen
6.Der offene Posten wird dem Ereignis hinzugefügt

1. Nutzer muss angemeldet sein
2. Nutzer navigiert zum gewünschten Ereignis (welches den Status „abrechnen“ hat)
   • Ausgabe der offenen Beträge
   • Optionen den „Schuldner“ zu kontaktieren, oder den Betrag als eingegangen markieren

Hintergrund ist, dass Ereignisse nur zwischen Benutzern abgerechnet werden können, die diesem Ereigbnis zugeordnet sind:

Main Success:

1. Benutzer ist eingeloggt oder loggt sich ein
2. ... verfügt über Code/spezifische URL und ruft diese/n auf
3. ... muss entscheiden ob er diesem Eregnis zugeordnet werden möchte [Ja]
4. ... gelangt auf die Ereignisübersicht/Postenübersicht des Ereignisses

Extension Points:

• Benutzer entscheidet sich für nein bei der Frage nach dem Beitritt
• ... soll (z.B. weil er ein Kind ist) "anders" abgerechnet werden, zum Beispiel mit einem geringeren Anteil an der Gesamtsumme (was Auswirkungen auf die Anteile nicht-ermäßigter Ereignisteilnehmer hat)

1.Benutzer meldet sich im System an
2.Benutzer wählt die Name, Ort und Zeitpunkt des Ereignis
3.Benutzer kann Zahlungsmodalitäten festlegen
4.Benutzer definiert die möglichen Teilnehmer (siehe X)
5.Benutzer bestätigt das Erstellen mit dem Druck auf einen Ereignis erstellen Button
6.Das neu erstellt Ereignis befindet sich nun in der Liste der aktiven Ereignisse

1. Nutzer muss angemeldet und „Ersteller“ des Ereignisses sein
2. Nutzer navigiert zum gewünschten Ereignis (welches den Status „abrechnen“ hat)
   • Ausgabe der offenen, beglichenen und eingegangen Beträge (Ein- und Ausgaben) und der damit verbundenen Nutzer
   • (optional) Möglichkeit ein Nutzer zu kontaktieren

Der Teilnehmer hat einen Posten erstellt und möchte ihn nach der Erstellung ändern/löschen (z.B. falscher Preis oder falsches Ereignis, Rechnung hinzufügen...)

Benutzer meldet sich an
Benutzer navigiert über Ereignisliste zu einem Ereignis
Benutzer öffnet dortige Postenliste
(Sofern das Ereignis noch nicht abgerechnet wurde) Bei den Posten die der Nutzer erstellt hat, sind "bearbeiten" und "löschen" Buttons (Der Ersteller des Ereignisses darf bei allen Posten jeweils ablehnen)
    Nutzer klickt "löschen": Nachdem die Aktion bestätigt wurde (Popup...) wird der Posten gelöscht
    Nutzer klickt "bearbeiten": Das selbe Formular, was der Benutzer bei der Erstellung ausgefüllt hat, erscheint. Nun kann er die vorausgefüllten Werte ändern. Bei einem Klick auf den "Speichern-Button" wird der Posten geändert
Benutzer wird zur Postenliste weitergeleitet

Extensions:

Validierung und Fehlermeldungen wie bei "Posten zu Ereignis hinzufügen"
    zu kurzer/gar kein Titel
    invalider Preis

I see no need for using UUID's, just disadvantages

• ugly URLs
• hassle with associations
• slow record lookup when using a stringish primary key

What was your intent when you implemented it?

If we will decide to keep it, we should use https://github.com/jashmenn/activeuuid

1. Benuter meldet sich im System an
2. Benutzer navigiert über Ereignisliste zu einem Ereignis an dem er teilnimmt
3. Benutzer über die Kostenpunkte Bilder der Rechnungen abrufen (falls verfügbar)

1. Benutzer meldet sich im System an
2. Benutzer navigiert zum gewünschten Ereignis
3. In der Historie kann der Nutzer nun ablesen, was die letzten Änderungen beim Ereignis waren (z.B. Neuer Kostenpunkt, neuer User, ...)

1. Nutzer wählt eine der verfügbaren Sprachen (Deutsch/Englisch)
   • Seite wird in der gewählten Sprache neu geladen
   • Die gewählte Sprache bleibt während der Sitzung aktiv
   • Ist der Nutzer eingeloggt, wird die gewählte Sprache als Standard
     im Profil gespeichert

Ablauf:

1. Das System zeigt den Logindialog an.
2. Der Benutzer trägt seinen Benutzernamen sowie das Passwort in die Textfelder ein.
3. Der Benutzer bestätigt seine Eingaben.
4. Ferner wird geprüft, ob der eingegebene Benutzername existiert und das eingegebene Passwort dazu stimmt.

Weiteres: Das System erkennt, dass der Benutzername nicht korrekt ist oder das Passwort nicht mit dem Benutzernamen übereinstimmt.In diesen Fällen wird eine Fehlermeldung mit dem Hinweis, dass der Benutzername oder das Passwort nicht korrekt eingegeben wurde, angezeigt. Weiter mit 2.Schritt.

Hintergrund: Rückfragen und Absprachen hinsichtlich der Abrechnung sollten öffentlich einsehbar sein. Deshalb ist es sinnvoll eine Kommentarfunktion an jedes Ereignis anzuhängen. Die Kommentare sollten einfach flach nacheinander folgen, wie beispielsweise "Facebook Kommentare" bei einer Veranstaltung.

Main Success Szenario:

1. Benutzer ist eingeloggt oder loggt sich ein
2. ... navigiert zu einem Ereignis auf das er Zugriff hat
3. ... klickt auf "Kommentiere/Rückfrage stellen" und wird zum Kommentarfeld navigiert
4. ... kommentiert im Formular das Ereignis und klickt auf Senden
5. Der eingegebene Text erscheint als Kommentar des Ereignisses

Extension Points optional:

• Es kann verboten sein Kommentare zu hinterlassen
• Ein Benutzer kann vom Kommentare-Verfassen ausgeschlossen sein
• Kommentare sollen gelöscht werden können

Translate all missing strings.. we have a lot of "translations not found"

• Statistik über Gesamtsumme der geteilten Kosten wird auf der Startseite ausgegeben (als teaser)

1.Benutzer meldet sich im System an
2.Benutzer navigiert über Ereignisliste zu einem Ereignis
3.Benutzer wählt eine Aktion "Bearbeiten" für einen Ereignis
4.Benutzer editiert beliebeige Felder und speichert seine Änderungen mit dem Druck auf einen "Speichern" Button

Alle Änderungen werden im System gespeichert

We still need an option for event-creation that decides whether one participant pays for all or the whole bill is split.

This was actually part of issue #1 but we were missing the point somehow.

1. Nutzer muss angemeldet sein
2. Nutzer navigiert zum gewünschten Ereignis (welches den Status „abrechnen“ hat)
3. Nutzer markiert einen seiner offenen, zu zahlenden Beträge als beglichen
   • Der gewählte Kontoverwalter/Nutzer wird benachrichtigt

1.Benutzer meldet sich im System an
2.Benutzer navigiert über Ereignisliste zu seinem Ereignis
3.Benutzer wählt eine Aktion "Entfernen" für einen Erreignis
4.Benutzer druckt auf ein OK Button in einem "popup message box" um seine Aktion zu Bestätigen

Ausgewähltes Ereignis wird aus der Ereignisliste entfernt und in den Papierkorb des Erstellers gelegt