Store model history and view/revert changes from admin site.

Overview

django-simple-history

Build Status Documentation Status Test Coverage PyPI Version Maintainability Downloads Code Style Jazzband

django-simple-history stores Django model state on every create/update/delete.

This app supports the following combinations of Django and Python:

Django Python
2.2 3.6, 3.7, 3.8, 3.9
3.1 3.6, 3.7, 3.8, 3.9
3.2 3.6, 3.7, 3.8, 3.9

Getting Help

Documentation is available at https://django-simple-history.readthedocs.io/

Pull requests are welcome. Read the CONTRIBUTING file for tips on submitting a pull request.

License

This project is licensed under the BSD 3-Clause license.

Comments
  • Allow the use of multiple databases

    Allow the use of multiple databases

    Right now, this library does not support saving historical to a database separate from its operational model. This PR allows the historical record to be saved to the same db as the historical record table.

    Description

    • Save historical record to the database associated with the historical record table by passing in the db alias contained in the historical instance.

    Motivation and Context

    As of now, the historical records are created using the database associated with the operational model being tracked, not the database associated with the historical table. That means if the operational model is in a separate database, the library attempts to look up the historical table in the operational database, and subsequently fails.

    How Has This Been Tested?

    So far, I have not been able to get the full test suite to run locally.

    That being said, the tests involve creating a record on a second database by passing the db name into the HistoricalRecords constructor and then asserting its existence.

    Types of changes

    • [x] Bug fix (non-breaking change which fixes an issue)
    • [ ] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to change)

    Checklist:

    • [x] I have run the make format command to format my code
    • [x] My change requires a change to the documentation.
    • [x] I have updated the documentation accordingly.
    • [x] I have read the CONTRIBUTING document.
    • [x] I have added tests to cover my changes.
    • [x] I have added my name and/or github handle to AUTHORS.rst
    • [x] I have added my change to CHANGES.rst
    • [x] All new and existing tests passed.
    accepted 
    opened by dopatraman 48
  • Prepare for Django 2.0

    Prepare for Django 2.0

    I was trying to get django-simple-history working with Django 2.0. Here are the changes I made to get it run. (No guarantee for completeness or correct downward compatibility)

    opened by flesser 28
  • Extend `as_of` to return a queryset instead of a list of instances (both are iterable).

    Extend `as_of` to return a queryset instead of a list of instances (both are iterable).

    Description

    The discussion in #397 is about using filtering and querysets with point-in-time queries. The current as_of implementation returns a instance generator so it can only be used to make a single query and obtain the result. The documentation states that it must return an iterable, so it does not have to be a generator. As a queryset, no tests needed to change to handle it.

    HistoricalQuerySet is now returned from queries on history. This is used internally by as_of queries to prune results to the latest of each primary key, and to convert to instances.

    The resulting queryset from as_of can be further filtered; any use of pk will be converted to the original model's primary key if the queryset is returning instances.

    Example (from unit tests):

        def test_as_of(self):
            """Demonstrates how as_of works now that it returns a QuerySet."""
            t0 = datetime.now()
            document1 = RankedDocument.objects.create(rank=42)
            document2 = RankedDocument.objects.create(rank=84)
            t1 = datetime.now()
            document2.rank = 51
            document2.save()
            document1.delete()
            t2 = datetime.now()
    
            # nothing exists at t0
            queryset = RankedDocument.history.as_of(t0)
            self.assertEqual(queryset.count(), 0)
    
            # at t1, two records exist
            queryset = RankedDocument.history.as_of(t1)
            self.assertEqual(queryset.count(), 2)
            self.assertEqual(queryset.filter(rank__gte=75).count(), 1)
            ids = set([item["id"] for item in queryset.values("id")])
            self.assertEqual(ids, {document1.id, document2.id})
    
            # at t2 we have one record left
            queryset = RankedDocument.history.as_of(t2)
            self.assertEqual(queryset.count(), 1)
            self.assertEqual(queryset.filter(rank__gte=75).count(), 0)
    
    

    Related Issues

    #118 #229 #354 This closes #397 #715 #758 This closes #803

    Motivation and Context

    A long-standing issue that kept me from using the library effectively.

    How Has This Been Tested?

    Tests were added, all tests pass. Existing tests did not have to change. Additionally, my company has been using this in production for over a month.

    Types of changes

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [X] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to change)

    Checklist:

    • [X] I have run the make format command to format my code
    • [X] My change requires a change to the documentation.
    • [X] I have updated the documentation accordingly.
    • [X] I have read the CONTRIBUTING document.
    • [X] I have added tests to cover my changes.
    • [X] I have added my name and/or github handle to AUTHORS.rst
    • [X] I have added my change to CHANGES.rst
    • [X] All new and existing tests passed.
    opened by jeking3 25
  • Integrate DJ2.1

    Integrate DJ2.1 "view" permissions for both model and historical model

    In some scenarios, it is not ideal to allow users to revert a model instance to a previous version. Django 2.1 introduced view permissions which, if integrated into DSH, would give an administrator the ability to allow a user to add/change a model but not revert to a previous instance through the model's history.

    Description

    The SimpleHistoryAdmin reviews the historical model instance permissions instead of just the model instance by overriding the has_xxxx_permission methods in ModelAdmin.

    • enable this feature through settings (SIMPLE_HISTORY_PERMISSIONS_ENABLED);

    • honor superuser privileges;

    • user/group permissions granted for the historical model cannot exceed those of the model. That is, granting view and change permissions for the historical model but only view permission for the model means the user has view permission only for the historical model;

    • text on the changelist and form becomes context sensitive (change permission vs view permission);

    • setting SIMPLE_HISTORY_REVERT_DISABLED=True limits all users (other than superuser) to view access. (this works for all Django versions)

    • the [Revert] button is changed to a [Close] button if the user has: -- if Django >= 2.1, feature is disabled, and has view on model; -- if Django >= 2.1, feature is enable and has view model permission and view historical model permission; -- if settings. SIMPLE_HISTORY_REVERT_DISABLED = True (regardless of Django version).

    How Has This Been Tested?

    See tests in test_admin_with_permissions.py

    A few tests in test_admin.py required very minor modifications.

    Screenshots (if appropriate):

    For a user with "view" only permission on a historical object, the changelist looks like this: 20_permissions

    and the form looks like this: 30_permissions

    Types of changes

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [x] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to change)

    Checklist:

    • [x] I have run the make format command to format my code
    • [x] My change requires a change to the documentation.
    • [x] I have updated the documentation accordingly.
    • [x] I have read the CONTRIBUTING document.
    • [x] I have added tests to cover my changes.
    • [x] I have added my name and/or github handle to AUTHORS.rst
    • [x] I have added my change to CHANGES.rst
    • [x] All new and existing tests passed.
    accepted 
    opened by erikvw 21
  • Track history of M2M fields

    Track history of M2M fields

    Initial work done in #370 by @avalanchy. Open to discussion here of how we might want to track history on M2M fields and see if that's a feature we want to accept.

    decision-needed help-wanted 
    opened by rossmechanic 21
  • Time for a new release?

    Time for a new release?

    It's been a while since 3.0.0 and a lot has been done. Is it time for 3.1.0/4.0.0?

    In my case, I need https://github.com/jazzband/django-simple-history/pull/866, and I'm finding myself installing git+https://github.com/jazzband/django-simple-history#master to be able to use it.

    opened by 1ace 20
  • Add Many-to-Many support

    Add Many-to-Many support

    As implemented in this fork: https://bitbucket.org/joaofrancese/django-simple-history/src/0d1630812d2eed3718eabf350d27425af0521a51/simple_history/models.py?at=default

    enhancement P3 decision-needed PyCon2014 Sprint 
    opened by treyhunner 19
  • Django 2.0 compatibility

    Django 2.0 compatibility

    I try to update my website to Django 2.0 and got an error for simple_history/models.py

      File "/home/bernd/.local/share/virtualenvs/bit-a8MytMjT/lib/python3.5/site-packages/django/db/models/base.py", line 308, in __new__
        new_class._prepare()
      File "/home/bernd/.local/share/virtualenvs/bit-a8MytMjT/lib/python3.5/site-packages/django/db/models/base.py", line 363, in _prepare
        class_prepared.send(sender=cls)
      File "/home/bernd/.local/share/virtualenvs/bit-a8MytMjT/lib/python3.5/site-packages/django/dispatch/dispatcher.py", line 178, in send
        for receiver in self._live_receivers(sender)
      File "/home/bernd/.local/share/virtualenvs/bit-a8MytMjT/lib/python3.5/site-packages/django/dispatch/dispatcher.py", line 178, in <listcomp>
        for receiver in self._live_receivers(sender)
      File "/home/bernd/.local/share/virtualenvs/bit-a8MytMjT/lib/python3.5/site-packages/simple_history/models.py", line 94, in finalize
        history_model = self.create_history_model(sender)
      File "/home/bernd/.local/share/virtualenvs/bit-a8MytMjT/lib/python3.5/site-packages/simple_history/models.py", line 129, in create_history_model
        fields = self.copy_fields(model)
      File "/home/bernd/.local/share/virtualenvs/bit-a8MytMjT/lib/python3.5/site-packages/simple_history/models.py", line 176, in copy_fields
        old_field.rel.to,
    AttributeError: 'ForeignKey' object has no attribute 'rel'
    
    opened by brot 17
  • Most recent with excluded fields

    Most recent with excluded fields

    Description

    Added changes in manager to compensate for excluded fields while feetching most recent. Updated test_model_with_excluded_fields test to verify.

    Related Issue

    Steps to reproduce:

    • Create a model with a historical records field
    • Add an excluded model field in historical records
    • Query for most_recent of the model's history field https://github.com/treyhunner/django-simple-history/issues/333

    Motivation and Context

    How Has This Been Tested?

    Screenshots (if appropriate):

    Types of changes

    • [x] Bug fix (non-breaking change which fixes an issue)
    • [ ] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to change)

    Checklist:

    • [x] My code follows the code style of this project.
    • [ ] My change requires a change to the documentation.
    • [ ] I have updated the documentation accordingly.
    • [x] I have read the CONTRIBUTING document.
    • [x] I have added tests to cover my changes.
    • [x] All new and existing tests passed.
    opened by Alig1493 16
  • Enable diffing m2m fields

    Enable diffing m2m fields

    At first @avalanchy did the initial work. After that https://github.com/bmedx made an excellent PR based on his work which wasn't completed, so I tried to make it work and created a PR myself, based on https://github.com/edx-unsupported/django-simple-history/pull/1 and rebased on the current master.

    Description

    This PR enables tracking history of m2m relations. It works in my specific situation, however I would be happy to hear if there are any situations I haven't looked at, I should cover or simply could be improved.

    Related Issue

    #399 - Track history of M2M fields

    Motivation and Context

    A few days ago I received the question "how can I see who has removed an article from this category?" I immediately dove into the history I had enabled, but I quickly discovered that m2m relations weren't tracked. I started googling for solutions and stumbled upon the Pull Request @bmedx made for #399. I installed his fork and after some minor tweaks and a rebase, I made it work for my situation. It tracks each m2m change in a separate m2m_history model, so that you won't need a reference to the actual referenced model.

    How Has This Been Tested?

    Tests have been included, however I'm unsure if they are enough to cover all use cases.

    Type of change

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [X] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to change)

    Checklist:

    • [X] I have run the pre-commit run command to format and lint.
    • [X] My change requires a change to the documentation.
    • [X] I have updated the documentation accordingly.
    • [X] I have read the CONTRIBUTING document.
    • [X] I have added tests to cover my changes.
    • [X] I have added my name and/or github handle to AUTHORS.rst
    • [X] I have added my change to CHANGES.rst
    • [X] All new and existing tests passed.
    opened by thijskramer 15
  • Implement Jazzband guidelines for django-simple-history

    Implement Jazzband guidelines for django-simple-history

    This issue tracks the implementation of the Jazzband guidelines for the project django-simple-history

    It was initiated by @treyhunner who was automatically assigned in addition to the Jazzband roadies.

    See the TODO list below for the generally required tasks, but feel free to update it in case the project requires it.

    Feel free to ping a Jazzband roadie if you have any question.

    TODOs

    • [x] Fix all links in the docs (and README file etc) from old to new repo
    • [x] Add the Jazzband badge to the README file
    • [x] Add the Jazzband contributing guideline to the CONTRIBUTING.md or CONTRIBUTING.rst file
    • [x] Check if continuous testing works (e.g. Travis CI, CircleCI, AppVeyor, etc)
    • [x] Check if test coverage services work (e.g. Coveralls, Codecov, etc)
    • [x] Add jazzband account to PyPI project as maintainer role (e.g. URL: https://pypi.org/manage/project/django-simple-history/collaboration/)
    • [x] Add jazzband-bot as maintainer to the Read the Docs project (e.g. URL: https://readthedocs.org/dashboard/django-simple-history/users/)
    • [x] Add incoming GitHub webhook integration to Read the Docs project (e.g. URL: https://readthedocs.org/dashboard/django-simple-history/integrations/)
    • [x] Fix project URL in GitHub project description
    • [x] Review project if other services are used and port them to Jazzband
    • [x] Decide who is project lead for the project (if at all)
    • [x] Set up CI for Jazzband project releases if needed and open ticket if yes

    Project details

    Description Store model history and view/revert changes from admin site.
    Homepage https://django-simple-history.readthedocs.org
    Stargazers 1012
    Open issues 50
    Forks 293
    Default branch master
    Is a fork False
    Has Wiki False
    Has Pages False
    opened by jazzband-bot 15
  • Bump tox from 3.27.1 to 4.2.5 in /requirements

    Bump tox from 3.27.1 to 4.2.5 in /requirements

    Bumps tox from 3.27.1 to 4.2.5.

    Release notes

    Sourced from tox's releases.

    4.2.5

    What's Changed

    Full Changelog: https://github.com/tox-dev/tox/compare/4.2.4...4.2.5

    4.2.4

    What's Changed

    Full Changelog: https://github.com/tox-dev/tox/compare/4.2.3...4.2.4

    4.2.3

    What's Changed

    Full Changelog: https://github.com/tox-dev/tox/compare/4.2.2...4.2.3

    4.2.2

    What's Changed

    Full Changelog: https://github.com/tox-dev/tox/compare/4.2.1...4.2.2

    4.2.1

    What's Changed

    New Contributors

    Full Changelog: https://github.com/tox-dev/tox/compare/4.2.0...4.2.1

    4.2.0

    What's Changed

    Full Changelog: https://github.com/tox-dev/tox/compare/4.1.3...4.2.0

    4.1.3

    ... (truncated)

    Changelog

    Sourced from tox's changelog.

    v4.2.5 (2023-01-06)

    Bugfixes - 4.2.5

    - The combination of ``usedevelop = true`` and ``--skip-missing-interpreters=false`` will no longer fail for environments
      that were *not* invoked - by :user:`stephenfin`. (:issue:`2811`)
    - Fix an attribute error when ``use_develop = true`` is set and an unsupported interpreter version is requested - by
      :user:`stephenfin`. (:issue:`2826`)
    - tox returns a non-zero error code if all envs are skipped. It will now correctly do this if only a single env was
      requested and this was skipped - by :user:`stephenfin`. (:issue:`2827`)
    

    v4.2.4 (2023-01-05)

    Bugfixes - 4.2.4

    • Setting [testenv] basepython = python3 will no longer override the Python interpreter version requested by a factor, such as py311 - by :user:stephenfin. (:issue:2754)
    • Also accept tab after colon before factor filter expansion - by :user:pdecat. (:issue:2823)

    v4.2.3 (2023-01-04)

    Bugfixes - 4.2.3

    - ``devenv`` does not respect the specified path when the package is a wheel file - by :user:`gaborbernat`. (:issue:`2815`)
    - Require space after colon before factor filter expansion, unless it is the last character of the line - by :user:`pdecat`. (:issue:`2822`)
    

    v4.2.2 (2023-01-04)

    Bugfixes - 4.2.2

    • Add CC, CFLAGS, CCSHARED, CXX, CPPFLAGS, LDFLAGS, PKG_CONFIG and PKG_CONFIG_SYSROOT_DIR to the default passed through environment variables list as these are needed for building various C-extensions
      • by :user:gaborbernat. (:issue:2818)

    v4.2.1 (2023-01-03)

    Bugfixes - 4.2.1

    - Fix extracting extras from markers with more than 2 extras in an or chain - by :user:`dconathan`. (:issue:`2791`)
    

    </tr></table>

    ... (truncated)

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 0
  • Bump coverage from 6.5.0 to 7.0.3 in /requirements

    Bump coverage from 6.5.0 to 7.0.3 in /requirements

    Bumps coverage from 6.5.0 to 7.0.3.

    Changelog

    Sourced from coverage's changelog.

    Version 7.0.3 — 2023-01-03

    • Fix: when using pytest-cov or pytest-xdist, or perhaps both, the combining step could fail with assert row is not None using 7.0.2. This was due to a race condition that has always been possible and is still possible. In 7.0.1 and before, the error was silently swallowed by the combining code. Now it will produce a message "Couldn't combine data file" and ignore the data file as it used to do before 7.0.2. Closes issue 1522_.

    .. _issue 1522: nedbat/coveragepy#1522

    .. _changes_7-0-2:

    Version 7.0.2 — 2023-01-02

    • Fix: when using the [run] relative_files = True setting, a relative [paths] pattern was still being made absolute. This is now fixed, closing issue 1519_.

    • Fix: if Python doesn't provide tomllib, then TOML configuration files can only be read if coverage.py is installed with the [toml] extra. Coverage.py will raise an error if TOML support is not installed when it sees your settings are in a .toml file. But it didn't understand that [tools.coverage] was a valid section header, so the error wasn't reported if you used that header, and settings were silently ignored. This is now fixed, closing issue 1516_.

    • Fix: adjusted how decorators are traced on PyPy 7.3.10, fixing issue 1515_.

    • Fix: the coverage lcov report did not properly implement the --fail-under=MIN option. This has been fixed.

    • Refactor: added many type annotations, including a number of refactorings. This should not affect outward behavior, but they were a bit invasive in some places, so keep your eyes peeled for oddities.

    • Refactor: removed the vestigial and long untested support for Jython and IronPython.

    .. _issue 1515: nedbat/coveragepy#1515 .. _issue 1516: nedbat/coveragepy#1516 .. _issue 1519: nedbat/coveragepy#1519

    .. _changes_7-0-1:

    Version 7.0.1 — 2022-12-23

    ... (truncated)

    Commits
    • 2ff9098 docs: prep for 7.0.3
    • 1f34d8b fix: race condition on data file shouldn't break combining. #1522
    • 85170bf build: two-step combines for speed
    • 1605f07 mypy: misc.py, test_misc.py
    • 4f3ccf2 refactor: a better way to have maybe-importable third-party modules
    • 98301ed mypy: test_config.py, test_context.py
    • 9d2e1b0 mypy: test_concurrency.py, test_python.py
    • c3ee30c refactor(test): use tmp_path instead of tmpdir
    • 0b05b45 mypy: test_annotate.py test_arcs.py test_collector.py
    • 2090f79 style: better
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 1
  • Custom m2m field are not handled correctrly

    Custom m2m field are not handled correctrly

    Describe the bug A clear and concise description of what the bug is.

    To Reproduce Steps to reproduce the behavior: Code snippet below illustrates the issue. There are assumptions to the name of the fields in through tables for m2m tables. For the default through tables it works, but for the custom ones it does not.

    If you try to save object of PageArticle you will see:

    django.core.exceptions.FieldError: Cannot resolve keyword 'pagearticle' into field. Choices are: article, article_id, id, tag, tag_id
    
    from django.db import models
    from simple_history.models import HistoricalRecords
    
    class Tag(models.Model):
        name = models.CharField(max_length=100)
    
    class ArticleTag(models.Model):
        article = models.ForeignKey("PageArticle", on_delete=models.CASCADE)
        tag = models.ForeignKey(Tag, on_delete=models.CASCADE)
    
    class PageArticle(models.Model):
        title = models.CharField(max_length=100)
        article_tags = models.ManyToManyField(Tag, through=ArticleTag)
    
        history = HistoricalRecords(m2m_fields=[
            article_tags,
        ])
    

    Expected behavior A model should be saved without any errors.

    Screenshots If applicable, add screenshots to help explain your problem. image

    Environment (please complete the following information):

    • OS: MacOS, Windows
    • Browser (if applicable): [e.g. chrome, safari]
    • Django Simple History Version: 3.2.0
    • Django Version: 4.1.5

    Additional context Pull request that addresses the issue is #1093

    opened by PiotrKurnik 0
  • Proper handling of custom m2m relationships

    Proper handling of custom m2m relationships

    django-simple-history does not work with custom through tables for m2m relations.

    Description

    Code snippet below illustrates the issue. There are assumptions to the name of the fields in through tables for m2m tables. For the default through tables it works, but for the custom ones it does not.

    If you try to save object of PageArticle you will see:

    django.core.exceptions.FieldError: Cannot resolve keyword 'pagearticle' into field. Choices are: article, article_id, id, tag, tag_id
    
    from django.db import models
    from simple_history.models import HistoricalRecords
    
    class Tag(models.Model):
        name = models.CharField(max_length=100)
    
    class ArticleTag(models.Model):
        article = models.ForeignKey("PageArticle", on_delete=models.CASCADE)
        tag = models.ForeignKey(Tag, on_delete=models.CASCADE)
    
    class PageArticle(models.Model):
        title = models.CharField(max_length=100)
        article_tags = models.ManyToManyField(Tag, through=ArticleTag)
    
        history = HistoricalRecords(m2m_fields=[
            article_tags,
        ])
    
    
    

    Related Issue

    #1079

    Motivation and Context

    We need to use model introspection to find the correct field name and not to relate on model name.

    How Has This Been Tested?

    Unit test has been added.

    Screenshots (if appropriate):

    image

    Types of changes

    • [x] Bug fix (non-breaking change which fixes an issue)

    Checklist:

    • [x] I have run the pre-commit run command to format and lint.
    • [ ] My change requires a change to the documentation.
    • [ ] I have updated the documentation accordingly.
    • [x] I have read the CONTRIBUTING document.
    • [x] I have added tests to cover my changes.
    • [x] I have added my name and/or github handle to AUTHORS.rst
    • [x] I have added my change to CHANGES.rst
    • [x] All new and existing tests passed.
    opened by PiotrKurnik 2
  • Bump tox-gh-actions from 2.11.0 to 3.0.0 in /requirements

    Bump tox-gh-actions from 2.11.0 to 3.0.0 in /requirements

    Bumps tox-gh-actions from 2.11.0 to 3.0.0.

    Release notes

    Sourced from tox-gh-actions's releases.

    v3.0.0

    What's Changed

    This is the first stable version which supports tox v4.

    • tox-gh-actions v3.0.0 implements a subset of features provided by the latest tox-gh-actions v2. Missing features will be added back gradually.
    • Users using tox v3 can keep using tox-gh-actions v2 maintained under the tox3 branch.

    Full Changelog: https://github.com/ymyzk/tox-gh-actions/compare/v3.0.0b1...v3.0.0

    v3.0.0b1

    What's Changed

    Full Changelog: https://github.com/ymyzk/tox-gh-actions/compare/v3.0.0a2...v3.0.0b1

    v3.0.0a2

    What's Changed

    Full Changelog: https://github.com/ymyzk/tox-gh-actions/compare/v3.0.0a1...v3.0.0a2

    v3.0.0a1

    • Preliminary support of tox 4. This version is tested with tox 4.0.0a9. (#59)

    v2.12.0

    What's Changed

    Full Changelog: https://github.com/ymyzk/tox-gh-actions/compare/v2.11.0...v2.12.0

    Commits
    • 1602fc1 Fix CI
    • 9f5b430 Preparation for 3.0.0 release
    • c9b535e Tune testing tools
    • 56019d1 Merge pull request #136 from ymyzk/update-dependencies
    • 54c19cd Update dependencies
    • 3def659 Update links to tox's documentation
    • 4722a2e Merge pull request #135 from ymyzk/tox4-ci
    • b4726e9 Remove pypy2 from test suites
    • 866c32a Add devpi-process optional dependency for integration testing
    • e2c010a Clean up workflow for tox4
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 0
  • Bump isort from 5.10.1 to 5.11.4 in /requirements

    Bump isort from 5.10.1 to 5.11.4 in /requirements

    Bumps isort from 5.10.1 to 5.11.4.

    Release notes

    Sourced from isort's releases.

    5.11.4

    Changes

    :package: Dependencies

    5.11.3

    Changes

    :beetle: Fixes

    :construction_worker: Continuous Integration

    v5.11.3

    Changes

    :beetle: Fixes

    :construction_worker: Continuous Integration

    5.11.2

    Changes

    5.11.1

    Changes December 12 2022

    ... (truncated)

    Changelog

    Sourced from isort's changelog.

    5.11.4 December 21 2022

    5.11.3 December 16 2022

    5.11.2 December 12 2022

    5.11.1 December 12 2022

    5.11.0 December 12 2022

    Commits
    • 98390f5 Merge pull request #2059 from PyCQA/version/5.11.4
    • df69a05 Bump version 5.11.4
    • f9add58 Merge pull request #2058 from PyCQA/deps/poetry-1.3.1
    • 36caa91 Bump Poetry 1.3.1
    • 3c2e2d0 Merge pull request #1978 from mgorny/toml-test
    • 45d6abd Remove obsolete toml import from the test suite
    • 3020e0b Merge pull request #2057 from mgorny/poetry-install
    • a6fdbfd Stop installing documentation files to top-level site-packages
    • ff306f8 Fix tag template to match old standard
    • 227c4ae Merge pull request #2052 from hugovk/main
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 1
Releases(3.2.0)
  • 3.2.0(Sep 28, 2022)

    What's Changed

    • Replaces count by exists in populate_history command by @fabiocapsouza in https://github.com/jazzband/django-simple-history/pull/982
    • [issue-983] querying history, convert to instance, chase foreign key on history_date by @jeking3 in https://github.com/jazzband/django-simple-history/pull/984
    • [fix] add fallback_version to scm settings by @areski in https://github.com/jazzband/django-simple-history/pull/981
    • Removed n+1 query from bulk_create_with_history utility by @twolfson in https://github.com/jazzband/django-simple-history/pull/975
    • Fixed simple typos by @creyD in https://github.com/jazzband/django-simple-history/pull/996
    • Fix code block in docs for Using custom OneToOneFields by @bheesham in https://github.com/jazzband/django-simple-history/pull/1011
    • Added support for Django 4.1 by @hramezani in https://github.com/jazzband/django-simple-history/pull/1021
    • Add pyupgrade to .pre-commit-config.yaml by @hramezani in https://github.com/jazzband/django-simple-history/pull/1022
    • Enable diffing m2m fields by @thijskramer in https://github.com/jazzband/django-simple-history/pull/932

    New Contributors

    • @fabiocapsouza made their first contribution in https://github.com/jazzband/django-simple-history/pull/982
    • @twolfson made their first contribution in https://github.com/jazzband/django-simple-history/pull/975
    • @creyD made their first contribution in https://github.com/jazzband/django-simple-history/pull/996
    • @bheesham made their first contribution in https://github.com/jazzband/django-simple-history/pull/1011
    • @thijskramer made their first contribution in https://github.com/jazzband/django-simple-history/pull/932

    Full Changelog: https://github.com/jazzband/django-simple-history/compare/3.1.1...3.2.0

    Source code(tar.gz)
    Source code(zip)
  • 3.1.1(Apr 23, 2022)

    What's Changed

    • Fix stale py36 references in pyproject.toml by @jeking3 in https://github.com/jazzband/django-simple-history/pull/978
    • Fix local setup.py install versioning issue by @jeking3 in https://github.com/jazzband/django-simple-history/pull/978
    • Prepare for 3.1.1 and remove py2 universal wheel by @jeking3 in https://github.com/jazzband/django-simple-history/pull/979

    Full Changelog: https://github.com/jazzband/django-simple-history/compare/3.1.0...3.1.1

    Source code(tar.gz)
    Source code(zip)
  • 3.1.0(Apr 23, 2022)

    Breaking Changes

    • Dropped support for Django 2.2 (gh-968)
    • Dropped support for Django 3.1 (gh-952)
    • Dropped support for Python 3.6, which reached end-of-life on 2021-12-23 (gh-946)

    Upgrade Implications

    • Run makemigrations after upgrading to realize the benefit of indexing changes.

    Full list of changes

    • Added queryset-based filtering with as_of (gh-397)
    • Added index on history_date column; opt-out with setting SIMPLE_HISTORY_DATE_INDEX (gh-565)
    • RecordModels now support a no_db_index setting, to drop indices in historical models, default stays the same (gh-720)
    • Support included_fields for history.diff_against (gh-776)
    • Improve performance of history.diff_against by reducing number of queries to 0 in most cases (gh-776)
    • Fixed prev_record and next_record performance when using excluded_fields (gh-791)
    • Fixed update_change_reason in pk (gh-806)
    • Fixed bug where serializer of djangorestframework crashed if used with OrderingFilter (gh-821)
    • Fixed make format so it works by using tox (gh-859)
    • Fixed bug where latest() is not idempotent for identical history_date records (gh-861)
    • Added excluded_field_kwargs to support custom OneToOneField that have additional arguments that don't exist on ForeignKey. (gh-870)
    • Added Czech translations (gh-885)
    • Added ability to break into debugger on unit test failure (gh-890)
    • Added pre-commit for better commit quality (gh-896)
    • Russian translations update (gh-897)
    • Added support for Django 4.0 (gh-898)
    • Added Python 3.10 to test matrix (gh-899)
    • Fix bug with history.diff_against with non-editable fields (gh-923)
    • Added HistoricForeignKey (gh-940)
    • Support change reason formula feature. Change reason formula can be defined by overriding get_change_reason_for_object method after subclassing HistoricalRecords (gh-962)
    Source code(tar.gz)
    Source code(zip)
  • 3.0.0(Apr 16, 2021)

    Breaking changes:

    • Removed support for Django 3.0
    • Removed changeReason in favor of _change_reason (see 2.10.0)

    Full list of changes:

    • Removed support for Django versions prior to 2.2 (gh-652)
    • Migrate from TravisCI to Github Actions (gh-739)
    • Add Python 3.9 support (gh-745)
    • Support ignore_conflicts in bulk_create_with_history (gh-733)
    • Use asgiref when available instead of thread locals (gh-747)
    • Sort imports with isort (gh-751)
    • Queryset history.as_of speed improvements by calculating in the DB (gh-758)
    • Increase black and isort python version to 3.6 (gh-817)
    • Remove Django 3.0 support (gh-817)
    • Add Django 3.2 support (gh-817)
    • Improve French translations (gh-811)
    • Remove support for changeReason (gh-819)
    Source code(tar.gz)
    Source code(zip)
  • 2.12.0(Oct 14, 2020)

    • Add default date to bulk_create_with_history and bulk_update_with_history (gh-687)
    • Exclude ManyToManyFields when using bulk_create_with_history (gh-699)
    • Added --excluded_fields argument to clean_duplicate_history command (gh-674)
    • Exclude ManyToManyFields when fetching excluded fields (gh-707)
    • Use default model manager for bulk_create_with_history and bulk_update_with_history instead of objects (gh-703)
    • Add optional manager argument to bulk_update_with_history to use instead of the default manager (gh-703)
    • Add support for Django 3.1 (gh-713)
    • Fix a bug with clean_old_history command's --days argument (gh-722)

    * NOTE: This will be the last minor release before 3.0.0.

    Source code(tar.gz)
    Source code(zip)
  • 2.11.0(Jun 20, 2020)

    • Added clean_old_history management command (gh-675)
    • Added user_db_constraint param to history to avoid circular reference on delete (gh-676)
    • Leverages get_user from HistoricalRecords in order to set a fallback user on bulk update and bulk create (gh-677)
    Source code(tar.gz)
    Source code(zip)
  • 2.10.0(Apr 27, 2020)

    • Added bulk_update_with_history utility function (gh-650)
    • Add default user and default change reason to bulk_create_with_history and bulk_update_with_history (gh-653)
    • Add french translation (gh-654)
    • Start using _change_reason instead of changeReason to add change reasons to historical objects. changeReason is deprecated and will be removed in version 3.0.0 (gh-655)
    Source code(tar.gz)
    Source code(zip)
  • 2.9.0(Apr 23, 2020)

    • Add simple filtering if provided a minutes argument in clean_duplicate_history (gh-606)
    • Add setting to convert FileField to CharField instead of TextField (gh-625)
    • Added notes on BitBucket Pipelines (gh-627)
    • import model ContentType in SimpleHistoryAdmin using django_apps.get_model to avoid possible AppRegistryNotReady exception (gh-630)
    • Fix utils.update_change_reason when user specifies excluded_fields (gh-637)
    • Changed how now is imported from timezone (timezone module is imported now) (gh-643)
    • settings.SIMPLE_HISTORY_REVERT_DISABLED if True removes the Revert button from the history form for all historical models (gh-632))
    Source code(tar.gz)
    Source code(zip)
  • 2.8.0(Dec 2, 2019)

    • Fixed bulk_create_with_history support for HistoryRecords with relation_name attribute (gh-591)
    • Added support for bulk_create_with_history for databases different from PostgreSQL (gh-577)
    • Fixed DoesNotExist error when trying to get instance if object is deleted (gh-571)
    • Fix model_to_dict to detect changes in a parent model when using inherit=True (backwards-incompatible for users who were directly using previous version) (gh-576)
    • Use an iterator for clean_duplicate_history (gh-604)
    • Add support for Python 3.8 and Django 3.0 (gh-610)
    Source code(tar.gz)
    Source code(zip)
Owner
Jazzband
We are all part of this
Jazzband
The Django Leaflet Admin List package provides an admin list view featured by the map and bounding box filter for the geo-based data of the GeoDjango.

The Django Leaflet Admin List package provides an admin list view featured by the map and bounding box filter for the geo-based data of the GeoDjango. It requires a django-leaflet package.

Vsevolod Novikov 33 Nov 11, 2022
Helps working with singletons - things like global settings that you want to edit from the admin site.

Django Solo +---------------------------+ | | | | | \ | Django Solo helps

Sylvain Toé 726 Jan 8, 2023
Django-static-site - A simple content site framework that harnesses the power of Django without the hassle

coltrane A simple content site framework that harnesses the power of Django with

Adam Hill 57 Dec 6, 2022
Django application and library for importing and exporting data with admin integration.

django-import-export django-import-export is a Django application and library for importing and exporting data with included admin integration. Featur

null 2.6k Dec 26, 2022
Simple API written in Python using FastAPI to store and retrieve Books and Authors.

Simple API made with Python FastAPI WIP: Deploy in AWS with Terraform Simple API written in Python using FastAPI to store and retrieve Books and Autho

Caio Delgado 9 Oct 26, 2022
django-quill-editor makes Quill.js easy to use on Django Forms and admin sites

django-quill-editor django-quill-editor makes Quill.js easy to use on Django Forms and admin sites No configuration required for static files! The ent

lhy 139 Dec 5, 2022
Simple yet powerful and really extendable application for managing a blog within your Django Web site.

Django Blog Zinnia Simple yet powerful and really extendable application for managing a blog within your Django Web site. Zinnia has been made for pub

Julien Fache 2.1k Dec 24, 2022
Displaying objects on maps in the Django views and administration site.

DjangoAdminGeomap library The free, open-source DjangoAdminGeomap library is designed to display objects on the map in the Django views and admin site

Vitaly Bogomolov 31 Dec 28, 2022
Store events and publish to Kafka

Create an event from Django ORM object model, store the event into the database and also publish it into Kafka cluster.

Diag 6 Nov 30, 2022
An API was build with Django to store and retrieve information about various musical instruments.

The project is meant to be a starting point, an experimentation or a basic example of a way to develop an API with Django. It is an exercise on using Django and various python technologies and design methodologies.

Kostas Ziovas 2 Dec 25, 2021
Django admin CKEditor integration.

Django CKEditor NOTICE: django-ckeditor 5 has backward incompatible code moves against 4.5.1. File upload support has been moved to ckeditor_uploader.

null 2.2k Jan 2, 2023
Django admin CKEditor integration.

Django CKEditor NOTICE: django-ckeditor 5 has backward incompatible code moves against 4.5.1. File upload support has been moved to ckeditor_uploader.

null 2.2k Dec 31, 2022
Add Chart.js visualizations to your Django admin using a mixin class

django-admincharts Add Chart.js visualizations to your Django admin using a mixin class. Example from django.contrib import admin from .models import

Dropseed 22 Nov 22, 2022
📝 Sticky Notes in Django admin

django-admin-sticky-notes Share notes between superusers. Installation Install via pip: pip install django_admin_sticky_notes Put django_admin_sticky_

Dariusz Choruży 7 Oct 6, 2021
mirage ~ ♪ extended django admin or manage.py command.

mirage ~ ♪ extended django admin or manage.py command. ⬇️ Installation Installing Mirage with Pipenv is recommended. pipenv install -d mirage-django-l

Shota Shimazu 6 Feb 14, 2022
Super simple bar charts for django admin list views visualizing the number of objects based on date_hierarchy using Chart.js.

Super simple bar charts for django admin list views visualizing the number of objects based on date_hierarchy using Chart.js.

foorilla LLC 4 May 18, 2022
Intellicards-backend - A Django project bootstrapped with django-admin startproject mysite

Intellicards-backend - A Django project bootstrapped with django-admin startproject mysite

Fabrizio Torrico 2 Jan 13, 2022
Generate generic activity streams from the actions on your site. Users can follow any actors' activities for personalized streams.

Django Activity Stream What is Django Activity Stream? Django Activity Stream is a way of creating activities generated by the actions on your site. I

Justin Quick 2.1k Dec 29, 2022
A Django app that allows visitors to interact with your site as a guest user without requiring registration.

django-guest-user A Django app that allows visitors to interact with your site as a guest user without requiring registration. Largely inspired by dja

Julian Wachholz 21 Dec 17, 2022