Welcome | Get started | Dive | Contribute | Topics | Reference | Changes | More
Lino has its own user management¶
This document explains why Lino replaces Django’s user management and permission system. See Introduction to permissions for an introduction to Lino’s permission system. See Introduction to user management for getting started with user management.
In Lino we opted to replace Django’s database-stored user groups and permissions system by a system that uses pure Python code objects. While Django stores permissions as rows in the database, in Lino they are entirely defined by the application developer as class-based user roles.
Defining, granting and managing permissions can become a hell when you maintain a complex application that runs on different sites, with different variants, different versions. Permission management is complex. Lino doesn’t turn it into something simple, but it brings light into the dark…
We believe that a purely code-based approach is more suitable than information stored in a database because
you can use powerful features of the Python language (inheritance, modularization, …)
every detail and every change is version-controllable and documentable
This radically different approach required us to replace Django’s
django.contrib.auth
module, including the User
model, by our own
plugin lino.modlib.users
.
Reconciling Lino and Django¶
This design decision of course has a price : application code developed for the
Lino framework won’t work in plain Django, and applications for Django need a
wrapper for making them usable in Lino. Also they cannot easily be mixed
together. Though there are exceptions, e.g. django.contrib.sessions
.
It shouldn’t be too difficult to reconcile Lino with Django by optionally
supporting the standard django.contrib.auth
plugin instead of
lino.modlib.users
. Next step would be to add an attribute
lino.core.actions.Action.required_permissions
and have the
std
fixture generate one Django user group for each user type
in Lino.