:date: 2020-04-18

========================
Saturday, April 18, 2020
========================


Printing a weekly sheet for workers
===================================

I pushed my work of the last days on :ticket:`3589`.

Until now we had only a :attr:`print_actions` field in the
:class:`lino_presto.lib.contacts.Worker` detail, which prints a weekly "roster"
per worker using the  :xfile:`contacts/Person/roster.weasy.html` template.  That
was basically what they want,  i.e. a document showing all calendar entries of
this week for this worker, one column per weekday.

But it's impolite to ask the secretary to enter the start and end dates each
time they want to print this document for a worker. It's actually impolite to
ask the dates at all. That action should go to the workers' calendar view where
Lino knows the week.

Most visible result: the :class:`lino_presto.lib.contacts.WeeklyView` now has a
"Print" button for every worker, which prints the weekly "roster",

Related changes en passant:

The :xfile:`orders/Order/base.weasy.html` template (in
:mod:`lino_xl.lib.orders`) no longer prints some fields in an intro block. This
was never useful and rather disturbing.  But the
:xfile:`weasyprint/base.weasy.html` template now produces a default main block
that says "You probably want to use a template that overrides the main block."

In :mod:`lino_presto.lib.contacts` I renamed the :class:`Member` model to
:class:`Membership`.

The :meth:`get_calview_chunks` method is no longer used, we use
:meth:`lino_xl.lib.cal.Event.get_event_summary` instead.

Change in the framework: I moved the virtual field :attr:`name_column` from
:class:`lino_xl.lib.contacts.Partner` to :attr:`core.model.Model.name_column`.
It does almost the same as the existing :attr:`mobile_item` field.  Not yet sure
about these names. Needs more documentation.

In Presto I now override that :attr:`name_column` field in the WorkersParameters
actor.  Note that it is perfectly possible to override a model field by a
virtual field in the actor.  But note that the signature changes and that the
actor method is a class method (since actors are never instantiated).

The :xfile:`orders/Order/default.weasy.html` template in the
:mod:`lino_presto.projects.presto1` demo project now features a German text that
will actually be used on their production site.  Christophe kindly gave
permission to publish this text.

Here is the simplified application code that adds a weekly print button to the
workers calendar view::

    @dd.displayfield(_("Worker"))
    def name_column(cls, obj, ar):
        d = ar.master_instance.date  # first day of current week
        ba = obj.print_roster
        pv = dict(start_date=d, end_date=d + ONE_WEEK)
        btn = ar.instance_action_button(ba, "Print",
            request_kwargs=dict(action_param_values=pv))
        return E.p(obj.obj2href(ar), " ", btn)

.. currentmodule:: lino.core.actions

I had to remove the :attr:`Action.keep_user_values`  for the  print_roster
action. Setting the :attr:`Action.keep_user_values` of a :term:`window action`
to `True` means that we don't want it to automatically re-initialize the default
values of its parameters to their default value upon each usage. This feature
(1) is not used on any production site and (b) has the side effect of causing
the fields to never have a default value, even not on first execution, and even
not when you explicitly specify programmatic field values.

Added a new observable date range :class:`lino.mixins.periods.Weekly`.

Remark (now integrated into :ref:`dev.custom_actions`): Isn't it a design flaw
of the action API that we cannot define just the action class and specify, as a
class attribute, the model it is to be installed on?  At least for PrintRoster
that would be cool. There are other cases where it looks quite tedious that we
define an action class (e.g. QuickAssignTo) and then still need to instantiate
it on the model by saying `quick_assign_to_action = QuickAssignTo()`. This
"tedious" API has several advantages: we can reuse a same action class on
different models (e.g. standard actions like
:class:`lino.core.actions.ShowInsert`). Or we have actions where we use
instances of a same class with different instance values (e.g.
:class:`lino.core.actions.ShowSlaveTable`).  And then actions can use
inheritance (e.g. :attr:`lino_presto.lib.contacts.PrintRoster` inherits from
:class:`lino.modlib.printing.DirectPrintAction`). In very simple cases we might
define an  action as a method on the model, but that's syntactically less
readable and I almost never use this approach.

I released Lino 20.4.1 and XL 20.4.2 to PyPI because e.g. the presto repository
was failing on travis after my changes.