Das ist genau der Knackupunkt. Vielleicht muss ich hier auch mein ein bisschen ausholen. Als das ganze geplant war handelte es sich noch gar nicht um Kurse. Das war eine Begrifflichkeit die wir nach Community Feedback erst so eingerichtet haben, in Entwicklerkreisen sind das Sessions.
Eine Session ist eine Liste an Nutzern welche einen Supervisor (Lehrer) haben. Gedacht ist das ganze damit der Lehrer mit diesen Interagieren kann. Passwort setzen, Dateien austeilen, Internet freischalten etc. pp.
Aus logischer Sicht kann ich verstehen dass man hier erwartet auch gleich ein Tauschverzeichnis zu haben.
Ich sage mal technisch wäre es tatsächlich möglich für jede dieser Sessions auch ein Tauschlaufwerk einzurichten. Allerdings sehe ich das als recht komplex an, gerade wenn man im Hinterkopf behält das sich jeder Lehrer beliebig viele Sessions anlegen kann.
Für eine wachsende Kurssammlung würde ich tatsächlich auch die Projekte empfehlen. Hierbei haben wir definierte Liste in die auch mehrere Lehrer im Zweifelsfall schauen können. Diese halten auch über das Schuljahr hinweg an.
Eine Schulsession ist auch schnell mal gelöscht, es wäre ja sehr ärgerlich wenn hier die Daten weg wären.
Ich sehe da schon die Komplexität eines solchen Vorhabens.
Wäre es denn vielleicht möglich, daß, wenn ein Lehrer ein Projekt erstellt, automatisch auch ein Kurs erstellt wird, welcher die selben Mitglieder hat?
Sobald sich ein weiterer Lehrer in das Projekt einschreibt, bekommt auch dieser den Kurs erstellt.
Wenn das Projekt geändert wird, z.B. Mitglieder hinzukommen, wird der entsprechende Kurs aller eingeschriebenen Lehrer aktualisiert.
Wenn der Lehrer sich aus dem Projekt austrägt, wird auch sein zugehöriger Kurs gelöscht.
Wahrscheinlich ist das aber ähnlich komplex Umzusetzen.
Ansonsten kann ich nach Deiner Empfehlung natürlich auch ein Projekt erstellen und erstelle einen identischen Kurs mit denselben Mitgliedern wie im Projekt. So habe ich ein Tauschlaufwerk für meinen persönlichen Kurs.
Wäre es nicht möglich, das transfer Verzeichnis bei jedem Login eines Schülers (Loginscript) leeren zu lassen? So ist das immer sauber, auch von Altlasten vorheriger Lehrer. So gewöhnen sich die Schüler automatisch an, daß dieser Ordner nichts für dauerhaftes Speichern ist.
Man muß nur schaun, daß das Loginscript bei einem Lehrer nicht ausgeführt wird. Weiß jemand, wie man das in einer Windows Batchdatei macht?
Das Problem hierbei ist das bei einem Projekt ein Lehrer Mitglied als auch zweiter (drittver, vierter…) Admin des Projekts sein kann.
Wer bekommt nun das Projekt angezeigt? Wie verhindern / ermitteln wir welcher Nutzer nun tatsächlich in den Kurs soll und welcher nicht? Filtern wir nicht haben wir Lehrer in der Session und Lehrer können anderen Lehrern die Berechtigungen entziehen.
So wie ich es verstanden habe, ist ein Admin eines Projekts ein „normaler“ Lehrer, mit dem Unterschied, daß dieser Admin weitere Schüler zum Projekt hinzufügen kann. Hier muss man dann eventuell keine Unterscheidung machen. Alle Lehrer die in dem Projekt eingeschrieben sind, bekommen den Kurs generiert.
Damit die Lehrer nicht in den Kurs kommen, könnte es eventuell möglich sein die Gruppenzugehörigkeit beim automatischen Generieren des Kurses abzufragen und so nur Schüler in den Kurs zu nehmen.
Aber das ist nur meine laienhafte Vorstellung von den Dingen. Ich möchte mir nicht anmaßen das als leicht umsetzbar darzustellen.
Ok, gerade beim Abschicken ist mir was aufgefallen.
Wenn Lehrer A im Kurs des Projekts den Schülern das Internet sperrt, dann kann Lehrer B zur selben Zeit im Kurs mit den Schülern nicht mit Internet arbeiten. So funktioniert das also nicht. Mein Vorschlag war nicht zu Ende gedacht…
Das stimmt, sollte aber eigentlich nicht vorkommen, da der gleiche Schüler stundenplantechnisch ja nicht gleichzeitig bei Lehrer A und Lehrer B sein kann, die Kurse sollten sich also nicht zeitlich überschneiden.
wenn aber ein Teil der Schüler bei Lehrer A ist und ein Teil der Schüler bei Lehrer B (gleichzeitig), dann kommt es wieder vor. Ok, da kann ich dann nicht den ganzen Raum sperren, sondern muß wirklich die Schüler auswählen, welche bei mir im Kurs sitzen.
Da weiß ich nicht wie praktikabel das dann ist.
So habe ich das jetzt gemacht:
/var/lib/samba/sysvol/fzi.lan/scripts/default-school/custom/windows/logon.bat
rem transfer Verzeichnis fuer Schueler beim Anmelden leeren
@echo off
whoami /groups | find "%USERDOMAIN%\teachers" > nul
if not errorlevel 1 goto end
H:
cd transfer
rd /s /q H:\transfer
echo..... Schueleraccount.....Transferinhalt geloescht!
goto exit
:end
echo..... Lehreraccount loesche nichts!
:exit
Das wäre theoretisch schon möglich, trifft aber auch schon einige Annahmen darüber was wie gemacht wird.
Generell stand auch schon im Gespräch dass Lehrer auch Sessions / Kurse mit anderen Lehrern starten können. Das war technisch geplant, ist aber gerade beschnitten von uns.
Würden wir diese Art von Annahmen treffen, wäre das Feature aber für immer vom Tisch und könnte so nicht umgesetzt werden.
Ich denke hier muss man tatsächlich zweigleisig fahren. Wenn ich für einen bestimmten Kurs / Stufe langfristig Material bereitstellen will, dann ist das in einem Projekt besser aufgehoben.
Für den schnellen Unterricht allerdings, ist das Session Modul mit aus- und einteilen die bessere und modernere Variante. Wenn wir in Richtung Tablets etc. denken, hat der Lehrer die Möglichkeit einfach mal eine Datei auszuteilen aus dem Interface in welchem er sich eh befindet anstatt den Schülern nochmal etwas in ein Tauschlaufwerk zu legen.
Mit der nächsten Version wird auch das Austeilen und Einsammeln nochmal etwas umgebaut. Dann wird es so sein, dass beim austeilen ein Ordner mit dem Lehrerlogin im Transfer Verzeichnis angelegt wird in welchem Die Daten landen. Somit wird es nicht mehr das Problem geben dass Lehrer A die Daten von Lehrer B abräumt die dieser vergessen hat mitzunehmen.
Das Transferverzeichnis sollte ohnehin als flüchtiger Speicher betrachtet werden. Die Idee dieses periodisch zu leeren finde ich gar nicht schlecht. Das müssten wir aber auch in Entwicklerkreisen nochmal besprechen.
