Wednesday, June 14, 2017

Renamed “auth” plugin back to “users”

Yes yesterday I realized that actually we didn’t need to rename “users” to “auth”. And yes, there is no technical need to turn back now, but

  • lino.modlib.users is about users, not about authentication.

  • it is less work to go back now than e.g. in two years.

  • We are only almost there, e.g. some users.rst files in the specs haven’t yet been renamed.

  • The community effect : it is easier to explain to Tonis why I decided to go back than to all other developers why we renamed it from users to auth.

So I now did what was obvious. I prefer working three hours and being back at the same place as before over working only two hours and being at the wrong place.

I created a separate ticket #1897 for this.

Lino and the Django PR

Yesterday I was disappointed when I saw that Tim Graham closed my PR one hour later with the lapidar comment “This change doesn’t qualify for a backport to 1.11 per our supported versions policy.” The fact that he then closed the PR tells me that they don’t even want to discuss about it. But then he also answered in Django ticket #28302, and this sheds new light onto the thing: I “just” need to

  • rewrite my PR against master

  • add tests and documentation

But this is less urgent since there is (as it seems) no way of getting it into Django 1.x because of their “supported versions policy”.

In the long run they are even right: they refuse to do useless work and force us to move forward (to Python 3). Why not. Yes, that’s both the advantage and drawback of having a big community.

I moved three modules (backends, middleware and utils) from lino.modlib.users to lino.core.auth because that’s where they should go.

I reviewed the documentation pages about all this (it is not finished but it is getting clear at least to me):

This is work on #1329.

Documentation

I am reviewing the general structure of the Lino Book:

  • about : non-technical stuff for stakeholders

  • dev : for developers (newbies and experienced, core and application)

  • admin : for system administrators who want to install and run some Lino application (and keep it alive, and possibly do all this with many applications)

  • hosting : a separate section for the “Hosting programme”

  • community : a separate section for the “Community” (whatever this means…)

As a result I moved two pages from hosting to admin because they were obviously too technical.

Restoring brute-force protection after #1329

The use_ipdict feature is back. Since this plugin had been deeply wired into Lino’s authentication system, and since that system is now gone and replaced by Django’s system, I had to write a few serious adaptations to this plugin.

As before this feature is implemented as a configuration option use_ipdict on the Site class which causes the lino.modlib.ipdict plugin to be installed or not. That’s not very elegant, but it works and is easy to activate or deactivate.

Lino Tera

Lydia reported a bug and a few more optimizations (#1891):

  • MoveDown geht nicht in MWSt-Regeln

  • Die Ankreuzfelder TRADETYPE_allowed sind nicht sichtbar. Außerdem sollten sie alle par défaut eingeschaltet sein.

  • Eingabe EKR mit MWSt-Betrag verteilt nicht

  • Den Kontenplan bearbeiten ist unbequem

Cannot print Sessions table as pdf (ExtJS6)

Hamza and I had an interesting voice session about #1898. The tricky part was how to see the traceback of an error which happens while the AppyRenderer parses the template.

You need to:

  • change the target_format from pdf to odt

  • set raiseOnError to False

  • and then you see the traceback inserted as comment in the resulting odt document

Here is our traceback:

Error while evaluating the expression "table(ar)" defined in the "from" part of a statement. ValueError: invalid literal for int() with base 10: ''
File "<string>", line 1, in <module>
File "/usr/local/python/lino_sites/jane/env/repositories/xl/lino_xl/lib/appypod/appy_renderer.py", line 279, in insert_table
return self.insert_table_(*args, **kw)
File "/usr/local/python/lino_sites/jane/env/repositories/xl/lino_xl/lib/appypod/appy_renderer.py", line 299, in insert_table_
columns, headers, widths = ar.get_field_info(column_names)
File "/usr/local/python/lino_sites/jane/env/repositories/lino/lino/core/tablerequest.py", line 536, in get_field_info
return with_user_profile(u.profile, getit)
File "/usr/local/python/lino_sites/jane/env/repositories/lino/lino/utils/jsgen.py", line 118, in with_user_profile
return func(*args, **kwargs)
File "/usr/local/python/lino_sites/jane/env/repositories/lino/lino/core/tablerequest.py", line 487, in getit
widths.append(int(all_widths[i]))
<type 'exceptions.ValueError'>: invalid literal for int() with base 10: ''

It then turned out that Hamza had actually and intuitively been looking at the right place: the extjs6 js code sends empty values for the cw items when requesting the pdf table file. And AppyRenderer fails of cours if you claim to specify explicit column widths and then actually specify an empty width for all your columns.

We learned (or Hamza learned and I got reminded) why it will be quite some work to reimplement the “print table to pdf” feature using something else than appypod. I am now quite sure that secretary (#1534 Use secretary instead of appy.pod?) is far away from being able to do such things. Maybe weasyprint.