===================================
20151204 (Friday, 04 December 2015)
===================================

Selecting photos from Shotwell using their date
===============================================

Annely asked me to send all my 2015 photos about our folk dance group
to Hillar. Since this is my second year with them and I don't want to
manually fiddle with photo files, I added two options `--after` and
`--before` to `shotwell2blog
<https://github.com/lsaffre/shotwell2blog>`_



Learning by doing: logrotate
============================

I saw that :ticket:`647` is still not solved. Let's see what's wrong::

    $ sudo logrotate -v /etc/logrotate.d/lino 
    reading config file /etc/logrotate.d/lino

    Handling 1 logs

    rotating pattern: /var/log/lino/prod/system.log  weekly (52 rotations)
    empty log files are not rotated, old logs are removed
    considering log /var/log/lino/prod/system.log
    
    error: skipping "/var/log/lino/prod/system.log" because parent
    directory has insecure permissions (It's world writable or
    writable by group which is not "root") Set "su" directive in
    config file to tell logrotate which user/group should be used for
    rotation.

So I added this line to the config file::

        su root www-data

Yes, now it looks better::

    $ sudo logrotate -v /etc/logrotate.d/lino
    reading config file /etc/logrotate.d/lino

    Handling 1 logs

    rotating pattern: /var/log/lino/prod/system.log  weekly (52 rotations)
    empty log files are not rotated, old logs are removed
    switching euid to 0 and egid to 33
    considering log /var/log/lino/prod/system.log
      log does not need rotating
    switching euid to 0 and egid to 0
    
And finally I ask to force the first rotation (otherwise I'd have
to wait again one week before seeing whether it really works)::

    $ sudo logrotate -f /etc/logrotate.d/lino 

Basically keep in mind: `logrotate FILENAME` simply executes the
rotation(s) specified by the given config file FILENAME.  The daily
cron job does exactly this every morning for every config file.  The
`-v` option adds verbosity. The `-f` option means "rotate the file
even if you think it is not necessary".


Wildcard in column_names
========================

There is still one subtle problem, I think it was already before
yesterday (thus not caused by :ticket:`650`)::

    File "docs/specs/users.rst", line 79, in users.rst
    Failed example:
        rt.show(users.Authorities)
    Expected:
        ==== ================= =================
         ID   Author            User
        ---- ----------------- -----------------
         1    Hubert Huppertz   Theresia Thelen
         2    Alicia Allmanns   Theresia Thelen
         3    Mélanie Mélard    Theresia Thelen
        ==== ================= =================
        <BLANKLINE>
    Got:
        ==== ================= ================= ========== ====================
         ID   Author            User              Workflow   Description
        ---- ----------------- ----------------- ---------- --------------------
         1    Hubert Huppertz   Theresia Thelen              *Authority object*
         2    Alicia Allmanns   Theresia Thelen              *Authority object*
         3    Mélanie Mélard    Theresia Thelen              *Authority object*
        ==== ================= ================= ========== ====================
        <BLANKLINE>

The `column_names` of `users.Authorities` has a wildcard.
    
The two standard virtual fields "Workflow" and "Description" should be
visible only when explicitly specified. But it should be possible to
add them manually.
    
    
Welfare test suite
==================

The Welfare test suite still has a few failures after :ticket:`650`.


Endbenutzer können keine SEPA-Konten sehen
==========================================

Gerd reported that they cannot see any imported account. This was due
to a bug introduced by renaming field `last_movement` to
`last_transaction`::

    TRACEBACK:
      File "/python2.7/site-packages/django/core/handlers/base.py", line 132, in get_response
        response = wrapped_callback(request, *callback_args, **callback_kwargs)
      File "/python2.7/site-packages/django/views/generic/base.py", line 71, in view
        return self.dispatch(request, *args, **kwargs)
      File "/python2.7/site-packages/django/views/generic/base.py", line 89, in dispatch
        return handler(request, *args, **kwargs)
      File "/lino/lino/modlib/extjs/views.py", line 543, in get
        for row in ar.sliced_data_iterator]
      File "/lino/lino/core/store.py", line 1094, in row2list
        v = fld.full_value_from_object(row, request)
      File "/lino/lino/core/store.py", line 364, in full_value_from_object
        return self.vf.value_from_object(obj, ar)
      File "/lino/lino/core/fields.py", line 476, in value_from_object
        return m(obj, ar)
      File "/lino-cosi/lino_cosi/lib/sepa/models.py", line 121, in statements
        return ar.obj2html(b2c, dd.fds(b2c.last_movement))

    201512-04 11:02:47 WARNING ajax : AjaxExceptionResponse AttributeError: 'Account' object has no attribute 'last_movement'



:mod:`lino_xl.lib.b2c.fixtures.demo` now connects the important
accounts to some random partner.

New tested document :ref:`welfare.specs.b2c`.



Rumma & Ko is going into the right direction
============================================


Nice: Susan Ward, Canadian Small Business Expert, writes in `The
Advantages of Being a Contractor
<http://sbinfocanada.about.com/od/startingadvice/ss/The-Advantages-of-Being-a-Contractor.htm>`_
that *Self-Employment is the Future* and that "according to a `study
by Intuit <http://http-download.intuit.com/http.intuit/CMO/intuit/futureofsmallbusiness/intuit_2020_report.pdf>`_
more than 80 percent of large corporations plan to substantially
increase their use of a "flexible" workforce. The study predicts that
by 2020 "contingent" workers will exceed 40 percent of the
U.S. workforce."

Which seems to indicate that my visions for `Rumma & Ko
<http://saffre-rumma.net/>`_ with Lino are aiming the right direction.

Released Atelier 0.0.16
=======================

This was necessary because Lino was `failing
<https://drone.io/github.com/lsaffre/lino/130>`_ with Atelier 0.0.15
which still tried to import the importlib coming with Django. See
:ref:`atelier.changes`.


Cannot delete a Place although it is not used
=============================================

There is another occurence of :ticket:`418` in Eupen. It says:

    IntegrityError (1451, 'Cannot delete or update a parent row: a
    foreign key constraint fails (`dbname`.`contacts_person`,
    CONSTRAINT `city_id_refs_id_d349fc28` FOREIGN KEY (`city_id`)
    REFERENCES `countries_place` (`id`))')
    
Last time (:doc:`0824`) I 

The :xfile:`system.log` file shows that Mélanie was tidying up to
remove duplicates. Before deleting place 1062 she had changed a few
address rows to point to the other instance. After the error message
she changed the name of place 1062 to "obsolet". Which is okay for
them. But why do Lino and MySQL disagree about whether there are still
other rows referring to place 1062?

I tried to create a new place (1063) and then to merge the place 1062
into it. Also here Lino does not see "anything related" to that place:

    Sind Sie sicher, dass Sie obsolet nach test fusionieren wollen?

        obsolet wird gelöscht

Here is again their MySQL engine status::

    mysql> show engine 'innodb' status;
    ...
    ------------------------
    LATEST FOREIGN KEY ERROR
    ------------------------
    151204  9:56:43 Transaction:
    TRANSACTION 116B0C9, ACTIVE 0 sec updating or deleting
    mysql tables in use 1, locked 1
    15 lock struct(s), heap size 3112, 8 row lock(s), undo log entries 1
    MySQL thread id 1062531, OS thread handle 0x7f34f0212700, query id 111621549 localhost django updating
    DELETE FROM `countries_place` WHERE `id` IN (1062)
    Foreign key constraint fails for table `dbname`.`contacts_person`:
    ,
      CONSTRAINT `city_id_refs_id_d349fc28` FOREIGN KEY (`city_id`) REFERENCES `countries_place` (`id`)
    Trying to delete or update in parent table, in index `PRIMARY` tuple:
    DATA TUPLE: 11 fields;
     0: len 4; hex 80000426; asc    &;;
     1: len 6; hex 00000116b0c9; asc       ;;
     2: len 7; hex 52000052691801; asc R  Ri  ;;
     3: len 6; hex 20457570656e; asc  Eupen;;
     4: len 2; hex 4245; asc BE;;
     5: len 0; hex ; asc ;;
     6: len 0; hex ; asc ;;
     7: SQL NULL;
     8: len 0; hex ; asc ;;
     9: len 0; hex ; asc ;;
     10: len 0; hex ; asc ;;

    But in child table `dbname`.`contacts_person`, in index `contacts_person_b376980e`, there is a record:
    PHYSICAL RECORD: n_fields 2; compact format; info bits 0
     0: len 4; hex 80000426; asc    &;;
     1: len 4; hex 800311ce; asc     ;;


I tried the following in a Django shell::

    from lino.api.shell import *
    for p in contacts.Person.objects.filter(city_id=1062):
        print p
    print "Done"

The output is simply "Done". No persons refer to that place.

Okay there other types of database objects that might refer to a city
(see:ref:`welfare.specs.ddh`), but obviously Lino would not see them,
otherwise it would have told so before asking to delete the record).

Hm...

.. _faggio:

Renamed "Lino Faggio" to "Lino Voga"
====================================

When choosing "Faggio" as name I did not know that there are real
persons living in Italy whose name is Lino Faggio.  I prefer to change
the name before the product gets more widely known...

- https://help.github.com/articles/renaming-a-repository/


  $ git remote set-url origin git@github.com:lsaffre/voga.git


Upgrade with surprises
======================

The online demos were broken for about 1 hour because I had some
surprises after upgrading. :ticket:`60` had caused a number of bugs
that had sneaked across our test suite.

And BTW the polls demo is still broken.