Friday, June 26, 2015

And still I continued to work on #173 (Class-based permission control (UserRoles)). The fact that this branch is getting rather big (and the fact that I accidentally made some changes in the master branch of welfare) makes me think that I would like to finish it before doing a release in Eupen.

I found (and reported) a documentation bug in Python: The docstring of built-in function isinstance should explain that if the classinfo is a tuple, the object must be instance of any (not all) of the class objects. I had to write the folowing snippet in order to find the answer:


class A(object):
    pass


class B(object):
    pass

b = B()

print isinstance(b, (A, B))

Leaving a trace when a partner was deleted

The murder bug reminds us about an old customer request: Lino should leave a trace somewhere when a partner has been deleted.

The current behaviour of lino.modlib.changes is that deleting the master will delete all changes as well, while deleting some other watched object will simply clear the object.

There are two possibilities to solve this:

  • Make also the master nullable (not only the object as it is currently)

  • Write a log message to system.log when a partner is deleted (#310).

Since I was still undecided which way to go, I continued to work on watch – Watching database changes in order to document the current behaviour.

This made me discover a subtle bug: When deleting a company, Django will automatically delete it’s MTI parent, the partner. But I didn’t know that Django, when deleting that the partner, will not call its delete method. Django uses a “collector” to optimize deletion of related objects. The result was that the change records actually did not get deleted. Only when first removing the company child and then deleting the partner.

The solution was to move the code from lino.core.model.Model.delete() to a handler connected to Django’s pre_delete signal.

This change required a change in A tested example of GFK fields which disables the pre_delete handler in order to produce some broken GFKs.

All this helped me to find a decision and to opt for solution 1 above: I made the master nullable. Because (1) it solves my customer’s request in the most user-friendly way and (2) anyway we will need some day have a look at the possible problems due to dangling change records hanging around in our database without any master.