¿Cómo tener 2 sitios de administración diferentes en un proyecto de Django?

Question

Quiero tener 2 sitios de administración separados dentro de un proyecto de Django.

Por separado quiero decir: deben tener autenticación de usuarios separada, deben administrar diferentes modelos y tener diferentes apariencias y URL.

La razón por la que quiero hacerlo es que el cliente desea una sección separada para administrar la parte CMS de la página, y separarla para usarla como una solución 'back-office'.

Pensé en hacer una copia de la aplicación django.contrib.auth en el árbol de mi proyecto, nombrarla de manera diferente y usar llamadas separadas admin.site.register() para ambas. De esta forma puedo tener otros modelos disponibles en cada uno de ellos, miradas diferentes, etc. No sé cómo resolver el problema de autenticación de usuario (debería tener un usuario diferente para poder iniciar sesión en CMS y luego en BackOffice) .

¿Alguien pasó a hacer esto antes y podría darme alguna pista? ¿O lo que planeo hacer es simplemente incorrecto por diseño?

Answer 1

Para registrar modelos en diferentes AdminSites que acaba necesita crear diferentes instancias de django.contrib.admin.sites.AdminSite, see this.

Tendrá que ir con dos sitios de administración diferentes que manejan diferentes modelos y tienen diferentes plantillas. Para la autenticación y los permisos, debería poder usar el built-in django.contrib.auth como está con los permisos personalizados (espero que alguien más pueda ayudar más aquí)

Answer 2

Usted puede subclase de Django AdminSite (ponerlo por ejemplo, en admin.py en la raíz del proyecto.):

from django.contrib.admin.sites import AdminSite 

class MyAdminSite(AdminSite): 
    pass 
    #or overwrite some methods for different functionality 

myadmin = MyAdminSite(name="myadmin") 

Al menos de 1,9 en lo que necesita para agregar el parámetro de nombre para que funcione correctamente. Esto se usa para crear las URL reversas, por lo que el nombre debe ser el de urls.py.

entonces usted puede utilizar en admin.py la misma forma de su aplicación como lo hace con el AdminSite ejemplo normales:

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

También es necesario definir algunas direcciones URL para ella (en su proyecto 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)), 

también vea esto: http://docs.djangoproject.com/en/dev/ref/contrib/admin/#adminsite-objects

Answer 3

No estoy seguro de que mi hallazgo, informado aquí, hubiera sido totalmente útil para kender porque, entre otras cosas, no sé si estaba hablando no solo de dos sitios de administración sino también de dos bases de datos, una para cada uno. Esa es mi situación. Obtuve la brillante idea de que quería que una de mis aplicaciones, una nueva aplicación, tuviera su propia base de datos y sus propias páginas de administración.

Pero me encontré con un problema con el enfoque de subclases AdminSite de Bernhard Vallant, aunque parece ser lo ortodoxo y esencialmente correcto de hacer. Resolví el problema.

Aquí está el mod al código de Bernhard Vallant que he encontrado para ser absolutamente necesaria:

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

Sí, yo realmente no significan name = 'nada' que elija (siempre y cuando no lo es 'admin ').Y he entrado y salido con él y falla siempre sin la asignación de nombre de todo, pero no de administrador.

Los síntomas que adquirí fueron que cuando agregué la segunda base de datos y creé un myadmin para él, registré el modelo con myadmin.register (My_ModelA) y fui a ver las dos páginas de la aplicación de administración, la de mi nueva aplicación que usaba la segunda base de datos y myadmin y el modelo My_ModelA se veía bien, pero mi página de administración anterior mostraba enlaces muertos para sus modelos y cuando hice clic allí en un enlace no muerto para una aplicación (una aplicación antigua que usa el antiguo base de datos) Obtuve un código 404 en el sentido de que la página no existía.

Además, no sé es que importe, pero hice algo diferente de lo que Bernhard Vallant hizo en la URLconf proyecto:

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

bien "someword" es irrelevante --- allí para apariencias con respecto al usuario final y no el nombre de una aplicación o el proyecto. Pero el administrador asociado es el de mi aplicación anterior y la base de datos anterior. Tenga en cuenta la inclusión de autodiscover(). Hay un lenguaje turbio en los documentos con el que Bernhard Vallant se relacionó con respecto a su uso cuando el proyecto urlconf está configurado como Bernhard Vallant lo tiene con la importación de myadmin pero también con una referencia al administrador predeterminado.

Y para la URLconf para mynewapp tengo:

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

A pesar de la absoluta necesidad de nombrar a su instancia AdminSite internamente a algo distinto de 'admin', debo añadir que cuando llegó el momento de jazz encima de la El archivo admin.py de mynewapp con alguna subclasificación admin.ModelAdmin, era necesario usar admin.ModelAdmin como clase principal. myadmin es, después de todo, una instancia de una subclase de AdminSite. Como tal, deduzco que está a la par de admin.site, no con admin.

Esto es muy confuso para un NOOB como yo porque el administrador, con la minúscula, parece una instancia, y no estoy familiarizado con las instancias de subclases. Entonces supongo que no es así.