20130720 (Saturday, 20 July 2013)

Two subtle bugs

lino_welfare.fixtures.demo had a problem when it was together with lino.modlib.countries.fixtures.be. It said “MultipleObjectsReturned: get() returned more than one City – it returned 2! Lookup parameters were {‘zip_code__exact’: u’4780’}” because both Recht and Sankt Vith have the same zip code 4780.

And another rather subtle pitfall which took me some time to find:

Users complained that when clicking on one of the RequestFields in UsersWithClients to open the correspondingly filtered list of Clients, Lino sometimes used some date in the past for the observed period. This was because the columns of this table are being dynamically built when database_ready, and in that signal handler I use a variable today which holds the current date. And that variable, I initialized it only once at the beginning of the handler. But of course I must evaluate it for each request.


Updated lino_welfare.migrate.migrate_from_1_1_7().

WARNING Abandoning with 57 unsaved instances from north.dpy_tmp_70496696: - pcsw.Coaching [u’Begleitungsperiode endet bevor sie startet.’] (57 object(s) with primary key 3639, 6145, 6172, 6178, 6181, 6192, 6201, 6236, 6242, 6243, 7155, 7167, 7171, 7267, 7290, 7297, 7327, 7336, 7338, 7349, 7352, 7356, 7359, 7360, 7362, 7364, 7365, 7366, 7372, 7373, 7374, 7375, 7376, 7377, 7378, 7379, 7380, 7381, 7382, 7383, 7384, 7385, 7386, 7387, 7388, 7389, 7390, 7391, 7392, 7393, 7395, 7396, 7397, 7398, 7400, 7521, 7522)

This was because watch_tim set end_date of the primary coaching of non-coached clients to 1990-01-01 instead of Coaching.start_date.

Updated the documentation about The Python serializer which was very scattered.

Permission problem for Theresia

A third subtle bug.

When logging in as Theresia on the Lino-Welfare demo, then I got a traceback

No view permission for main panel of reception.ExpectedGuests.InsertFormPanel : main requires {‘auth’: True, ‘user_groups’: u’office’}, but actor cal.Guests requires {‘user_level’: u’admin’, ‘auth’: True, ‘user_groups’: u’office’})

When I disabled this security check, then it generated the following code:

Lino.reception.ExpectedGuests.insertPanel = Ext.extend(Lino.reception.ExpectedGuests.InsertFormPanel,{
  empty_title: "Neu Expected Guests",
  hide_navigator: true,
  ls_bbar_actions: [ { "itemId": "post", "menu_item_text": "Erstellen", "tooltip": "Datensatz erstellen und dann im Detail-Fenster \u00f6ffnen", "panel_btn_handler": function(panel){panel.save(null,true,'post')}, "text": "Erstellen", "overflowText": "Erstellen", "auto_save": false }, { "itemId": "poststay", "menu_item_text": "Erstellen ohne Detail", "tooltip": "Nach Erstellen des Datensatzes kein Detail-Fenster \u00f6ffnen", "panel_btn_handler": function(panel){panel.save(null,false,'poststay')}, "text": "Erstellen ohne Detail", "overflowText": "Erstellen ohne Detail", "auto_save": false } ],
  ls_url: "/reception/ExpectedGuests",
  action_name: "insert",
  initComponent : function() {
    this.ls_detail_handler = Lino.reception.ExpectedGuests.detail;
    this.ls_insert_handler = Lino.reception.ExpectedGuests.insert;

which failed because a Lino.reception.ExpectedGuests.InsertFormPanel has not been defined.

The reason was a bug in Lino’s requirement arithmethics: lino.ui.elems.LayoutElement.loosen_requirements() must treat user_groups differently than user_level. There are probably more bugs like this, and the only real solution will be a class lino.utils.auth.Requirements. But that’s not urgent.

And finally Theresia revealed another bug: the Calendar menu didn’t suppress separators when they were useless (because there were no items to separate, which may happen due to permission requirements).