Tuesday, May 24, 2016

I continued on #897.

I renamed lino_presto.projects.daniel to lino_presto.projects.psico. IOW we have now Lino Psico (which is a variant of Lino Presto). Because “Lino Presto à la Daniel” was just too silly as a name for a software product.

More plugin inheritance subtilities

Compare also Friday, February 5, 2016.

I discovered yet another edge case where lino.core.site.Site.is_abstract_model() plugin inheritance didn’t work as expected. Consider the following 3 versions of the clocking plugin:

  1. lino_noi.lib.clocking

  2. lino_noi.projects.team.lib.clocking

  3. lino_presto.lib.clocking (whose name should be lino_presto.projects.psico.lib.clocking because it is psicospecific)

When building the docs for Lino Presto, we have lino_presto.projects.std.settings.doctests active. Which installs lino_noi.lib.clocking. So #3 is never imported. But then autodoc nevertheless imports it for inspection. And Django then gets mad and says:

RuntimeError: Conflicting ‘session’ models in application ‘clocking’: <class ‘lino_noi.lib.clocking.models.Session’> and <class ‘lino_presto.lib.clocking.models.Session’>.

I added a new internal Site instance attribute installed_plugin_modules to avoid this.

Very similar to Friday, February 5, 2016, we now have:

  1. lino_presto.projects.psico.lib.contacts inherits from

  2. lino_presto.lib.contacts which inherits from

  3. lino.modlib.contacts

The problem then is that the contacts plugin defines several models (Partner, Person, Company, …)

  1. lino_presto.projects.psico.lib.contacts overrides Partner

  2. lino_presto.lib.contacts overrides Partner, Person and Company

  3. lino.modlib.contacts

I rewrote the internal mechanism for is_abstract_model almost completely, and I think that the Friday, February 5, 2016 problem is now solved as well.

Managing user profiles

Mathieu asked an interesting question (#937):

Mes collègues de la médiation de dettes sont intéressées par le module lino_welfare.modlib.debts. Peux-tu donner accès à celui-ci au profil 120 (Agent d’insertion (nouveaux bénéficiaires)) ?

There are two ways to solve this. You’ll probably need look at the source code of lino_welfare.modlib.welfare.roles in order to follow.

We have already ReceptionClerk, ReceptionClerkNewcomers and IntegrationAgentNewcomers. The profile “120 Integration agent (Newcomers)” corresponds the latter. There is also the DebtsUser role, which is currently used only for the user profile “300 Debts consultant”.

To fix Mathieu’s problem, I just need to change IntegrationAgentNewcomers, telling it to inherit also from DebtsUser. Voilà. En passant I noted that one docstring was erroneous.

Note the difference between a user profile and a user role. A role is just a class object used to specify a set of permissions to grant. A user profile has exactly one role. A user profile has, in addition to the role, a few more attributes (like hidden_languages, readonly) which are relevant when generating JavaScript library.

We might be tempted to change Lino and say that a profile can have several roles. The advantage of this would be that we wouldn’t need to create classes like ReceptionClerkNewcomers and IntegrationAgentNewcomers because these are just a combination of some other existing roles. But that’s just a temptation. Actually it is not bad at all to force us to write a class for every possible combination of user permissions.

Alexa reported #938. This was (probably) a bug in courses/Course/presence_sheet.weasy.html.

En passant I changed slave_grid_format for EnrolmentsByCourse so that it shows the slave table panel in plain html (not editable). Newbie users were confused because this table looked looked almost the same whether as slave panel or opened in own window.

Upgrade for Die Eiche

Änderungen:

  • Die Panels für “Termine” und für “Einschreibungen” im Detail-Fenster eines Kurses sind jetzt nicht mehr bearbeitbare Tabellen. Um darin zu arbeiten, muss man das Panel im eigenen Fenster öffnen.

  • Anwesenheitsblatt zeigte auch Teilnehmer an, die auch nach der Periode anfingen.

OptionParser usage for django-admin commands is deprecated

When restoring a Python dump, I get the following warning:

WARNING:py.warnings:a/restore.py:656: RemovedInDjango110Warning: OptionParser usage for django-admin commands is deprecated, use ArgumentParser instead

Lino not sending emails

Oops, here is an example which shows that I am not a very good system administrator. One production site did not send any emails any more. The end-users complained about this yesterday. The reason was that I made them an upgrade on 28 January and forgot to define a LINO_SITE_MODULE environment variable. Which was necessary after Saturday, January 9, 2016. Their site module not only defined the SMTP settings but also e.g. LOGGING. They have been running almost four month without a Lino log and without getting any emails from Lino.