Saturday, January 31, 2015

Demo data for the Immersion trainings module

While a first version of the new lino_welfare.modlib.trainings plugin was easy, the demo fixture took more time.

The challenge of demo fixtures is that we want to generate fictive data which (1) looks realistic and (2) is testable.

I started by defining a arbitrarily selected list of clients:

selected_clients = (131, 129, 141, 146)

And generating a training contract for each of them

Which caused an error message Contract overlaps with ISIP contract #5 during initdb_demo.

First of all: Lino was better than Mathieu and me together! The ContractBase.full_clean method “decided” that trainings must not overlap with other contracts. We hadn’t even thought about this. I guess that Lino is right.

But the error message does not (and should not) include the offending contract because it is intended to be displayed when the user is modifying a contract. In this situation it would be irritating to “remind” the user on which contract the problem happens.

While thinking about how to find demo clients who are available for demo trainings, I added two new choices to ClientEvents. Users can now ask to show only the “available” clients, i.e. those who have no running contract at all during the given period.

But then I did not even use this new feature because I had the following idea for a little optimization in lino.utils.dpy: I extended FakeDeserializedObject.try_save to include the guilty object into the error message when the error is a simple ValidationError. We will see whether this causes problems somewhere in the future.

I also changed the the __unicode__ method of lino_welfare.modlib.isip.mixins.ContractBase to support unsaved contracts.

This change allowed me to use a simple iterative approach: I simply replacing the problematic selected clients with other random client numbers and running initdb_demo again, until I had a series of 4 clients which did not conflict.

Note that for such cases we have an initdb_tmp file in most demo projects.

And when my series finally worked in lino_welfare.projects.chatelet, it still failed in lino_welfare.projects.std because these demo projects had different demo dates. (In lino_welfare.projects.eupen it is not necessary since thy don’t yet use it). This caused some reorganization:

  • Renamed lino_welfare.projects.docs to lino_welfare.projects.std

  • All three demo projects of Lino Welfare now have the same the_demo_date.

Miscellaneous

  • lino_welfare.projects.std.settings no longer defines the name SETUP_INFO in its global namespace.

  • One page of the Lino documentation tree, https://www.lino-framework.org/eidreader/applets.html page caused the build to fail on Mahmoud’s machine. He had to clone the eidreader project just for building Lino’s docs, which is a bit surprising ;-)

    TODO: move lino.modlib.beid into the eidreader project and document all these things there.

  • lino_welfare.modlib.uploads.fixtures.demo2.py failed on The Lino framework due to an assertion:

    assert newcomer.client_state == ClientStates.newcomer

    Yes, okay, Client.objects.get(id=121) is not always a newcomer because that depends on database language and sorting order.

Adieu, good old EnableChild field!

Yesterday Gerd confirmed that the lino.mixins.polymorphic.Polymorphic.mti_navigator is a full success. Now I removed all usages of lino.utils.mti.EnableChild from my projects (besides Lino, these were Lino Welfare and Renamed “Lino Faggio” to “Lino Voga”). The biggest work was to adapt https://www.lino-framework.org/tutorials/mti/index.html and https://www.lino-framework.org/tutorials/letsmti/index.html.