Moodle: Gruppenzugehörigkeit wird nicht syncronisiert

Hallo Jörg,

Vorher müssen die Mitglieder einer LDAP-Gruppe in die Globale Gruppe
gelangen. Da es dafür mehrere Möglichkeiten gibt, müsstest Du kurz
posten, wie Du das machst. Denkbar wäre, das anhand eines Profilfeldes
zu machen oder mit den LDAP Syncing Scripts.

ich mach das anhand eines Profilfeldes (weil alles andere irgend wann
immer wieder aus irgend welchen Gründen nicht funktioniert hat).

LG

Holger

Hallo Holger,

dann sollten die Profilfelder selbst spätestens über Nacht passen. Der Task, der dann die Leute in die Globalen Gruppen packt, wird dadurch leider nicht getriggert, dazu hatte ich in einem anderen Thread letztens was geschrieben. Man muss im Code eine Abfrage auskommentieren, dann klappt das. Ich bin gerade in Eile, sonst würde ich es heraussuchen.

Beste Grüße

Jörg

Hallo zusammen,
zunächstmal möchte ich mich entschuldigen, dass ich erst jetzt antworte. Ich habe heute nochmal das schöne Wetter ausgenutzt :slight_smile:
Und ich möchte mich bei allen bedanken, die hier schon etwas gepostet haben!!!

@jrichter Ich bin genau so vorgegangen, wie es hier im Wiki beschrieben wurde:

  1. Über ldap_sync die Benutzer mit der lmn 7.2 abgleichen.
  2. Mit den LDAP-syncing-skripts die Gruppen synchronisiert. Damit gibt es in Moodle auch die Gruppen der lmn.

Das klappt auch alles super. Nur werden die Gruppenzugehörigkeiten nach dem Versetzen der Schüler nicht mehr geändert :frowning:

Und genau diese Thread finde ich nicht mehr. Könntest du mir nochmal den Thread nennen oder einen Link hier posten? Ich hab mir damals gedacht, dass ich das ausprobiere, wenn ich die Schüler versetze.
Vielen Dank schon mal!
Gruß,
Mathias

Hallo Mathis,

das beschriebene Problem hat mit einem anderen Plugin zu tun, das die Globalen Gruppen aus den Profilfeldern zusammenstellt.

Läuft denn der Task zu den LDAP Syncing Sripts durch, und wenn ja, was sagt das Log?

Beste Grüße

Jörg

Hallo Jörg,

Der Name LDAP Syncing Scripts kommt so nicht vor. Bei mir laufen die Skripts

Synchronisierung von LDAP-Nutzerkonten :

Execute scheduled task: Synchronisierung von LDAP-Nutzerkonten (auth_ldap\task\sync_task)
... started 22:05:01. Current memory use 29.8 MB.
Zum LDAP-Server verbinden ...Temporäre Tabelle tmp_extuser erstellen.......................................................................................................................................................................................................................................................................................................................................................................................................................................................................455 Datensätze von LDAP eingelesenKeine Nutzerkonten zum Entfernen gefundenKeine Aktualisierung nötigNutzerkonten zum Hinzufügen: 1	Eingefügte Nutzer/in ludwig ID 630
... used 482 dbqueries
... used 0.43938302993774 seconds
Scheduled task complete: Synchronisierung von LDAP-Nutzerkonten (auth_ldap\task\sync_task)

Synchronize cohorts from LDAP groups:

Execute scheduled task: Synchronize cohorts from LDAP groups (local_ldap\task\group_sync_task)
... started 22:15:01. Current memory use 33.3 MB.
... used 1490 dbqueries
... used 0.92861795425415 seconds
Scheduled task complete: Synchronize cohorts from LDAP groups (local_ldap\task\group_sync_task)

Allerdings muss ich sagen, dass ich local_ldap zunächst deinstalliert habe und dann die LDAP Syncing Sripts nochmals installiert habe. Jetzt wurden die Gruppenzugehörigkeiten korrekt angepasst.
Lautr deines Threats ist das aber klar. Spannend wirds, wenn Schüler von einer Klasse in eine andere versetzt werden.
Gruß,
Mathias

Hallo,

dann sollten die Profilfelder selbst spätestens über Nacht passen. Der
Task, der dann die Leute in die Globalen Gruppen packt, wird dadurch
leider nicht getriggert, dazu hatte ich in einem anderen Thread letztens
was geschrieben. Man muss im Code eine Abfrage auskommentieren, dann
klappt das. Ich bin gerade in Eile, sonst würde ich es heraussuchen.

das war wohl in diesem Tread:

LG

Holger

Hallo Mathis,

das ist der richtige Task: local_ldap\task\group_sync_task

Der packt die User aus den LDAP-Gruppen in die Globalen Gruppen. Das funktioniert bei mir aber zuverlässig auch zwischendurch. Wenn Du das von mir modifizierte Plugin aus dem Wiki nimmst, dann steht etwas mehr in den Logs.

Beste Grüße

Jörg

Hallo Jörg,

du schreibst damals:

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.

nun kann ich aber nicht programmieren.
Im plugin-cron script
/…/moodle/local/profilecohort/classes/task/update_cohorts.php steht am
Ende:

     public function execute() {
         if (get_config('local_profilecohort', 'updatecohorts')) {
             $manager = new profilecohort();
             $manager->update_all_cohorts_from_rules();
             set_config('updatecohorts', false, 'local_profilecohort');
         }
     }

jetzt soll ich die if Anweisung auskommentieren.
Mach ich das so?

     public function execute() {
//        if (get_config('local_profilecohort', 'updatecohorts')) {
             $manager = new profilecohort();
             $manager->update_all_cohorts_from_rules();
             set_config('updatecohorts', false, 'local_profilecohort');
//        }
     }

?

Also nur die „if“ Zeile und die unten zugehörige „geschweifte Klammer zu“?

LG

Holger

Hallo Holger,

ja, genau. Das hatte ich letztens so ausprobiert und es läuft gut:

https://ask.linuxmuster.net/t/profilbasierte-zuweisung-zu-globalen-gruppen/10237

Herzliche Grüße
Jörg

Hallo Jörg,
komischer Weise gibt es bei mir die Datei/…/local/profilecohort/classes/task/update_cohorts.php nicht?!? Die Datei update_cohorts.php existiert im ganzen Container nicht?!?
Es sieht so aus, als ob bei mir ein Plugin fehlen würde.

Ich sags gleich, ich bin heute den ganzen Tag nicht da. Ich kann also erst wieder heute abend antworten. Das heißt also nicht, dass ich kein Interesse an deiner Antwort hätte. Ganz im Gegenteil!

Gruß,
Mathias

Hallo Mathias,

wie im anderen Thread beschrieben, läuft es bei mir auch ohne Manipulation von Dateien aber dafür mit etwas Geduld (24h?).
Es kann aber auch sein, das ich hier einen etwas anderen Weg gehe, darum beschreibe ich mal kurz, wie ich das für die kleine Schule mit 6 Klassen mache.

  • Bei den Einstellungen beim LDAP-Plugin im Feld Daten übernehmen (Klasse/Lerngruppe) steht sophomorixAdminClass
  • Ich lege die Klassen als globale Gruppen mit Schuljahresbezeichnung an, also z.B. 5a (23/24), 6a (23/24) usw.
  • Dann „aktiviere“ ich diese Gruppen unter * Profilfeld-basierende Zuweisung globaler Gruppen im Reiter „verwaltete Gruppen“
  • Jetzt kann die Zuordnung über die Profilfeld neu vorgenommen werden:

    usw.

Und danach hatte ich mich mehrmals mit den „geplanten Tasks“ auf dem Moodle-Server verausgabt (Protokolle gelesen, Zeiten verändert usw.). Aber letztendlich ging es auch dieses Jahr von allein.

VG
Christian

Hallo zusammen,
ich habe jetzt testweise einen Schüler in eine andere Klasse versetzt, die Cron-Jobs Synchronisierung von LDAP-Nutzerkonten (\auth_ldap\task\sync_task) und Synchronize cohorts from LDAP groups (\local_ldap\task\group_sync_task) nacheinander nacheinander ausgeführt.
Und siehe da, es hat geklappt. Auch das Zurückversetzen hat geklappt.

Nur leider weiß ich nicht warum. Ich habe moodle vor 2 Monaten aufgesetzt und einen ähnlichen Test durchlaufen lassen. Damals hat auch alles geklappt. Und dann, als ich alle (ok, fast alle :wink: ) Schüler versetzt hatte hat’s nicht mehr geklappt.

@jrichter Jörg, du als Moodle-Spezialist, kannst du dir vorstellen, was da schief gelaufen sein könnte? Ich befürchte, irgendwann wird mich dieses Problem wieder einholen.

Gruß,
Mathias

Hallo Mathias,

schön, dass es klappt!

Dass es zwischendurch nicht lief, kann viele Ursachen haben. Leider sind die Logs der Plugins oft nicht sehr hilfreich, bei meiner Version der Ldap Syncing Scripts wird etwas mehr ausgegeben, da hat man eher Chancen, ein Problem zu erkennen. Und es greifen halt mehrere Mechanismen ineinander, da kann es an ganz vielen Dingen liegen.

Beste Grüße

Jörg

Hallo,

… noch eine Frage:
ich verwende das profilbasierte cohort plugin: ist zu dessen Betrieb das
Plugin LDAP syncing scripts den nötig?
Das hab ich nicht mehr drin.
Liegt es daran, dass meine Schüler in den falschen Klassen sind?

Ich hab das rausgeschmissen wegen des „Lehrer der Klasse 5a ist auch
Schüler der 5a“ Problems.
Sollte ich das wieder nehmen müssen, würde ich Jörgs Pluginversion
nehmen, da das die Klassen nciht mehr synct (wenn man es richtig einstellt).

LG

Holger

Hallo Christian,

  • Ich lege die Klassen als globale Gruppen mit Schuljahresbezeichnung
    an, also z.B. 5a (23/24), 6a (23/24) usw.

… dann hast du aber für jedes Jahr neue globale Gruppen …
Ich verstehe den Vorteil: die Gruppen sind erst mal leer und werden dann
wieder befüllt.
Was machst du mit den alten?
Löschen?
Ist das nicht viel Handarbeit?
Du mußt alle neuen globalen Gruppen anlegen und alle alten löschen …
jedes Jahr …

Am anderen Ende behebt es natürlich ein weiteres Problem: wenn ein
Lehrer „jetzt“ (in den Sommerferien) nicht die globale Gruppe aus seinem
Kurs wirft, dann sind die Schüler (bei mir) weiterhin drin: nur eben die
„Neuen“.
Bei dir nicht …

LG

Holger

Hallo Holger,

ich verwende das profilbasierte cohort plugin: ist zu dessen Betrieb das
Plugin LDAP syncing scripts den nötig?

Nein, das brauchst Du nicht.

Liegt es daran, dass meine Schüler in den falschen Klassen sind?

Schau doch mal bei einem betroffenen Schüler, ob im Profilfeld die richtige Klasse steht. Wenn nein, dann läft der LDAP-Sync-Job nicht richtig. Wenn ja, dann läuft das profilbasierte Cohort Plugin nicht richtig - dort musst Du ja die besagte if-Abfrage auskommentieren.

Beste Grüße

Jörg

Hallo Holger,

ja, es ist Handarbeit und vielleicht auch ein Spezialfall für eine Schule mit nur 6 Klassen.
Ich musste erst nochmal nachdenken, woher die Schuljahresbezeichnungen bei den Klassen kommen, aber es war schon genau so, wie du beschrieben hast. Die Kollegen kümmern sich nicht mehr um ihre Kurse, wenn das Schuljahr vorbei ist und dann würden bei gleichbleibenden Klassenbezeichnungen Schüler in die Kurse wandern, die dort nicht hingehören. Ich verschiebe diese Kurse in den Sommerferien in einen Bereich Archiv und lösche sie aber erst endgültig in den Herbstferien. Bis dahin wären die Schüler in irgendwelchen Kursen, die sie gar nicht betreffen.

LG
Christian

Hallo Jörg,

Dachte ich mir. Wenn alles läuft, ist es halt schwer, Ursachen für ein mögliches Nichtfunktionieren zu erkennen.
Nochmals vielen Dank für deine Hilfe und für dein erweitertes Plugin :wave:
Gruß,
Mathias

…. nur ganz kurz: dafür gibt’s doch auch ein Plugin…. Ich lösche damit hunderte globaler Gruppen in einem Rutsch …

Hallo zusammen,
ich habe jetzt mit local_profilecohort reine Klassengruppen, wie hier unter Feintunig beschrieben, angelegt. Also die Gruppe Klasse_10a enthält alle Schüler der 10a, aber keinen Lehrer. Die Gruppe 10a, die wie bisher mit local_ldap\task\group_sync_task angelegt wurde enthält die Schüler und die Lehrer.

Klappt zunächst super. Dann habe ich testweise einen Schüler von der b- in die a-Klasse versetzt. In der Gruppe 10a ist wie es sollte. Der Schüler ist jetzt in der Gruppe 10a.
Aber in der Gruppe Klasse_10a ist er nicht :frowning:
Nichtmal nachdem ich den Cache geleert habe.

@jrichter Jörg hast du mir einen Tip?

Gruß,
Mathias