Thursday, May 15, 2014¶

Middle name¶

I decided to add a field middle_names to lino.mixins.human.Human after reading the Wikipedia entry about Middle name (which in German is called Zwischenname).

Adapted ml.beid.BaseBeIdReadCardAction.card2client().

Cannot assign newcomer to a coach¶

I discovered another bug which was introduced during the last weeks. When I assign client #116 of the Lino Welfare demo database to a coach, then I get:

WARNING AjaxExceptionResponse:
Http404
newcomers.AvailableCoachesByClient has no row with primary key u'116'

TRACEBACK:
  File "/home/luc/pythonenvs/py27/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 114, in get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/home/luc/pythonenvs/py27/local/lib/python2.7/site-packages/django/views/generic/base.py", line 69, in view
    return self.dispatch(request, *args, **kwargs)
  File "/home/luc/pythonenvs/py27/local/lib/python2.7/site-packages/django/views/generic/base.py", line 87, in dispatch
    return handler(request, *args, **kwargs)
  File "/home/luc/hgwork/lino/lino/modlib/extjs/views.py", line 513, in get
    (rpt, pk))

I was first afraid that we have a fundamental problem in linoweb.js: actions with parameters are called using different JavaScript code than those without parameters. In order to understand the problem a bit better and get prepared for another surgery, I updated https://www.lino-framework.org/ref/javascript.html and tidied up some code. And then my fears turned out to be wrong. The reason was “only” a bug in determining the URL of the AJAX call.

The call had the following URL:

GET /api/newcomers/AvailableCoachesByClient/116?_dc=140015
...
Begleitung%20durch%20Alicia%20Allmanns.&fv=false&
an=assign_coach&mt=58&mk=116

Which had the wrong element id (116).

Added a test case about this in Integration Service. The bug itself was in ext_renderer.ExtRenderer.action_button.

When an action has parameters, then Lino generates a subclass of ActionFormPanel which defines the Window to be opened. And when the user confirms such a window (by clicking on its OK button), the client must send an AJAX call. But we cannot hard-code the URL for that call in our generated ActionFormPanel subclass because it is possible that a same window is being reused on many different tables.

CachedPrintable vs. Attestable¶

Gerd helped my to understand the following.

Es fehlten in der Tat noch ein paar fundamentale Erkenntnisse bei den Bescheinigungen bzw. Auszügen:

CreateAttestation braucht ein Dialogfenster. Selbst eine Anwesenheitsbestätigung braucht nicht mit einem einzigen Klick als pdf generiert zu werden (das ist ein Klick zu wenig).
Verträge und Budgets müssen ebenfalls Attestable statt CachedPrintable werden. Aber da brauchen wir eine neue spezielle Art von Auszugsart, nämlich “definitiv”. Siehe unten.

Sonstige Probleme, die wir entdeckt haben:

Layout im Reiter “Historie”
cal.Guest ist Printable und Attestable zugleich, das ist Quatsch. Eine Anwendung, die lino.modlib.attestations nutzt, sollte selber keine direkten CachedPrintable definieren.
importierte Lebensläufe: es fehlen der owner und die build_method

Ein definitiver Auszug blockert das bescheinigte Objekt. Oder genauer gesagt er bewirkt, dass das verknüpfte Objekt nicht mehr bearbeitet werden kann. Das, was die Leute als “Cache löschen” kennen, bleibt äußerlich gleich, bewirkt aber in Zukunft, dass der definitive Ausdruck entfernt wird. Der definitive Auszug bleibt übrigens dann als solcher in der Historie bestehen, wirkt aber nicht mehr blockierend. Jeder Attestable kriegt ein neues Feld “final_attestation”, einen FK nach Attestation. “Cache löschen” bedeutet dann einfach, dass dieses Feld geleert wird.