Jak mieć 2 różne strony administracyjne w projekcie Django?

Question

Chcę mieć 2 oddzielne strony administracyjne wewnątrz projektu Django.

Oddzielnie mam na myśli - powinny one mieć oddzielne uwierzytelnianie użytkowników, powinny administrować różnymi modelami i mieć różne wygląd i adresy URL.

Powodem, dla którego chcę to zrobić, jest to, że klient chce osobnej sekcji do administrowania częścią strony CMS i oddzielne do użycia jako rozwiązanie "back-office".

Zastanawiałem się nad stworzeniem kopii aplikacji django.contrib.auth w moim drzewie projektu, nazywając ją inaczej i używając osobnych wywołań admin.site.register() dla obu z nich. W ten sposób mogę mieć inne modele dostępne w każdym z nich, różne spojrzenia itp. Nie wiem, jak rozwiązać problem z uwierzytelnianiem użytkownika (powinienem mieć innego użytkownika, aby móc zalogować się do CMS, a następnie do BackOffice) .

Ktoś zdarzył się zrobić to wcześniej i mógł dać mi wskazówkę? Czy to, co planuję zrobić, jest po prostu błędne według projektu?

Answer 1

Aby zarejestrować modeli w różnych AdminSites po prostu trzeba utworzyć różne instancje django.contrib.admin.sites.AdminSite, see this.

Będzie można korzystać z dwóch różnych stron administracyjnych zarządzających różnymi modelami i posiadających różne szablony. W celu uwierzytelnienia i uprawnień, powinieneś być w stanie używać wbudowanego django.contrib.auth, tak jak z własnymi uprawnieniami (mam nadzieję, że ktoś inny będzie w stanie Ci pomóc).

Answer 2

Można podklasy Django AdminSite (umieścić go np admin.py w katalogu głównym projektu.):

from django.contrib.admin.sites import AdminSite 

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

myadmin = MyAdminSite(name="myadmin") 

Przynajmniej od 1,9 sprawie trzeba dodać parametr nazwa, aby to działało poprawnie. Służy do tworzenia adresów zwrotnych, więc nazwa musi być taka sama, jak w urls.py.

Wtedy można go używać w Twojej aplikacji admin.py taki sam sposób, jak to zrobić z normalnego AdminSite przykład:

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

Należy również określić adresy URL do niego (w urls.py Twojego projektu):

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

zobacz także: http://docs.djangoproject.com/en/dev/ref/contrib/admin/#adminsite-objects

Answer 3

Nie jestem pewien, czy moje odkrycie, Podane tutaj informacje byłyby całkowicie przydatne dla kendera, ponieważ między innymi nie wiem, czy mówił on nie tylko o dwóch stronach administratora, ale także o dwóch bazach danych, po jednej dla każdego. To moja sytuacja. Mam świetny pomysł, że chcę, aby jedna z moich aplikacji, nowa aplikacja, miała własną bazę danych i własne strony administracyjne.

Ale wpadłem na problem z podklasowaniem AdminSite w Bernhard Vallant, choć wydaje się, że jest to ortodoksyjne i zasadniczo poprawne. Rozwiązałem problem.

Oto mod do kodu Bernhard Vallant, że znalazłem się być absolutnie konieczne:

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

Tak, ja naprawdę oznacza name = „coś”, aby wybrać (o ile nie jest to „admin ").I włączałem i wyłączałem to i to za każdym razem kończyło się niepowodzeniem bez przypisywania nazwy "tylko" ale "admin".

Objawy, które nabyłem, to to, że po dodaniu drugiej bazy danych i utworzeniu do niej myadmin, a następnie zarejestrowałem model za pomocą myadmin.register (My_ModelA), i poszedłem do dwóch stron aplikacji administratora, tej dla moja nowa aplikacja, która korzystała z drugiej bazy danych i myadmin oraz modelu My_ModelA wyglądała dobrze, ale moja stara strona administratora pokazała martwe linki do swoich modeli i kiedy kliknąłem tam na niezmiennym łączu dla aplikacji (stara aplikacja, która używa starego baza danych) Otrzymałem kod 404, że strona nie istnieje.

Także, ja nie wiem, czy to ważne, ale zrobiłem coś innego od tego, co Bernhard Vallant zrobił w URLconf projektu:

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” nie ma znaczenia --- tam wyglądy w odniesieniu do użytkownika końcowego, a nie nazwa aplikacji lub projektu. Ale powiązany administrator to ten dla mojej starej aplikacji i starej bazy danych. Zwróć uwagę na włączanie autodiscover(). W dokumentach jest trochę mrocznego języka, do którego Bernhard Vallant odwołuje się w odniesieniu do jego użycia, gdy konfiguracja projektu urlconf jest skonfigurowana tak, jak ma to miejsce w przypadku Bernhard Vallant z importem myadmin, ale także z odwołaniem do domyślnego administratora.

A dla URLconf dla mynewapp mam:

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

Bez względu na zupełny konieczność nazywania AdminSite instancji wewnętrznie do czegoś innego niż „admin”, muszę dodać, że kiedy przyszedł czas na jazz w górę Plik admin.py mynewapp z pewną podklasą admin.ModelAdmin, konieczne było użycie admin.ModelAdmin jako klasy nadrzędnej. myadmin jest przecież instancją podklasy AdminSite. W związku z tym uważam, że jest to na równi z admin.site, a nie z adminem.

To wszystko jest bardzo mylące dla NOOB, tak jak ja, ponieważ admin, z małymi literami, wygląda jak instancja i nie jestem zaznajomiony z instancjami podklasy. Zakładam więc, że tak nie jest.