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 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 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 lino.models.About, a first use-case of the new window_size attribute for lino.core.actors.Actor.

lino.core.actions.ActorRequest.confirm() required a first argument step. This wasn’t necessary since it can itself count the number of confirms.

lino.ui.extjs3.ext_ui.action_response() and 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 ExtSummaryField und 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 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 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 morgen.

Übrigens könnte FormPanel.save() vom PUT bzw. POST den aktualisierten Record zurückbekommen statt ein weiteres GET zu machen.