Hallo Jörg,
wow – das ging ja flott 
Besten Dank dafür! Ich habe es gerade nochmal mit Deiner neuen Version ausprobiert: Läuft wieder 
Hier zwei Screenshots:
Vielen Dank für Deinen prompten Einsatz!
Damit sollte das Problem gelöst sein.
Zuletzt noch ein Screenshot, der zeigt, dass die globale Gruppe der Klasse 5a nun wieder geschrumpft ist:
Viele Grüße,
Michael
Hallo Jörg,
ich muss diese Antwort von Dir besser verstehen, weil ich im letzten und diesem Jahr an exakt diesem Problem hänge und keine Lösung finde. Trotz passender Einstellungen werden Schüler*innen aus den mit diesem Verfahren erstellten globalen Gruppen wieder rausgeschmissen, andere nicht eingetragen.
Der Cronjob läuft doch so oft, wie ich das bei „Geplante Tasks“ eingestellt habe. Es ändert sich beim Anmelden der SuS ja auch nichts an der Klasse/Lerngruppe. Ich verstehe also nicht, weshalb die globalen Gruppen nicht stabil bleiben.
Grüße und Danke!
Martin
Hi
bei mir hat bisher immer geholfen, als Administrator unter Websiteadministration - Entwickler- alle Caches löschen
aufzurufen.
Anschließend hat das Plugin stets getan wie ihm geheißen:)
Vielleicht hilft das auch bei deinem Problem
LG Jesko
Hallo Jesko,
Danke. Caches lösche ich fleißig und regelmäßig. 
Wieso gibt’s dafür eigentlich keinen Cronjob?
Für mich fühlt sich das wie ein Bug an. Da hauptsächlich die neuen 5er betroffen sind, dachte ich
es liegt vielleicht daran, dass manche noch nicht richtig im System registriert sind, aber auch da erkenn ich kein Muster.
Ich werde vermutlich ab nächstem Jahr einfach warten, bis alle SuS in den richtigen Klassen sind und die globalen Gruppen dann händisch hochladen.
Grüße
Martin
Hallo Martin,
das Problem ist, dass das Plugin zwei Mechanismen kennt, um aktiv zu werden:
Bei einem User wird das Profil modifiziert. Dann wird dieser User bei den Gruppen aktualisiert.
Per Cronjob. Der Cornjob prüft aber beim Start erst einmal, ob er gebraucht wird. Und das ist nach der internen Logik nur der Fall, wenn was an den Einstellungen des Plugins verändert wurde, denn ansonsten greift ja der erste Fall.
Und hier liegt das Problem: Das Plugin bekommt eine Veränderung des Profils nur mit, wenn bei der Veränderung der für solche Fälle vorgesehene Mechanismus angestoßen wird. Und das ist leider nicht immer der Fall. Insbesondere ist es nicht der Fall, wenn das LDAP-Sync-Plugin ein Profil verändert - und genau so ist es bei uns ja die Regel. Das ist nun zwar ein Fehler des LDAP-Sync-Plugins, aber das hilft uns nicht weiter.
Deshalb habe ich bei uns die Prüfung beim Cronjob deaktiviert. Der bricht also nicht ab,. sondern läuft jedes Mal durch und prüft alle User. Da das bei uns sehr schnell geht (unter einer Sekunde), ist das kein Problem.
Lieder muss man die Prüfung im Code deaktivieren (am besten wie oben beschrieben, indem man die if-Abfrage samt zugehöriger „geschweifte Klammer zu“ auskommentiert), sodass man das bei Updates immer wieder neu erledigen muss.
Ich hoffe, das hilft Dir weiter!
Beste Grüße
Jörg
Hallo,
nun sehe ich, dass das ein anderer Thread war, der Vollständigkeit halber also nochmal hier:
Die Änderung mach man in der Datei moodle/local/profilecohort/classes/task/update_cohorts.php ganz unten:
public function execute() {
// if (get_config('local_profilecohort', 'updatecohorts')) {
$manager = new profilecohort();
$manager->update_all_cohorts_from_rules();
set_config('updatecohorts', false, 'local_profilecohort');
// }
}
Man muss nur in zwei Zeilen die doppelten Schrägstriche einfügen.
Beste Grüße
Jörg
Hallo Jörg,
vielen Dank für die ausführliche Erläuterung. Jetzt sehe ich klarer. Und ja, es betrifft
tatsächlich die neuen 5er, bei denen es - bei uns / noch / leider - etwas länger dauert,
bis die alle ihre Zugangsdaten haben und damit umgehen können.
Deinen Vorschlag, den Code zu modifizieren, kommt für unser noch bei Belwue gehostetes Moodle
wohl nicht infrage.
Aber die Infos reichen mir erstmal, damit ich mir für das nächste Jahr mein Vorgehen genauer zurechtlegen kann. Danke.
Grüße
Martin
Hallo Martin,
wir sind auch bei Belwü, das geht dort problemlos. Wir müssen nur immer daran denken, nach einem Update den Code wieder zu patchen.
Beste Grüße
Jörg
Hallo Jörg,
wir haben unser Moodle erst während Corona eingerichtet. Soweit ich informiert bin, gibt’s für uns keine Möglichkeit auf das Dateisystem des Servers zuzugreifen, weil uns der SCP-Zugang fehlt/nicht gegeben wird. Oder bin ich da falsch informiert? Macht man das anders?
Grüße
Martin
Hallo Martin,
als wir unser Moodle noch bei BelWü hatten, hatten wir dort einen SFTP-Zugang und die Möglichkeit in php den exec Befehl zu nutzen. Also habe ich mir ein paar Skripte geschrieben, die dann das tun, was auf sonst auf der Konsole zu tun wäre. Nach der Ausführung sollte man das Skript natürlich wieder vom Server löschen.
Unser Moodle war bei BelWü in eigenem Webspace, ob bzw. wie das auch bei den gemanagten Instanzen geht weiß ich nicht.
LG,
Simon
Hallo Martin,
wir haben (per Fax) Zugangsdaten für SCP und auch die Datenbank bekommen. Ohne wäre es in der Tat schwierig.
Beste Grüße
Jörg
Hallo Jörg, Martin und alle anderen,
jetzt verstehe ich das Verhalten so langsam.
Ich habe gerade mit ein paar Testschülern durchprobiert was passiert. Ein Klassenwechsel im LDAP auf dem LMN-Server wird vom cronjob in Moodle tatsächlich nicht verarbeitet.
Aber für mich völlig ausreichend: sobald sich der Benutzer anmeldet, wird er in die richtige globale Gruppe gesetzt und erscheint auch in den Kursen, die die Teilnehmer über die Einschreibemethode „globale Gruppe“ aufgenommen haben.
Das erklärt vielleicht auch, warum manche Schüler in der richtigen globalen Gruppe landen und andere noch in der falschen bleiben. Die Schüler in der alten/falschen globalen Gruppe hatten sich einfach noch nicht in Moodle (im Browser?) angemeldet.
VG
Christian
Alternative wäre:
Download des gezippten moodle-plugins, entzippen, Script wie oben angegeben verändern,alle Dateien einschließlich der modifizierten wieder packen und dann dieses modifizierte moodle-plugin zu installieren (per upload vom heimischen Rechner).
L.G.
Christoph
Hallo zusammen,
auch wenn es nicht zur Pflege des Plugins beiträgt, möchte ich noch einmal loswerden, dass bei mir zumindest beim Belwü Moodle die Schüler auch bei einem Klassenwechsel im LDAP ganz ohne weitere manuelle Eingriffe nach einigen Stunden, evtl. noch später, im richtigen Kurs landen. Bevor hier dieser Aufwand getrieben wird, der bei jedem Update (in wenigen Tagen steht wieder eines an) wiederholt werden muss, würde ich lieber etwas länger warten. Habt ihr einfach mal 24h abgewartet?
VG
Christian
Hallo Christian,
warten hilft leider nicht. Wie gesagt gibt es durchaus Ereignisse (wie z. B. eine Anmeldung, auch im Hintergrund), die das Plugin triggern, aber ohne passiert leider nichts. Das Problem betrifft auch nicht nur uns, und es gibt entsprechende Feature-Requests.
Beste Grüße
Jörg
Halklo Christoph,
Gute Idee - dann müsste man zusätzlich zur eigentlichen Änderung noch in der Datei moodle/local/profilecohort/version.php den Wert von $plugin->version erhöhen. Das sollte auch gehen, wenn man keinen SCP-Zugriff hat.
Bei uns ist das ja vor allem in den ersten Wochen des Schuljahres relevant, später gibt es ja kaum noch Wechsel bei den Klassen. Da ist es auch nicht so schlimm, wenn das Plugin mal ein paar Tage nicht läuft.
Viele Grüße
Jörg
Hallo Jörg,
danke und schade, dass das nicht mit dem ldap_sync harmoniert. Der sollte ja eigentlich bei der kleinsten Änderung die profilfeld-basierende Zuweisung globaler Gruppen für einen Volldurchlauf triggern.
(Keine Ahnung, warum es dann bei mir trotzdem klappt, auch ohne Anmeldung der entsprechenden User - neu erstellt und nie angemeldet. Ich war nur als Trainer des Kurses regelmäßig auf der Teilnehmerliste und habe ansonsten Moodle in Ruhe gelassen.)
VG
Christian