Как определить текущего пользователя из модели?

Question

[Степан Крапивин]

Есть модель:

class Post(models.Model):
    title = models.CharField(max_length=127)
    datetime = models.DateTimeField(default=datetime.now())
    author = models.ForeignKey(User)
    content = models.TextField(max_length=4095)

В поле author, по умолчанию должен быть вписан пользователь, создающий запись.
Я знаю, что делать нужно через параметр default, но как определить текущего пользователя?

P.S.
Возможно, что правильным будет определять пользователя через саму форму создания поста, а не из модели?

Answer 1

[Сардар]

Нет, default там не нужен. Скорее всего User у вас из django.contrib.auth.models.User. А это значит, что у вас стоит AuthenticationMiddleware. А это значит, что у вас есть пользователь request.user, попробуйте его напечатать из вашего view. Значит вы можете post.author = request.user

Ваша форма скорее всего не включает поле с пользователем, а значит сохранять надо как post = form.save(commit=False), чтобы форма записала данные в post, но не пыталась его сохранить. Потом вы присваиваете пользователя.

А вообще, стоило бы полностью пройти туториал.

Comments

[Степан Крапивин]

да, про request.user я знаю, но request ведь доступен из views, так? А как views может повлиять на добавление Post через стандартную админку django?

[Сардар]

Админка это тоже view. Если вы используете django.contrib.admin (иными словами admin.py в вашем приложении), то у вашего ModelAdmin есть методы add_view, change_view etc. Все они принимают request, из которого есть доступ к текущему пользователю request.user Вы можете переопределить эти методы или инициализировать форму вместе с request, либо передать себе request в save_object. Вариантов масса. Я так понимаю, вы скрыли поле author, поэтому оно не появляется в форме с большим списком пользователей?

[Степан Крапивин]

нет, поле я не скрывал (собирался), но по умолчанию поле пустое, и приходится каждый раз при добавлении выбирать себя из списка. Именно проблемы "выбирания себя из списка" я и хочу решить

[Степан Крапивин]

но спасибо за то, что указали правильное направление: решить через request.user в admin.py

[Сардар]

Тогда все просто, добавляете к своему админу метод save_model(). По умолчанию это просто obj.save(), но вы перед этим можете проводить с объектом любые манипуляции. В документации по ссылке сразу приводится решение вашей проблемы, присвоение текущего пользователя.

Answer 2

[dibrovsd]

А чем не устроили сигналы?
Создание экземпляров модели может быть инициировано по цепочке сигналов или как-то по другому, а не только через админку.

Да и что теперь, писать один и тот же код в админке, всех views и так далее.

Внутри сигнала получить текущего пользователя без обращения к объекту request поможет вот такая middleware:
djangosnippets.org/snippets/2179
Она работает и свою задачу выполняет.

P.S. Если нужно описать более подробно, говорите.
Не стал описывать в деталях, чтоб не быть К.О.
Но если не получится разобраться самостоятельно, готов помочь.

Comments

[Сардар]

Если используется threading.local, то лучше сразу ложить туда request. Но стоит помнить, что на сервере с gevent workers необходим monkey patch пакета threading. Иначе можно нарваться на забавные баги, очень похожие на черную магию)

Сигналы, как и любая другая каскадная логика, могут резко усложнить жизнь при росте сложности проекта. Например сигналы, зависящие от request, превращаются в головную боль при восстановлении объектов из fixtures, работе с консоли и т.д. А если человек еще и не подумал о подключении к нескольким БД (аргумент using), то повреждения данных и танцы с транзакциями на несколько connections обеспечены.