Saturday, January 31, 2015¶
Demo data for the Immersion trainings module¶
While a first version of the new
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
First of all: Lino was better than Mathieu and me together! The
“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
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
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
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
lino_welfare.projects.std.settingsno longer defines the name SETUP_INFO in its global namespace.
One page of the Lino documentation tree, /eidreader/applets 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 ;-)
lino.modlib.beidinto the eidreader project and document all these things there.
lino_welfare.modlib.uploads.fixtures.demo2.pyfailed on lino-framework.org 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 /tutorials/mti/index and /tutorials/letsmti/index.