On 10/14/2014 09:46 AM, Collin Anderson wrote: > If you _really_ want it to be automatic, I think your best bet is to use > a middleware to store the user or request object in a "thread local" > variable, and then have a pre_save signal set the last_updated_by field > based on that. That method is frowned upon, but should work. (If you're > doing "green" threading, it may break.) The pre_save signal could error, > or something if it is not able to determine the request (like in the > command-line case).
I've done this while avoiding thread-locals (and signals) by just overriding the model save method to add a ``user`` argument, and giving the model a custom manager/queryset whose ``update`` method also takes a ``user`` argument. This just means anywhere you call ``save`` or ``update`` you have to pass in a ``user``. It's a bit more typing than doing it via thread-local and signals, but I much prefer making it explicit. Also makes it simpler for the cases (like a management command) where there is no request, but you may still have a way to identify the responsible user. If you use the admin, it means you have to customize the ModelAdmin slightly too so that it passes in the ``user`` kwarg, but that's not hard. Carl -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/543D4B2C.3070204%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
