Ever wanted to add a link or two at the end of a row in a model's change list?  Say you had a model for people and a model for registrations or blog posts and you want to modify the people change list so it has a link to, say all of the registrations or blog posts for the person.
Well, Django provides half of the solution already in that the example registration change_list already handles the display of all registrations tied to that person.  For example, the url `/admin/registrations/registration/?person__id__exact=121` gets you to a filtered list of registrations for the person with the id of 121.  This is the same url used if you use list_filter in your model definition (though setting list_filter is not required for what we're doing).
Okay, so to add a link to the end of each person row in the change list, you need to create a template tag similar to "person_result_list" in the code.  There, I've given an example that adds two links.  Each dictionary in additional_links needs to have at least a text, sortable, and url_template attribute.  The text attribute is what will display as the header to the column.  url_template will be fed the id of the row object (in this example, a person id), which you can use to construct the link for each row.  You could extend this if you wish, though all I ever need is the id.
And the last step is to use your new template tag in a modified change_list.html in place of the default result_list tag.  The example at the bottom of the code shows an example usage of the tag.
Hope this makes sense and is helpful to someone!
                
                    
                    
                    - template
- admin
- tags
- change_list
 
            
            
        
        
        
            
                
                I wanted to make the objects of a particular model approvable and store the timestamp of when that happened. In other frameworks/languages, I used to combined those in one "approved_at" field, which would be NULL if an object was currently unapproved.
I tried different approaches to implement this in django, and this is the best I came up with so far. Basically, the code in __setattr__ makes sure that the field, once set, will not be updated again.
Overriding setattr__() could also be a solution to determining if a field value has changed in save(), a question that seems come up from time to time in #django.
                
                    
                    
                    - newforms
- models
- fields
- forms
- save