========================
Friday, January 30, 2015
========================

Submitting an ActionFormPanel no longer forwards `param_values`
===============================================================

Uff! Ticket :ticket:`49` is fixed. :ref:`gx` and Melanie discovered
yesterday how to reproduce it. The trick was to open the detail panel
*via the table view*, not (as I usually do) by clicking on some client
in the welcome page.

As expected, this was subtle and required several hours of debugging
and a change in :xfile:`linoweb.js`. I also wrote a new test case
:mod:`lino_welfare.projects.docs.tests.test_households` which helped
me to understand the problem.

Explanation: `Lino.call_ajax_action` also asked the requesting panel
to add its base params to the parameters of the AJAX call::

  Ext.apply(p, panel.get_base_params());

In our case (user clicks on one of the `create_household` links in the
summary panel of
:class:`MembersByPerson<lino.modlib.households.models.MembersByPerson>`)
the requesting panel is the detail window of the client.  Which (when
opened via the table view) included the parameter values (:data:`pv
<lino.core.constants.URL_PARAM_PARAM_VALUES>`) of that view.  But at
least in our case we do *not* want to add these when sending the `OK`
of the `ActionFormPanel`.  I am not yet sure whether this is generally
what we want because the current case is furthermore special: the
`create_household` action is called from `pcsw.Clients` but defined on
the `contacts.Person` model.

Commit and push.

And here is already a destructive side-effect of above solution.  The
following comes when I tried to assign a newcomer to a coach::

    AttributeError 'NoneType' object has no attribute '__dict__'

    TRACEBACK:
      ...
      File "welfare/lino_welfare/modlib/newcomers/models.py", line 453, in run_from_ui
        watcher = ChangeWatcher(client)
      File "lino/lino/core/utils.py", line 694, in __init__
        self.original_state = dict(watched.__dict__)

Okay the parameter values (:data:`pv
<lino.core.constants.URL_PARAM_PARAM_VALUES>`) must *maybe* never go
to the AJAX call, but the :data:`mt
<lino.core.constants.URL_PARAM_MASTER_TYPE>` and 
:data:`mk <lino.core.constants.URL_PARAM_MASTER_PK>` 
are always needed. For
example the
:class:`AssignCoach<lino_welfare.modlib.newcomers.models.AssignCoach>`
action in :class:`AvailableCoachesByClient
<lino_welfare.modlib.newcomers.models.AvailableCoachesByClient>` needs
the `master_instance`.

Commit and push. Upgrade in :ref:`weleup`.

Remember the active tab when saving
===================================

And then another Javascript problem solved: :ticket:`68`. The problem was:

- When I save a detail form for the first time, Lino switches back to
  the first tab even if I was in another tab when clicking the Save
  button.

Note that Lino did *not* forget to add the :data:`tab
<lino.core.constants.URL_PARAM_TAB>` url parameter to the AJAX
call. But the response did not return it back.  Added new keyword
argument `active_tab` to :meth:`ar.set_response
<lino.core.requests.BaseRequest.set_response>`, changed
:js:func:`Lino.handle_action_result` (in :xfile:`linolib.js`) to
handle this keyword, and changed :meth:`ar.parse_req
<lino.core.requests.BaseRequest.parse_req>` to detect the :data:`tab
<lino.core.constants.URL_PARAM_TAB>` url parameter on incoming calls.

Commit and push.

Immersion trainings
===================

I started to work on :ticket:`72`. It was almost done in less than 2
hours: a new module :mod:`lino_welfare.modlib.trainings`.

But the :mod:`demo fixture
<lino_welfare.modlib.trainings.fixtures.demo>` took some more
time. See :lino:`tomorrow <0131>`.