Re: Can anyone give me a suggestion or a recommendation as to how I can access the current user's username in the models.py?

Collin and Russell (and anyone else),

Do you have any opinion on this?
- https://bitbucket.org/aptivate/django-current-user

It was offered in an earlier post:
- https://groups.google.com/d/msg/django-users/y7aIbN2_CsA/GtmrSjG1nq8J

as a solution to exactly this problem.

Makes the current user available to the save() method of all
models.

I read the code and it looks good, but I don't know the details
of Apache/WSGI/Django/Python multi-threading well enough
to know if it is thread safe. 

It basically uses django.db.models. signals.pre_save.connect()
to get a callback called just before each save(), and that callback
was generated by a middleware layer to know what the current
user was for a request, so it sets a model field with a name like
update_user to the current user just before the save().

If there were 2 concurrent HTTP requests, would this work
reliably?  Or would there just be 2 registered callbacks, that
would overwrite each other's values in the update_user field
before the save()?  If so, one user would be recorded for saves
done by both requests.

It seems to me that this would work fine if each HTTP request
was handled by a separate process, but not if handled by
separate threads that share the same memory, and presumably
the same signals and callbacks.

Thoughts?

--Fred

---

Fred Stluka -- mailto:fred@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.

---

On 12/14/14 2:13 PM, Collin Anderson wrote:

Hi,

The "admin save handlers" refers to save_model() and there's actually a nice example of accessing the user.

https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.save_model

If you're using the admin, that's a good place to record this sort of thing.

Using a middleware is also helpful for a more general approach, though be careful because connections can now be re-used over multiple requests. Also, if you're deploying using threading, be sure what you are doing is thread-safe.

Collin

On Friday, December 12, 2014 5:29:35 AM UTC-5, malt...@gmail.com wrote:

Thanks Mike and Russell, this is very helpful for starters. Do you have some more verbose code examples I can use as crutches while I hobble along the path of understanding Django? Especially an expansion on something like "All the admin save handlers" would be much appreciated.

For me every change needs to be tracked, not just ones from the admin realm, and the audit trail entry is written by a trigger function which gets the current user name from a variable set for the postgres connection. My quest so far was to find the magical place where I have access to the request (for the username) and the db.connection (for setting the database variable), which – if I understand correctly – does not exist. So right now I was about writing my own middleware class with a process_view. Would that be the right place and how would I introduce the username into the data flow?


Sincerely,

Malte

--
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+unsubscribe@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/561482b8-a4bf-44fd-9c7d-ef2bbec54726%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.