Как иметь 2 разных админ-сайта в проекте Django?

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

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

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

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

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

3 ответа

Решение

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

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

Вы можете подкласс Джанго 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 Бернарда Валланта, хотя это кажется ортодоксальным и по существу правильным делом. Я решил проблему.

Вот мод к коду Бернхарда Валланта, который я счел крайне необходимым:

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, как я, потому что администратор в нижнем регистре выглядит как экземпляр, а я не знаком с экземплярами подклассов. Поэтому я предполагаю, что это не так.

Другие вопросы по тегам