20130724 (Wednesday, 24 July 2013)

Continued to work on the welfare.reception module.

Added a “Quick appointment” action which creates (1) a calendar event that belongs to the selected user and (2) a checked-in Guest for this event.


I added a new virtual column action_buttons which is similar to the existing workflow_buttons column. The new attribute lino.core.actions.Action.show_in_row_actions defines whether this action should be displayed in this column.

The difference is subtle: it does not display the state, nor does it automatically include any state change actions. The whole system for defining actions is not yet really transparent and consistent.


Is “secretary” a “user role” (currently called “level”) or a “functional group”? The answer to this question depends on the application. The framework should not make some presumption.

The reception clerk should not see the contacts module. I think the best solution for this is to change the general lino.modlib.contacts module so that these commands also require user_groups=’office’.

The default UserLevels had an entry “secretary”, situated between “guest” and “user”. I renamed this (back) to “restricted”.

The “restricted” user level was used in lino.modlib.postings: the idea was that “secretaries” do certain general jobs for the “specialists”. They are members of these “user groups”, but have less rights than the real users. They are more than “guests” however. Thus the need for an intermediate level. But this was maybe an unnecessary complication. Removed it. Waiting for user feedback.

The two actions to manage Belgian eID cards (which were previously in lino_welfare.modlib.pcsw.models) are now in a separate module lino.modlib.reception.beid.

TODO: model mixin BeidCardHolder and make it even an independant app and make the linoweb.js fragmented…

The welfare.reception module starts to get ready, but two technical challenges are yet TODO:

  • There are two ways to execute the “Read eID card” action on a client: using the toolbar button and using the JS link of the new “Actions” field. The latter doesn’t work because the JS isn’t correct.

  • A reception clerk sees the welfare.reception.ExpectedGuests table rendered as HTML in their admin_main.html, very nice, but the “Checkout” actions don’t work from there.


A simply typo bug occured when trying to merge:

unsupported operand type(s) for %: 'NoneType' and 'tuple'

  File "/home/luc/hgwork/lino/lino/core/merge.py", line 77, in logmsg
    lst.append("Merge %s into %s") % (self.obj,self.merge_to)