Como ter dois sites admin diferentes em um projeto do Django?

Eu quero ter 2 sites admin separados dentro de um projeto Django.

Por separado, quero dizer – eles devem ter autenticação de usuários separados, eles devem administrar modelos diferentes e ter visuais e URLs diferentes.

O motivo pelo qual desejo fazer isso é que o cliente deseja que a seção separada administre a parte da página do CMS e separe-a para usar como uma solução de ‘back-office’.

Eu pensei em apenas fazer uma cópia od django.contrib.auth appliaction na minha tree de projetos, nomeando-a de forma diferente e usando admin.site.register() separadas de admin.site.register() para ambas. Dessa forma eu posso ter outros modelos disponíveis em cada um deles, diferentes visuais, etc. Eu não sei como resolver o problema de autenticação do usuário (eu deveria ter um usuário diferente para poder entrar no CMS e depois no BackOffice) .

Alguém aconteceu para fazer isso antes e poderia me dar alguma dica? Ou o que eu pretendo fazer é errado por design?

Para registrar modelos em diferentes AdminSites você só precisa criar instâncias diferentes de django.contrib.admin.sites.AdminSite, veja isto.

Você será bom para ir com dois sites de administração diferentes, gerenciando modelos diferentes e com modelos diferentes. Para autenticação e permissions você deve ser capaz de usar o django.contrib.auth embutido como é com permissions customizadas (esperamos que alguém possa ajudar mais aqui)

Você pode subclassificar o AdminSite do Django (por exemplo, em admin.py na raiz do seu projeto):

 from django.contrib.admin.sites import AdminSite class MyAdminSite(AdminSite): pass #or overwrite some methods for different functionality myadmin = MyAdminSite(name="myadmin") 

Pelo menos a partir de 1.9 você precisa adicionar o parâmetro name para que ele funcione corretamente. Isto é usado para criar as urls reversas, assim o nome tem que ser o do urls.py.

Então você pode usá-lo no admin.py do seu aplicativo da mesma forma que você faz com a instância normal do AdminSite :

 from myproject.admin import myadmin myadmin.register(MyModel_A) 

Você também precisa definir alguns URLs para isso (no urls.py do seu projeto):

 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)), 

Veja também: http://docs.djangoproject.com/en/dev/ref/contrib/admin/#adminsite-objects

Não tenho certeza de que minha descoberta, relatada aqui, teria sido útil para o kender, porque, entre outras coisas, não sei se ele estava falando não apenas de dois sites de administração, mas também de dois bancos de dados, um para cada. Essa é a minha situação. Eu tive a shiny ideia de que eu queria que um dos meus aplicativos, um novo aplicativo, tivesse seu próprio database e suas próprias páginas de administração.

Mas me deparei com um problema com a abordagem de subsorting do AdminSite de Bernhard Vallant, embora pareça ser a coisa ortodoxa e essencialmente correta a ser feita. Eu resolvi o problema.

Aqui está o mod para o código de Bernhard Vallant que eu achei totalmente necessário:

 from django.contrib.admin.sites import AdminSite class MyAdminSite(AdminSite): pass #or overwrite some methods for different functionality myadmin = MyAdminSite(name='anything') 

Sim, eu realmente quero dizer nome = ‘qualquer coisa’ que você escolher (contanto que não seja ‘admin’). E eu entrei e saí com ele e ele falha toda vez sem a atribuição do nome de qualquer coisa, mas de admin.

Os sintomas que eu adquiri foram que quando eu adicionei o segundo database e criei um myadmin para ele e, em seguida, registrei o modelo com myadmin.register (My_ModelA), e fui olhar as duas páginas do aplicativo admin, a do meu novo aplicativo que usei o segundo database e myadmin e o modelo My_ModelA parecia bem, mas minha antiga página de administração mostrava links mortos para seus modelos e quando eu clicava em um link não morto para um aplicativo (um aplicativo antigo que usa o database antigo) um código 404 no sentido de que a página não existia.

Além disso, eu não sei o que importa, mas fiz algo diferente do que Bernhard Vallant fez no projeto 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)), ) 

OK, “algum lugar” é irrelevante – há aparências em relação ao usuário final e não o nome de um aplicativo ou o projeto. Mas o administrador associado é aquele para meu aplicativo antigo e database antigo. Observe a inclusão autodiscover (). Há alguma linguagem obscura nos documentos a que Bernhard Vallant se vinculou em relação ao seu uso quando o urlconf do projeto está configurado, pois Bernhard Vallant o possui com a importação myadmin, mas também com uma referência ao administrador padrão.

E para o urlconf para mynewapp eu tenho:

 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"), ) 

Não obstante a absoluta necessidade de nomear sua instância do AdminSite internamente para algo diferente de ‘admin’, devo acrescentar que quando chegou a hora de atualizar o arquivo admin.py do mynewapp com alguma subsorting admin.ModelAdmin, era necessário usar o admin. ModelAdmin como a class pai. myadmin é afinal uma instância de uma subclass de AdminSite. Como tal, eu entendo que está em pé de igualdade com admin.site, não com admin.

Isso tudo é muito confuso para um NOOB como eu, porque admin, com letras minúsculas, parece uma instância, e eu não estou familiarizado com instâncias de subsorting. Então eu suponho que não é.