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.

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)

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.

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:

and the form looks like this:

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.

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.

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.

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

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'

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.

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.

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

Bumps tox from 3.27.1 to 4.2.5.

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.

Bumps coverage from 6.5.0 to 7.0.3.

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.

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.

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

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):

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.

Bumps tox-gh-actions from 2.11.0 to 3.0.0.

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.

Bumps isort from 5.10.1 to 5.11.4.

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.