2014-01-07 5 views
2

Использование Django 1.5 здесь. У меня есть приложение, которое я создал, который в настоящее время имеет один большой набор данных, для одной «учетной записи», если хотите. Значение всех данных во всех моделях моего приложения доступно всем зарегистрированным пользователям. Теперь я хочу, чтобы позволить большему числу людей использовать мое приложение, но с их собственным набором данных. Поэтому мне нужно разделить пользователей на разные учетные записи с разными наборами данных для каждой учетной записи. Там может быть один или несколько пользователей, имеющих доступ к каждой учетной записи. В настоящее время мне не нужны разные пользователи в одной учетной записи, чтобы иметь разные уровни доступа, хотя я намереваюсь, чтобы один пользователь был владельцем учетной записи.Django: несколько учетных записей с несколькими пользователями под каждой учетной записью, но данные для учетной записи

enter image description here

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

Несколько мыслей у меня было до сих пор:

  • Просто фильтровать каждый и каждый запрос по счету
  • Wrap каждый вид с декоратором, но с несколькими моделями, у меня есть, чтобы создать другой декоратор для каждой модели? Могу ли я сказать из декоратора, к какой модели обращаются?
  • Как-то используйте декоративный декодер системы Auth user_passes_test, но опять же, разные модели.
  • Расширение системы auth для включения атрибута request.account
  • Создать новый миксин для просмотра? Что делать, если я не использую исключительно CBV?
  • Различные промежуточное ПО?

Я рассмотрел возможность использования новой группы для каждой учетной записи, а затем фильтрацию по группе вместо новой модели учетных записей, но я предсказываю, что это будет плохо соответствовать этой ситуации, поскольку она не использует группы, поскольку они были предназначены ,

Это вопрос не только о кодах, но и многом другом. Как бы вы к этому подошли?

+0

Я не получаю цели цели/пользователя/разделения данных. можете ли вы описать его более подробно? – Alp

ответ

2

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

http://spapas.github.io/2013/11/05/django-authoritiy-data/

резюмировать пост, я предлагаю просто добавив Authority модели, для которой ваша User будет иметь ForeignKey (каждый User будет иметь a Profile).

Теперь все ваши модели, чьи данные будут принадлежать определенному Authorities, будут содержать только ForeignKey до Authority. Чтобы проверить разрешения, вы можете использовать CBVs - администратор django будет доступен только центральным администраторам, которые имеют доступ ко всем данным. Я рекомендую не использовать разрешения django для авторизации данных Authority. Если вы хотите прочитать сообщение, которое более подробно, и задайте здесь любые вопросы.

Смежные вопросы