:date: 2016-08-31 ==================================== 20160831 (Wednesday, 31 August 2016) ==================================== Hamza is advancing on :ticket:`835`. I reviewed his work and merged it into the master branch. Changed user roles for ReceptionClerkNewcomers ============================================== Ticket :ticket:`1154`. Mathieu asked to reduce the access rights of a :class:`ReceptionClerkNewcomers `. This sounds trivial, but it caused quite some changes in the hierarchy of user roles. - We have a new user role :class:`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 :ref:`noi`: .. inheritance-diagram:: lino_noi.lib.noi.user_types User roles in :ref:`voga`: .. inheritance-diagram:: lino_voga.lib.voga.user_types Rename "UserTypes" to "UserGoggles" ====================================== I start to like the word "goggle" as a replacement for "profile" (:ticket:`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 :xfile:`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: - `Developing and Deploying with Branches `_ - `Stop using git pull for deployment! `__ 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 (:ticket:`1154`) caused code changes in 7 projects (:ref:`lino`, :ref:`xl`, :ref:`welfare`, :ref:`noi`, :ref:`cosi`, :ref:`presto`, :ref:`voga`): - 2016-08-31 17:54 : `lino `__ `6e2bba8 `__ - 2016-08-31 17:54 : `lino_xl `__ `eda57a5 `__ - 2016-08-31 17:54 : `lino_noi `__ `aec468b `__ - 2016-08-31 17:55 : `lino_cosi `__ `eb7aefb `__ - 2016-08-31 17:55 : `lino_welfare `__ `eb7aefb `__ - 2016-08-31 17:55 : `lino_presto `__ `9e439f0 `__ - 2016-08-31 17:55 : `lino_book `__ `f03e7b5 `__ 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 :ticket:`1143` and did for :ref:`xl` and :ref:`noi` what I started for :ref:`cosi` on :doc:`0820`. 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 :ref:`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 :ref:`atelier` 0.0.3 because of the changed :cmd:`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 :ticket:`1154` was not finished : they wanted :class:`ReceptionClerkNewcomers ` to *not* see :mod:`lino_xl.lib.courses`. But most tables in that module were visible to everybody until now.