0.3.2

[RobCombs]

• Added documentation for installation
• Added support for handling and displaying foreign keys
• Added unit test support using tox
• Made display more appealing
• Added full serialization of inherited fields
• Fixed bugs

[jantman]

I can confirm that I'm using this code in an internal Django 1.5.4 app and it seems to work perfectly, and fixes the simplejson errors introduced by using fullhistory 0.3.1 with django 1.5+.

[RobCombs]

We also use version 0.3.2 of django-fullhistory in our production environment that has heavy traffic. Here are a few screenshots:
http://grab.by/qqI0
http://grab.by/qqIe
http://grab.by/qqIm

[jantman]

It's been five months. Can we please either get a response on this PR, or have maintainership of the PyPI package transferred to us?

[nikolajbaer]

Hi,

We will look to merge this pull request in the coming week. Sorry for the delay!

[jantman]

@RobCombs hey if you happen to get a chance, could you take a peek at the merge conflicts and see if we can finally get this merged? I'm a bit confused, it seems like someone pushed to master recently... if you don't have the time or desire, I can try to get this done...

[nikolajbaer]

I took a look at merging this and the only issue i am not clear on is the change on fullhistory/admin.py where you replace the context variable with a hardcoded version. This eliminates the ability for extra_context to be passed in. I am not sure of the implication of this in our code, but I imagine the most compatible approach would be to have it be both your admin_name change, as well as the extra context.

e.g.

context = dict(self.get_context(), **(extra_context if extra_context else {}))
context.update({'admin_name': getattr(self.admin_site, 'name', 'admin'),})

I am going to take a look at how this impacts our systems, but would this work for you application?

Thanks,
Nikolaj