Thursday, August 24, 2017

Store the village but show the municipality

I worked on #1950 for Lino Avanti: In Lino kann man pro Ort den übergeortneten Ort angeben. Also pro Dorf angeben, welche Gemeinde das ist. Und dann brauchen wir gar kein neues Feld, sondern Lino würde bei Wohnort “Heppenbach” automatisch (in deinen Tabellen) “Gemeinde Amel” schreiben.

help_text not loaded from docstrings in a prosa file

Note: lino_avanti was missing in the help_texts_builder_targets dict in the conf.py of Developer Guide. But the help_text of the new field is still not being loaded. Yes, the help_text_builder system fails when the docstrings are in a prosa file.

I wrote a new utility function lino.core.utils.simplify_name() and updated both lino.core.site and lino.sphinxcontrib.help_texts_extractor to use it.

>>> from lino.core.utils import simplify_name
>>> print(simplify_name('lino_avanti.lib.avanti.models.AllClients'))
lino_avanti.lib.avanti.AllClients

I am a bit afraid that this first approach is to simplistic because it is based on a hard-coded set of module name parts to be ignored (currently “models”, “ui”, “desktop”, “choicelists”).

The help text still does not get loaded. Maybe because it is a virtual field. Also the overridden docstring for lino_avanti.lib.avanti.Client.city is being ignored. That’s probably because once a fields help_text has been set, Lino doesn’t change it any more. To be meditated.

>>> from lino import startup
>>> startup('lino_book.projects.adg.settings.demo')
>>> from lino.api.doctest import *
>>> s = [f for f in avanti.Client._meta.get_fields() if f.name.startswith('mun')]
>>> print(s)
[VirtualField lino_avanti.lib.avanti.models.Client.municipality]

Einschreibe-Optionen

I realized that a choicelist EnrolmentOptions would be useless overkill.

It is easier to just define our customized Enrolment model for Avanti and to add the new fields to the EnrolmentsByCourse table which existed already.

Anmahnungen

I added a new table PresencesByEnrolment because I felt the need when testing this. Seems to be a cool thing which they will like.

Reverted my yesterday changes to use_silk_icons

I remembered why Lino was ignoring the use_silk_icons option for DeleteSelected and ShowInsert actions: As long as most standard actions are not available in unicode it is too ugly to have these two converted. But we do want the default value to be False because lino_xl.lib.cal has a beautiful set of working unicode icons. We usually want these. And using silk icons should be an explicit local choice.

Failed to update the verbose_name of a field

In the Lino Welfare test suite is a failure which looks more innocent than it is:

$ go welfare
$ python setup.py test -s tests.SpecsTests.test_finan

The failure says that it expected “Externe Referenz” but got “Ihr Zeichen” as header of the last column of the table (finan.ItemsByPaymentOrder).

It is the override_field_names() function in lino_welfare.modlib.finan.models which is expected to change the verbose_name of that field from “Ihr Zeichen” to “Externe Referenz”.

The function gets invoked correctly, but the verbose_name is unchanged afterwards. It seems that update_field fails. Since build #276 on travis still passed, I suppose that this bug was introducted by 634e51f.

First ideas for the People plugin

There will be one Google account per Site, to be created by the site owner. And then all mobile users can connect to that account. We cannot have the authentication credentials per user in the Lino database because nobody would agree to give their personal credentials into a shared database.

What happens if 5 mobile users are then updating their contacts to that single account? According to this article it won’t be trivial to share contacts in a bi-directional way. But for calendars RW sharing seems commonly used.

This seems the best starting point.