A Django app that keeps a log of changes made to an object.
Find a file
Lukas Graf d02ed6b9e0
Make diffing more robust for polymorphic models (#784)
* Add failing test for diffing polymorphic model instances.

* Make diffing more robust for polymorphic models:

When working with polymorphic models, where a child model inherits from a
parent model, Django's pre_save signal may send model instances in a way
where the log_update() handler receives an instance of the child as the
`old` model, but an instance of the parent as the `new` model.

This leads to a `FieldDoesNotExist` error when a field that only exists on the
child was modified, and `get_field_value()` attempts look up that field on the
parent.

This change makes diffing polymorphic models more robust by considering this
case in `get_default_value()`. Changes to those child fields won't be tracked
in these cases, but at least `django-auditlog` won't prevent the model from
being saved.
2025-11-25 09:12:41 +01:00
.github Bump actions/checkout from 5 to 6 in the github-actions group (#783) 2025-11-24 13:56:49 +01:00
auditlog Make diffing more robust for polymorphic models (#784) 2025-11-25 09:12:41 +01:00
auditlog_tests Make diffing more robust for polymorphic models (#784) 2025-11-25 09:12:41 +01:00
docs Add CustomLogEntry model support and update tests: (#764) 2025-11-19 09:46:43 +01:00
.gitignore Add I18N Support (#762) 2025-09-30 16:15:45 +02:00
.pre-commit-config.yaml [pre-commit.ci] pre-commit autoupdate (#782) 2025-11-24 19:19:51 +01:00
.readthedocs.yaml pip install . during RTD build (#578) 2023-10-27 19:31:36 +03:30
CHANGELOG.md Make diffing more robust for polymorphic models (#784) 2025-11-25 09:12:41 +01:00
CODE_OF_CONDUCT.md Jazzband: Created local 'CODE_OF_CONDUCT.md' from remote 'CODE_OF_CONDUCT.md' 2022-01-04 11:27:52 +01:00
CONTRIBUTING.md Changes for Jazzband (#269) 2020-10-23 12:16:27 +02:00
LICENSE Bump copyright year 2020-09-07 16:52:32 +02:00
Makefile Add I18N Support (#762) 2025-09-30 16:15:45 +02:00
MANIFEST.in Amend setup configuration to include non-python package files (#769) 2025-10-11 09:57:22 +02:00
pyproject.toml Drop Python 3.8 support (#678) 2024-10-17 18:40:21 +02:00
README.md Add note about V3 to readme (#626) 2024-04-07 21:36:13 +02:00
runtests.sh Extend CI and local test coverage to MySQL and SQLite (#744) 2025-08-17 16:50:23 +02:00
setup.py Drop 'Python 3.9' support (#773) 2025-10-17 17:51:53 +02:00
tox.ini Add CustomLogEntry model support and update tests: (#764) 2025-11-19 09:46:43 +01:00

django-auditlog

Jazzband Build Status Docs codecov Supported Python versions Supported Django versions

Migrate to V3

Check the Upgrading to version 3 doc before upgrading to V3.

django-auditlog (Auditlog) is a reusable app for Django that makes logging object changes a breeze. Auditlog tries to use as much as Python and Django's built in functionality to keep the list of dependencies as short as possible. Also, Auditlog aims to be fast and simple to use.

Auditlog is created out of the need for a simple Django app that logs changes to models along with the user who made the changes (later referred to as actor). Existing solutions seemed to offer a type of version control, which was found excessive and expensive in terms of database storage and performance.

The core idea of Auditlog is similar to the log from Django's admin. Unlike the log from Django's admin (django.contrib.admin) Auditlog is much more flexible. Also, Auditlog saves a summary of the changes in JSON format, so changes can be tracked easily.

Documentation

The documentation for django-auditlog can be found on https://django-auditlog.readthedocs.org. The source files are available in the docs folder.

License

Auditlog is licensed under the MIT license (see the LICENSE file for details).

Contribute

If you have great ideas for Auditlog, or if you like to improve something, feel free to fork this repository and/or create a pull request. I'm open for suggestions. If you like to discuss something with me (about Auditlog), please open an issue.

Releases

  1. Make sure all tests on master are green
  2. Create a new branch vX.Y.Z from master for that specific release
  3. Update the CHANGELOG release date
  4. Pull request vX.Y.Z -> master
  5. As a project lead, once the PR is merged, create and push a tag vX.Y.Z: this will trigger the release build and a notification will be sent from Jazzband of the availability of two packages (tgz and wheel)
  6. Test the install
  7. Publish the release to PyPI