Hallo Michael,
bei unserem Belwü-Moodle funktioniert das, die Lehrer sind Lehrer und nicht zusätzlich als Schüler in den Kursen.
Hast Du vielleicht noch ein anderes Plugin aktiviert, wie zum Beispiel die „LDAP Syncing Scripts“?
Beste Grüße
Jörg
Ja also von kir war sas vorhon falsche info. Sorry fuer den post dann vohrhin. Die lehrer sind beinuns in belwue kursersteller und teacher.
Die schueler rolle ist da nicht drin. Aber klar man kann ja dienrolle wechseln. Kann leider dann nichts zur loesung und ursache finden des problems beitragen.
Nur hab ich in erinnerung dass sich die globalen gruppen nur aktualisieren, wenn irgendeine eine aenderung gemacht wurde bei den Profilfeld zugewiesenen Gruppen und man dann den cache loescht. Das war ein Bug und ich weiss net ob der noch aktuell ist.
Wüsste nicht, welche Info vorher falsch gewesen sein soll?!?
Das andere Plugin „LDAP Syncing Scripts“ ist auch installiert aber ich bin nicht sicher, ob das läuft. Ich werde die globalen Gruppen in nächster Zeit wieder etwas genauer im Auge behalten. Dann wird sich zeigen, ob in der 5a plötzlich auch wieder die Lehrer in der Rolle Schüler eingeschrieben werden…
Hallo Michael,
poste doch mal die Einstellungen des Plugins (unter Plugins → Local Plugins → Ldap Syncin Scripts) und außerdem, ob die zugehörigen Tasks aktiviert sind (Server → Tasks → Scheduled Tasks, dort nach local_ldap suchen).
Beste Grüße
Jörg
Hallo.
Über Nacht hat es sicher wieder verstellt. Jetzt sind die globalen Gruppen für die Klassen wieder um die Lehrer angewachsen 
Die Einstellungen des „Ldap Syncin Scripts“ sehen mir aus wie die defaults:
Hier die Einstellungen zum Cronjob:
Es scheint also ebenfalls zu laufen und vermutlich ist das auch die Ursache, warum die globalen Gruppen der Klassen sich verändern. Seltsam ist, dass das scheinbar erst neuerdings ein Problem ist (denn das wäre normalerweise schon vorher aufgefallen).
Was mir nicht klar ist: Aus den Einstellungen zu den Ldap Syncin Scripts geht nicht hervor, wie/ob Klassen überhaupt behandelt werden, oder??
Viele Grüße,
Michael
@jrichter Ich habe erst gerade realisiert, dass die Seite aus dem Wiki (nach der ich das damals eingerichtet hatte) von Dir stammt 
https://wiki.linuxmuster.net/community/anwenderwiki:webapps:moodle:moodle_extern_ldap:start
Hallo Michael,
so ist es, drum hatte ich auch gleich den richtigen Riecher. Dieses Skript synct Dir ebenfalls die Gruppen, und zwar alle, also auch die Klassen. Und wenn sich ein Lehrer in der Schulkonsole in eine Klasse einträgt, dann landet er letztlich als Schüler in der Globalen Gruppe.
Ich habe deshalb extra eine modifizierte Version des Plugins gebastelt, bei der man noch einen LDAP-Filter setzen kann. Da nehme ich (cn=p_*) und synce somit nicht die Klassen. Für die nehme ich wie Du das Profilfeld. Die modifizierte Version des Plugins ist im Wiki hinterlegt und läuft so mit unserem Belwü-Moodle 4.1.3.
Herzliche Grüße
Jörg
Hallo nochmal - gab es denn evtl von diesem Plugin in letzter Zeit irgendwann ein Update, das mir diese Einstellung „unbemerkt“ überschrieben hat? Ich bin ganz sicher, dass ich damals bei der Ersteinrichtung die Version aus dem Wiki genommen hatte.
Das wäre zumindest eine brauchbare Erklärung für den jetzt beobachteten Effekt 
Viele Grüße
Michael
Hallo Michael,
genau so ist es. Es gibt jetzt 3.11. Da muss ich also wieder ran, denn leider habe ich auf meinen Vorschlag, meinen Patch generell einzupflegen, noch nicht mal eine Antwort erhalten.
Immerhin gibt es einen Fix für leere Gruppen, das war gerade bei uns ein Problem.
Ich würde an Deiner Stelle erst mal Downgraden (vermutlich einfach die Dateien ersetzen und als Admin anmelden).
Beste Grüße
Jörg
Ok – dann lade ich das Plugin aus dem Wiki mal neu hoch … wie schätzt du die Lage bzgl deines nächsten Updates ein? Kannst Du das dann hier bekannt geben?
Leider war das nicht erfolgreich:
Ich bin wieder zurück auf Version
local_ldap_moodle42_2023022701.zip(unsere moodle-Version ist übrigens noch Moodle 3.11.14+)
Hallo Michael,
vermutlich ist ein Downgrade möglich, indem man die Versionsnummer manipuliert, aber das einfach auszuprobieren ist vielleicht nicht die beste Idee. Ich schaue mal, wann ich dazu komme.
Herzliche Grüße
Jörg
Hallo Michael,
nachdem ich in den nächsten Tagen keine Zeit hab, habe ich mich lieber gleich daran gesetzt. Die neue Version ist hier zu finden:
Bislang war mein einziger Test, dass bei unserem Belwü-Moodle die Gruppen durch die neue Version nicht verändert wurden. Nachdem meine Änderungen aber nur minimal sind und zweitens nur darauf Einfluss haben, welche Gruppen gesynct werden, und nicht, wie genau das gemacht wird, gehe ich davon aus, dass das so passt.
Beste Grüße
Jörg
1 „Gefällt mir“
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:
… und die Projekte werden ebenfalls wieder richtig synchronisiert:
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
2 „Gefällt mir“
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
1 „Gefällt mir“
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