Open kroerig opened 10 months ago
Auch ErzieherBeiVolljaehrigkeitDeaktivieren=1
wird nicht übernommen.
Da hat sich möglicherweise im SVWS-Server was geändert. Wenn ich das im Debugger teste, bekomme ich die Fehlermeldung 400 (bad request), das hat früher funktioniert. Werde ich prüfen.
Ich sehe gerade, dass es um die Migration geht, hat also gar nichts mit dem Speichern in SchILD3 selbst zu tun. Ich habe in diesem Zusammenhang aber festgestellt, dass es beim Speichern von Ortsnamen mit Umlauten (als "Nachbarorte") zu der besagten Fehlermeldung 400 kommt. Das ist nun zumindest abgestellt.
Ja, nach der Migration scheint SchILD3 nur Defaultwerte anzuzeigen, obwohl die richtigen Einstellungen in der Datenbank stehen.
Testweise habe ich mal in SchILD3 einen Wert geändert: "0" Bei Telefonvorwahl für TK-Anlage eingetragen.
Der Wert kommt in EigeneSchule.Einstellungen
nicht an, oder ich schaue an der falschen Stelle.
Aber nach der Änderungen konnte ich SchiLD nicht mehr beenden. Und zwar durch diesen Fehler: https://github.com/SVWS-NRW/Schild3-BetaTest/issues/852
Ok, war die falsche Stelle, aber die Werte werden definitiv nicht migriert.
Die Einstellungen werden in ScHILD3 über die REST-API geladen (aus der Tabelle client_configuration_global), bei der Migration werden sie aber nicht dahin geschriebene. Der bisherige Speicherort "EigeneSchule.Einstellungen" ist aber noch vorhanden (war mir gar nicht bewusst). Man könnte nun in ScHILD3 eine Prüfung einbauen "Wenn keine Einträge in client_configuration_global vorhanden sind, dann lade aus "EigeneSchule.Einstellungen".
In der Tabelle client_configuration_global stehen bei mir trotzdem Werte drin. Allerdings nicht die Werte, die in der Schild2 DB unter eigeneSchule vorliegen. In der Tabelle eigeneSchule der migrierten MariaDB stehen die migrierten Werte richtig.
Sobald die Datenbank einmal mit SchILD3 geöffnet wurde, stehen da auch Werte drin, das sind dann deie Defaults. Bitte mal frisch migrieren, danach ist vermutlich die Tabelle client_configuration_global leer.
Stimmt, nach der Migration ist die Tabelle leer.
Aber eigentlich wäre das ja dann Aufgabe des SVWS Servers, die Werte bei der Migration an die richtige Stelle zu übertragen.
Dann könnte dieses Feld auch weg.
Klar könnte Schild3 beim Start schauen ob die Tabelle leer ist und, sofern vorhanden, die INI Datei von der alten Stelle übertragen.
Das muss ja auch dann noch funktionieren, wenn es den Desktopclient nicht mehr braucht.
Ich habe es jetzt erst mal so wie beschreiben umgesetzt
Ich bitte das Issue wieder zu öffnen.
Ausgelöst durch https://github.com/SVWS-NRW/SVWS-Server/issues/250#issuecomment-2378817205 da ich die Einstellungen nachgeschaut hatte, ist mir aufgefallen, dass in der aktuellen Version 3.0.91.15 die Maileinstellungen nicht (mehr?) übernommen werden.
Im SVWS Client wird der SMTP Server richtig angezeigt, die Einstellungen kommen bei der Migration also mit. Stehen auch in client_configuration_global.Einstellungen
unter AppName=Schild2, Schlüssel=Einstellungen.
Auch die Benutzereinstellungen stehen in der Tabelle BenutzerEmail
, wenn auch teilweise mit leeren Zeilen.
Auch die anderen Einstellungen stimmen nicht (mehr).
SchILD2:
SchILD3:
Flollowup zu https://github.com/SVWS-NRW/Schild3-BetaTest/issues/799, da nur Colaboratoren Issues wiedereröffnen können.
Die globalen Maileinstellungen werden auch in Version 3.0.78.14 nicht übernommen. In SchILD2 stehen sie auf "Direktes SMTP", nach der Migration stehen sie in SchILD3 auf "Mailprogramm" und die SMTP-Felder sind leer.
In der Datenbank steht:
Aber SchILD3 weiß nichts davon.