I'm writing a lot of models these time and most of them requires some generic informations, some kind of meta data like who create the object and when, who was the last to modify it and when.
I used to add manually those fields to my models, but even when they represented the same data I used different names and it started to bug me. For example, if the model was for storing messages I would probably use sent_by and when I'm dealing with something else, like a calendar event for example, I would most likely use created_by. It quickly becomes boring trying to remember how I named those field for each models, especially when semantically they are equivalents.
Then I recalled that Django's models support inheritance, which is awesome since it would allow me to reuse those fields and thus normalizing my field names. How pretty.
UPDATE: I added abstract = True because someone pointed out I should use it. He didn't say why but after some digging I found that it makes sense. If I don't use an abstract base class Django will create two tables and keep the relationship using a table join, which is not really bad but not really optimal either. By specifying abstract Django knows it must create only one table and thus avoid table joins.
UPDATE 2: I also replaced 'object_modifier' and 'object_creator' with '%(class)s_modifier' and '%(class)s_creator'. This way related names are created dynamically so they don't clash when multiple models are used.
I knew for quite a while about model inheritance in Django so I can't really explain why I didn't do this before, sometime it's just too obvious I guess. However there's one little bit of magic to add in order to make it silky smooth and transparent with the Django admin.
The main problem is that we want those field to auto-populate themselves. It's piece of cake for the DateTime field using auto_now*, but it's not that simple with the user fields. By design Django doesn't allow access to the request object within the model so it's not really possible to get the user who performed the request and bypassing this design decision somewhat defeat a good design decision.
We could overload the save method with a custom form, but it would only do the trick for custom views. The Django admin interface would still ask you to fill out manually those fields, which is not really optimal and really easy to cheat or at least, not really reliable.
To achieve what we want, we need to overload the save method in an admin object. Fortunately admin objects also support inheritance, so we can do it quite easily without repeating ourselves;