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:
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.”
lino_presto.lib.contacts I renamed the
Member model to
get_calview_chunks() method is no longer used, we use
Change in the framework: I moved the virtual field
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).
orders/Order/default.weasy.html template in the
lino_presto.projects.noereth 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)
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
Remark (now integrated into Writing 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
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.