Saturday, April 18, 2020

Printing a weekly sheet for workers

I pushed my work of the last days on #3589.

Until now we had only a print_actions field in the lino_presto.lib.contacts.Worker detail, which prints a weekly “roster” per worker using the 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 lino_presto.lib.contacts.WeeklyView now has a “Print” button for every worker, which prints the weekly “roster”,

Related changes en passant:

The orders/Order/base.weasy.html template (in lino_xl.lib.orders) no longer prints some fields in an intro block. This was never useful and rather disturbing. But the 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 lino_presto.lib.contacts I renamed the Member model to Membership.

The get_calview_chunks() method is no longer used, we use lino_xl.lib.cal.Event.get_event_summary() instead.

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

In Presto I now override that 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 orders/Order/default.weasy.html template in the 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.as_summary_item(ar), " ", btn)

I had to remove the Action.keep_user_values for the print_roster action. Setting the Action.keep_user_values of a 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 lino.mixins.periods.Weekly.

Remark (now integrated into Write 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 lino.core.actions.ShowInsert). Or we have actions where we use instances of a same class with different instance values (e.g. lino.core.actions.ShowSlaveTable). And then actions can use inheritance (e.g. lino_presto.lib.contacts.PrintRoster inherits from 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.