# Friday, October 16, 2015¶

## Git cheat sheet¶

Hamza worked on #505 and I merged his work on Lino Così and Lino Welfare to my masters.

Note about how I do this. For each of our projects, Hamza made a fork to his github account. I added his fork on my machine as a remote (for every project):

$git remote add hamza https://github.com/HamZuS/XXX.git  And now the most simple usage is to do the following (for every project): $ git fetch hamza
\$ git merge hamza/master


## Testing #505¶

I tried Hamza’s changes on the test environment in Eupen.

It turned out that they do have duplicate accounts. At least for the moment. A duplicate Account object currently exists if two clients have a common account at the bank. Of course this is not correct (and I need to think with Gerd about how to solve this), but in order to see first results, I changed the Found more than one account with IBAN xxx error issued in lino_cosi.lib.sepa.models from an Exception to a simple logger warning.

I then had to reload their database from the nightly snapshot because Account.partner is now nullable, i.e. the database structure has changed. With plain Django (1.7 or later) you would run migrations to do this. But with Lino it is easier to restore a dump which must of course have been generated before (see Data migrations à la Lino).

I then understood a bug in the database structure: the bank_account field of a sepa.Movement must not be a pointer to sepa.Account. We do not want an Account object for all possible accounts in the world but only for those whose partner is known to us. I changed the name of that field from bank_account to remote_account. I added a field remote_bic (which can be blank) and have it be imported in import_file.

Next two commits and pushes in Lino Così (2 and 3) are for this. Second restore of their database from last snapshot.

Each restore takes –admittedly– about 10 minutes. This is certainly much more time than a regular database migration with Django would need. But for my customers (until now) it is no problem to have their server down during 10 minutes and to do such works only between 6pm and 8am. The advantage of my system (of reloading a snapshot instead of Django’s migrations) is to be more flexible and more intuitive. Especially in situations like this one where I do a series of several quick changes in database structure. Imagine for example that I would discover now (during the second restore) that I have some stupid bug in the database structure which makes the resulting data unusable. With Django migrations such a bug would cause quite some work because I would need to manually edit the migrations. I have no experience with Django migrations, but until now I am satisfied with my system and don’t feel a need to start using them. We will think about this more in detail when #38 is finished and all my customers have upgraded…

Yet another commit and push because I had need seen that the remote_bank_bic field of a BankTransaction defaults to False if the field is empty.

Et voilà, finally I can invite Gerd to have a look at the imported data!

It is a historic event for Lino because this is the first user-visible change which was mostly done by somebody else than me.

## #584 (Statistiques pour le Fonds Social Européen)¶

After feedback from Mathieu and Aurélie for #584, I wrote a first specification: Statistiques pour le Fonds Social Européen

## When to check clearings¶

I continued on #554. The last session (Wednesday, October 14, 2015) revealed the problem that Lino automatically runs check_clearings for each document to be registered. While this is useful in daily work, it caused a serious bottleneck when importing 25000 vouchers.

That’s why I added a new option auto_check_clearings per Journal whose default value is True, but lino_xl.lib.tim2lino sets it to False.

TODO: add an action per partner which manually runs check_clearings.