====================== Thursday, May 15, 2014 ====================== Middle name ----------- I decided to add a field `middle_names` to :class:`lino.mixins.human.Human` after reading the Wikipedia entry about `Middle name `_ (which in German is called `Zwischenname `_). Adapted :meth:`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 :ref:`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 :xfile:`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 :lino:`/ref/javascript` 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 :ref:`welfare.specs.integ`. 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 :mod:`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.