Objects with a Floatfield value ending in zero can be incorrectly included the object's change history

[metvop <2y4lhcyggs@…>]

If an object has a Floatfield value ending in zero (e.g., 1.0, 2.0, etc), editing the object using the change_form template results in the Floatfield being rendered by the object_history template even when the Floatfield has not been edited. A user who then clicks on the object's History link will see the Change History page show not only the changes the user made to other fields, but also incorrect entries (for Floatfields ending in zero).

This may be due to some recasting of ints and floats occurring between SQLite and Django because the floats (that is, 1.0, 2.0 etc) are rendered by change_form as 1, 2, etc in the form fields.

This is true for 0.9.7-pre-SVN-7520, as well as 0.96.1, though I've tested this with SQLite 3.5.8 only.

[rockmhoward@…]

Spent some time trying to reproduce this with Beta 1, but failed. However I discovered some related funkiness that caused me some confusion and led me to believe for awhile that this might be a real bug. Now I am not so sure. Here is what I know for sure:

First, when a model is reset, Admin Log Entries for that model are not deleted. The old entries can reappear if the object ID happens to get reused in a subsequent session. Second, the change_message is empty when an object is added. (This adds to the confusion when the first problem occurs.) I have an easy patch to fix the second problem -- add choices to action_flag and modify the history template to display get_action_flag_display when the change_message is not set. I will review the tickets and see if these are addressed. If not I will add new tickets.

[James Bennett]

If you can't reproduce the original issue, let's close this. If you believe there's another bug somewhere, open a new ticket for it.

[Jacob]

Milestone 1.0 deleted