hub: check appropriateness of `on_delete` for `ForeignKey` fields about openscanhub HOT 4 OPEN

As already commented at release-engineering/kobo#224 (comment) I do not think it is a bug that the initial behavior has been preserved.

from openscanhub.

Yes, is was definitely correct from the point of migration to the new Django version.

However, I still believe that it may cause rather ugly surprises if deleting a single row in database can in theory delete other rows that should have been preserved.

Until yesterday, I did not even know that it is the default behaviour of OSH and Kobo. If nothing else, it should be properly documented, at least.

from openscanhub.

It is (strictly speaking was) the default behavior of Django. I have been notified about this many times when I tried to delete something in Django admin. I believe that it is also the reason why many technically disposable entities in OpenScanHub (such as mock configs, scanning profiles, or client analyzers) have the enabled field. I do not see anything surprising on the current behavior myself.

from openscanhub.

@lzaoral When commenting on this yesterday I mistakenly thought this was a kobo issue. These change are, of course, safer to make in the OpenScanHub project compared to kobo. But even in OpenScanHub I would apply the changes only where needed and when needed.

from openscanhub.