20120207 ======== Ein paar subtile Bugs --------------------- Die folgenden Bugs sind nun in der Development-Version behoben: - In Grids mit mehr als einer Bildschirmseite voll Daten konnte man nicht blättern. - Quicklink [Detail Personen] erlaubte das Bearbeiten importierter Felder. - Kursanfragen: im Detail wurde das neue Feld "Dringend" noch nicht angezeigt. - [Layout Editor] funktionierte nicht Details und Bemerkungen In der :mod:`lino.apps.pcsw.settings` machte ich:: def setup_quicklinks(self,ui,user,tb): tb.add_action(self.modules.contacts.Persons,'detail') ... Stattdessen musste es sein:: def setup_quicklinks(self,ui,user,tb): tb.add_action(self.modules.pcsw.Persons,'detail') ... Der Effekt war, dass man importierte Felder bearbeiten konnte. Das ist eine Mausefalle, die nicht gekommen wäre, wenn das `app_label` von :class:`lino.apps.pcsw.models.Persons` weiterhin `contacts` wäre. Soll ich wieder forcieren, dass dass `app_label` vererbt wird? Aber ich glaube es gibt andere Fälle, wo diese Möglichkeit wichtig ist... Der [Layout Editor] funktionmierte nicht, weil er dann folgendes machte:: AttributeError type object 'XyzTable' has no attribute 'can_config' TRACEBACK: File "l:\snapshots\django\django\core\handlers\base.py", line 111, in get_response response = callback(request, *callback_args, **callback_kwargs) File "t:\hgwork\lino\lino\ui\extjs3\ext_ui.py", line 1313, in detail_config_view if not rpt.can_config.passes(request.user): Ja klar, in `detail_config_view` machte er noch das alte System von vor `get_permission`. Ich habs jetzt einfach deaktiviert (war ja sowieso für alle Benutzer offen), aber bei Gelegenheit will ich eine neue Aktion `ConfigureLayout` machen und die `detail_config_view` in die `api_list_view` aufnehmen. About ----- New Window :class:`lino.models.About`, a first use-case of the new :attr:`window_size ` attribute for :class:`lino.core.actors.Actor`. :meth:`lino.core.actions.ActorRequest.confirm` required a first argument `step`. This wasn't necessary since it can itself count the number of confirms. :func:`lino.ui.extjs3.ext_ui.action_response` and :attr:`lino.ui.extjs3.ext_ui.ACTION_RESPONSES`. Änderungen Kalender ------------------- Erstens habe ich einen Bug behoben (man konnte vom Kalender aus keine Termine erstellen), zweitens das Feld "Dauer" rausgeworfen und drittens ein neues Ankreuzfeld "ganztags". Der Bug kam, weil `summary` und `all_day` virtuelle Felder waren. Zwei neue Klassen :class:`ExtSummaryField ` und :class:`ExtAllDayField `, um sie editierbar zu machen. `all_day` ist ein Checkbox-Feld, das in den meisten Kalender-Clients benutzt wird, um dynamisch die beiden Zeit-Felder zu deaktivieren. Diese Info braucht man nicht in der Datenbank zu speichern. Aktive Felder ------------- Die Namen der aktiven Felder eines Detail-Fensters werden jetzt schon beim Generieren der :xfile:`lino.js` aufgelöst. Also Schutz vor Tippfehlerbugs und Aufbau ein bisschen effizienter. FormPanel hat jetzt auch eine `loadMask`, die beim Speichern aktiviert wird. Also das folgende Problem ist gelöst: - Eingabe Art-60-7-Konventionen : hier sind ja einige "aktive Felder", d.h. wenn man eine Stelle eingegeben hat und das Feld verlässt, wird das Formular ohne zu fragen abgespeichert. Das muss auch so sein, weil dadurch einige andere Felder eventuell verändert werden. Problem ist, dass die Anfrage an den Server oft eine Sekunde dauert, in der ein Schnelltipper womöglich schon beginnt, im nächsten Feld etwas einzugeben. Also Lino sollte das Formular während dieser Zeit mit einer loadMask ("Bitte warten") deaktivieren. Es gibt aber noch zwei Bugs mit den :attr:`active_fields `: erstens reagieren Checkboxen scheinbar nicht aufs change-Event und zweitens stimmt da was nicht: wenn man in einem VSE, dessen `Vertreten durch` leer ist, die `Organisation` ändert und dann das Feld mit [TAB] verlässt, dann speichert er ein erstes Mal, und wenn man dann zum nächsten VSE springt, speichert er ein zweites Mal. Sehr subtil. Das kommt daher, dass der Eingabefokus dann während des Speicherns in einem Feld ist, das durch das Speichern verändert wird, und das ebenfalls aktiv ist. Also der Cursor befindet sich in einem aktiven Feld, dann kommt der AJAX-Call rein und verändert unter anderem just dieses Feld. Logisch, dass er dann beim Weiterspringen denkt, er hätte sein Feld verändert. Also wenn man mehr als ein aktives Feld definiert, sollten die sich beim Speichern nicht auch noch gegenseitig aktualisieren. Lösung im Fall von Verträgen:siehe :lino:`morgen <0208>`. Übrigens könnte FormPanel.save() vom PUT bzw. POST den aktualisierten Record zurückbekommen statt ein weiteres GET zu machen.