Univention Bugzilla – Bug 24947
Hinweis wenn Frontend-Paket aktualisiert/ein neues Modul installiert wurde
Last modified: 2012-12-12 21:07:47 CET
Derzeit können u.U. JavaScript-Probleme auftreten, wenn das Frontend oder Module aktualisiert oder nachinstalliert werden. Dabei wird der Timestamp für die JavaScript-/CSS-Dateien aktualisiert. Danach ist ein Refresh notwendig, da sonst noch nicht geladene JS-Dateien (insb. für neue Module) nicht geladen werden können, da sie unter dem alten Timestamp nicht mehr existieren. Um Irritation und evtl. inkorrekte Fehlermeldungen zu vermeiden, wäre es hilfreich, dem Benutzer einen Hinweis anzuzeigen, dass das Frontend-Paket aktualisiert wurde und ein Reload notwendig ist. Dies könnte bspw. durch einen Check auf die Verzeichnisse alle X sec geschehen.
Da das in "normalen" Umgebung nur bei Release Updates passiert und da sowieso Reboot empfohlen werden halte ich das nicht für so wichtig.
*** Bug 25236 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > *** Bug 25236 has been marked as a duplicate of this bug. *** Bug 25236 beschreibt einen alternativen Lösungsansatz
Das führt zu Problem bei größeren Updates aus der UMC heraus.
Mit einer Server-Abfrage könnte die Versionsnummer des installierten Frontend-Paketes mit der des im Cache befindlichen Paketes verglichen werden (umc.tools.status('version')), um diesen Mechanismus zu implementieren.
(In reply to comment #5) > Mit einer Server-Abfrage könnte die Versionsnummer des installierten > Frontend-Paketes mit der des im Cache befindlichen Paketes verglichen werden > (umc.tools.status('version')), um diesen Mechanismus zu implementieren. Der web-server könnte seine Versionsnummer im HTTP-Feld 'Server' mitsenden, die im Frontend dann mit umc.tools.status('version') verglichen werden kann.
(In reply to comment #6) > (In reply to comment #5) > > Mit einer Server-Abfrage könnte die Versionsnummer des installierten > > Frontend-Paketes mit der des im Cache befindlichen Paketes verglichen werden > > (umc.tools.status('version')), um diesen Mechanismus zu implementieren. > Der web-server könnte seine Versionsnummer im HTTP-Feld 'Server' mitsenden, die > im Frontend dann mit umc.tools.status('version') verglichen werden kann. In univention/management/console/protocol/server.py existiert dafür sogar schon code. Ein Aufruf von umcp/get/info liefert ein dict mit den benötigten Infos. Die HTTP Header-Variable sollte trotzdem gesetzt werden.
(In reply to comment #6) > Der web-server könnte seine Versionsnummer im HTTP-Feld 'Server' mitsenden, die > im Frontend dann mit umc.tools.status('version') verglichen werden kann. Finde ich eine sehr gute Idee.
Siehe auch ideen aus Bug #23142
Man kann auch get/modules/list um eine version für jedes Modul erweitern: {"status": 200, "modules": [{"description": "Systemstatistiken anzeigen", "name": "Statistiken", "priority": -1.0, "id": "mrtg", "categories": ["system"], "icon": "mrtg"}, ... -> {"status": 200, "modules": [{"description": "Systemstatistiken anzeigen", "name": "Statistiken", "priority": -1.0, "id": "mrtg", "categories": ["system"], "icon": "mrtg", "version": "2.0.3-TIMESTAMP"}, ... Neben modules: {...} könnte auch noch ein extra "version": "5.0.23-TIMESTAMP" für UMC selber zurückgegeben werden. Wenn sich das Frontend den anfänglichen Rückgabewert merkt (beim Laden der Module für die Übersicht) und den dann hin und wieder überprüft, sollte das ganz gut klappen. Mit "hin und wieder" meine ich explizit in "umc/lib/server.askRestart" (vielleicht mit einem weiteren Parameter if_needed: true). Es mag dabei noch mehr Pakete geben, die einen Restart auslösen sollten, z.B. univention-directory-manager-modules, oder?
(In reply to comment #7) > (In reply to comment #6) > > Der web-server könnte seine Versionsnummer im HTTP-Feld 'Server' mitsenden, die > > im Frontend dann mit umc.tools.status('version') verglichen werden kann. > In univention/management/console/protocol/server.py existiert dafür sogar schon > code. Ein Aufruf von umcp/get/info liefert ein dict mit den benötigten Infos. > Die HTTP Header-Variable sollte trotzdem gesetzt werden. Noch einmal drüber nachgedacht. Hilfreich wäre vielleicht doch ein eigener ucmp/get/server/info Aufruf oder so. Die Abfrage kann durchge
(In reply to comment #11) > Noch einmal drüber nachgedacht. Hilfreich wäre vielleicht doch ein eigener > ucmp/get/server/info Aufruf oder so. Die Abfrage kann durchge Ups... das Mitschicken im Header ist wahrscheinlich nicht hilfreich, da dies noch die alte Version wäre (UMC-Server wurde direkt nach einer Aktualisierung noch nicht neu gestartet). Deshalb eine Abfrage, die die aktuelle Version übermittelt (und ggf. in welcher Version der Server läuft). Dies kann auch hilfreich sein beim Öffnen eines neuen Moduls, wenn das Öffnen fehlschlägt, kann geprüft werden, ob eine neue Version vorliegt.
Im frontend wird ein Hinweis angezeigt, wenn das laden eines Moduls nicht funktioniert und beim Login wenn die js$hash$/umc/ Seite nicht mehr existiert. Im backend wurden keine Änderungen gemacht.
Mir ist noch aufgefallen, dass ich nach längere Zeit einen solchen Hinweis sehe, wenn ich allerdings auf "Abbrechen" drücke, kommt der gleiche Dialog noch einmal.
(In reply to comment #14) > Mir ist noch aufgefallen, dass ich nach längere Zeit einen solchen Hinweis > sehe, wenn ich allerdings auf "Abbrechen" drücke, kommt der gleiche Dialog noch > einmal. Nein, nicht unbedingt. Der Fehler ist, dass sich der Mechanismus nicht merkt, dass bereits ein Dialog offen ist. Deshalb legen sich nach und nach lauter Dialoge übereinander.
(In reply to comment #15) > (In reply to comment #14) > > Mir ist noch aufgefallen, dass ich nach längere Zeit einen solchen Hinweis > > sehe, wenn ich allerdings auf "Abbrechen" drücke, kommt der gleiche Dialog noch > > einmal. > > Nein, nicht unbedingt. Der Fehler ist, dass sich der Mechanismus nicht merkt, > dass bereits ein Dialog offen ist. Deshalb legen sich nach und nach lauter > Dialoge übereinander. Ist nun ein Singleton. Der Dialog wird allerdings wieder angezeigt, wenn z.b. auf Abbrechen geklickt wurde und wieder versucht wird ein Modul zu laden, was nicht mehr möglich ist. Aber das sollte so ok sein.
Jetzt wurde der Text in title gepackt. Dadurch ist der Dialog so breit wie mein Bildschirm
(In reply to comment #17) > Jetzt wurde der Text in title gepackt. Dadurch ist der Dialog so breit wie mein > Bildschirm Installier mal lieber die aktuelle frontend version ;)
Das funktioniert nicht notwendigerweise immer. Wenn ich umc_frontend_new_hash während einer Sitzung aufrufe und ein neues Modul öffne, kann das Modul zwar geladen werden (weil alle Abhängigkeiten schon initial geladen wurden), allerdings werden die Bilder nicht richtig dargestellt. Es könnte zusätzlich beim ersten (oder jedem) Öffnen eines Moduls im Hintergrund geprüft werden, ob sich die Version aktualisiert hat.
(In reply to comment #19) > Das funktioniert nicht notwendigerweise immer. Wenn ich umc_frontend_new_hash > während einer Sitzung aufrufe und ein neues Modul öffne, kann das Modul zwar > geladen werden (weil alle Abhängigkeiten schon initial geladen wurden), > allerdings werden die Bilder nicht richtig dargestellt. Es könnte zusätzlich > beim ersten (oder jedem) Öffnen eines Moduls im Hintergrund geprüft werden, ob > sich die Version aktualisiert hat. Ok, wird jetzt bei jedem Modulladen geprüft.
Es gibt immer noch einige Spezialfälle, in denen ein notwendiger Reload (noch) nicht angezeigt wird, und man deshalb Bilder nicht sieht. Im Normalfall wird das nicht geschehen, weil man nicht gezielt über umc_frontend_new_hash einen neuen Pfad der JS-Dateien erzeugt, sondern das im Rahmen eines Updates geschieht und danach ist ohnehin ein kompletter UMC-Neustart erforderlich. Die Fälle, die tatsächlich hin unnd wieder auftreten können (z.B. eine Installation eines neuen UMC-Moduls) werden korrekt erkannt. Changelog OK.
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".