Come avere 2 diversi siti di amministrazione in un progetto Django?

Question

Desidero avere 2 siti di amministrazione separati all'interno di un progetto Django.

Con distinti intendo: devono avere l'autenticazione degli utenti separati, devono amministrare modelli diversi e avere look e URL diversi.

Il motivo per cui voglio farlo è che il cliente desidera una sezione separata per amministrare la parte CMS della pagina e separarla per utilizzarla come soluzione di "back-office".

Ho pensato di fare una copia di django.contrib.auth appliaction nella mia struttura del progetto, nominandola in modo diverso e utilizzando chiamate separate admin.site.register() per entrambi. In questo modo posso avere altri modelli disponibili in ognuno di essi, sguardi differenti, ecc. Non so come risolvere il problema di autenticazione dell'utente (dovrei avere un utente diverso per poter accedere al CMS nel BackOffice) .

Qualcuno è successo a farlo prima e potrebbe darmi qualche suggerimento? O quello che ho intenzione di fare è solo sbagliato nella progettazione?

Answer 1

Per registrare modelli in diversi AdminSites basta è necessario creare diverse istanze di django.contrib.admin.sites.AdminSite, see this.

Sarai a posto con due diversi siti di amministrazione che gestiscono modelli diversi e con modelli diversi. Per l'autenticazione e le autorizzazioni dovresti essere in grado di usare il build-in django.contrib.auth così come è con permessi personalizzati (spero che qualcun altro sarà in grado di aiutare di più qui)

Answer 2

È possibile creare una sottoclasse di Django AdminSite (metterlo ad esempio in admin.py nella directory principale del progetto.):

from django.contrib.admin.sites import AdminSite 

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

myadmin = MyAdminSite(name="myadmin") 

Almeno da 1.9 a è necessario aggiungere il parametro name per farlo funzionare correttamente. Questo è usato per creare gli URL di inversione, quindi il nome deve essere quello di urls.py.

Quindi è possibile utilizzarlo in admin.py allo stesso modo della tua app come si fa con la normale AdminSite esempio:

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

È inoltre necessario definire alcuni URL per esso (in del progetto 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)), 

vedere anche questo: http://docs.djangoproject.com/en/dev/ref/contrib/admin/#adminsite-objects

Answer 3

Non sono sicuro che la mia ricerca, riportato qui, sarebbe stato di grande aiuto per kender perché, tra le altre cose, non so se stesse parlando non solo di due siti di amministrazione ma anche di due database, uno per ciascuno. Questa è la mia situazione. Ho avuto la brillante idea che volevo che una delle mie app, una nuova app, avesse il proprio database e le proprie pagine di amministrazione.

Ma mi sono imbattuto in un problema con l'approccio di sottoclasse di AdminSite di Bernhard Vallant, anche se sembra essere la cosa ortodossa ed essenzialmente corretta da fare. Ho risolto il problema.

Ecco il mod per il codice di Bernhard Vallant che ho trovato per essere assolutamente necessaria:

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

Sì, lo faccio davvero dire name = 'qualsiasi cosa' che si sceglie (a patto che non lo è 'admin ').E ho inserito e disinserito con esso e fallisce ogni volta senza l'assegnazione del nome nulla-ma-admin.

I sintomi che ho acquisito fosse che quando ho aggiunto il secondo database e creato un MyAdmin per esso e quindi registrato il modello con myadmin.register (My_ModelA), e andò a guardare le due pagine di app di amministrazione, quello per la mia nuova app che usava il secondo database e myadmin e il mio modello My_ModelA andava bene, ma la mia vecchia pagina di amministrazione mostrava link morti per i suoi modelli e quando ho cliccato su un link non morto per un'app (una vecchia app che usa il vecchio database) Ho ottenuto un codice 404 per l'effetto che la pagina non esisteva.

Inoltre, non so che è importante, ma ho fatto qualcosa di diverso da ciò che Bernhard Vallant ha fatto nel progetto 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 "someword" è irrilevante --- lì per apparenze nei confronti dell'utente finale e non il nome di un'app o del progetto. Ma l'amministratore associato è quello per la mia vecchia app e il vecchio database. Nota l'inclusione autodiscover(). C'è un linguaggio oscuro nei documenti a cui Bernhard Vallant ha collegato il suo uso quando il progetto urlconf è configurato come ha Bernhard Vallant con l'importazione myadmin, ma anche con un riferimento all'amministratore predefinito.

E per l'urlconf per mynewapp ho:

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

Nonostante la necessità assoluta di nominare l'istanza AdminSite internamente a qualcosa di diverso 'admin', devo aggiungere che, quando è arrivato il momento per il jazz il il file admin.py di mynewapp con alcune sottoclassi admin.ModelAdmin, era necessario utilizzare admin.ModelAdmin come classe genitore. dopotutto, myadmin è un'istanza di una sottoclasse di AdminSite. Come tale capisco che è alla pari con admin.site, non con admin.

Questo è tutto molto confuso per un NOOB come me perché admin, con il minuscolo, sembra un'istanza, e non ho familiarità con le istanze di sottoclassi. Quindi presumo che non lo sia.