Friday, October 2, 2015¶

Accounting translations for Lino Welfare¶

There was yet another problem with the side-effect of #520: after having transferred the translations to Lino Così, they still did not become activated in Lino Welfare.

Note that for generating language files, Lino does not use Django’s system (Localization: how to create language files) but the system defined by Babel. It is visible in the setup_info.py files where we define message_extractors. There were several reasons for this and I don’t remember them all right now. One of the principal problems with Django’s system is that it works only for the INSTALLED_APPS, and there is no Lino application which uses all plugins at once. Even lino.projects.docs doesn’t use them all, because some are mutually exclusive.

A consequence –or feature– is that I centralize all translations into one “main” plugin per software project. The fab mm command knows this thanks to the locale_dir setting in fabfile.py.

The translations for Lino are in lino.modlib.lino_startup. Those for Lino Welfare are in lino_welfare.modlib.welfare. And now, the translations for Lino Così are in lino_cosi.lib.cosi.

Applications don’t need to know this since it is automatic because lino_cosi.lib.accounts now has lino_cosi.lib.cosi in its needs_plugin.

A side effect of above is that we now have new methods setup_actions and setup_layouts. Because I had to move the things that were in lino_cosi.lib.cosi.models to some other place. These definitions would not have been wanted for Lino Welfare.

Ticket #219¶

I pushed above changes and released them to The Lino framework. Mainly in order to test Hamza’s fix for #219.

I discovered that this fix has an irritating side effect: the insert window, after clicking the “Create” button, is now being displayed once more for a short time before it closes.

I removed the fix temporarily for the next push (which is easy because is is just an additional call to ‘panel.refresh();` in linoweb.js) because I also promised a release to CPAS de Châtelet, and am afraid that they won’t like the irritating side effect.

In general I hope that we can find a better solution.

Release in Chatelet¶

The release in CPAS de Châtelet went without surprises (of course I had to add Lino Così to their repositories and to run $ sudo apt-get build-dep lxml).

no such table: django_session¶

I get this when I run fab initdb in the Lino Noi repository, then go to the team demo database and runserver:

OperationalError at / no such table: django_session

Hamza also had this some days ago, and only after having had it myself, I started to understand the reason.

It is because the fabfile.py of Lino Noi defines two demo projects, lino_noi.projects.team and lino_noi.projects.bs3, and because the second demo project uses the same database file as the first. So fab initdb does the work twice. This not yet a problem, but bs3 has default_user set to ‘anonymous’, which causes it to deactivate both authentication and sessions. And especially the latter means that the database has no sessions table.

To solve this, I added a new site attribute readonly which causes initdb to do nothing (except issuing an info message “Skipped initdb on readonly site ‘foo.settings’.”

And lino_noi.projects.bs3.settings.demo uses this.

So after running fab initdb in the Lino Noi repository, you can now run runserver in both demo projects (team uses the normal “editable” user interface and bs3 the readonly user interface). The public ticket database of the Lino team at http://bugs.lino-framework.org/ uses a subclass of lino_noi.projects.bs3.

More about #219¶

The definition of this function (generated in lino_900_en.js) is:

Lino.tickets.Tickets.wf3 = function(rp, pk, params) {
  var h = function() {
    Lino.run_row_action(rp, "/tickets/Tickets", "GET", pk, "wf3", params, null);
  };
  var panel = Ext.getCmp(rp);
  if(panel) panel.do_when_clean(true, h); else h();
};

It is strange that this call to Lino.run_row_action would issue a POST…

While exploring above, I noticed the following error message in the JavaScript console:

TypeError: opt is undefined             (in ext-all-debug.js:28435:17)

This was due to a stupid bug in Lino.FormPanel.do_when_clean() (when auto_save is true) which caused it to call MessageBox.show() without any config object.

And to my surprise, #219 was gone afterwards!

So Hamza’s fix for #219 was not yet the solution, but it inspired me to find the solution. This is what I would call synergy. Hamza, don’t be sad. The fact that you were able at all to find a first solution to such a hidden problem shows your competence. Really. It would just have been too beautiful if your fix had been the final solution. Please check my code change and make sure that you understand what happened.