Monday, July 4, 2016

About time zones

During this weekend I worked on #807. The only problem was that dump2py serialized the values of DateTimeField as follows:

if isinstance(field, models.DateTimeField):
    d = value
    return 'dt(%d,%d,%d,%d,%d,%d)' % (
        d.year, d.month,, d.hour, d.minute, d.second)

And at the beginning of the file wrote:

from datetime import datetime as dt

Now it just writes a different definition at the beginning:

from datetime import datetime
from django.utils.timezone import make_aware
def dt(*args):
    return make_aware(datetime(*args))

This should work in all “normal” circumstances.

But what will it do when e.g. we make a dump, then change USE_TZ and/or TIME_ZONE, then re-read the dump? In these cases it is possible that we need to manually change that definition of the dt() function in our file.

After reading the Django docs about Time zones it seems to me that the best configuration for our own Lino Noi production site is to set USE_TZ to True and TIME_ZONE to ‘UTC’. But the latter is 'Europe/Tallinn' right now.

Testing dumps

Ticket #807 looks trivial, but this is an area where dragons live. And because I want to avoid any risk, I wrote a new tested spec Python dumps which uses a new project lino_book.projects.dumps.

To write this tested doc in a more or less reasonable style, I invented the new testing utility atelier.sheller.

A beneficial side effect: the generated by dump2py, until now, did no argument parsing, and it was not possible to run it in batch mode, i.e. to prevent it from asking a user confirmation before flushing the database. For above test case I needed it to have a command-line argument –noinput. This is one reason why I never wrote any tests about it so far. Now I added this option.

Which revealed that we have yet another problem: the run command, after conversion to argparse (#967), did not accept to call scripts with optional arguments. It took me some time to find out that I just need to specify nagrs=argparse.REMAINDER)

The lino_extjs6 demo database

I merged Hamza’s work on #920 into the lino_extjs6 master.

I adapted the demo database for lino_extjs6, lino_extjs6.projects.mysite, to demonstrate more clearly how easy it is to switch to another user interface: it no longer redefines its own get_installed_apps() but just inherits from an existing application. I chose Lino Noi because this is our first milestone. I added lino_noi to the install_requires of lino_extjs6.

I noted that failed on applications which did not have languages de and fr in their language setting. This is not elegant. A fixture should work with any combination of language. I adapted the fixture to work also in this case. Note that only the users Rolf and Romain are language-dependent because they are created by lino.modlib.users.fixtures.demo_users.

A little API optimization as a side effect: I added to lino.api.dd.

Hamza, here’s a little exercise for you: please explain with your words why the Lino Noi test suite now has failures, and adapt the tests where appropriate.

Optimizations in Lino Welfare

#799 (Panneaux - Mise à l’emploi articles 60§7 et 61/Activation)

Quand on est dans le dossier d’un bénéficiaire,

  • peux-tu ajouter la visibilité d’office des colonnes pour:
    • Panneau “Mises à l’emploi art60§7”: “Date de fin”
    • Panneau “Mise à l’emploi article 61 et activations” : “Date de Fin” - “Activa” - “Tutorat” - “Région wallonne” - “SINE” - “PTP”
  • Ajouter un champ “Remarque” en texte libre (comme tu l’as fait pour l’art60§7) quand on crée une mise à l’emploi Art.61.
  • Le calcul automatique de la date de fin est erroné. Tu peux supprimer ce calcul automatique.
  • Modified
  • Modified lino_welfare.modlib.art61.models.ContractsByClient

Lino failed to print descriptions of invoice items

Alexa reported #1020. The problem was that lino_xl.lib.sales.models.ItemsByInvoicePrint.description_print failed when the restified description contained only a single paragraph.

And I am still fiddling with the whitespace problem there.