Schüler-Profil: Meine Absenzen (2PT)

[fbufbi]

Neues Hauptmodul «Meine Absenzen», eigene URL, wird direkt im Evento verlinkt.

Die Lernenden sollen bei von Fachlehrkräften erfassten Absenzen den Grund selber nachtragen können. Nachher können die Lernenden einen PDF-Report herunterladen, um die notwendigen Unterschriften zur Entschuldigung der Absenzen einzuholen.

Bemerkungen:

• "Absenzen melden" wird zuoberst integriert und ist kein eigener Navigationseintrag. Die Rubrik/der Link führt auf eine weitere Seite (=> Absenzen melden (3PT) #186 ).
• Angezeigt werden alle offenen Absenzen, mit oder ohne Grund
• Über «Bearbeiten» (Symbol Stift) können die Lernenden für die ausgewählten Lektionen einen Grund eingegeben oder mutieren (dies ist der Fall, wenn sich die Lernenden nicht selber abgemeldet haben)
  • Führt auf einen Bearbeiten-Dialog bei dem ein Grund ausgewählt werden kann
  • Nach Klick auf "Bestätigen" kommt der Schüler zurück auf den ersten Screen und die Offenen Absenzen werden neu geladen (so dass die Mutation sichtbar ist).
  • Wurde ein Grund erfasst, kann dieser nicht mehr verändert werden => Ist technisch schwierig, daher wird dies nicht umgesetzt. In erster Phase soll nicht voreilend eingeschränkt werden, erst wenn die Schulen dies tatsächlich wünschen.
  • Der Halbtag steht als Absenzgrund nicht zur Auswahl, da dieser voraus beantragt werden muss.
• Über Drucken (Icon PDF) können die Lernenden einen Report für die ausgewählten Lektionen alle offenen Absenzen herunterladen, um die notwendigen Unterschriften einzuholen -> Link auf Report URL, welcher in neuem Fenster geöffnet wird. Das Icon soll nur erscheinen, wenn mindestens 1 hinterlegter Report aktiv ist. Das Icon ist disabled, wenn bei ausgewählten Lektionen noch Absenzgründe fehlen.
• Weitere Rubriken: Entschuldigte Absenzen, Unentschuldigte Absenzen, Vorfälle
  • Es kann nichts bearbeitet werden. Der Aufbau ist aber sonst wie bei den offenen Absenzen.
  • Die freien Halbtage erscheinen unter den entschuldigten Absenzen ohne eigene Rubrik. Gründe: Ohne Statistikendpunkt erscheint die Anzahl Lektionen, nicht die daraus berechnete Anzahl Halbtage. Ausserdem erscheinen nur die Halbtag-Lektionen des aktiven Semesters, Halbtage zählen aber für das ganze Schuljahr (5 Halbtage pro Schuljahr).
• Der Grund wird angezeigt in den Rubriken Offene Absenzen, Entschuldigte Absenzen und Vorfälle.

Technische Umsetzung:

• Offene Absenzen, entschuldigte und unentschuldigte via > /Students/{token.payload.id_person}/LessonAbsences laden
• Vorfälle via /Students/{token.payload.id_person}/LessonIncidents laden
• Absenzen und Vorfälle anreichern /Students/{token.payload.id_person}/TimetableEntries?filter.Id=;{LessonIncidents.Id;LessonAbsences.Id}&fields=Id,From,To,EventNumber,EventDesignation,EventManagerInformation
• Offene Absenzgründe via /PresenceTypes/ filter => Active && NeedsConfirmation && IsAbsence
• Update Endpunkt LessonPresences/Edit Body: {"LessonIds":[],"PersonIds":[],"PresenceTypeId":(Id)} -> analog Offene Absenzen bearbeiten
• Statistikendpunkt (für Counts) ist für Schüler nicht verfügbar, die Absenzen müssen vorgeladen werden.
• Report Id im settings.js hinterlegen (Bug EVO-10553 wurde von SLH behoben), Mussfeld
  Request-Report vorhanden: /CrystalReports/AvailableReports/Praesenzinformation/?ids={settings.report.confirmationStudent}&keys=0
  Request-Report anzeigen: /Files/CrystalReports/Praesenzinformation/{settings.report.confirmationStudent}?ids={LessonAbsences.LessonRef.Id_RegistrationId}&token={token} (Ids={LessonAbsences.LessonRef.Id_RegistrationId} können Komma getrennt aufgeführt werden). Auf Hofwil wurde die Test ReportId=30 erfasst.

Beispiel: GYM Schülerin s1@test.ch (dazugehörige Klassenlehrerin l1@test.ch)

[hupf]

Offene Punkte:

• Lehrer welche auch eine Schülerrolle haben würden auch Absenzen von anderen Schülern sehen. Ist hier ein Filter auf die Person nötig?
• Default Report ID, welche wir verwenden können?

[pmurkowsky]

Hier ein erster Vorschlag.

[pmurkowsky]

Offene Punkte zur Diskussion mit @fbufbi

1. Wieso soll man den Grund nachträglich nicht ändern können? Schüler*innen müssen Fehler korrigieren können.

Und: die technische Umsetzung wäre aufwändig: die Berechtigung zum Schreiben dieses spezifischen Feldes durch Schüler*in ist abhängig davon, ob bereits ein Inhalt erfasst wurde.

2. Ist es sinnvoll, wenn der "Report" nur die ausgewählten Absenzen enthält? M.E. gibt es dafür keinen Grund.

3. Wie wollen wir den "Report" genau nennen? Entschuldigungsformular?

Die Desktop-Version folgt, wenn die Mobile-Version diskutiert und die offenen Punkte geklärt wurden.

[fbufbi]

@pmurkowsky

1. Wir wollen überall das gleiche Regelwerk. In Absenzen melden (3PT) #186 können Schüler*innen ihre Abwesenheiten melden. Den Lehrkräften möchten wir eine Notifikation schicken. Einmal erfasst können diese Abwesenheiten nur von der Lehrkraft verändert werden. Damit soll die Hemmschwelle für absichtliche Falscheingaben und ein Hin & Her (was zur Bombardierung der Lehrkräfte mit Notifikationen führen könnte) höher liegen. In diesem Task möchten wir daher bei der gleichen Logik bleiben. Die Schülerin muss eh noch den PDF-Report ausdrucken und unterschreiben lassen - sie könnte dort den Grund von Hand durchstreichen und überschreiben.

2. Es wäre natürlich viel einfacher, wenn der Report immer alle offenen Absenzen bringen würde. Dann könnte die Checkbox nur aktiv sein, wenn der Grund noch fehlt ("bearbeitbar") - würde das Punkt 1 technisch vereinfachen? Ich denke, wir machen das mal so. Falls es das Bedürfnis gibt, dass gewisse Fächer auf andere Weise (oder bei einer anderen Stelle) entschuldigt werden müssen, können wir immer noch versuchen, dies über die Report-Logik zu lösen und z.B. zwei Seiten auszugeben.

3. Ist zwar lang, aber treffend: Entschuldigungsformular (fr: Formulaire d'excuses)

4. Rückmeldungen zum ersten Vorschlag:

• Wir möchten überall möglichst die gleichen Ansichten, sowohl aus inhaltlicher als auch aus technischer Perspektive. Wir haben in Schüler-Profil: Absenzen aufführen (4PT) #151 die Absenzen im Schüler-Profil für die Fachlehrkraft ergänzt. Bei der Schülerin sollen die Absenzen nun genauso daherkommen. a) Damit es keine Verständigungsschwierigkeiten gibt und Lehrkraft und Schülerin das gleiche sehen und vom gleichen reden (eine wichtige lesson learned einer Schule mit Absenzen-Eigenentwicklung) und b) damit wir die Komponenten möglichst gleich aufbauen können. Gleiches gilt für das Bearbeiten der Absenzen - dies möchten wir für die Schüler*innen möglichst gleich gestalten wie für die Lehrkräfte (Absenzen bearbeiten #22 bzw. wie es heute aussieht). Ansonsten müssen wir es ab beiden Orten ändern.
• Das Wort "Speichern" kommt bisher nirgends vor, sondern immer "Übernehmen", dabei wollen wir bleiben.
• Download bestätigen ist überflüssig, ein Klick mehr...
• Grund prominenter in Rot ist gut.
• Grund muss erfasst sein, bevor Formular ausgedruckt werden kann, ist eine gute Idee - wir wollen digitalisieren und der Verursacher soll den Grund erfassen, nicht die Lehrkraft.

[pmurkowsky]

Hallo @fbufbi, danke für Deine Rückmeldungen.

Zu 1. und 2. OK, dann machen wir das so. Es wird aber nicht einfacher, da wir diese Logik (in der Rolle Schüler*in darf ich sieses Feld nur schreiben, wenn noch nichts drinsteht) nach meinem Verständnis in den Client einbauen müssen.

Zu 4.

• Gleiche Ansichten: Ich verstehe diese Anforderung gut, hätte aber trotzdem gerne mehr Flexibilität. Ich schaue mal mit Hupf, welche Möglichkeiten es gibt um die gleiche Komponente zu verwenden, aber trotzdem gewisse Felder auszublenden um die Übersichtlichkeit zu verbessern und Redundanzen zu vermeiden.
• Übernehmen statt Speichern: OK
• Download bestätigen: diesen Extra-Klick habe ich absichtlich eingebaut, damit die Studis nicht ein PDF herunterladen, mit dem sie (auf dem Mobile) nix anfangen können, weil sie es nicht drucken können.

[pmurkowsky]

Hallo @fbufbi, hier mein 2. Vorschlag.

• Ich habe nun versucht, gleiche Ansichten zu erstellen.
• Download bestätigen habe ich aus oben erwähnten Gründen drin gelassen.
• rote Kommentare sind noch zu diskutieren

[fbufbi]

@pmurkowsky

• PDF + roter Text (Grund erfassen ein Muss) soll nur erscheinen, wenn Report aktiv ist (falls dies technisch möglich ist)
• Ist Wochentag wirklich wichtig? Müsste dann Datum überall angepasst werden à la "Fr, 04.09.2020"? => Ich bin gegen den Wochentag, auch wegen des nächsten Punkts:
• Wichtige Info "vor X Tagen" geht verloren => wohl die wichtigste Info, weil Schulen eine Frist zur Einreichung der Absenzen haben und so auf einen Blick klar ist, ob diese Frist eingehalten wird
• Monat sicher nicht ausgeschrieben
• Datum zuoberst nicht so, wie sonst überall => Fach zuoberst
• "X Lektionen ausgewählt" => nicht fett
• Bin immer noch kein Fan vom Bestätigen des Downloads. Vielleicht will man sich das PDF an eine Adresse mailen, wo man drucken kann. Und sonst lernt man nach dem ersten Mal, dass PDF auf Handy nicht viel bringt.

[fbufbi]

@pmurkowsky Ich bin noch nicht sicher/glücklich bzgl. Aufteilung 1) Fach 2) Lehrkraft 3) Datum, vor X Tagen 4) Zeit 5) Grund. Bisher ist es deutlich kompakter und - je nach Länge der Lehrkraft - ausgewogener:

[pmurkowsky]

Hallo @fbufbi, ich finde die Darstellung so recht gut.

De facto ist es ein Tradeoff zwischen:

1. Vollständigkeit (d.h. inkl. Lehrperson)
2. Übersichtlichkeit bzw. gute Lesbarkeit (durch einzelne Zeilen)
3. fachlich stimmiger Reihenfolge
4. Länge

Bei der aktuellen Ansicht sind Punkt 2 und 3 meines Erachtens weniger gut erfüllt. Dafür ist die Ansicht kürzer.

[pmurkowsky]

@fbufbi Und hier noch die überarbeitete Version.

[hupf]

@fbufbi In der Präsenzkontrolle werden im Profil neben Offene Absenzen, Entschuldigte Absenzen, Unentschuldige Absenzen und Vorfälle noch die Halbtage angezeigt, sofern dies beim jeweiligen Mandanten aktiv ist. Sollen die Halbtage hier auch angezeigt werden, oder habt ihr sie bewusst weggelassen?

[fbufbi]

@hupf Wir haben sie weggelassen, weil wir folgendes Problem haben: Es werden alle Lektionen angezeigt, aber wir haben keinen Zugriff auf den Statistikendpunkt, der die effektive Anzahl Halbtage zählt. Sprich: Es zeigt 10 Lektionen an, was umgerechnet 2 Halbtage sind. Wenn man nur die 10 Lektionen sieht, fragt man sich vielleicht, was das soll. Ich muss zudem noch testen, ob die Lektionen dieses Semesters im nächsten Semester verschwunden sind (davon gehe ich aus). Die 5 Halbtage können aber über den Verlauf des Schuljahres (2 Semester) bezogen werden. Ergo würde die Darstellung nur mehr Fragen aufwerfen als Nutzen bieten. Ich melde mich diesbezüglich nochmals, lass die Rubrik vorerst mal weg.

[hupf]

@fbufbi Okay, das leuchtet ein. Ist es richtig, dass in diesem Fall hier die Halbtage auch als LessonIncident auftauchen und ich diese über LessonIncidents.TypeRef.Id != settings.halfDayPresenceTypeId rausfiltern muss?

Oder kommen unter LessonIncidents nur die mit PresenceTypes.IsIncident = true?

[fbufbi]

@hupf Im Schüler-Profil (Sicht Lehrkräft) filtern wir den Inhalt der Rubrik Vorfälle wie folgt: /LessonPresences/?filter.StudentRef=={id}&filter.TypeRef=;{Id von allen /PresenceTypes welche IsIncident:true haben}. Ergo: Frage 1 = nein, Frage 2 = ja.

[hupf]

@fbufbi Zwei weitere Fragen sind aufgetaucht:

1. Ich habe festgestellt, dass Halbtage zusätzlich auch unter "Entschuldigte Absenzen" erscheinen (sie sind ja effektiv entschuldigt). Dies ist bereits im Profil so.

(Hinweis der Count 7 stimmt im Screenshot nicht, sonst schon, habe etwas rausgekürzt)

Sollen Halbtage im Profil und unter "Meine Absenzen" im Abschnitt "Entschuldigte Absenzen" erscheinen oder nicht?

---

2. Wo soll der Grund überall angezeigt werden? Offene Absenzen, Entschuldigte Absenzen und Vorfälle?

[fbufbi]

@hupf

1. Es ist richtig, dass Halbtage auch unter den entschuldigten Absenzen erscheinen. Dort gehören sie auch am ehesten hin. Wenn die Lehrkräfte nicht noch eine pauschale Korrektur machen (z.B. wegen einer Exkursion, die nicht als einzelne Lektionen abgebildet wird), dann ist das die Zahl, die auf dem Zeugnis erscheint. Die Rubrik Halbtage ist ein Extrading zur Übersicht und für den Counter.
2. Ja, Grund bitte anzeigen bei Offene Absenzen, Entschuldigte Absenzen und Vorfälle. Bei den Unentschuldigten Absenzen gibt es keinen Grund und bei den Halbtagen ist es eine überflüssige Wiederholung.

[hupf]

@fbufbi @schefbi Ich bin noch etwas verwirrt, was das Updaten betrifft.

In der Beschreibung ist spezifiziert:

Update Endpunkt LessonPresences/Edit Body: {"LessonIds":[],"PersonIds":[],"PresenceTypeId":(Id)} -> analog Offene Absenzen bearbeiten

Das beschriebene LessonPresences/Edit entspricht nicht dem Bearbeiten unter Offene Absenzen, dort verwenden wir nämlich LessonPresences/Confirm – welcher der beiden Endpoints soll also verwendet werden?

Ich habe es mit beiden Endpoints versucht (als s1@test.ch auf GymHofwil), offenbar setzt hier aber das Backend implizit den ConfirmationValue:

• Wenn ich auf LessonPresences/Edit einen PUT Request mit dem Body {"LessonIds":[55586],"PersonIds":[4515],"PresenceTypeId":12} mache, dann wird der ConfirmationValue des Eintrags auf 1080 (zu kontrollieren) gesetzt.
• Das gleiche geschieht interessanterweise, wenn ich im PUT Request auf LessonPresences/Edit explizit den ConfirmationValue 219 (zu bestätigen) angebe: {"LessonIds":[55586],"PersonIds":[4515],"PresenceTypeId":12,"ConfirmationValue":219}
• Wenn ich auf LessonPresences/Confirm einen PUT Request mit dem Body {"LessonIds":[55586],"PersonIds":[4515],"AbsenceTypeId":12} mache, erhalte ich einen 400er zurück, mit der Meldung "Error when deserializing request: Required property 'ConfirmationValue' not found in JSON. Path '', line 1, position 59.\r\n" – dies ist also hier ein Mussfeld
• Der PUT Request auf LessonPresences/Confirm klappt, wenn ich auch hier explizit den ConfirmationValue 219 (zu bestätigen) angebe: {"LessonIds":[55586],"PersonIds":[4515],"AbsenceTypeId":12,"ConfirmationValue":219} – allerdings wird auch dann der ConfirmationValue des Eintrags auf 1080 (zu kontrollieren) gesetzt.

Mit welchem Request können wir sowohl den PresenceType ändern, als auch den ConfirmationValue auf 219 belassen?

[fbufbi]

@hupf In der Spezifikation steht: "Auf dem Domänenobjekt [Student] wird das Feld «ConfirmationStateId» immer auf «zu kontrollieren» gesetzt". Ich befürchte, das wurde falsch (zu restriktiv) spezifiziert.

[schefbi]

@hupf Hier hat sich mit dem Patch 2 etwas geändert wir haben einen Task eingegeben. Ich melde mich bei dir sobald ich weiss wann SLH den Fehler korrigiert für einen allfälligen Workaround.

[fbufbi]

@hupf
Auswählen eines Grundes - übernehmen ohne Grund entspricht nicht dem Mockup: Zurzeit suggeriert die Fehlermeldung, dass alle roten Felder ausgewählt werden müssen. Es kann/muss aber nur 1 Grund ausgewählt werden.

Kann dies gemäss Mockup umgesetzt werden? Die Fehlermeldung darf auch über dem Text "Bereits erfasste Absenzgründe..." stehen, sollte aber linksbündig und wenn möglich in gleicher Schriftgrösse wie der restliche Text umgesetzt sein.

[hupf]

Ich habe nun der Abstand vor dem Validierungsfehler etwas erhöht. Kannst du es noch einmal anschauen, insb. mit dem Halbtag?

Es ist so, dass dies der Default Style von Bootstrap für Validierungen ist (siehe https://getbootstrap.com/docs/4.5/components/forms/#supported-elements): die Meldung erscheint unter dem Feld und das Feld wird rot hervorgehoben. Wenn ich die Meldung vor die Felder nehme, greifen die Bootstrap Styles nicht mehr. Da es halt hier Radio Buttons sind, sind alle rot.

[fbufbi]

Test ok