Thursday, June 2, 2016

Giving up #951 (for now)

I realized (with Hamza’s help) that #951 is far from being done and will cause us still some more work. This ticket is important and should be done one day in the future, but right now is not the good moment.

So I revoked all changes related to that ticket and returned back to the version of last Friday.

$ go lino
$ git checkout 'master@{2016-05-29}'
$ go xl
$ git checkout 'master@{2016-05-29}'

I manually restored some changes in Lino which were not related to #951:

Once more

  • go back to 3a216f874c2f4e4b0207face94b1b0037e199b62 (28.05.2016)

$ git merge once_more Auto-merging lino/modlib/extjs/views.py CONFLICT (content): Merge conflict in lino/modlib/extjs/views.py Auto-merging lino/modlib/extjs/elems.py CONFLICT (content): Merge conflict in lino/modlib/extjs/elems.py Auto-merging lino/core/renderer.py CONFLICT (content): Merge conflict in lino/core/renderer.py Auto-merging lino/core/layouts.py Auto-merging lino/core/actors.py Automatic merge failed; fix conflicts and then commit the result.

About #951 (for later)

Here is an summary of what #951 will be (after the experience of last week):

  • Introduce the notion of widgets. These are a bit like the current elements in lino.modlib.extjs.elems, but they are UI-agnostic: they get instantiated once and for all user interfaces during kernel startup. The UI-agnostic part of lino.modlib.extjs.elems moves into a new module lino.core.widgets

    Widgets are responsible for the following:

    • width and preferred_width
    • height and preferred_height
    • vflex and hflex
    • permission handling
  • There will be quite some internal code changes in the startup process and at many places. The code will become more straightforward because widgets don’t need to “know” the user interface.

    Much of what is currently in LayoutHandle can go either to Layout or to a new class CompiledLayout. We will probably have a list of all layouts, and we will “compile” them at startup.

    Layout.main currently contains the original “layout template” during the lifetime of the application. That’s actually rather useless.

    The main attribute of a Handle would wimply be (1) a text (or layouts.Panel) before compiling, and during “compilation” it would be replaced by the resulting widget instance.

  • To generate plain HTML or text, we don’t need any “UI elements”

  • Unlike my first attempt for this ticket, we must not use multiple inheritence when translating widgets to ExtJS elements. We continue to create almost one element class per widget class, but now we will rather have an attribute widget on each element. Actually these elements become sinmple wrapper objects for generating JavaScript code.

The value_date of a ledger movement

  • Added new field Movement.value_date. This corresponds by default to the voucher’s entry_date except for DatedFinancialVoucher where it is filled from the items date field.
  • Changed the internal API of Voucher.create_movement and FinancialVoucher.get_finan_movements
  • But how to fill the new field Movement.value_date for Alexa who has already entered more than hundert bank statements? Best solution seems to be a new admin command which re-registers all (or some) vouchers: reregister.
  • And then a new data checker lino_xl.lib.ledger.models.VoucherChecker.
  • A little API optimization: one can now define a get_checkable_models method of a data checker.
  • FinancialVoucherItem.get_default_match returned a string with the internal prinary key. But we want the voucher number.

Releases

I upgraded both lino-framework.org and Die Eiche because of the layout problems caused by #951.. The latter also for #952.

Sample output of the reregister command:

$ python manage.py reregister
INFO Started manage.py reregister (using prod_sites.eiche.settings) --> PID 18685
INFO Re-register all vouchers in journal Verkaufsrechnungen (VKR)
[################################] 910/910 - 00:00:28
INFO Re-register all vouchers in journal Belfius BE24 1234 5678 9012 (BEL)
[################################] 6/6 - 00:00:00
INFO Re-register all vouchers in journal Einkaufsrechnungen (EKR)
[################################] 0/0 - 00:00:00
INFO Re-register all vouchers in journal KBC (KBC)
[################################] 114/114 - 00:00:17
INFO Re-register all vouchers in journal Kasse (KAS)
[################################] 14/14 - 00:00:00
INFO 1044 vouchers have been re-registered.
INFO Check clearings for all partners Kasse (KAS)
[################################] 2153/2153 - 00:00:07
INFO Done manage.py reregister (PID 18685)