This is a breaking change. The default behavior is to delete the
related objects, but it doesn't make sense to apply it to audit log
entries, at least not by default.
* Audit changes to FK fields when saved using *_id naming.
In Django you can save changes to a FK field on a model using the ID
field name (attname) in addition to the regular FK field name with:
model.related_model_id = 42
model.save(update_fields=["related_model_id'])
or:
model.related_model = related_model
model.save(update_fields=["related_model_id'])
as opposed to the more common:
model.related_model = related_model
model.save(update_fields=["related_model'])
This change ensures those model changes are logged properly.
* Apply suggested change from code review.
* Add a CHANGELOG entry for the fix.
* Change diff to evaluate PKs for FK relationships
The diff method now evaluates the primary keys for changes to determine
if a new LogEntry should be created. Previously, the diff method was
evaluating the string representation of the object. This was flawed
because cases can occur when a parent object has in memory changes to
its string string representation and the child related object is saved
prior to these in memory changes being persisted. In these cases a new
LogEntry object would be created erroneously. This cases is asserted
with a test and a regression test will verify the bug.
The consequence of these updates is that the ``LogEntry.changes`` field
now stores primary keys rather than string representations for related
objects. To keep the changes dictionary display unaffected by this
update, a method was added to the ``LogEntry`` model. This method looks
up the object display string from the stored foreign key. Exceptions
were written to handle backwards compatibility.
* Added test case to cover another bug
Because the string representation is not unique for every object, relying
on it to determine FK diffs may not capture all changes. This test case
shows another type of scenario that is fixed by comparing primary keys
rather than object string representations. This is likely occurring
fairly regularly but is hard to spot because it is an error of omission.
* Update to docstring and added changelog
* Modify ``change`` field to be a json field.
Storing the object changes as a json is preferred because it allows SQL
queries to access the change values. This work moves the burden of
handling json objects from an implementation of python's json library in
this package and puts it instead onto the ORM. Ultimately, having the
text field store the changes was leaving them less accessible to external
systems and code that is written outside the scope of the django
auditlog.
This change was accomplished by updating the field type on the model and
then removing the JSON dumps invocations on write and JSON loads
invocations on read. Test were updated to assert equality of
dictionaries rather than equality of JSON parsable text.
Separately, it was asserted that postgres will make these changes to
existing data. Therefore, existing postgres installations should update the
type of existing field values without issue.
* Add test coverage for messages exceeding char len
The "Modify change field to be a json field" commit reduced test
coverage on the mixins.py file by 0.03%. The reduction in coverage was
the result of reducing the number of operations required to achieve the
desired state. An additional test was added to increase previously
uncovered code. The net effect is an increase in test case coverage.
* Add line to changelog
Better markdown formatting
Co-authored-by: Hasan Ramezani <hasan.r67@gmail.com>
* Update CHANGELOG text format
More specific language in the improvement section regarding `LogEntry.change`
Co-authored-by: Hasan Ramezani <hasan.r67@gmail.com>
* Update migration to show Django version 4.0
Co-authored-by: Hasan Ramezani <hasan.r67@gmail.com>
* Update CHANGELOG to show breaking change
Running the migration to update the field type of `LogEntry.change` is a breaking change.
Co-authored-by: Hasan Ramezani <hasan.r67@gmail.com>
* Update serial order of migrations
* Adjust manager method for compatibility
The create log method on the LogEntry manager required an additional
kwarg for a call to create an instance regardless of a change or not.
This felt brittle anyway. The reason it had worked prior to these
changes was that the `change` kwarg was sending a string "null" and
not a None when there were no changes.
Co-authored-by: Hasan Ramezani <hasan.r67@gmail.com>
* Disable on raw save prototype
* Contextmanager to disable instead of just raw - so we can catch m2m relations too
Co-authored-by: Hasan Ramezani <hasan.r67@gmail.com>
