Django admin: Was ist der beste Weg, um eine benutzerdefinierte Listenansicht hinzuzufügen?

Question

Ich möchte eine benutzerdefinierte Ansicht im Administrator geben, die sehr ähnlich ist changelist_view(), aber ohne die Links zur Ansicht der Bearbeitungsform. Benutzer können die Elemente in der Liste auswählen und Aktionen genau wie im Änderungslistenformular anwenden, sie haben jedoch keinen Zugriff auf das Bearbeitungsformular.

Ich denke, die Struktur in der ModelAdmin -Klasse sollte so sein:

class ProductAdmin(admin.ModelAdmin):
    def get_urls(self):
        urls = super(ProductAdmin, self).get_urls()
        urls += patterns('',
            (r'^selectlist/$', self.selectlist_view)
        )
        return urls

    def selectlist_view(self):
        return render_to_response(...)

Die zurückgegebene Aussicht ist sehr ähnlich zu ModelAdmin.changelist_view(). Was ist der beste und trockene Weg, dies zu tun?

Answer 1

Das folgende maßgefertigte ModellAdmin ist die beste Lösung, die ich bisher entwickeln könnte:

class UserModelAdmin(ModelAdmin):
    def get_urls(self):
        urls = super(UserModelAdmin, self).get_urls()
        info = self.model._meta.app_label, self.model._meta.module_name
        select_list_url = patterns('',
            url(r'^selectlist/$', self.selectlist_view, 
                name='%s_%s_select' % info)
        )
        return select_list_url + urls

    def selectlist_view(self, request, extra_context=None):
        temp_list_display_links = self.list_display_links
        self.list_display_links = (None, )
        response = self.changelist_view(request, extra_context)
        self.list_display_links = temp_list_display_links
        return response

Answer 2

Ich weiß nicht wirklich warum, aber persönlich neige ich dazu Überschreiben (oder erweitern) die Änderungslistenvorlage Für ein bestimmtes Modell anstelle von MonkeyPatching -ModellAdmin.

Bearbeitet:

Vielen Dank, aber ich brauche eine Anpassung, die nicht durch Überschreiben der Vorlage durchgeführt werden kann. Zum Beispiel mit einem anderen Queryset usw. anzeigen

Um einen anderen Queryset anzuzeigen, können Sie ModellAdmin.queryset () überschreiben.

Auch sollte die aufgeführten Elemente nicht bearbeiten können. Wenn ich die Vorlage überschreibe, wird der Benutzer keinen Link zum Bearbeitungsformular angezeigt, aber er kann weiterhin auf das Formular zugreifen und sie bearbeiten, indem er die URL eingreift, wenn er die URL an das Formular erraten kann, das ein Sicherheitsloch wäre.

Warum nicht einfach die Bearbeitungsberechtigung von den betreffenden Benutzern entfernen? Sie können auch die Ansichten "Hinzufügen" und "ändern" überschreiben:

class SomeModelAdmin(admin.ModelAdmin):
    ...
    def change_view(self, request, object_id, extra_context=None):
        return render_to_response('forbiden_operation.html', dict(op='edit'))
    def ModelAdmin.add_view(self, request, form_url='', extra_context=None):
        return render_to_response('forbiden_operation.html', dict(op='add'))

Dies sind "offizielle" Haken, die in Zukunft weniger wahrscheinlich brechen.

Denken Sie auch an "den Zen des Administrators":

Im Kern ist Django's Admin -Schnittstelle für eine einzelne Aktivität ausgelegt:

Vertrauenswürdige Benutzer bearbeiten strukturierte Inhalte.

Ja, es ist extrem einfach - aber diese Einfachheit basiert auf einer ganzen Reihe von Annahmen. Die gesamte Philosophie von Djangos Admin -Schnittstelle folgt direkt aus diesen Annahmen. Geben Sie also in den folgenden Abschnitten in den Untertext dieser Phrase ein. "Vertrauenswürdige Benutzer ..."

Die Admin -Schnittstelle wurde so konzipiert, dass sie von Personen verwendet werden, die Sie, der Entwickler, das Vertrauen. Dies bedeutet nicht nur „Menschen, die authentifiziert wurden“; Dies bedeutet, dass Django davon ausgeht, dass Ihre Inhaltsredakteure vertrauenswürdig sind, um das Richtige zu tun.

Dies bedeutet wiederum, dass es keinen Genehmigungsprozess für die Bearbeitung von Inhalten gibt. Wenn Sie Ihren Benutzern vertrauen, muss niemand seine Änderungen genehmigen. Eine weitere Implikation ist, dass das Berechtigungssystem zwar leistungsfähig ist, aber nicht die Begrenzung des Zugangs auf einer Basis pro Objekt zum Zeitpunkt dieses Schreibens hat. Wenn Sie jemandem vertrauen, der seine eigenen Geschichten bearbeitet, vertrauen Sie diesem Benutzer, die die Geschichten eines anderen ohne Erlaubnis nicht zu bearbeiten.

"... bearbeiten ..."

Der Hauptzweck von Djangos Admin -Schnittstelle besteht darin, Personen Daten bearbeiten zu lassen. Dies scheint zunächst offensichtlich, aber es gibt auch einige subtile und kraftvolle Auswirkungen.

Obwohl die Administratorschnittstelle für die Überprüfung von Daten (wie nur beschrieben) sehr nützlich ist, ist sie beispielsweise nicht unter Berücksichtigung dieses Zwecks konzipiert. Beachten Sie beispielsweise das Fehlen einer Berechtigung „Can View“ (siehe Kapitel 12). Django geht davon aus, dass Menschen, wenn sie Inhalte in der Admin -Schnittstelle anzeigen dürfen, auch bearbeiten.

Eine weitere wichtigere Sache, die zu beachten ist, ist das Fehlen von irgendetwas, das sich auch aus der Ferne „Workflow“ nähert. Wenn eine bestimmte Aufgabe eine Reihe von Schritten erfordert, wird die Durchsetzung nicht unterstützt, dass diese Schritte in einer bestimmten Reihenfolge durchgeführt werden. Die Verwaltungsschnittstelle von Django konzentriert sich auf die Bearbeitung und nicht auf Aktivitäten rund um die Bearbeitung. Diese Vermeidung des Workflows beruht auch auf das Prinzip des Vertrauens: Die Philosophie der Admin -Schnittstelle ist, dass Workflow ein Personalproblem ist und nicht in Code implementiert werden muss.

Beachten Sie schließlich den Mangel an Aggregation in der Administratorschnittstelle. Das heißt, es gibt keine Unterstützung, um Summen, Durchschnittswerte usw. anzuzeigen. Auch hier dient die Admin -Schnittstelle zur Bearbeitung - es wird erwartet, dass Sie benutzerdefinierte Ansichten für den Rest schreiben.

"... strukturierter Inhalt"

Wie beim Rest von Django möchte die Admin -Schnittstelle mit strukturierten Daten. Somit unterstützt es nur die Bearbeitungsdaten, die in Django -Modellen gespeichert sind. Für alles andere, wie beispielsweise Daten, die in einem Dateisystem gespeichert sind, benötigen Sie benutzerdefinierte Ansichten.

Punkt

Es sollte inzwischen klar sein, dass Djangos Admin -Schnittstelle nicht versucht, für alle Menschen alles zu sein. Stattdessen konzentrieren wir uns, uns fest auf eine Sache zu konzentrieren und das Ding sehr gut zu machen.

Wenn es darum geht, Djangos Admin -Schnittstelle zu erweitern, gilt ein Großteil derselben Philosophie (beachten Sie, dass in unseren Zielen die „Erweiterbarkeit“ nirgendwo hinweist). Da benutzerdefinierte Django-Ansichten alles bewirken können und sie leicht in die Administratorschnittstelle (wie im nächsten Abschnitt beschrieben) visuell integriert werden können, sind die integrierten Möglichkeiten zum Anpassen der Admin-Schnittstelle durch Design etwas begrenzt.

Sie sollten bedenken, dass die Admin -Schnittstelle „nur eine App“ ist, wenn auch eine sehr komplizierte. Es tut nichts, was ein Django -Entwickler mit genügend Zeit nicht reproduzieren konnte. Es ist durchaus möglich, dass in Zukunft jemand eine andere Verwaltungsschnittstelle entwickelt, die auf einer anderen Reihe von Annahmen basiert und sich daher anders verhalten wird.

Schließlich sollten wir darauf hinweisen, dass Django -Entwickler nach diesem Schreiben an einer neuen Version der Admin -Schnittstelle arbeiteten, die viel mehr Flexibilität bei der Anpassung ermöglicht. Wenn Sie dies lesen, haben sich diese neuen Funktionen möglicherweise in die echte Django -Verteilung gelandet. Um es herauszufinden, fragen Sie jemanden in der Django-Community, ob die Branche „NewForms-Admin“ integriert wurde.

Die Admin -App hat eine große Verbesserung verzeichnet, um mehr Flexibilität bei der Anpassung zu ermöglichen, aber ein Großteil des "Zen des Administrators" gilt immer noch.