Changes between Version 5 and Version 6 of AuditTrail

Timestamp:

Aug 27, 2007, 9:41:33 AM (17 years ago)

Author:

George Vilches <gav@…>

Comment:

--

AuditTrail

@@ -60 +60 @@
 ForeignKeys and OneToOneFields are now supported both for saving and accessing the audit data.  However, it does not archive the contents of the ForeignKey table for the appropriate entries at the same time, and will fail if the ForeignKey a given audit entry is related to is deleted (including if you're auditing the ForeignKey table as well, it does not have a way to link the two audit tables together).
 
+== Tracking Extra Information ==
+Sometimes you need to track more information than is available in just the model.  For instance, you may want to know who is performing the change on a particular entry, or track some sort of state information about the system.  AuditTrail now supports this through the concept of "track fields".  These can be specified on a per-model basis or a global basis, and the per-model options will stack with the global ones (but per-model options cannot override global ones currently).  Here's an example:
+
+{{{
+def some_callback(instance):
+    return `random.randrange(1, 99)` + 'trackable_val'
+
+class Person(models.Model):
+    first_name = models.CharField(maxlength=255)
+    last_name = models.CharField(maxlength=255)
+    salary = models.PositiveIntegerField()
+    history = audit.AuditTrail(track_fields=(('extra_1', models.CharField(maxlength=50), 'hardcoded_value'), ('extra_2', models.CharField(maxlength=50), some_callback),))
+
+    def __str__(self):
+        return "%s %s" % (self.first_name, self.last_name)
+}}}
+
+The track_fields is a tuple of 3-tuples.  The 3-tuples are structured {{{ (field_name, type_of_field, value) }}}.  `type_of_field` can be any currently functioning field type, although see the [#Caveats Caveats] for issues related to ForeignKeys.  `value` can be either a static value or a callback function, which will get called at the time of the save/delete.  This means that if you want to do something involving threadlocals at runtime (for getting things out of the request, for instance) you can do it via this callback.
+
+Assume we ran the example above with this new model.  You could then do the following:
+
+{{{
+>>> p_hist = person.history.all()
+[<PersonAudit: John Public as of 2007-08-27 09:29:14>, <PersonAudit: John Public as of 2007-08-27 09:28:57>]
+>>> p_hist[0].extra_1
+'hardcoded_value'
+>>> p_hist[0].extra_2
+'27trackable_val'
+}}}
+
+Currently, you cannot filter on these trackable columns, this should be fixable.
+
+=== Global Track Fields ===
+
+What if you have a field you want tracked on every model that supports history?  No problem!  In the root of your project, create a file called settings_audit.py, and put something like this in it:
+
+{{{
+from django.db import models
+
+def callback_func_ptr2(original_instance):
+    import random
+    return `random.randrange(1, 99)` + 'hardcoded_global_2'
+
+# Populate the fields that every Audit model in this app will use.
+GLOBAL_TRACK_FIELDS = (
+    ('global_1', models.CharField(maxlength=50), 'hardcoded_global_1'),
+    ('global_2', models.CharField(maxlength=20), callback_func_ptr2),
+)
+
+}}}
+
+GLOBAL_TRACK_FIELDS is set up exactly the same way as the track_fields option passed into AuditTrail, and has the same uses and limitations.
+
 == Caveats ==
 This needs testing!  This has only been used in a few cases, there's plenty of possible room for strangeness.  It has specifically not been tested for things like safe (de-)serialization.