Saturday, April 25, 2020

This weekend I moved the virtual municipality field from Lino Avanti to lino_xl.lib.countries because we will also use it for Lino Presto. Also this field is now a virtual ForeignKey field (and no longer a lino.core.fields.displayfield()).

I did this because I want Lino Presto to be able to filter calendar entries by the municipality. That is, I wanted, in cal.AllEntries, a table parameter “Municipality” that, if set, would show only calendar entries whose lino_xl.lib.cal.Entry.project field points to a lino_presto.lib.presto.Client who lives either in that place or in a place that is part of it.

This change caused a series of internal optimizations.

After doing it, I realized that it was not really necessary for Lino Presto because I they simply print “service reports” using the service_report.weasy.html template.

New developer feature : Lino now also understands remote fields that forward to a virtualfield as actor parameters. The application developer must define themselves how to translate this parameter into a queryset filter by providing a custom get_request_queryset() method.

The virtual municipality field and its chooser is defined on the lino_xl.lib.countries.CountryCity mixin. Presto uses it in lino_presto.lib.cal.

I moved some internal utility functions from one module to another (make_converter, make_remote_field, get_chooser_for_field etc). The caching in check_for_chooser() didn’t actually work.

>>> from lino import startup
>>> startup('lino_presto.projects.presto1.settings.doctests')
>>> from lino.api.doctest import *
>>> ses = rt.login('robin')

Note that Lino’s lino.core.fields.RemoteField has nothing to do with Django’s remote_field of a FK field.

>>> fld = rt.models.contacts.Partner._meta.get_field('city')
>>> fld.remote_field
<ManyToOneRel: contacts.partner>