20160831 (Wednesday, 31 August 2016)

Hamza is advancing on #835. I reviewed his work and merged it into the master branch.

Changed user roles for ReceptionClerkNewcomers

Ticket #1154. Mathieu asked to reduce the access rights of a ReceptionClerkNewcomers. This sounds trivial, but it caused quite some changes in the hierarchy of user roles.

  • We have a new user role SimpleContactsUser

  • OfficeUser no longer inherits from ContactsUser (we now want to define OfficeUser profiles who do not have full contacts functionality). Similar changes for several other user roles. For example a ReceptionClear no longer inherits from SocialAgent.

In general I learned today that the user roles should be as atomic as possible, plugins should usually not define roles which inherits some other role defined by another plugin. Such combination of user roles should happen in the user_profile_module (which I plan to rename to user_goggles_module because I plan to rename user “profiles” to user “goggles”, see below). This is not a final verdict. To be observed.

At some moment I had error messages like the following:

Error when calling the metaclass bases
    Cannot create a consistent method resolution order (MRO) for bases AidsStaff, SepaStaff, SiteUser, ContactsUser, OfficeUser

The error was caused e.g. by the following class definition:

class SiteAdmin(
        AuthorshipTaker,
        SiteAdmin,
        IntegrationStaff,
        DebtsStaff, LedgerStaff,
        NewcomersAgent,
        OfficeStaff,
        AidsStaff, SepaStaff):
    """The site adminstrator has permission for everything."""

Such errors can happen when you fiddle inside of the role definitions. And it was quite difficult to find a solution because the class hierarchy is so complex. Some examples:

User roles in Lino Noi:

Inheritance diagram of lino_noi.lib.noi.user_types

User roles in Lino Voga:

Inheritance diagram of lino_voga.lib.voga.user_types

Rename “UserTypes” to “UserGoggles”

I start to like the word “goggle” as a replacement for “profile” (#1031). Note that this is yet another vocabulary conflict between Django and me, and that this time (not as with the application conflict) I recognize that Django is right and that I was wrong. A profile, in general, is a description of a person’s life, work, interests. Every user has its own profile. But in Lino, for the moment, many users share the same “profile”. A user “profile” in Lino is a set of attributes which results in a given rendering of the linoweb.js file. Currently this means, in first place, a given user role, but also some options like the languages to hide and the optional “readonly” mode. The word “goggle” means that every user must chose a goggle which will determine which parts of the application he or she is going to see.

Yes, this change is purely “linguistic” and will cause a lot of changes in code and documentation. And worse: even my customers are used to the word “profile” and I will need to re-educate them. But I believe that men should do what needs to be done, without worrying too much about their chances of success.

Hm… the above is true also if we replace goggle by user_class or user_type… to be meditated.

About our deployment workflow

I start to understand that, if we want to find independent hosters who offer Lino applications to their customers, we must optimize our deployment workflow. Actually Hamza is working on this: test coverage, get our projects to build on travis, drone and readthedocs.

But one missing piece is a “stable” version of our application suite. I read the following articles:

Questions:

  • Should I start to emit a pull request for every commit? And if yes, must I fork all projects on lino-framework?

  • If we have two or even three branches in every project, how will my everyday work change?

Let’s take today as an example: one trivial ticket (#1154) caused code changes in 7 projects (The lino package, Lino Extensions Library, Lino Welfare, Lino Noi, Lino Così, Lino Presto, Lino Voga):

Resetting a forgotten password

Until now it was not possible (via the web interface) to reset the password of a user who had forgotten their password. Now it is: I added a new rule that a SiteAdmin does not need to specify a current password in the ChangePassword action.

Include template files with source distributions

I continued with #1143 and did for Lino Extensions Library and Lino Noi what I started for Lino Così on Saturday, August 20, 2016.

First I initialized a temporary virtualenv:

$ go xl
$ virtualenv tmp/env
$ . tmp/env/bin/activate
$ pip install lino-xl

And then I invoked the following suite until ls worked:

$ inv sdist
$ pip uninstall lino-xl -y
$ pip install --no-index -f /home/luc/work/book/docs/dl/ lino-xl
$ ls tmp/env/local/lib/python2.7/site-packages/lino_xl/lib/excerpts/config/excerpts/LetterPaper.odt

Similar for Lino Noi:

$ go noi
$ virtualenv tmp/env
$ . tmp/env/bin/activate
$ pip install lino-noi

And then I invoked the following suite until ls worked:

$ inv sdist
$ pip uninstall lino-noi -y
$ pip install --no-index -f /home/luc/work/book/docs/dl lino-noi
$ ls tmp/env/local/lib/python2.7/site-packages/lino_noi/lib/clocking/config/clocking/ServiceReport/default.weasy.html

I also replaced some underscores by dashes in some places (after reading this).

I also released Atelier 0.0.3 because of the changed inv sdist command.

Okay, it seems that the template files would now get included with the next official release. But I still have no clear plan about how to continue. I guess we must setup a unit test which kind of runs above commands (i.e. make a fake release to a local directory sdist_dir), then installs the package into a virgin environment and then runs some kind of “deployment test suite”.

Courses not visible to everybody

I realized that #1154 was not finished : they wanted ReceptionClerkNewcomers to not see lino_xl.lib.courses. But most tables in that module were visible to everybody until now.