Я хочу иметь 2 отдельных сайта администратора внутри проекта Django.
Отдельно я имею в виду - у них должна быть отдельная аутентификация пользователей, они должны администрировать разные модели и иметь разные взгляды и URL-адреса.
Причина, по которой я хочу это сделать, заключается в том, что клиент хочет, чтобы отдельный раздел администрировал часть CMS на странице и отделялся от использования в качестве "бэк-офиса".
Я подумал о том, чтобы сделать копию django.contrib.auth appliaction в моем дереве проектов, назвав ее по-разному и используя отдельные вызовы admin.site.register() для обоих из них. Таким образом, у меня могут быть доступны другие модели в каждом из них, разные взгляды и т.д. Я не знаю, как решить проблему аутентификации пользователя (у меня должен быть другой пользователь, чтобы иметь возможность входа в CMS затем в BackOffice).
Кто-нибудь это делал раньше и мог дать мне какой-то намек? Или что я планирую сделать, это просто неправильно по дизайну?
Для регистрации моделей в разных AdminSites вам просто нужно создать разные экземпляры django.contrib.admin.sites.AdminSite, посмотреть это.
Вам будет хорошо пойти с двумя разными административными сайтами, управляющими разными моделями и имеющими разные шаблоны. Для аутентификации и разрешений вы можете использовать встроенный django.contrib.auth, а также пользовательские разрешения (надеюсь, что кто-то еще сможет помочь здесь)
Вы можете подклассифицировать Django AdminSite (поместите его, например, в admin.py в корневой каталог проекта):
from django.contrib.admin.sites import AdminSite
class MyAdminSite(AdminSite):
pass
#or overwrite some methods for different functionality
myadmin = MyAdminSite(name="myadmin")
По крайней мере, с 1,9 до вас нужно добавить параметр имени, чтобы он работал правильно. Это используется для создания обратных URL-адресов, поэтому имя должно быть одним из urls.py.
Затем вы можете использовать его в своем приложении admin.py так же, как и с обычным экземпляром AdminSite:
from myproject.admin import myadmin
myadmin.register(MyModel_A)
Вам также нужно определить некоторые URL-адреса для него (в вашем проекте urls.py):
from myproject.admin import admin, user_site
from myproject.admin import myadmin
urlpatterns = patterns('',
...
(r'^admin/', include(admin.site.urls)),
(r'^myadmin/', include(myadmin.urls)),
Также см. это: http://docs.djangoproject.com/en/dev/ref/contrib/admin/#adminsite-objects
Я не уверен, что мое обнаружение, о котором сообщалось здесь, было бы очень полезно для кендера, потому что, между прочим, я не знаю, говорил ли он не только о двух сайтах администратора, но и о двух базах данных, один для каждый. Это моя ситуация. Я получил яркую идею о том, что я хотел, чтобы одно из моих приложений, новое приложение, имело собственную базу данных и собственные страницы администратора.
Но у меня возникла проблема с подклассическим подходом AdminSite Бернхарда Валанта, хотя, похоже, это была ортодоксальная и, по сути, правильная вещь. Я решил проблему.
Вот мода на код Бернхарда Валланта, который я нашел абсолютно необходимым:
from django.contrib.admin.sites import AdminSite
class MyAdminSite(AdminSite):
pass
#or overwrite some methods for different functionality
myadmin = MyAdminSite(name='anything')
Да, я действительно имею в виду name= "что угодно", которое вы выберете (пока это не "админ" ). И я переключился с ним, и он терпит неудачу каждый раз без назначения имени ничего, кроме admin.
Признаками, которые я приобрел, было то, что когда я добавил вторую базу данных и создал для нее myadmin, а затем зарегистрировал модель с myadmin.register(My_ModelA) и перешел посмотреть две страницы приложения администратора, одну для моей новое приложение, которое использовало вторую базу данных и myadmin, а модель My_ModelA выглядела отлично, но моя старая страница администратора показывала мертвые ссылки для своих моделей, и когда я нажал туда на не-мертвую ссылку для приложения (старое приложение, использующее старую базу данных ) У меня есть код 404, что страница не существует.
Кроме того, я не знаю, что это важно, но я сделал что-то отличное от того, что Bernhard Vallant сделал в проекте urlconf:
from django.conf.urls import patterns, include, url
from django.contrib import admin
admin.autodiscover()
urlpatterns = patterns('',
url(r'^admin/', include('mynewapp.urls')),
url(r'^someword/admin/', include(admin.site.urls)),
)
ОК, "someord" не имеет значения - там для выступлений с конечным пользователем, а не с именем приложения или проекта. Но связанный администратор - тот, который используется для моего старого приложения и старой базы данных. Обратите внимание на включение автообнаружения(). В документах, с которыми связан Bernhard Vallant, есть некоторые мутные слова, связанные с его использованием, когда проект urlconf настроен так, как Bernhard Vallant имеет его с myadmin import, но также со ссылкой на администратора по умолчанию.
И для urlconf для mynewapp у меня есть:
from django.conf.urls import patterns, url, include
from myproject.admin import myadmin
urlpatterns = patterns('',
url(r'/', include(myadmin.urls) )
)
urlpatterns += patterns('mynewapp.views',"... url() stuff for mynewapp views"),
)
Несмотря на полную необходимость называть ваш экземпляр AdminSite внутренне чем-то другим, кроме "admin", я должен добавить, что, когда пришло время разжечь файл mynewapp admin.py с некоторым подклассом admin.ModelAdmin, необходимо было действительно используйте admin.ModelAdmin как родительский класс. myadmin - это, в конце концов, экземпляр подкласса AdminSite. Как таковой, я понимаю, что он наравне с admin.site, а не с администратором.
Это все очень запутывает NOOB, как я, потому что администратор с нижним регистром выглядит как экземпляр, и я не знаком с экземплярами подкласса. Поэтому я предполагаю, что это не так.