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).
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.
Hallo zusammen,
zunächstmal möchte ich mich entschuldigen, dass ich erst jetzt antworte. Ich habe heute nochmal das schöne Wetter ausgenutzt
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:
Über ldap_sync die Benutzer mit der lmn 7.2 abgleichen.
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
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
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
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 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.
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“?
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!
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.
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.
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 ) 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.
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.
… 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).
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 …
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.
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.
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
Gruß,
Mathias
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
Nichtmal nachdem ich den Cache geleert habe.