Moodle: Profilfeld-basierende Zuweisung globaler Gruppen verschluckt sich

Hallo zusammen,

wie in diesem Post beschrieben, verwenden wir in unserem BelWü-Moodle das Plugin „Profilfeld-basierende Zuweisung globaler Gruppen“ um automatisch Klassengruppen anzulegen. Das funktioniert(e) so weit auch wunderbar.

Nun ist es bereits zum zweiten Mal vorgekommen, dass Schüler:innen durch dieses Plugin aus Gruppen entfernt werden, obwohl sie noch in der entsprechenden Klasse sind. Ändere ich nur eine Kleinigkeit an einem der Filter und speichere die Filterliste erneut ab, werden alle Klassengruppen wieder richtig befüllt.

Hat dieses Phänomen noch jemand beobachtet und gibt es dafür eine Lösung?

Viele Grüße
Christoph

Hallo zusammen,

leider ist dieses Problem bei unserem BelWü-Moodle im Zusammenspiel mit der LMN7 erneut wiederholt aufgetreten. Betrifft das denn sonst keinen hier? Die Kombination scheint ja nicht so selten zu sein.

Viele Grüße
Christoph

Hallo Christoph,

stimmt denn zum Zeitpunkt des Entfernens das Profilfeld noch oder ist das auch falsch? Besteht die Möglichkeit, dass die SuS den Inhalt des Profilfeldes ändern oder ist es gesperrt? Wird es bei jedem Login aktualisiert oder nur beim Anlegen?

Viele Grüße
Sven

Hallo Sven,

der Inhalt des Profilfeldes sollte stimmen. Das Feld kann nicht von den Schüler:innen bearbeitet werden und wird bei jedem Login aktualisiert.

Immer, wenn ich bei betroffenen Schüler:innen das Profilfeld überprüfe, stimmt der Inhalt. Der Cronjob hat in der Zwischenzeit auch schon etliche Male gewerkelt, die Schüler:innen jedoch nicht wieder der globalen Gruppe hinzugefügt, obwohl der Inhalt des Profilfeldes in Ordnung ist.

Erst nachdem ich einen der Filter leicht abändere, läuft der Cronjob wieder wie gewohnt durch und fügt die fehlenden Schüler:innen den Gruppen hinzu. Das ist ja das Seltsame.

Spätestens nach einigen Tagen fliegen aber wieder Schüler:innen aus den Globalen Gruppen und das Spiel beginnt von vorne.

Viele Grüße
Christoph

Hallo Christoph,

das Plugin lauscht auf Events wie „User wurde verändert“ oder „User login“ und gleicht dann alles ab. Insofern wäre es interessant, ob im Fehlerfall beim Login alles wieder repariert wird.

Der Cronjob wird nur aktiv, wenn die Regeln auf der Einstellungsseite geändert wurden. Das passt zu Deiner Beobachtung. Es gibt leider keinen Cronjob, der eine Art Komplettinventur macht - wäre vielleicht mal ein Feature Request.

Wenn ich das richtig sehe, kann man den Cronjob relativ einfach entsprechend umbauen: Es müsste reichen, in der Datei classes/task/update_cohorts.php ganz unten die if-Anweisung zu deaktivieren. Wäre natürlich nur ein Workaround bis zum nächsten Update.

Beste Grüße

Jörg

Hallo. Ich wärme diesen Thread mal kurz wieder auf, da ich heute eine Nachricht bekommen habe, mit der ich zunächst nichts anfangen konnte. Eine Kollegin schrieb mir, dass sie momentan keine Nachrichten nur an die Schüler schicken kann. Wenn man in einem Kurs unter „Rollen“ → „Schüler“ auswählt, bleiben die eingeschriebenen Lehrer ebenfalls erhalten. :thinking:

Ein Blick auf die Liste der eingeschriebenen User pro Klasse zeigte dann, dass z.B. in Klasse 5a über die globale Gruppe 5a sowohl die SuS als auch die entsprechenden LuL eingeschrieben wurden.

Ein weiterer Blick in die Nutzerliste pro Kurs bestätigte dann, dass alle Lehrer sowohl mit der Rolle Lehrer als auch mit der Rolle Schüler eingeschrieben sind. Das darf offenbar so nicht sein. Man kann die Lehrer auch nicht einfach aus der Rolle „Schüler“ wieder rauswerfen (aufgrund der Einschreibung über eine globale Gruppe).

Ich kann nicht mehr genau reproduzieren, seit wann das der Fall ist aber das war ganz sicher nicht immer so. Eigentlich läuft die Zuweisung, wer in die globale Gruppe 5a kommt über ein profilbasiertes Feld. Ich habe dazu das Feld „homeDirectory“ genommen, da das eindeutig ist. So sollten in die globale Gruppe 5a eigentlich nur die Schüler der 5a gelangen – nicht aber die Lehrer.
Hat jemand eine Idee, durch welchen Vorgang sich das umgestellt haben könnte?

Viele Grüße,
Michael

Das ist normal so dass ein trainer in seinem kurs auch die schueler rolle hat, wuerd ich jetzt so aus dem stand sagen.
Man kann das ja wechseln als trainer in dem man die rolle eines schuelers annimmt und dann kann man auch als lehrer eine aktivitaet aufgabe oder einen trst bearbeiten und bewerten lassen

Das ganze hat m.E.gar nix mit globalen gruppen zu tun. Das ist auch so wenn du zwei trainer in nennkurs manuell einschreibst. Mal testen?

Nein – das war hier bisher definitiv nicht so und ich habe die Cronjobs zur profilbasierten Zuweisung globaler Gruppen nochmal genau verfolgt. Ich habe in den Einstellungen eine Kleinigkeit geändert und dann nochmal gespeichert. Nun ist es scheinbar vorerst wieder in Ordnung: In der globalen Gruppe 5a sind jetzt nur noch die Schüler und nicht mehr die Lehrer. Diese kommen über eine andere Gruppe in den Kurs (Fachlehrer_5a). Nur so ist die Trennung der Gruppen automatisch möglich … vorerst läuft es also wieder. Ich denke, dass es auch hier daran lag, dass sich das Plugin irgendwo verschluckt hat?!?

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 :frowning:
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 :+1:
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 :slight_smile:

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:

https://wiki.linuxmuster.net/community/anwenderwiki:webapps:moodle:moodle_extern_ldap:start#ldap-gruppen_mit_globalen_gruppen_in_moodle_syncen

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“