Django как сделать запрос к профайлу user'a в шаблоне и проверить принадлежность к группе?

Question

[zigen]

Добрый день. Стоит довольно тривиальная задача создать два типа пользователей на сайте.
Я изначально,наверное. пошел по неверному пути и просто расширил модель встроенного User двумя профайлами, а при регистрации одного из типов пользователей добавлял в группу, чтобы можно их было разделять.
Сейчас создаю для пользователей личные кабинеты и столкнулся вроде бы не сложной проблемой.
Как в шаблоне понять принадлежит ли юзер определенной группе и в зависимости от результата отдавать ссылку на профайл. И второе - как получить значение поля профайла юзера в шаблоне.

class VendorProfile(models.Model):
    user = models.OneToOneField(User, related_name='vprofile')
    org_name = models.CharField(max_length=50, blank=True)
    slug = models.SlugField(unique=True)
    #....

class UserProfile(models.Model):
    user = models.OneToOneField(User,related_name='uprofile')
    website = models.URLField(blank=True)
    avatar = models.ImageField(upload_to='profile_images', blank=True)

Answer 1

[Максим Дунаевский]

В статье я написал, как делать расширенную модель пользователя: dunmaksim.blogspot.ru/2015/05/django-18.html
Для решения Вашей задачи нужно:

• описать базовую модель User с полем role или полями вида is_user, is_vendor и т.п.
  
• унаследовать от неё классы Vendor и PlainUser
  

В виде делаем ещё проще (показано для ClassBasedView, так же требуется обязательная авторизация, но Вы можете допилить для себя):

from os import path

from django.contrib.auth.decorators import login_required
from django.core.context_processors import csrf
from django.shortcuts import render_to_response
from django.template import RequestContext
from django.views.generic import View


class Login(View):

    def get(self, request):
        c = {}
        c.update(csrf(request))
                RequestContext(request, c)
        return render_to_response(
            path.join('login', 'index.html'),
            RequestContext(request, c)
        )


class LoginRequiredMixin(object):

    @classmethod
    def as_view(cls, **initkwargs):
        view = super(LoginRequiredMixin, cls).as_view(**initkwargs)
        return login_required(view)


class Desktop(LoginRequiredMixin, View):

    def get(self, request):
        c = {}
        c.update(csrf(request))
        user = request.user
        if user.is_admin:
            return render_to_response(
                path.join('admin', 'index.html'),
                RequestContext(request, c)
            )
        if user.is_vendor:
            return render_to_response(
                path.join('vendor', 'index.html'),
                RequestContext(request, c)
            )
        return render_to_response(
            path.join('desktop', 'index.html'),
            RequestContext(request, c)
        )

Comments

[zigen]

А как выкрутиться из текущего решения? Проверить из шаблона принадлежность к группе и получить slug из профайла

[sim3x]

zigen: делать шаблон умным нельзя

[Максим Дунаевский]

zigen: Можете изговнять весь свой шаблон множественными проверками {% if user.is_vendor %} ... {% endif %}, потом получить мощнейший баттхёрт, когда спустя месяц скажут добавить третью сущность, например, какой нибудь посредник BrockerUser.

[zigen]

Максим Дунаевский: Ок. Я только не понял зачем нужно "описать базовую модель User " и от нее наследоваться. Разве не проще два раза унаследоваться от AbstractUser? ЗЫ не судите строго, слабо еще разбираюсь в джанговском auth

[Максим Дунаевский]

zigen:
Первая итерация: создаём наследников от AbstractUser, всё работает, но вдруг выясняется, что у нас пользователь не Vendor, а просто User, и свойство is_vendor у него отсутствует, а потому при получении данных начинаются проблемы - ошибка при обращении к несуществующему свойству. Переписываем User, добавляем свойство is_vendor, которое всегда возвращает False, всё снова начинает работать. Вдруг выясняется, что у Vendor нет свойства avatar, которое есть у User, переписываем модель Vendor, чтобы добавить сво... WAIT, OH SHI~
Вторая итерация: создаём базовую модель со всеми нужными свойствами, такими, как is_staff, is_admin, avatar и т.д. Надо сменить пароль. Нужно ли проверять, является пользователь Vendor и инстанцировать экземпляр КОНКРЕТНОГО класса? Нет, достаточно BaseUser, а дальше включается вся мощь наследования.

[zigen]

Максим Дунаевский: Вроде бы ясно, попробуем! Спасибо.

[zigen]

Максим Дунаевский: Еще хотел уточнить. Сначала я наследуюсь от AbstractBaseUser и создаю базового пользователя MyBaseUser,например, в нем описываю общие атрибуты и указываю атрибут is_vendor. Затем от MyBaseUser наследую PlainUser и Vendor в которых описываю уже частные поля модели. В settings добавляю AUTH_VENDOR_MODEL=MyBaseUser.Vendor и AUTH_USER_MODEL=MyBaseUser.PlainUser и уже работаю с ними. Я верно понял идею?

[Максим Дунаевский]

В AUTH_USER_MODEL указываете только базовый класс, в Вашем случае - MyBaseUser. Vendor и PlainUser будут неявно использовать эту же таблицу в БД для получения значений базовых свойств.
Как получить экземпляр нужного класса (например, Vendor), зная id текущего пользователя:

user = request.user

if user.is_anonymous:
    # Делаем что-то для анона

if user.is_vendor:
    vendor = Vendor.objects.get(id=user.id) # Магия! id одинаковы!