Tuesday, August 25, 2020¶
‘NoneType’ object has no attribute ‘get_layout_handle’¶
I fixed #3766. This was a quite blocking bug: it was not possible to
edit any combobox field in the My Settings form. The issue occurred
only here because
Users is abstract and nevertheless has parameters
defined. I added test cases to cover this in users : user management and
The lino_welfare.modlib.reception plugin.
There is an internal rule that when parameters is None, params_layout is
also None and no functionality related to parameters is used. This rule was
not satisfied here. It is not satisfied because
Users is abstract.
Interesting to note that the Ajax call requests
/MySettings/ or some other non-abstract table name. That’s because none
of the non-abstract subclasses of
Users adds anything to the question
“which choices do we have for field
User.coaching_type?”. That’s why all
fields use the same Ajax call. The problem occurred also for
>>> from lino import startup >>> startup('lino_welfare.projects.gerd.settings.doctests') >>> from lino.api.doctest import *
>>> lh = users.AllUsers.get_detail_layout() >>> lh.layout._datasource lino.modlib.users.desktop.Users >>> lh.get_data_elem('coaching_type') <django.db.models.fields.related.ForeignKey: coaching_type>
>>> show_choices('romain', '/choices/users/Users/coaching_type') <br/> SSG SI Médiation de dettes
Internal side effect: Lino now supports action requests on an abstract actor. Such requests are of course limited, but we need them e.g. in above case.
I did not remove the exception “has a params_layout but no parameters” e.g. ledger.ByJournal is just a mixin but provides a default value for its children
Note also the special case
lino_xl.lib.ledger.ByJournal. This is a
table mixin. It is not explicitly marked as abstract by the application
developer. That’s okay because a data table is automatically considered abstract
when it has no model.
Make Lino applications use Django the user model¶
Until now I was still assuming that “Django’s approach provides no means for
defining instance-specific permissions.” I now saw that this is no longer true.
So think once more about whether we should support Lino applications that use
django.contrib.auth plugin instead of
lino.modlib.users. The main obstacle is the fundamentally different
permission system. But there is a solution for it. Probably even several
solutions. One of them would be to add an attribute
lino.core.actions.Action.required_permissions and to have the
std fixture generate one Django user group for each user type
I reviewed Lino has its own user management.