Moritz Bunkus [Wed, 1 Mar 2017 12:46:34 +0000 (13:46 +0100)]
Dateimanagement: Stammdaten: DOM-Elemente bei multiples Tab-Aufrufen nicht duplizieren
Der Aufruf des Tabs »Dateianhänge« in den Artikelstammdaten liefert
einen Tab aus, in dem der HTML-Code für den Umbenennen-Dialog
vorhanden ist (initial versteckt). Ruft man den Dialog dann auf, so
verschieb jQuery den in dem Moment im DOM an eine ganz andere
Stelle (an den Ende vom <body>), sodass der Dialog-Code nun nicht mehr
innerhalb des <div> liegt, das für den Tab geladen wurde.
Wechselt man nur zu einem anderen Tab und ruft den Tab »Dateianhänge«
erneut auf, so wird die bisherige <div> für den Tab entfernt und neu
geladen. Beim Neuladen wird natürlich auch wieder eine Kopie des
HTML-Codes für den Dialog mitgeschickt.
Die erste Kopie befindet sich zu dem Zeitpunkt aber weiterhin im DOM,
weil sie ja kein Kind des ursprünglichen Tab-<div>s mehr ist. Somit
haben wir nun zwei Kopien des HTML-Codes im DOM.
Das führt dazu, dass auch die Inputs doppelt vorhanden sind. Es wird
dann die falsche Input (nicht die, die der Benutzer*in angezeigt wird)
an den Server geschickt.
Der Fix sorgt dafür, dass der Dialog beim Schließen wieder an seine
ursprüngliche Stelle im DOM verschoben wird. Dadurch wird der beim
Neuladen des Tabs zusammen mit dem alten Tab-<div> sauber entfernt.
Moritz Bunkus [Wed, 1 Mar 2017 12:45:05 +0000 (13:45 +0100)]
kivi.popup_dialog: Dialog vor »custom close function« schließen
Wenn die »custom close function« den Dialog im DOM verschieben möchte,
so macht sie das mit $dlg.remove().appendTo('#new_parent_id'). Dabei
geht aber die Dialog-Initialisierung flöten.
Wird also erst anschließend $dlg.dialog('close') ausgeführt, so hagelt
das eine Fehlermeldung.
Moritz Bunkus [Wed, 1 Mar 2017 11:52:16 +0000 (12:52 +0100)]
generic/exception.html wiederhergestellt
Die Vorlage wurde im Commit 9d8f72a0f92d01e1e25b14788b193cd662cad0d3
entfernt, weil fälschlicherweise gedacht wurde, dass sie nicht mehr
benutzt wird, da locales.pl eine Warnung diesbezüglich ausgab.
Tatsächlich wird sie aber noch benutzt, und zwar als generische
Fehler-Seite für das Template-Modul. Dieser Fall wurde von locales.pl
mangels Markup aber nicht erkannt.
Moritz Bunkus [Tue, 28 Feb 2017 16:00:23 +0000 (17:00 +0100)]
Dateimanagement: Anhänge nicht als Referenz an SL::Mailer übergeben
SL::Mailer erwartet, dass der Inhalt der Anhänge, die in
$mailer->{attachments} übergeben werden, direkt im Attribut »content«
gespeichert ist.
Das Interface von SL::File hingegen gibt nur eine Skalarreferenz auf
den Dateiinhalt zurück. Daher kann diese nicht 1:1 an den SL::Mailer
übergeben werden, da es ansonsten zu Fehlermeldungen von Rose beim
Speichern im E-Mail-Journal kommt (»cannot bind reference«).
Moritz Bunkus [Tue, 28 Feb 2017 12:00:23 +0000 (13:00 +0100)]
Versehentlich entfernte Fremdschlüssel auf sepa_export_items wieder hinzugefügt
Das DB-Upgrade-Script
»auto_delete_sepa_export_items_on_ap_ar_deletion.pl« hat via
»SL::DBUpgrade2::Base::drop_constraints« alle Constraints auf
»sepa_export_items« entfernt, dann aber nur zwei davon (mit anderen
Bedingungen) neu angelegt — nicht aber die für die Spalten »chart_id«
und »sepa_export_id«.
Resultat ist, dass die Relationships aus den MetaSetups rausfliegen,
wenn man die von einer sauberen DB erzeugen lässt (z.B. mit
Scriptoption »--test-client«).
Moritz Bunkus [Fri, 13 Jan 2017 09:25:48 +0000 (10:25 +0100)]
ActionBar: ComboBox mit nur einem Eintrag wie Eintrag rendern
Das erleichtert, wenn man in einer ComboBox mehrere Einträge evtl. gar
nicht anzeigt. Der Aufrufer muss dann nicht prüfen, ob er der ComboBox
einen oder mehrere Einträge übergibt.
Moritz Bunkus [Fri, 13 Jan 2017 09:22:12 +0000 (10:22 +0100)]
ActionBar: Auslassen von Actions über Parameter »only_if«/»not_if« steuern können
Gedacht für Buttons, die z.B. aufgrund der Mandantenkonfiguration nie
angezeigt werden können. Nicht gedacht für Buttons, die nur aufgrund des
Belegzustands nicht benutzt werden können (z.B. »Löschen« bei einem noch
nicht gespeicherten Beleg).
Moritz Bunkus [Wed, 11 Jan 2017 08:51:34 +0000 (09:51 +0100)]
ActionBar: existierende Inputs namens »action« vor Submit entfernen
Wenn man zuerst druckt und dabei »action« auf z.B. »print« gesetzt wird,
so wird anschließend das PDF heruntergeladen. Allerdings verbleibt die
»action=print« in der Form.
Wenn dann anschließend einer der Menüpunkte angeklickt wird,
z.B. »Erneuern«, so wurde nur ein weiterer Hidden namens
»action_update=1« ergänzt und die Form abgeschickt. Da aber
»action=print« weiterhin gilt (und nicht »action=dispatch«), wird
weiterhin das Drucken ausgeführt und nicht das Erneuern.
Ähnlich sähe es aus, wenn beim Drucken nicht »action=print« sondern
»action_print=1« hinzugefügt wird. Auch dann würde beim Erneuern
»action_update=1« hinzugefügt, und schon hätte man zwei
»action_…«-Einträge in der Form. Dann käme es darauf an, in welcher
Reihenfolge die »sub dispatch« die gesetzten Actions überprüft.
Generell ist das Problem bei jedem Submit via JavaScript, dass die
auszuführende Action irgendwie gesetzt werden muss, und dass man sich
andererseits auch nicht darauf verlassen kann, dass »action=dispatch«
gilt.
Die einzig zuverlässige Variante ist:
1. den Dispatcher-Mechanismus von bin/mozilla gar nicht benutzen, weil
sich der darauf verlässt, dass »action=dispatch« gilt,
2. zuerst dafür zu sorgen, dass in der Form keine Input mit Namen
»action« vorhanden ist und
3. anschließend einen Input mit Namen »action=gewünschte Action«
hinzuzufügen.
Das ist genau das, was dieser Commit implementiert.
projects / mfinanz.git / log