vielleicht kann mir mal einer die „Blackbox“ der Nutzerverwaltung erklären. Ich importiere über den Listenimport einen Schüler, der zwar schon einmal im System war, aber nun
einen neuen Nachnamen hat (Schreibfehler)
dadurch ergäbe sich eigentlich auch ein neuer Benutzername (Schreibfehler in den ersten 6 Stellen)
eine neue Klasse besucht und
eine neue ID zur identifizierung hat (ASV-ID)
Trotzdem wird der alte Benutzer herausgeholt und auf diesen Schüler gemappt. Das ist zwar von der Sache her in diesem Fall richtig, aber ich verstehe nicht, wie die Zuordnung vorgenommen wird. Identisch sind ja im Prinzip nur Vorname und Geburtsdatum. Das kann ja auch schnell mal schiefgehen, oder? Und: Wozu setze ich dann überhaupt beim Listenimport das Häkchen bei CSV laden → Spalten überprüfen → „CSV contains custom student ID attribute“,
wenn die Benutzerverwaltung dann doch nach anderen Kriterien entscheidet?
Und wenn wir schon dabei sind: Was bringt eigentlich der sophomorix user-kill.log? Wenn ein Schüler den ganzen Ablauf hinter sich hat (tolerated → disabled → removable → killed), dann will ich ihn doch nicht wieder aus dem Grab heraufholen, genau das macht aber Sophomorix indem es sich den Benutzernamen merkt und bei Neuanlage oder gleichem Benutzernamen eine Ziffer hinten anhängt. Wieso werden gekillte Schüler nicht ganz aus dem System entfernt?
Oder kurz gefragt: Spricht etwas dagegen, diesen log nach jedem Import zu löschen, damit Nutzernamen immer nur gegen bestehende Nutzer durchnummeriert werden?
bei der Änderung von mehr als 3 Buchstaben im Namen bekommt der Nutzer einen neuen Benutzernamen und damit ein neues Profil.
Wenn sich z.B. durch Heirat der Nachname ändert, kann man diesen über mehrere Schritte anpassen ohne das sein Profil geändert wird.
Trotzdem: wäre es nicht wünschenswert, bei einer neuen ASV-ID auch einen neuen Benutzer anzulegen, zumal die Option ja mit dem o.g. Häkchen angeboten wird?
das merken schon einmal vergebener Usernamen ist kein Unfall und ergibt Sinn, wenn man bedenkt, dass einige andere Dienste angebunden haben wie nextcloud oder mails oder moodle.
Wenn dort der gekillte user nicht automatisch auch gelöscht wird, dann wird das gerne vergessen.
Am Beispiel der nextcloud bekäme dann der neue Nutzer, der den usernamen wiederverwendet die Daten des alten Nutzer präsentiert: nicht gerade ein wünschenswertes Szenario …
Also: du kannst die Datei natürlich löschen, wenn du magst: bedenke aber die möglichen Nebenwirkungen.
Und zu den „Schreibfehlern“ der User, die dann neue Usernamen bewirken: ein leidiges Problem.
Die normale Toleranz, wie Steffen schreibt, beträgt 3 Buchstaben: kann aber auch hochgesetzt werden.
Meist sind das bei mir plötzlich auftauchende zweite Vornamen im Export, die im Jahr danach auch wieder verschwinden …extrem ärgerlich …
Ich füge dann 3 Buchstaben des „neuen“ Vornamens hinzu, mache check und update, dann die nächsten 3 … meist reicht das.
Fällt er weg, nehme ich den alten Zweiten Vornamen rein bis auf die letzten drei Buchstaben, mache check und update, dann wieder 3 usw.
Vielen Dank für die Infos zur Logdatei. Jetzt verstehe ich den Sinn dahinter und kann gezielt entscheiden.
Meine ursprüngliche Frage ist allerdings noch offen. Genau vor dem besprochenen Hintergrund (neue User dürfen nicht an Daten von anderen, alten Usern kommen) macht es mich etwas nervös, wenn ein Schüler mit einer neuen ID und einem (mit einem Buchstaben) geänderten Namen auf ein gelöschtes Konto gematcht wird. Sehe ich das richtig, dass das Feature mit der ID noch gar nicht richtig umgesetzt ist? Dann kann ich mir den Punkt beim Import nämlich sparen.
das funktioniert schon richtig, wenn du den empfohlenen Weg beschreitest.
Also die students.csv verwendest und den Mechanismus der die Usernamen erschafft.
Einzelne Rechtschreibfehler bewirken da nichts: auch wenn der Username sich ändern sollte, weil in den ersten 4 Buichstaben des Nachnamens ein Schreibfehler ist: der wird geändert im AD, also der Vorname wird dort dann richtig stehen, aber der Username bleibt der, der er war, auch wenn er dann nciht mehr dem Mechanismus entsprechen würde…
Die ID tut das ihrige: es funktioniert wie es soll.
sorry, das verstehe ich nicht. Ich denke schon, dass wir den empfohlenen Weg einhalten, der wie folgt aussieht:
Export der Schüler aus ASV inkl. der ASV-ID
Import der Liste über die Schulkonsole > Listenverwaltung > CSV > CSV laden > Spalten überprüfen
Setzen des Hakens bei "CSV contains custom student ID attribute (optional) "
Die Spalte mit der id wird richtigerweise mit id betitelt
Sortierung akzeptieren
Speichern und prüfen
Meinem Verständnis nach sollte die ID nun verwendet werden, um Schüler eindeutig zu identifizieren, sprich wenn ich einen Schüler mit einer noch nie vorhanden gewesenen ID importiere sollte dieser auf jeden Fall ein neues Benutzerkonto bekommen. Und das ist eben nicht so, sondern er bekommt anhand anderer Attribute und des Mechanismus ein altes, gelöschtes Konto (welches eben vielleicht nur zufällig in diesem Fall tatsächlich seines war).
Wahrscheinlich stehe ich irgendwo auf dem Schlauch, vielleicht kannst du mir runterhelfen…
Ich bin zwar nicht sicher, aber ich denke, dass die ID, die Du zum Import verwendest nicht verwendet wird, um den Vorgang eindeutig zu machen!
Bei uns war es (aus „historisch gewachsenen Gründen“) immer so, dass wir Schüler-IDs mit 8 Ziffern hatten. Die letzte Ziffer war dabei aber immer nur eine Kontrollnummer (ähnlich wie bei der ISBN von Büchern). Das haben wir in diesem Schuljahr wieder abgeschafft und sind für alle Schüler auf eine ID mit 7 Ziffern gegangen, damit es auf allen Systemen einheitlich ist. Daher musste ich in die geänderte students.csv neu importieren und schauen was geschieht: die Logins sind alle so geblieben wie sie waren aber das Feld für die (externe) ID wurde problemlos geändert!
Ich habe das allerdings komplett über die Konsole gemacht, daher kann ich zu der Option „Custom“ nichts sagen. Aber ich denke, dass die ID, die es eindeutig macht, eine andere ist
Du kannst Dir ja mal die Ausgabe von
sophomorix-user -iu
ansehen.
Viele Grüße
Michael
wenn ich die Ausgabe über sophomorix-user -iu mache erscheint die importierte ASV-ID unter „sophomorixUnid“ - hört sich für mich so an, als ob das die identifizierende ID sein sollte, oder?
… das kann ich nch nciht vollständig nachvollziehen.
Vorab: die ID funktioniert natürlich nur, wenn sie schon im AD ist un dincht, wenn das erste mal mit IDs importiert wird.
Ich hab damals z.B. die IDs erst mitten im Schuljahr eingeführt. Da hab ich eine neue schueler.csv Datei genommen MIT IDs und die dann importiert.
Ein sophomorix-update hat dann bei allen die IDs eingetragen (… FunFact: beim nächsten Schuljahreswechsel kam dann raus, dass die Realschule ihre Datei leider bearbeitet hatten und deswegen alle IDs um eine Zeile verschoben waren … hahaha … wie lustig … also hab ich alle IDs rausgenommen, check und update gemacht, dann wieder richtig reingenommen ud wieder check und update: dann standen die richtigen drin).
Das sollte einfach erklären, wo die IDs sein müssen, damit sie funktionieren können.
Jetzt zu deinem Fall:
es kann erstmal nciht „ohne weiteres“ passieren, dass ein neuer User, den Login eines gelöschten bekommt. Dein User war also nciht gelöscht, nehme ich an, sondern nur deaktiviert oder im Dachboden.
Und dann zum „in diesem Fall zufällig der gleiche …“
Aber dann ist doch alles richtig? Selbst wenn er vorher keine ID hatte, dann hat sophomorix erkannt: „Ach schau, der Peter Altmeier mit Geb. Datum 1.1.2001 ist wieder da: und jetzt hat er auch eine ID“ und hat ihn aus dem Dachboden geholt und die ID verpaßt.
Oder er hatte vorher schon die ID: auch dann ist doch alles richtig.
Kannst du einen Fall schildern, bei dem es falsch gelaufen ist?
Ich schließe nicht aus, dass die Auswertung der ID möglicherweise nicht so „hart“ ist, wie wir uns das manchmal wünschen würden. Ich kann noch nciht sagen, dass es so ist, aber auch nicht, dass es nicht so ist. Ich bin noch am Forschen
LG
Sophomorix versucht beim Check, die User aus den Dateien mit den Usern aus dem System zu matchen. Wenn in einer Datei eine UID steht, dann wird nachgesehen, ob es im AD einen User mit dieser ID gibt. Wenn ja, dann ist das ein Match. Wenn nein, dann ist das kein Match und es wird anderweitig versucht, ein Match zu finden. Der zweite Schritt ist ein Loginname in der Datei, danach greift die Heuristik.
Wenn also eine neuer User mit einer komplett neuen ID kommt, dann wird es in den ersten beiden Schritten kein Match geben. Also greift die Heuristik. Und wenn es dann im System einen ähnlichen User gibt, dann kann das ein Match geben - auch, wenn der User deaktiviert ist.
Würde Sophomorix ausschließlich nach den UIDs gehen, dann könnte man nie nachträglich eine UID ergänzen oder ändern - sonst hätte man ja lauter neue User. Das überwiegt gegenüber vereinzelten falschen Matches.
Natürlich könnte man auch strikt nach UIDs gehen, aber Sophomorix macht das nicht.
danke für die Infos. Ich habe die ID immer als Primärschlüssel verstanden und käme nicht auf die Idee, die ändern zu wollen. In ASV ist es ja auch so: Neue ID = neuer Schüler, auch wenn der vielleicht schon mal in einer anderen Schulart an der Schule war. In welchen Fällen ist es denn eigentlich notwendig, die UID zu ändern?
In Linuxmuster haben wir es gerade nochmal getestet. Hier mal ein mögliches Testsetting:
Marie Müller (muellema), geboren am 08.07.1997, ehemals Klasse 1lo1, jetzt gelöscht mit Status „D“
Maria Müller, geboren am 01.01.1997 wird neu importiert in Klasse f1a, natürlich eine andere ASV-ID als Marie
Preisfrage: wie entscheidet Sophomorix? Es stellt den Account wieder her und
ändert den Vornamen von Marie auf Maria
ändert die Klasse von attic auf f1a
ändert das Geburtsdatum vom 08.07.1997 auf den 01.01.1997
Diese Konstellation ist meines Erachtens nicht so unwahrscheinlich, vor allem wenn jemand lange Toleranzzeiten eingestellt hat. Und dann bekommt eben die Maria die digitale Identität von der Marie…
für welches Szenario welche Herangehensweise sinnvoll ist - da gibt es viele Aspekte. Aber Du wolltest ja wissen, wie es funktioniert.
Bei Deinem Beispiel vermutet Sophomorix, dass der erste Datensatz früher mal fehlerhaft war und nun korrigiert wurde.
Das ist bei vielen Szenarien durchaus sinnvoll. Oftmals wird die UID nachträglich eingepflegt oder ändert sich aus irgendeinem Grund, zum Beispiel bei einem Wechsel des Schulverwaltungsprogramms - in BW vermutlich erst mal nicht mehr so schnell, aber es gibt ja auch Schulen außerhalb von BW. Und Fehler bei Namen und Geburtsdaten kommen natürlich dauernd vor. Da ist dieser Ansatz schon gar nicht so blöd. UIDs in der Schulverwaltung gibt es bei unserer Schule deutlich kürzer als Linuxmuster.
Natürlich gibt es auch Szenarien, bei denen es sinnvoll wäre, die UID als echten Primärschlüssel zu nehmen. Vor allem dann, wenn man von Anfang an alles sauber einpflegt.
Mach doch mal ein Feature Request: Eine Option bei Sophomorix „UID=PrimaryKey“. Vielleicht setzt es ja jemand um.
D bedeutet: deaktiviert
Die Hierarchie ist:
benutzbar → tolleriert → deaktiviert → killbar (removeable)
mit den Buchstaben:
A → T → D → R
Der „alte“ user war also noch zwei SChritte vom löschen entfernt und damit durchaus noch im System.
Aber trotzdem sollte er nciht so reaktiviert werden: schon garnicht, wenn die ID nicht stimmt.
Vielelicht bezieht sophomorix, wenn ein user deaktiviert ist, beim matching Geb. Datum und ID nciht mehr mit ein?
Das würde ich als Fehler ansehen.
Ich würde dir empfehlen erstmal die alten Nutzer zu löschen: dann kann das auch nciht mehr passieren.
ja, ich wollte das System besser verstehen, was ich dank eurer Hilfe nun auch tue. Aber mir geht es auch darum, zu sensiblisieren und vielleicht auch zu dokumentieren. Nicht jeder kennt Linuxmuster/Sophomorix länger als ASV und ich finde schon, dass man die Option „CSV contains custom student ID attribute“ so verstehen kann, dass es sich um ein wirklich „identifizierendes“ Attribut handelt.
Ich bin an der Stelle halt auch ein gebranntes Kind, weil ich (durch eigene Dummheit) es schon geschafft habe, einem Nutzer sensible Daten seines „Benutzernamensvetters“ zugänglich zu machen.
Ich habe aber auch verstanden, dass Sophomorix aus guten Gründen so funktioniert, wie es funktioniert und kann das nun gut handlen. Den Feature Request werde ich trotzdem einreichen.
der Vollständigkeit halber: wenn man beim Geburtsdatum nicht nur Tag und Monat sondern auch das Jahr ändert, spuckt Sophomorix einen neuen Nutzer aus. Das System funktioniert also schon sehr gut, und meine Bedenken hinsichtlich ID sind ja nun ausreichend diskutiert.
