Monday, October 8, 2018¶
Row-level edit locking¶
Wow, Lino has a cool ned feature: row-level locking. This is to fix a
problem they encountered in Lino Avanti: user 1 opens the detail of
a client and starts editing the field translator_notes. While she is still
writing, user 2 opens the same client, changes some other field
(e.g. professional_state) and submits. One
minute later user 1 submits her translator notes. And poof, the
professional state is back to its old value.
To fix this problem, we decided that Lino should show all clients read-only by default. IOW all form fields are disabled. If somebody wants to modify something, they must first “lock” the record with a click, which enables the form fields. As soon as they hit Save the lock is released. The locking does not need to persist after a server restart (we are not launching a spaceship here).
The coding itself took only 1,5 hours. Plus two hours of meditation and surf.
New attribute lino.core.userprefs.UserPrefs.locked_rows : a
set with a tuple (model, pk) for each row locked by this user.
A model mixin lino.modlib.system.mixins.Lockable which adds
the two actions and the displayfield, and which extends the
after_ui_save method to
automatically unlock the row after save. And the
disabled_fields method
to return all fields unless the row is locked. Also the userprefs
registry is now thread-safe (it’s possible that this fixes a rather
unexplored problem that the dashboard didn’t always refresh).
Of course it’s not perfect. More ideas to improve it:
welcome message if locked_rows is not empty
currently it’s a displayfield showing either the “Lock” or the “Unlock” action. Disadvantage is that the field is only in one tab. So a toggle button in the toolbar would probably be better. But Lino doesn’t yet have support for toggle toolbar buttons.
Optimizations in UserRoles table¶
I worked a bit on lino.modlib.users.UserRoles: added
docstrings for the roles, and a more subtle change: it makes no sense
to show UserRole subclasses which have been defined in within
the user_types_module
itself since these are not useful for understanding which permissions
are given to which user type.