Hopiu/django-auditlog
1
0
Fork 0
mirror of https://github.com/jazzband/django-auditlog.git synced 2026-03-16 22:20:26 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
A Django app that keeps a log of changes made to an object.
534 commits 7 branches 77 tags 2.5 MiB
Python 97.4%
HTML 1.6%
Makefile 0.5%
Shell 0.5%
Find a file
Christopher Charbonneau Wells 5621777622
fix: use sender for m2m signal dispatch connection (#686) 
* fix: use sender for m2m signal dispatch connection

This fix adds support for a use case where a single m2m through model is
used on multiple models. When the reciever is used for the dispatch uid
in this use case it cause duplicated logs because the through model
singal connection happens multiple times.

By changing the m2m signal connection to use the sender for the dispatch
uid this duplication is prevented because the signal connection only
happens once for the through model.

Refs: #685

* fix(format): apply black formatting

* add test and changelog entry

* remove unused import

* correct import sorting

* move change log message to correct section
2024-11-12 16:35:06 +01:00
.github Drop Python 3.8 support (#678) 2024-10-17 18:40:21 +02:00
auditlog fix: use sender for m2m signal dispatch connection (#686) 2024-11-12 16:35:06 +01:00
auditlog_tests fix: use sender for m2m signal dispatch connection (#686) 2024-11-12 16:35:06 +01:00
docs Add AUDITLOG_TRUNCATE_CHANGES_DISPLAY and AUDITLOG_TRUNCATE_LIMIT (#684) 2024-11-04 14:39:25 +01:00
.gitignore Added remote port (#671) 2024-10-07 15:52:34 +02:00
.pre-commit-config.yaml [pre-commit.ci] pre-commit autoupdate (#663) 2024-10-29 15:32:12 +01:00
.readthedocs.yaml pip install . during RTD build (#578) 2023-10-27 19:31:36 +03:30
CHANGELOG.md fix: use sender for m2m signal dispatch connection (#686) 2024-11-12 16:35:06 +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
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.py Add black and format files with black. 2020-12-06 23:10:18 +01:00
setup.py Confirm Django 5.1 support and drop Django 3.2 support. (#677) 2024-10-17 18:53:55 +02:00
tox.ini Confirm Django 5.1 support and drop Django 3.2 support. (#677) 2024-10-17 18:53:55 +02:00

README.md

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