Tuesday, May 15, 2018

Reporting what you do

I reviewed the Start your own developer blog page and moved it from the Writing documentation section to Working with others because it is rather about teamwork than about documentation.

A Kanban board for Jane

I probably fixed #2384 (Kanban for Jane) in a simple way:

I changed lino_xl.lib.tickets.MyTicketsToWork as follows:

  • now it shows tickets in an active state (having active=True) instead of those in a state having show_in_todo=True.

  • I changed order_by from [“priority”, “-id”] to [“state”, “priority”, “-id”] (i.e. the tickets are sorted by their state in first place. This should not be a big problem since anyway the priority makes no sense when used across states.

  • I wrote a summary view which shows them grouped by state in an <UL>.

  • Of course I also set slave_grid_format to summary in order to activate the summary.

  • I changed the active of TicketStates.ready from True to False: when a ticket is marked “ready”, I don’t want to see it in my to-do list anymore (I revoked this change afterwards. See below).

I was surprised to see that these changes did not require any change in the test suite. Which actually just shows that the dashboard of lino_book.projects.team is not covered completely.

Thunderbird does not start

Thunderbird does not start. The launcher switches to a hourglass cursor for a minute or so, but nothing happens. And oops, when I invoke it from a terminal:

$ thunderbird
Segmentation fault (core dumped)

$ thunderbird --help
Segmentation fault (core dumped)

      -g or --debug          Start within debugger
      -d or --debugger       Specify debugger to start with (eg, gdb or valgrind)
      -a or --debugger-args  Specify arguments for debugger

The problem disappeared after a restart of my machine. Don’t ask me what it was…

More optimizations in Jane

The fact that “I don’t want to see tickets marked “ready” in my to-do list” indicates that there are at least two “contexts” of working: when I am “alone” and when I am “with a client”. When I am with a client, then I actually do want to see those tickets that are marked “ready” (because “ready” means “waiting for test results to confirm that it is done”). But only those of the site we are working on.

I did some changes in the “Sites overview” table:

  • I removed the summary fields about worked hours and moved the table back from lino_xl.lib.working to lino_xl.lib.tickets.

  • I continued to hide the concept of “mission” (which is internally called “project”) from Lino Noi: removed the TicketsByProject table and the parameter field “project”, and changed has_project to has_site.

  • I activated the summary view of MyTicketsToWork also for TicketsBySite and reviewed the detail layout of Site.

All Lino Noi users except EndUser are now Helpers (lino.modlib.users.Helper), and the AssignToMe action is no longer disabled when you are the author. Because for a ticket in Lino Noi you want to be able to assign yourself to your own ticket. This caused a side effect in Lino Welfare where they use assignment of calendar entries in order to specify that a user A agreed with a client an appointment for another user B. In that context you don’t want the author of an entry to assign themselves. Added lino.modlib.users.Assignable.disable_author_assign to allow both behavours.

I pushed these changes to master and tried them on Jane without previously verifying the test suite. After having done a few releases to Jane I got satisfied (for this time) and ran the test suite on my computer. This time there were some changes in the test suite: tickets (Ticket management in Noi).

Here is a funny failure that happened today:

FAIL: atelier.test.DocTestCase (docs/specs/search.rst)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/media/dell1tb/work/atelier/atelier/test.py", line 45, in func
    self.run_subprocess(args)
  File "/media/dell1tb/work/atelier/atelier/utils.py", line 407, in run_subprocess
    self.fail(msg)
AssertionError: /media/dell1tb/virtualenvs/py27/bin/python2 -m atelier.doctest_utf8 docs/specs/search.rst ({}) returned 1:
-----
**********************************************************************
File "/media/dell1tb/work/book/docs/specs/search.rst", line 17, in search.rst
Failed example:
    rt.show('about.SiteSearch', quick_search="foo")
Expected:
    No data to display
Got:
    ========================== ============================================================================================
     Description                Matches
    -------------------------- --------------------------------------------------------------------------------------------
     *Romain Raffault* (User)   password:pbkdf2_sha256$36000$MF5Vl**fOo**1Rwm$OiSIiNl3E4X4mh1z0FgjrwD60W9CD5PjSRVgKdit1vU=
    ========================== ============================================================================================
    <BLANKLINE>
**********************************************************************
1 items had failures:
   1 of   6 in search.rst
***Test Failed*** 1 failures.

Explanation: the random hash of the password contained the sequence of letter “foo”. We might ignore this failure and assume that it won’t happen very often. But it is clear that the password field should definitively not be searchable, i.e. included in the default value for quick_search_fields. The problem is: I see no good way for Lino to “automatically” recognize a password field. So I now specified an explicit quick_search_fields on lino.modlib.users.User.