Saturday, May 23, 2015¶
I continue to be excited about using Lino Noi for my daily work. First of all it is of course a good thing that I finally started to eat my own dog food. But that’s not the reason why I am excited. I am excited because it helps me so much for managing my customer’s tickets.
It is not finished, though. After two phone meetings with two customers yesterday I had a lot of small ideas.
The latest changes show again why
inject_field (or some analog method, see
#246) is so necessary.
lino.modlib.tickets needs a
field current_project, and
lino.modlib.clocking needs a field
open_session_on_new_ticket. These fields should be on the
How could we work around using
First idea: instead of storing these fields directly to the User model, could I store them in their own table. For example called tickets.User and clocking.User. Each these models would have two fields: user (a pointer to User with unique=True) and the given field. Or even more transparent, they would be a subclass of users.User. Multi-table inheritance and polyformy. It seems clear that this would have an impact on the system performance, but Guido tells us to not worry about performance.
A second idea (which I actually had before the first): plugins would
define their subclass of User as abstract. But we don’t want to
oblige app developers to subclass e.g.
User just because they include
lino.modlib.contacts. So we need a system for generating the
(concrete) User class dynamically. One difficulty is the fact that
the standard User class must “know” whether it should be abstract or
not. If there are abstract subclasses of it somewhere, then it should
be abstract. The Site object cannot discover this on its own because
the models are not yet loaded. I might change the
attribute again to include the app labels.
And then (if there is any plugin which extends a model of another
lino.core.site.Site could use the
function to generate a dynamic concrete User class object (as
explained by EOL in a
and all those abstract subclasses of User as the bases. I am not
yet sure where this generated User model should “live”.
Side note: Poor Travis CI! They are doing a trustworthy job of
checking every of my commits and sending me an email saying that it is
“Still failing”. I know that Lino doesn’t yet pass on travis (ticket
#269). But I didn’t yet find a way to tell them that I
“temporarily” don’t want them to test every checkin. Or… while we
are talking about it… maybe… by simply renaming the
.travis.yml file to e.g.
try! Yes, that works.