If worse comes to worst, you could always patch the url dispatcher to store the user in a global variable before it calls the view. It should be sure to set that variable to None when the view returns, so that the global doesn't keep a reference on the user object between requests (a try finally around the call to the view will work fine. If you're running in a multi-threaded interpreter you need to think a little harder, but it should still be doable.
And alternative is to look up the call stack for a function whose first argument is a request object, assume that it is *the* request object, and extract the user from there. Both these assume that you're using the standard auth middleware that puts a user attribute on the request object. Hopefully someone else will have better solutions. On Fri, Jan 29, 2010 at 12:05 PM, Shawn Milochik <sh...@milochik.com> wrote: > I need to implement auditing for my models. The current plan is to listen for > the post_save() signal and dump the current values of the instance to an > external database. > > The only problem is that I need to store the request.user with this data, and > I don't see any way to capture that, since it appears to be completely out of > scope. Is there any clean way to get that? > > Thanks, > Shawn > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
