Tuesday, February 21, 2017

Another market for Lino Care

Do you know this surprising effect when you are working at something for quite a while already, you believe that you have quite a complete grasp of it, and then by some random idea you shift your viewpoint a little bit, and the seemingly well-known something suddenly changes, before your eyes, into something completely new.

That’s what I had this morning with our two Lino Care project (Oikos and Vilma). Until now I had always imagined that the people that are going to be put into these databases were living in the same place, and this place is what unites them. A local network of people who care for their neighbours.

But you can shift that viewpoint, saying that the person who entered them into the database, not the place where they live, is the uniting element. Lino Care as a network of friends. Different scenarios, one application: Lino Care.

A series of changes in Lino Noi

A series of ideas have been in my mind since Sunday when I started interviewing my friends for the Vilma project. Now finally “everything became clear” (at least to me, at least for the moment). I did the following changes:

  • users.User now inherits from Person (instead of just pointing to it or inheriting from Addressable). This adds lino_noi.lib.contacts also to Lino Care. Ticket.end_user now points to a Person, not a User (this was already possible by setting lino_noi.lib.tickets.Plugin.end_user_model.

  • Same for faculties.Competence : users don’t edit only their own competences but also those of the Persons they are coaching. A Competence still remains UserAuthored because it can be important to know which user declares a given person to offer a given skill. New attribute lino_noi.lib.faculties.Plugin.end_user_model.

  • I am now convinced that we need a possibility of having more than one “required faculty” per ticket. So we remove Ticket.faculty and add a new model faculties.Demand.

  • I removed the User.user_site field which was no longer used

TODO:

  • Check the “Where can I help” table.

  • Write a migrator which converts the users to persons and Ticket.faculty into an instance of faculties.Demand.

  • Check whether lino_xl.lib.coachings is interesting for Lino Care. I first thought that Partner might inherit from UserAuthored : every partner is managed by one and only one responsible user, its “author”. I thought that this concept might be useful for replacing the “primary coach” of lino_xl.lib.coachings. But nope. Because a same end user can potentially be “managed” (coached) by several system users. That’s perfectly possible in a network of friends.

  • support for User as subclass of Person

Worked on RecentComments

Tonis and I had a voice session were we explored a subtle problem: RecentComments.get_slave_summary was showing all the comments, but we wanted it to show only a configurable number of the most recent comments.

We discovered that we must indeed specify the limit explicitly as a keyword to our subrequest in get_slave_summary() because Lino has no way to know whether we want to use the actor’s preview_limit.

We added some tested code snippets to Using action requests (and added that document to the test suite).