Planbare Präsenzzeiten #13
Comments
sheepyhollow
changed the title
|
Wäre ein tolles Feature für die Zukunft! So etwas lässt sich sicherlich per cron lösen. Dafür gibt es mindestens eine Django Library (z.b. django-celery). |
|
Muss gar nicht Echtzeit sein. Kann ja auch im Vorfeld gebucht werden - allerdings muss man dann vllt. die Plausibilitätsprüfung in Bezug auf Uhrzeit umwerfen (keine Buchungen in der Zukunft) |
Das ist tatsächlich das große Problem. Aktuell erlaubt das System gar keine Schichten in der Zukunft zu erstellen. Entweder wir hebeln die Restriktion ganz raus und alle müssen darauf achten, dass die Schichten stimmen - oder es muss irgendwie rumgetrickst werden. |
|
@sheepyhollow Wie sollen wir das Problem lösen? Beim manuellen hinzufügen einer Schicht kann ein Haken gesetzt werden "Wiederkehrende Schicht", nachdem die Periode gewählt wird (monatlich, wöchentlich, jeder 02. des Monats, ..). Praktisch wie bei den gängigen Kalender-Anwendungen. Aber was macht das System nun? Wie ich es vom Kalender kenne, werden die Termine (Schichten) bis in die Unendlichkeit erstellt. Das ist nicht sinnvoll, wenn wir die Datenbank dadurch fluten lassen könnten, auch wenn nur bis zum Vertragsende. Wie gehen wir also vor?
Jetzt wie ich es gerade geschrieben habe, ist eventuell Methode 1 die eleganteste. Allerdings: dem User sollte es leicht möglich sein noch "geplante" Schichten auch wieder löschen zu können (sprich zukünftige, aber nicht schon vollendete Schichten). |
mimischi
changed the title
|
Das sind irgendwie zwei Fragen: Grundsätzlich ist eine Eintragung über das Vertragsende hinaus nicht sinnvoll. Was aber möglich sein sollte, wäre, bereits angelegte regelmäßige Termine im nächsten Vertrag als Template zu nutzen. Im Konkreten (wann wird die Schicht eingebucht) habe ich keine Präferenzen. Mit der gleichen Argumentation wie beim Beenden zu langer Schichten würde ich 4. okay finden, wobei mir 1. besonders logisch erscheint. Da müsste man vllt. auch überlegen, welche typischen Szenarien es gibt (Tutorien, Labor-Schichtbetrieb, Blockpraktika, Groupmeeting....) Da stellt sich auch die Frage, wie das "Dashboard" aussieht/aussehen könnte. Wenn es eine Kalenderansicht gibt, dann würde ich dort natürlich gerne die vor-eingetragenen Schichten sehen können. |
|
Ich denke wir werden das so etablieren: Beim erstellen einer neuen Schicht kann man auswählen, dass diese sich wiederholen soll. Dann kann der User auswählen in welchem Interval dies geschehen soll. Die späteste planbare Schicht ist dann am jeweiligen Vertragsende. Beim Speichern werden die Schichten direkt alle angelegt. Man könnte dann noch eine extra Übersicht anbieten: "geplante Schichten". Diese zeigt einfach alle in der Zukunft liegenden Schichten an. Problematisch wird es aktuell (mit dem jetztigen Django Frontend) mit dem simplen löschen von mehreren Schichten am Stück. Aktuell muss man das ja ziemlich tedious per Hand machen. Eventuell müsste ich mal kurzfristig doch was mit AJAX machen, damit man solche Dinge direkt aus der Tabellenübersicht löschen kann. Die große Frage: welche Intervalle bieten wir an? Ein Beispiel aus dem aktuellen Google Calendar Interface:
|
|
Täglich und wöchentlich sollte für's Erste genügen. Es wäre aber hilfreich, mittelfristig filigranere, benutzerdefinierte Wiederholung zu erlauben. Was das Löschen mehrerer Schichten angeht - wenn es um das manuelle Löschen durch den Benutzer geht, könnte ich mir Checkboxen und einen Löschbutton auch vorstellen. Dynamisch (mit Mülleimer-Symbol oder so) ist natürlich noch schöner. |
* Shifts can now be created periodically for the following days, weeks and months. * TODO: Add a way to choose the ending date. * We still need to check if there are collisions with other Shifts. Resolves #13.
* Shifts can now be created periodically for the following days, weeks and months. * TODO: Add a way to choose the ending date. * We still need to check if there are collisions with other Shifts. Resolves #13.
|
Der Commit e0d8bdc bringt die erste Version der planbaren Präsenzzeiten mit. Aktuell kann man beim Erstellen einer Schicht auswählen ob diese täglich, wöchentlich oder monatlich wiederholt werden soll. Das ist alles sehr statisch (die Anzeige im Dropdown Feld ist unabhängig von der aktuellen Datums-Auswahl). Man könnte sich überlegen das ähnlich wie Google zu handhaben und etwas dynamisches einzuführen: |
|
@sheepyhollow Eine Frage habe ich aber noch, bezieht sich auch einigermaßen auf die Diskussionen aus #461: was macht die geplante Schicht-Erstellung, wenn es Kollisionen gibt? Also wenn ich im März schon Schichten habe und dann für die nächsten zwei Wochen täglich Schichten generieren lasse. Erstelle ich einfach nur die Schichten, für die es keine Kollision gibt oder lösche ich die Schichten, mit denen ich sonst kollidiere? Eine Auswahl zur Konfliktlösung stellen wir jetzt mal nicht in den Raum :) |
|
Es ist schwierig, abzuwägen, wer in dem Fall "gewinnt" - vor allem, wenn es 'automatisierte' Schichten sind, mit denen es Kollisionen gibt. Aber wir hatten in #464 schon einmal über das Problem von Überlappungen diskutiert. Im Prinzip kommt das doch aufs Gleiche hinaus? Eine Auswahl zur Konfliktlösung ist auch hier natürlich wieder die sauberste Variante. Aber wichtiger ist das Reporting. Ich würde in dem Fall vorschlagen, dass die Schichten nicht erstellt werden, das aber gemeldet wird. |
|
@sheepyhollow Aktuell werden die Schichten einfach so erstellt, ohne großes Feedback. Ich würde vorschlagen, dass wir den User beim Erstellen von sich wiederholenden Schichten auf eine Bestätigungsseite weiterleiten. Hier würde man dann sehen, welche Schichten erstellt werden und welche (durch eine Kollision) nicht erstellt werden. Ist zwar ein extra Schritt, bringt dem User aber einen großen Informationsgehalt. |
HiWis, die z.B. in regelmäßigen Tutorien arbeiten, könnten sich feste Präsenzzeiten einrichten, in denen sie automatisch geclockt werden.
Das setzt dann entsprechende Einträge in die Shift-List (müsste dann eben aber für die Zukunft erlaubt sein... uh...), die natürlich bei der Überarbeitung geändert werden können (habe überzogen, war krank...)
The text was updated successfully, but these errors were encountered: