Wednesday, October 17, 2018

Loading from a python dump

Hamza, why did you set loading_from_dump to True in install_migrations? Your code change caused failures in all demo projects with a RestoreTestCase. I undid your change because I am afraid it might cause problems when restoring a dump of a production site.

It seems that we need to document why loading_from_dump exists and what it does.

When loading a python fixture, the dpy loader loads calls full_clean() and save() on every single row. That’s what we want.

But then we have models whose full_clean or save method can decide to create other database objects.

For example the save() method of a user in welfare says:

def save(self, *args, **kwargs):
    super(User, self). save(*args, **kwargs)
    if self.calendar and not settings.SITE.loading_from_dump:, self.calendar)

In Lino Welfare we have one calendar for every user (at least for every user who has permission to use the calendar). When saving a user, Lino Welfare calls to make sure that the user subscribes to its own calendar.

Of course such actions must not happen when we are loading this row from a dump.

About demo bookings

I started to write end user documentation about how to manually clear matching partner movements.

A first problem for explaining is that the demo data is not really optimal. About the demo_bookings fixtures.

lino_xl.lib.ledger defines a list of “purchase stories” : each story represents a provider who sends monthly invoices.


Ordering of menu items

I am working now on #2579 for Lino Tera.

Daniel and Harry realized only yesterday that what they call “Akten” (German for “dossier”) in TIM becomes a “therapy” in Lino, not a “patient”.

They suggested to (1) change the word “Therapy” to “Akte” and (2) the order of menu items to have the menu in first place.

An easy solution is to set the needs_plugins of to []. This attribute is meant to automatically install dependencies. It makes sense in (designed to be used by many different applications), but in it is rather useless.