Как создать 2 разных админ-сайта в проекте Django? - PullRequest
17 голосов
/ 08 июля 2010

Я хочу иметь 2 отдельных админ-сайта внутри проекта Django.

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

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

Я думал о том, чтобы просто сделать копию приложения od django.contrib.auth в моем дереве проектов, присвоить ему другое имя и использовать для каждого из них отдельные вызовы admin.site.register(). Таким образом, я могу иметь другие модели, доступные в каждой из них, различные взгляды и т. Д. Я не знаю, как решить проблему аутентификации пользователя (у меня должен быть другой пользователь, чтобы иметь возможность войти в CMS, а затем в BackOffice) .

Кто-нибудь случайно делал это раньше и мог дать мне подсказку? Или то, что я планирую сделать, просто неправильно по замыслу?

Ответы [ 3 ]

39 голосов
/ 08 июля 2010

Вы можете создать подкласс 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, вам нужно добавить параметр name, чтобы он работал правильно. Это используется для создания 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

8 голосов
/ 08 июля 2010

Чтобы зарегистрировать модели на разных сайтах AdminSite, вам просто нужно создать разные экземпляры django.contrib.admin.sites.AdminSite, см. Это.

Вам будет хорошо работать с двумя разными сайтами администратора, управляющими разными моделями и имеющими разные шаблоны. Для аутентификации и разрешений вы должны иметь возможность использовать встроенный django.contrib.auth, как и с пользовательскими разрешениями (надеюсь, кто-то еще сможет помочь здесь)

0 голосов
/ 17 ноября 2013

Я не уверен, что мои находки, о которых здесь сообщалось, были бы полностью полезны для Кендера, потому что, среди прочего, я не знаю, говорил ли он не только о двух сайтах администратора, но и о двух базах данных, одна для каждый. Это моя ситуация. Мне пришла в голову яркая идея, что я хочу, чтобы одно из моих приложений, новое приложение, имело собственную базу данных и собственные страницы администратора.

Но я столкнулся с проблемой подхода на основе подклассов 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 о том, что страница не существует.

Кроме того, я не знаю, что это имеет значение, но я сделал нечто отличное от того, что Бернхард Валлант сделал в проекте 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)),
)

ОК, "someword" не имеет значения --- там для внешности относительно конечного пользователя, а не названия приложения или проекта. Но связанный админ для моего старого приложения и старой базы данных. Обратите внимание на включение автообнаружения (). В документах есть какой-то мутный язык, с которым Бернхард Валлант связал его использование, когда проект urlconf настроен так, как у Бернхарда Валланта он есть с импортом myadmin, но также со ссылкой на администратора по умолчанию.

А для 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's views"),
)

Несмотря на крайнюю необходимость присвоения экземпляру AdminSite внутреннего имени чему-то другому, нежели «admin», я должен добавить, что когда пришло время объединить файл admin.py в mynewapp с некоторыми подклассами admin.ModelAdmin, это было действительно необходимо используйте admin.ModelAdmin в качестве родительского класса. В конце концов, myadmin является экземпляром подкласса AdminSite. Таким образом, я понимаю, что это наравне с admin.site, а не с admin.

Это все очень запутанно для такого NOOB, как я, потому что администратор в нижнем регистре выглядит как экземпляр, а я не знаком с экземплярами подклассов. Поэтому я предполагаю, что это не так.

...