Navigation

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:

Since I was still undecided which way to go, I continued to work on
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.

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.