========================== Thursday, January 15, 2015 ========================== Overriding workflow transition actions ====================================== Wow. Lino has another cool feature: overriding workflow transition actions. The :mod:`lino_xl.lib.cal.workflows.feedback` workflow defines an event state "took place" with a simple transition, represented by a smilie, which marks the event has "took place". This is the default behaviour for :mod:`feedback `. But in :ref:`welfare` they want more. They requested that clicking the smilie should not only mark the meeting as "took place", but should also check out all participants, after asking for a user confirmation before doing so. All this is implemented in :class:`lino_welfare.modlib.cal.models.CloseMeeting`, the first usage example for the new :meth:`lino.core.workflows.Workflow.override_transition` method. Ordering of tasks ================= :class:`lino_xl.lib.cal.MyTasks` was ordered decending, but for tasks this is not intuitive. Now ordered ascending. The same is true for all tasks lists, so in fact I just change it on :class:`lino_xl.lib.cal.Tasks`. Upgrade in Eupen ================ Upgrade in Eupen. Noticed that the reception.AgentsByClient (:ticket:`60`) doesn't yet work: find_date gets the record_id of the Coaching and interprets it as the id of the partner. "am heutigen Tage" ================== The text of presence certificates (:xfile:`presence_certificate.body.html`) had a bug: it said always "was present today" ("am heutigen Tage") even when you issued it on a presence at another date. Neither VISUAL nor EDITOR environment variable is set! ====================================================== Typing :cmd:`fab blog` failed when neither :envvar:`VISUAL` nor :envvar:`EDITOR` environment variable were set. As :ref:`mma` describes in `his blog `_. This is the time to speak about another problem. Actually, :cmd:`fab blog` should use neither :envvar:`VISUAL` nor :envvar:`EDITOR`. Because these variables are expected for use cases when the calling program **waits until the editor terminates**. Like `git commit`, `git merge` and `git rebase -i`. But when we invoke :cmd:`fab blog`, we want to **not wait** for the editor to terminate. We want it to launch the editor with our blog entry and then we want to return back to the command line. Since I never seriously used `git commit`, `git merge` and `git rebase -i`, I had my :envvar:`EDITOR` set to `emacsclient --no-wait` and was happy. But that happiness was ephemeric. See :blogref:`20150105` for an example. I changed :mod:`atelier.fablib` accordingly. It no longer looks for any of these environment variables but expects a new configuration setting :attr:`atelier.fablib.env.editor_command`.