Должны ли группы и разрешения Django быть жестко запрограммированы или загружены?

Я создаю приложение, которое предполагает наличие определенных групп и разрешений для своего рабочего процесса. Например, «член» может войти в приложение и просматривать и редактировать свои личные данные, но не может видеть заметки, которые обычно отображаются на том же экране. «Сотрудник» может видеть эти заметки и создавать или редактировать свои собственные, но только «менеджер участников» может удалять или редактировать чьи-либо заметки.

Моя проблема связана с загрузкой данных для этого приложения. Я могу создать данные фиксации JSON для групп, но тогда мне придется жестко закодировать PK, что кажется плохой практикой (что, если стороннее приложение, которое я хотел использовать, сделало то же самое и возник конфликт?) проблема заключается в разрешениях - мне пришлось бы добавить ПК к разрешениям, которые, в свою очередь, будут иметь ПК к своим типам контента.

Я читал об использовании хука post_syncdb для добавления исходных данных более программным способом, который, как я надеюсь, поможет мне решить жестко закодированную проблему PK. Но мне интересно, является ли это лучшим решением этой проблемы, или я «злоупотребляю» концепциями Django Group и Permission здесь и должен делать что-то еще, например создавать новые модели или просто ставить флаги (например, « is_member_manager") в моей модели профиля пользователя и т. д.


person Tony    schedule 23.10.2012    source источник


Ответы (1)


Обычно создают приложение с именем init с командой управления initialize, я помещаю туда весь код для начальной загрузки приложения. Это позволит вам:

  • если вы используете инструмент развертывания (я использую [Ansible](http://www.ansible.com/home, bat может быть amy tool Fabric, bash...) вы можете автоматизировать процесс и удалить init приложение из установленных приложений после подготовки (первой установки)

or

  • проверить, была ли уже запущена команда, чтобы пропустить процесс (Group.objects.all().exists() ? )

(или оба)

Я нашел это решение очень простым в обслуживании и достаточно мощным для любых обстоятельств.

post_syncdb (post_migrate в djang 1.7) не является решением, которое вызывается для каждой миграции

Если вам нужно только загружать данные и/или создавать записи (например, группы/администраторы...), ИМХО лучшим решением является использование миграции данных](https://docs.djangoproject.com/en/1.7/темы/миграции/#data-migrations)

person sax    schedule 11.12.2014