innoq/seawatch_planner

⛴ Software for planning SeaWatch's rescue operations

seawatch_planner

⛴ Software for planning SeaWatch's rescue operations

SeaWatch Planner is an application which should support SeaWatch by planning their operations. It allows volunteers to register theirself to help SeaWatch. These volunteers create a profile with availabilitys where they have time to volunteer for SeaWatch Operations. SeaWatch Planner allows the crewing staff to use these Informations in their crewing process and request documents and other information of the volunteers.

How to run the application

To run the application you have to use docker, you will find the installation instructions on https://docs.docker.com/v17.12/install/.

After you downloaded or cloned the repository switch to the directory containing the file docker-compose.yml and run

docker-compose up -d (-dstarts the containers in a detached mode (containers run in background)).

The Django app and the database will then start up.

How to create a Django admin user

To create a superuser (you will need it to enter the admin interface) run

docker exec -it seawatch_planner_web_1 python manage.py createsuperuser

Urls and ports

The application can be reached at localhost:8001/.

The admin interface can be reached at localhost:8001/admin.

If you want to change the ports edit them in the docker-compose.yml file.

How to test the application

For testing the application, start the app as described before. Then run the following command:

docker exec -it seawatch_planner_web_1 python manage.py test

Coding conventions

We decided to use the the following coding conventions.

• Use PEP 8 coding style.
• If possible use Djangos generic class based views, for example ListView, CreateView, DetailView, UpdateView and DeleteView.
• ListViews are often represented with tables. For each dataset you have actions like delete this dataset of go to detail view. These actions are represented by links with fontawesome icon in the table and not by buttons.
• General actions like add a new dataset are represented by buttons with fontawesome icons outside of the table.
• Use the following table as an example for the url paths, the naming of the class of the views and the view name itself:

url path	class name of view	view name
ships/	ShipListView	ship_list
ships/add	ShipCreateView	ship_create
ships/int:pk/	ShipDetailView	ship_detail
ships/int:pk/edit	ShipUpdateView	ship_update
ships/int:pk/delete	ShipDeleteView	ship_delete

seawatch_planner's Issues

Konsistenzprüfungen

Es soll geprüft werden, wo Konsistenz Prüfungen notwendig sind. Z.B. bei der Erstellung einer Mission darf das Startdatum nicht nach dem Enddatum liegen. Genauso sollte das Geburtsdatum im Profil nicht in der Zukunft liegen. Für die einzelnen Prüfungen sollen dann Issues erstellt werden.

Hinweis für passendes Format für Datumsfelder hinzufügen oder lokalisieren

Für Browser, die bei input type = date keinen Datepicker anbiete (z.B. Safari) sollte das passende Format als Hinweistext hinzufügt werden.
Alternativ könnte zusätzlich das deutsche Datumsformat als gültige Angabe akzeptiert werden.

[Crewing] Jede beliebige Position soll approved werden können

Aktuell können nur requested Positions approved werden. Es sollen jedoch auch Positionen approved werden, die nicht als requested eingetragen sind.

[Registrierung] Verfügbarkeiten angeben

Der Nutzer soll nach erfolgreicher Registrierung die Möglichkeit haben Verfügbarkeiten anzulegen.

[Registration] E-Mail Verifikation beim Anmelden und bei E-Mail Änderung

Wenn sich ein Nutzer neu registriert, soll dieser an seine Mail Adresse eine E-Mail mit einem Verifizierungslink geschickt bekommen, durch welchen das Konto aktiviert wird. Zusätzlich soll der Nutzer beim Ändern seiner E-Mail Adresse ebenfalls eine neue Verifizierungsemail geschickt bekommen. Hier soll der Nutzer jedoch nicht neu aktiviert werden, sondern die E-Mail Adresse soll erst übernommen werden, wenn diese verifiziert wurde.

[Crew-Anwendnung] Eigene UI zum Fragen verwalten

Damit die Fragen nicht über das Admin Interface anlegen zu müssen, soll hierfür ein eigenes UI geschaffen werden. Es soll eine Übersichtsseite mit allen Fragen (ListView), sowie eine Seite zum Anlegen von neuen Fragen (CreateView), eine Seite zum Löschen von Fragen (DeleteView) und eine Seite zum Anpassen von Fragen (UpdateView) geben. Eine DetailView wird nicht benötigt, da alle Daten in der Übersichtsseite ersichtlich sein sollen.

[Registration] Nationalität als Dropdown o. Auto-complete?

Ich habe gerade gelesen, dass Drop-down-Menüs nicht nutzungsfreundlich sind - ich störe mich aber am Gedanken an "Deutsch", "Deutschland", "Germany", "German", "GER", "Grmany" und "Europa <3" im Freitextfeld.

[Crew-Anwendung] Profile Review Übersicht (Assessments)

Nachdem ein Profil über die Registrierungsanwendung angelegt wurde, muss dieses gereviewt werden. Dafür wird eine Ansicht benötigt, in der alle noch nicht Profile angezeigt werden die den Assessment Status pending besitzen. Wenn man auf ein Profil klickt sollen alle Daten angezeigt werden.

Welche Daten in der Übersicht benötigt werden sollte mit SeaWatch abgeklärt werden.

Fehlermeldungen verständlich formulieren

Alle Fehlermeldungen sollten verständlich formuliert werden.
Beispiel:
"Input could not be saved. Please correct missing or invalid data!"
oder
"Please enter a valid e-mail address"

[Crew-Anwendung] Wechsel von Assignments ermöglichen

Problem:
Ich habe Manuel Müller als Koch eingeteilt.
Jetzt möchte ich einen Kapitän besetzen. Hier finde ich aber keinen. Manuel Müller könnte aber auch Kapitän sein. Diesen kann ich jedoch nicht mehr auswählen, weil er bereits als Koch eingeteilt wurde. Um diesen nun als Kapitän einteilen zu können, muss ich zunächst die Position Koch von der Crew löschen, damit Manuel Müller wieder frei ist. Dann muss ich ihn als Kapitän zuweisen. Anschließend muss ich wieder die Position Koch hinzufügen und dann eine andere Person als Koch einteilen.

Mögliche Lösungen:

1. In der Auswahl für eine Position werden auch bereits eingeplante Personen angezeigt und ggf. entsprechend markiert. Wird diese Person für eine neue Position besetzt, muss die alte Verknüpfung entfernt werden.
2. Es ist mögliche eine Zuweisung zu einer Position wieder zu entfernen, sodass die Person wieder für eine andere Position verfügbar ist.
3. ???

Aktuell ist mein Favorit die 1. Darf gerne diskutiert werden.

[Allgemein] Benennung der Fachklassen

Ich tue mich aktuell mit dem Benennungen der Fachklassen schwer. Ich merke immer mehr, dass ich mir die Namen mehr eingeprägt habe, die Namen aber nicht gerade eine große Bedeutung haben. Ich denke vor allem in der engeren Zusammenarbeit mit SeaWatch kann dies eher schaden als Helfen. Besonders beim Übersetzen ist mir aufgefallen, dass die Namen eher schlecht gewählt sind. Ich denke man sollte die Fachklassen mit deutschen Namen versehen, so wie Sie bei SeaWatch genutzt werden. Da wir hauptsächlich auf Deutsch kommunizieren machen meines Erachtens nach auch deutsche Namen Sinn.

Gebt mir gerne Feedback was ihr davon haltet @janmax @mschwarz82 @nadyes

[Crew-Anwendung] Profile Review Detailansicht (Assessments)

Nachdem man in der Profile Review Übersicht auf ein Profil geklickt hat, soll man alle Details zu dem Review angezeigt bekommen. Die kann nun das Profile approved, rejected oder bearbeitet werden.

[Registierung] Profil soll DateField nutzen

Im Profil soll ein DateField benutzt werden. Die zeigt deutlich, in welchem Format ein Datum eingegeben werden muss, und prüft ob das eingegebene Datum existiert.

[Registrierung] Übersicht der Daten (Ready for Review)

Bevor die Daten von einem SeaWatch Mitarbeiter approved oder rejected werden, soll der Nutzer die Möglichkeit habe die Daten in einer Übersicht zu überprüfen und diese dann als Ready for Review zu markieren. Erst dann wird das Profil auf pending gesetzt und steht den SeaWatch Mitarbeitern zur Überprüfung bereit.

Anzeigen, welcher Nutzer gerade angemeldet ist

Dadurch ist für den Benutzer einfacher ersichtlich, dass er angemeldet ist, und dass auch der richtige Nutzer angemeldet ist.

Beim debuggen hilft es auch, falls man mehrere Nutzer zum testen verwendet (z.B. bei der Rechte-Struktur)

[Registrierung] Registrierungsprozess kann nicht abschlossen werden ohne ein Dokument hochzuladen

Um im Registrierungsprozess weiter zu kommen, muss zwingend ein Dokument hochgeladen werden. Das sollte noch geändert werden, damit man den Prozess zunächst auch ohne Dokumente abschließen kann.

[Registration] E-Mailadresse und Name muss geändert werden können.

Nutzer sollten in der Lage sein ihre E-Mailadresse und Namen zu ändern. Diese sollten zum Editierungsformular des Profils hinzugefügt werden.

[Crew-Anwendung] Eigenständige Crew Anwendung

Die Django App Missions sollte als eigenständige Django App existieren, damit diese so deployt werden kann, dass sie nur aus einem VPN heraus erreichbar ist. Wie die beiden Anwendungen integriert werden muss noch diskutiert werden.

[Crew-Anwendung] DateField in Missionen nutzen

In den Missionen soll ein DateField benutzt werden. Die zeigt deutlich, in welchem Format ein Datum eingegeben werden muss, und prüft ob das eingegebene Datum existiert.

[Registrierung] Antworten auf eingepflegte Fragen

Es wird eine View benötigt um auf die eingepflegten Fragen antworten zu können.

[Crewing] Filterung fehlerhaft

Die Filterung funktioniert nicht richtig bei den Zeiträumen. Hier scheint lediglich ein > und kein >= verwendet zu werden. Dies soll angepasst werden und mit entsprechenden Tests geprüft werden.

[Crewing] Missionsdaten beim Zuweisen einer Person sichtbar.

Wenn eine Person einer Mission zugewiesen werden soll, ist nicht ersichtlich, wann die Mission startet, oder welche Position gerade besetzt werden soll.

[Registierung] Skills angeben

Es wird eine View benötigt über die Skills angegeben werden. Es gibt bei den Skills keine Ausprägungen, d.h. entweder man besitzt einen Skill oder nicht. Der Skill wird dann durch einen ManyToMany Beziehung den Profile zugeordnet.
Bei den Skills soll in zwei Gruppen unterschieden werden, die grafisch gruppiert sein sollen:

• Sprachen (SkillGroup lang)
• Andere (SkillGroup other)

[Crewing] Warnung bei Assignment in zwei gleichzeitigen oder sich überschneidenden Missionen

Aktuell kann eine Person zwei Missionen zugewiesen werden, die in einem überschneidenden Zeitraum liegen. Ist dies der Fall soll darauf aufmerksam gemacht werden.

[Crew-Anwendung] Automatisierte Mail bei Zuordnung zu einer Mission

Wird sein Profil einer Mission zugeordnet, so soll der Nutzer automatisiert eine Mail erhalten, die Ihn über den geplanten Einsatz informiert und die geforderten Dokumenten für den Einsatz anfordert, falls sie nicht bereits vorliegen und noch gültig sind.

[Registrierung] Availabilities erweitern

In meinen Augen macht es Sinn die Availabilities so zu erweitern, dass ich sagen kann ich kann den kompletten Zeitraum, oder ich kann in diesem Zeitraum beispielsweise 7 Tage oder 5 Werktage.

Seht ihr das auch so? @janmax @mschwarz82 @nadyes

name conflict base.html

We have two base.html files. One in the registration app and one in the missions app. Because of that only one file is used. In my case the file of the missions app is used. We should think about one common base.html or we should rename them that there isn't a name conflict.

[Registierung] Zertifikate angeben (Diskussion)

Da die Anwendung in zwei Anwendungen getrennt werden soll, wobei die Internet-facing Anwendung möglichst keine sensiblen Daten nutzen soll, wäre es sinnvoll nur anzugeben ob man ein Zertifikat besitzt. Die Daten zu dem Zertifikat sollen dann in der Crewing Anwendung nach Zusendung des Zertifikats ergänzt werden.

Um dies Umzusetzen müsste das Datenmodell angepasst werden, ein Form und eine View gebaut werden.

Über diese Entscheidung können wir hier gerne diskutieren.

Profile ansehen

Kann ich eigentlich (als Staff) auch nach dem Assessment nochmal irgendwann Profile ansehen? Auch in der Auswahl bei der Zuweisung zu einer Mission sehe ich dafür keine Option.

[Crew-Anwendung] Assignments sollen nach Zuweisung wieder aufgehoben werden können

Eine Person die einer Position zugewiesen wurde, soll ohne das Assignment zu löschen wieder entfernt werden können.

[Registierung] TextArea bei Fragen

Da die Fragen bei der aktuellen Registierung von SeaWatch sehr umfangreich sind, macht es Sinn dem Nutzer genügend Platz zum Antworten zu geben. Daher soll das TextField gegen eine TextAre ausgetauscht werden. Ebenso sollte die maximale Länge der Antwort überprüft und ggf. angepasst werden

[Crew-Anwendung] Profilübersicht mit Filterung

Als Mitarbeiter von SeaWatch möchte ich alle Profile mit ansehen können, um ggf. Personen zu finden, die nicht genau auf ein Assignment passen. Daher ist es nötig die Profile Filtern zu können. So möchte ich beispielsweise auf eine spezielle Position oder auf spezielle Dokumente filtern können.

Separate application into registration and missions

separate applications into registration and missions such that the missions app can be secured by an VPN

[Crew-Anwendung] Filterung der potentiellen Crew-Mitglieder nach Rolle, Status und Verfügbarkeit

Aktuell werden alle Mitglieder aufgelistet. Die Suche sollte auf mögliche Kandidaten automatisch eingeschränkt werden.

Document upload to S3 or other storage service

The document upload saves the files in the folder static/document/. Because we want to use containers it is not a good solution to save the documents in that folder. We should save the files in a storage service like S3.

[Registrierung] Diskussion über sensible Daten im Profil

Welche Daten des Profils sollen in die interne Crewing Anwendung verlagert werden, da diese als sensible anzusehen sind?

[Crew-Anwendung] Freie Suche nach Crew-Mitgliedern

Der Django-Admin bietet bereits eine Möglichkeit nach Crew-Mitgliedern zu suchen. Es wäre allerdings wünschenswert eine Suche zu haben, die auch Verfügbarkeiten als Kriterium zulässt.

Zum Beispiel:

• 4 Wochen verfügbar
• Im Zeitraum von / bis

[Registrierung] Registrierungsflow erstellen

Wenn man sich anmeldet, soll man durch einen Flow von Seiten geleitet werden, um die Registrierung abzuschließen. Dieser Flow sieht wie folgt aus:

Benutzer registriert sich:

1. Schritt: Benutzer gibt Email, Passwort, Name an
2. Schritt: Benutzer gibt Daten für Profil an
3. Schritt: Benutzer gibt Skills an
4. Schritt: Benutzer gibt Zertifikate an
5. Schritt: Benutzer gibt Gewünschte Positionen an
6. Schritt: Benutzer antwortet auf eingepflegte Fragen & macht eigene Anmerkungen
7. Schritt: Benutzer sagt "Meine Angaben sind vollständig, ihr könnt mich reviewen"

Dieser Flow muss durch Weiterleitungen zwischen den Seiten sichergestellt werden. Ebenso muss sichergestellt sein, dass die Seiten erst angesehen werden können, wenn des die nächste Seite des Flows ist. Auch soll nach erfolgreicher Registrierung keine dieser Views des Flows mehr aufgerufen werden können. Nach erfolgreicher Registrierung können die Daten nur noch bearbeitet werden, wobei bei jedem Bearbeiten der Status des Assessment auf pending zurückgesetzt wird.

[Crew-Anwendung] Profile bearbeiten (Assessments)

Die Profile können hier von den SeaWatch Mitarbeitern, falls nötig, bearbeitet werden.

Über den Nutzen dieser Funktion darf gerne diskutiert werden, da er mir hier nicht ersichtlich ist.

Logout muss auf /accounts/login/ weitergeleitet werden

Nach einem Logout über den Logout-Button in der Navbar wird der Nutzer auf eine Admin-Seite weitergeleitet. Folgt er dort dem Link, um sich wieder einzuloggen, wird gelangt der Nutzer zum Admin-Login. Dort kann er sich nicht anmelden. Nutzer müssen sich über /accounts/login anmelden.

[Registirerung] Availabilities muss zum abschicken der Registrierung

Sollen die Availabilities als required markiert sein? Ich denke die Availabilities sollen nicht benötigt werden müssen, da ich mich so auch registieren kann ohne bereits Urlaub geplant zu haben. Die Prüfung kann dann bereits erfolgen. Für die Prüfung werden die Assessments auch nicht benötigt.

[Registierung] Kommentar pro Availabilty

Es macht Sinn pro Availability einen Kommentar anlegen zu können. Gäbe es nur einen Kommentar für alle Availabilities könnte dieser Kommentar bei der Besetzung der Crew zu Verwirrung führen, da nicht erkennbar ist für welchen Zeitraum der Kommentar genau gilt, bzw. von anderen Zeiträumen die Rede ist, die hier nicht betrachtet werden.

[Crew-Anwendung] Positionsliste an Schiff hinterlegen

Beim Anlegen eines Schiffes könnte neben dem Namen auch eine Liste von benötigten Positionen angelegt werden. Dann könnten später beim Assignment diese Positionen einfach gefüllt werden.

z.B.:

• 1x Kapitän
• 1x 1. Offizier
• 1x 2. Offizier
• 2x Koch
• 3x Arzt
• etc.

[Crew-Anwendung] Positionen zuweisen (Assignments) Filterung nach Position und Availabilty

Beim zuweisen einer Position soll standardmäßig gefiltert werden nach der zu besetzenden Position und der Verfügbarkeit. Diese Filter sollen jedoch abgeschaltet werden können, um weitere Optionen zu erhalten, falls kein passender Kandidat zur Verfügung steht.

[Crew-Anwendung] Missionen anpassen

Missionen sollen editierbar sein.

[Crewing] Zuweisen einer Person - Requested und Approved Position

Beim zuweisen einer Person soll ersichtlich sein, welche Position gewünscht und approved sind und welche lediglich approved sind. So soll für den SeaWatch Mitarbeiter ersichtlich sein, mit wem man ggf. Rücksprache halten müsse um diesen von der Positionseinteilung zu überzeugen.

[Crew-Anwendung] Default Positionen pro Schiff angeben

Bei der Erstellung eines Schiffs soll angegeben werden welche Positionen mit welcher Anzahl benötigt werden. Wird nun einen neue Mission mit diesem Schiff angelegt, so soll für die beim Schiff hinterlegten default Positionen bereits ein Assigment angelegt werden. So muss nicht für jede Mission neu alle benötigen Positionen hinzugefügt werden.

[Crewing] Mehrere Positionen von einer Person besetzt -> Warnung

Aktuell ist es möglich mehrere Positionen einer Mission mit ein und der selben Person zu besetzen. Dies kann für die Planung sinnvoll sein. Es sollte jedoch in der Missionsansicht gewarnt werden, dass eine Person mehre Positionen besetzt. Ebenso soll bei dem zuweisen einer Person darauf hingewiesen werden, falls eine Person bereits in der Mission eingeplant ist.

[Registration] Attach skills, profile, availability, questions, requested positions and documents with the user instead of the profile

Idea

During the registration process the all of the fields above have separate steps. However, technically the profile is special since it is used as ForeignKey for the others (except the user). Domainwise this is not justified. The profile should just be metainformation for the user.

Technical relevance

• This harmonises the data model and allows abstraction over registration steps each of which should be associated with exactly one user information (skill, availability, etc). The order in which they are presented to the user and whether a step is optional (see #33) should be globally defined.

• Adding steps in the future should become easier.

• Fever database queries since everything can be accessed directly through the user which is always present (in the HTTPContext).

[Crewing] Default Assignments funktionieren nicht

Die Default Assignments scheinen nicht zu funktionieren. Diese werden über Signals gesteuert. Eine Analyse und Fehlerbehebung sind erforderlich. Zudem erstellen von Tests.