Tuesday, April 29, 2014

Formatting IBAN numbers

Lino now renders IBAN numbers as it should: “EE87 2200 2210 1206 7904” instead of “EE872200221012067904”.

The first challenge was a decision: should we store the spaces in the database or not? My current answer is: we don’t store the spaces, we use a renderer to insert them dynamically.

This is more or less compatible to django-iban who currently just accepts spaces and removes them forever (but does not render them formatted).

The second challenge was how to implement this. The commit shows what I did. I made changes in lino.modlib.iban.fields and /lino/modlib/iban/config/uppercasetextfield.js (those in lino.ui.elems are rather cosmetic). Thanks to How to insert space every 4 characters for IBAN registering? asked in March 2014 by Jackyto and answered by David Thomas

The current solution has some drawbacks:

• Works only in a grid (IBAN fields in a Detail window are not formatted. Which is not a problem since we currently have no occurence of this case).

• Pressing F2 to start editing causes the formatting to disappear (waiting for user feedback on this).

• We will also need a renderer for plain HTML and plain text.

ParameterStore on pcsw.Clients expects a list of 12 values but got 16

I discovered an urgent bug:

• Wenn ich eine Klientenliste über ein RequestField (von UsersWithClients aus) öffne und dort auf einem Klienten doppelklicke, kriege ich:

  Exception
  ParameterStore of LayoutHandle for ParamsLayout on pcsw.Clients expected a list of 12 values, but got [u'30', u'200096', u'', u'29.04.2014', u'29.04.2014', u'', u'', u'', u'', u'', u'false', u'', u'', u'1', u'false', u'false']
  
  TRACEBACK:
  File "/usr/local/django/testlino/env/lib/python2.6/site-packages/django/core/handlers/base.py", line 114, in get_response
  (...)
  File "/home/lsaffre/repositories/lino/lino/core/requests.py", line 822, in __init__
  request))
  File "/home/lsaffre/repositories/lino/lino/ui/store.py", line 949, in parse_params
  self, len(self.param_fields), pv))
  

Worked several hours on it, without success until now. I encapsulated some code into install_layout in order to use the same logic for params_layout where this was not yet done. But that was not the reason.

Why does a GET to /api/integ/Clients/177 use the ParameterStore defined on pcsw.Clients!? Yes, integ.Clients inherits from pcsw.Clients, but it even specifies its own parameters and params_layout (so my install_layout above was of course useless).

Started new tested document Integration Service which reproduces the problem.

The problematic code was this:

elems += [
    E.br(), ar.instance_action_button(obj.create_household)]

Here obj.create_household instantiates an InstanceAction on a Person’s create_household. The application code is okay, but we must decide whether or not ar.instance_action_button should parse ar.request (i.e. the web request which caused the current request). In the above case it may not. But here be dragons. Not sure whether this will cause problems elsewhere. The API for rendering action buttons is not yet what I would call “stable”.

Cool: I added a get_slave_summary method to UploadsByController. This will make our “quick upload buttons” needless! Not yet finished, but promising.

Checkin wegen Feierabend.

More bugs to fix:

• IBAN numbers don’t seem to get validated.

• The Insert window of an Upload has a layout problem. I guess that the Lino.FileUploadField doesn’t collaborate well with the auto height.

• Inserting in UploadsByClient sets the owner but not the client.