========================== Saturday, January 31, 2015 ========================== Demo data for the Immersion trainings module ============================================ While a first version of the new :mod:`lino_welfare.modlib.trainings` plugin was easy, the :mod:`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 :message:`Contract overlaps with ISIP contract #5` during :manage:`initdb_demo`. First of all: Lino was better than Mathieu and me together! The :meth:`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 :class:`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 :mod:`lino.utils.dpy`: I extended :meth:`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 :class:`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 :manage:`initdb_demo` again, until I had a series of 4 clients which did not conflict. Note that for such cases we have an :xfile:`initdb_tmp` file in most demo projects. And when my series finally worked in :mod:`lino_welfare.projects.chatelet`, it still failed in :mod:`lino_welfare.projects.std` because these demo projects had different demo dates. (In :mod:`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 :mod:`lino_welfare.projects.std` - All three demo projects of :ref:`welfare` now have the same :attr:`the_demo_date`. Miscellaneous ============= - :mod:`lino_welfare.projects.std.settings` no longer defines the name `SETUP_INFO` in its global namespace. - One page of the Lino documentation tree, :lino:`/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 ;-) TODO: move :mod:`lino.modlib.beid` into the `eidreader` project and document all these things there. - :mod:`lino_welfare.modlib.uploads.fixtures.demo2.py` failed on :ref:`lf` 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 :ref:`gx` confirmed that the :attr:`lino.mixins.polymorphic.Polymorphic.mti_navigator` is a full success. Now I removed all usages of :class:`lino.utils.mti.EnableChild` from my projects (besides Lino, these were :ref:`welfare` and :ref:`faggio`). The biggest work was to adapt :lino:`/tutorials/mti/index` and :lino:`/tutorials/letsmti/index`.