vikkyshostak
@vikkyshostak
< This head full of dreams.

Best practies? Две независимые модели для пользователя и админа, Django 1.11.x?

Всем доброго времени года!

После ударных месяцев поддержки разных API и мелких сайтиков на Flask/Bottle/Sanic, знакомые подкинули нулевой проект на Django 1.11.x (причём буквально «нулевой»: создано пару моделей, разделены настройки по окружениям, прописаны начальные тесты и тому подобное). С Джангой я знаком только с бородатой 1.6 версией (потом затянуло в пучину Laravel), и ничего серьёзней «Hello World» на нём не делал, а поучаствовать в проекте есть желание (в том числе, чтобы узнать Django по-лучше) :(

[лирика] Тема проекта: сайт-блог для владельцев собачек-кошечек-хомяков-etc, с пожертвованиями на лечение животных из приютов Петербурга (да-да, пора бы уже плюс в карму сделать, проект нон-профит). Соответственно, должен быть личный кабинет, где все эти транзакции пишутся, ибо планируется подключение онлайн кассы с ОФД (чтобы не нарушать 54-ФЗ). Зачем? Ну вообще закон надо соблюдать, да и потом отчитываться в налоговой, говорят, проще будет (сбор средств для животинок, а не своей наживы — всё по белому должно быть). [/лирика]

Итак, сам вопрос. Есть ли какие-либо проверенные и рабочие best practies для осуществления вот такой системы:
  1. Есть стандартный суперпользователь + модераторы сайта (модель User, которая из коробки);
  2. Есть модель для пользователей-меценатов CustomUser (с полями для личной инфы, телефона, etc);
  3. Эти две модели не должны пересекаться, то есть наследоваться или работать через proxy (две разных таблицы БД);
  4. Должна быть и стандартная авторизация для модели User, и отдельная — для модели CustomUser;
  5. Только модель CustomUserвидна в публичной части сайта (аля «больше всех в этом месяце помог [...], прислав [...]»;
  6. У CustomUser должен быть (приватный) личный кабинет (вне админки), со всеми транзакциями и редактированием;

[ремарка] Сама модель CustomUser — это что-то типа «покупатель пожертвования» (жесть, но по-другому не могу объяснить). То есть, планируется делать некие фиксированные «бандлы» с фирменными безделушками от партнёров (типа «1000 руб. = магнитик», «5000 руб. = футболочка» и так далее), чтобы нельзя было жертвовать произвольную сумму + что-то осталось на память :) [/ремарка]

Собственно, буду рад толковым комментариям и предложениям! Заранее спасибо.

P.S. я понимаю, что никто не даст тут «готового кода на блюдечке», но алгоритм построения такой системы — уже хлеб :D
  • Вопрос задан
  • 1170 просмотров
Решения вопроса 1
@immaculate
Программист-путешественник
Я не раз видел попытки такого разделения пользователей по классам в проектах на Django. Не знаю, почему все сразу выбирают такое решение, которое в перспективе не приносит ничего, кроме боли.

Проще всего пойти стандартным путем: унаследовать пользователя от django.contrib.auth.models.AbstractUser, а различие между пользователями определять либо по группе/разрешениям, либо добавить поле в свою модель типа is_moderator. Это будет во много раз (на порядок точно) проще реализовать и поддерживать, будет совместимость со всем стандартным кодом Django и сторонними библиотеками, любому просто войти в проект и внести изменения.

Разделение на две разных модели никаких абсолютно преимуществ не дает, кроме тонны мусорного кода и головняков с поддержкой данной гидры.

TLDR:
1) Из вашего вопроса остается неясным, почему требуется разделение по разным классам. Это самый безумный вариант для разграничения полномочий, и в Django разделение полномочий пользователей уже предусмотрено по умолчанию
2) Поддерживал пару проектов с разными классами для разных классов пользователей. Поверьте, это просто ужас-ужас в поддержке, а самое главное, что он ничем не оправдан.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
un1t
@un1t
Делаешь одну модель, добавляшь ей поле role например. И по ней потом даешь доступы.
Ответ написан
Делить пользователей на две таблицы не стоит, хотя бы потому, что множество библиотек сразу же не сможет с такой системой работать, или придётся писать костыли.

Я думаю, что проще всего использовать стандартную модель User + свою модель Profile, подключённую через OneToOneField. В ней можно собирать все необходимые свойства. Что мешает модератору сайта одновременно быть покупателем футболочек? Собственно ничего.

А теперь что касается проверок на is_staff. Посмотрите django-braces. Вам достаточно использовать class based views и подключать нужные mixins, - и вы забудете об этих проверках: большая их часть будет выполняться в mixins, а не в бизнес-логике предметной области. Вы можете и свои классы для этого дела написать.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы