{"title":"Django-administratörens webbplats","version":"6.1","locale":"sv","docname":"ref/contrib/admin/index","url":"/sv/6.1/ref/contrib/admin/","canonical":"https://djangodocs.dev/sv/6.1/ref/contrib/admin/","summary":"En av de mest kraftfulla delarna av Django är det automatiska administratörsgränssnittet.","html":"

Django-administratörens webbplatsLink to this heading#

\n

En av de mest kraftfulla delarna av Django är det automatiska administratörsgränssnittet. Det läser metadata från dina modeller för att tillhandahålla ett snabbt, modellcentrerat gränssnitt där betrodda användare kan hantera innehåll på din webbplats. Administratörens rekommenderade användning är begränsad till en organisations interna hanteringsverktyg. Det är inte avsett för att bygga hela frontend runt.

\n

Administratören har många hooks för anpassning, men akta dig för att försöka använda dessa hooks exklusivt. Om du behöver tillhandahålla ett mer processcentrerat gränssnitt som abstraherar bort implementeringsdetaljerna för databastabeller och fält, är det förmodligen dags att skriva dina egna vyer.

\n

I det här dokumentet beskriver vi hur du aktiverar, använder och anpassar Djangos administratörsgränssnitt.

\n
\n

ÖversiktLink to this heading#

\n

Administratören är aktiverad i den standardprojektmall som används av startproject.

\n

Om du inte använder standardprojektmallen följer här kraven:

\n
    \n

  1. Lägg till 'django.contrib.admin' och dess beroenden - django.contrib.auth, django.contrib.contenttypes, django.contrib.messages, och django.contrib.sessions - till din INSTALLED_APPS inställning.

    2. \n

  2. Konfigurera en DjangoTemplates-backend i din TEMPLATES-inställning med django.template.context_processors.request, django.contrib.auth.context_processors.auth och django.contrib.messages.context_processors.messages i alternativet 'context_processors' i OPTIONS.

    3. \n

  3. Om du har anpassat inställningen MIDDLEWARE måste django.contrib.sessions.middleware.SessionMiddleware, django.contrib.auth.middleware.AuthenticationMiddleware och django.contrib.messages.middleware.MessageMiddleware inkluderas.

    4. \n

  4. Haka på administratörens webbadresser i din URLconf.

    5. \n
\n

När du har gjort det här kan du använda administratörswebbplatsen genom att besöka den URL som du har kopplat den till (/admin/, som standard).

\n

Om du behöver skapa en användare att logga in med använder du kommandot createsuperuser. För att logga in på admin krävs som standard att användaren har attributet is_staff inställt på True.

\n

Slutligen ska du bestämma vilka av applikationens modeller som ska kunna redigeras i administratörsgränssnittet. För var och en av dessa modeller registrerar du dem med administratören enligt beskrivningen i ModelAdmin.

\n
\n

Övriga ämnenLink to this heading#

\n
\n\n
\n\n\n
\n
\n
\n

ModelAdmin-objektLink to this heading#

\n
\n
\nclass ModelAdminLink to this definition#
\n

Klassen ModelAdmin är representationen av en modell i admin-gränssnittet. Vanligtvis lagras dessa i en fil med namnet admin.py i din applikation. Låt oss ta en titt på ett exempel på ModelAdmin:

\n
Code
from django.contrib import admin\nfrom myapp.models import Author\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n    pass\n\n\nadmin.site.register(Author, AuthorAdmin)\n
\n\n
\n\n
\n

Dekoratorn ”registerLink to this heading#

\n
\n
\nregister(*models, site=django.contrib.admin.sites.site)Link to this definition#
\n

Det finns också en dekorator för att registrera dina ModelAdmin-klasser:

\n
Code
from django.contrib import admin\nfrom .models import Author\n\n\n@admin.register(Author)\nclass AuthorAdmin(admin.ModelAdmin):\n    pass\n
\n

Den får en eller flera modellklasser att registrera med ModelAdmin. Om du använder en anpassad AdminSite, skicka den med nyckelordsargumentet site:

\n
Code
from django.contrib import admin\nfrom .models import Author, Editor, Reader\nfrom myproject.admin_site import custom_admin_site\n\n\n@admin.register(Author, Reader, Editor, site=custom_admin_site)\nclass PersonAdmin(admin.ModelAdmin):\n    pass\n
\n

Du kan inte använda denna dekorator om du måste referera till din modelladministratörsklass i dess __init__()-metod, t.ex. super(PersonAdmin, self).__init__(*args, **kwargs). Du kan använda super().__init__(*args, **kwargs).

\n
\n\n
\n
\n

Upptäckt av adminfilerLink to this heading#

\n

När du lägger till 'django.contrib.admin i din INSTALLED_APPS-inställning, letar Django automatiskt efter en admin-modul i varje applikation och importerar den.

\n
\n
\nclass apps.AdminConfigLink to this definition#
\n

Detta är standardklassen AppConfig för admin. Den anropar autodiscover() när Django startar.

\n
\n\n
\n
\nclass apps.SimpleAdminConfigLink to this definition#
\n

Den här klassen fungerar som AdminConfig, men den anropar inte autodiscover().

\n
\n
\ndefault_siteLink to this definition#
\n

En prickad importsökväg till standardadministratörswebbplatsens klass eller till en anropsbar som returnerar en webbplatsinstans. Standard är 'django.contrib.admin.sites.AdminSite'. Se Åsidosätta standardwebbplatsen för administratörer för användning.

\n
\n\n
\n\n
\n
\nautodiscover()Link to this definition#
\n

Denna funktion försöker importera en ”admin”-modul i varje installerad applikation. Sådana moduler förväntas registrera modeller med administratören.

\n

Vanligtvis behöver du inte anropa den här funktionen direkt eftersom AdminConfig anropar den när Django startar.

\n
\n\n

Om du använder en anpassad AdminSite är det vanligt att importera alla ModelAdmin-subklasser till din kod och registrera dem till den anpassade AdminSite. I det fallet, för att inaktivera automatisk upptäckt, bör du sätta 'django.contrib.admin.apps.SimpleAdminConfig' istället för 'django.contrib.admin' i din INSTALLED_APPS inställning.

\n
\n
\n

ModelAdmin alternativLink to this heading#

\n

ModelAdmin är mycket flexibelt. Den har flera alternativ för att hantera anpassningen av gränssnittet. Alla alternativ är definierade i underklassen ModelAdmin:

\n
Code
from django.contrib import admin\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n    date_hierarchy = "pub_date"\n
\n
\n
\nModelAdmin.actionsLink to this definition#
\n

En lista över åtgärder som ska göras tillgängliga på sidan med ändringslistan. Se Administrativa åtgärder för mer information.

\n
\n\n
\n
\nModelAdmin.actions_on_topLink to this definition#
\n
\n\n
\n
\nModelAdmin.actions_on_bottomLink to this definition#
\n

Styr var åtgärdsfältet visas på adminens ändringslistsida. Som standard visar adminens ändringslista åtgärder överst på sidan (actions_on_top = True; actions_on_bottom = False).

\n
\n\n
\n
\nModelAdmin.actions_selection_counterLink to this definition#
\n

Styr om en urvalsräknare ska visas bredvid rullgardinsmenyn för åtgärder. Som standard visas den i admin-changellistan (actions_selection_counter = True).

\n
\n\n
\n
\nModelAdmin.date_hierarchyLink to this definition#
\n

Ange date_hierarchy till namnet på en DateField eller DateTimeField i din modell, så kommer sidan med ändringslistan att innehålla en datumbaserad drilldown-navigering efter det fältet.

\n

Exempel:

\n
Code
date_hierarchy = "pub_date"\n
\n

Du kan också ange ett fält i en relaterad modell med hjälp av __ lookup, till exempel:

\n
Code
date_hierarchy = "author__pub_date"\n
\n

Detta kommer att fylla i sig självt på ett intelligent sätt baserat på tillgängliga data, t.ex. om alla datum är i en månad kommer det bara att visa drill-down på dagsnivå.

\n\n
\n\n
\n
\nModelAdmin.empty_value_displayLink to this definition#
\n

Detta attribut åsidosätter standardvisningsvärdet för postfält som är tomma (None, tom sträng, etc.). Standardvärdet är - (ett streck). Till exempel:

\n
Code
from django.contrib import admin\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n    empty_value_display = "-empty-"\n
\n

Du kan också åsidosätta empty_value_display för alla adminsidor med AdminSite.empty_value_display, eller för specifika fält så här:

\n
Code
from django.contrib import admin\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n    list_display = ["name", "title", "view_birth_date"]\n\n    @admin.display(empty_value="???")\n    def view_birth_date(self, obj):\n        return obj.birth_date\n
\n
\n\n
\n
\nModelAdmin.excludeLink to this definition#
\n

Detta attribut, om det anges, bör vara en lista över fältnamn som ska uteslutas från formuläret.

\n

Låt oss till exempel betrakta följande modell:

\n
Code
from django.db import models\n\n\nclass Author(models.Model):\n    name = models.CharField(max_length=100)\n    title = models.CharField(max_length=3)\n    birth_date = models.DateField(blank=True, null=True)\n
\n

Om du vill ha ett formulär för modellen Author som bara innehåller fälten name och title anger du fields eller exclude så här:

\n
Code
from django.contrib import admin\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n    fields = ["name", "title"]\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n    exclude = ["birth_date"]\n
\n

Eftersom modellen Author bara har tre fält, name, title och birth_date, kommer de formulär som blir resultatet av ovanstående deklarationer att innehålla exakt samma fält.

\n
\n\n
\n
\nModelAdmin.fieldsLink to this definition#
\n

Använd alternativet fields för att göra enkla layoutändringar i formulären på sidorna ”add” och ”change”, till exempel att bara visa en delmängd av tillgängliga fält, ändra deras ordning eller gruppera dem i rader. Du kan till exempel definiera en enklare version av adminformuläret för modellen django.contrib.flatpages.models.FlatPage enligt följande:

\n
Code
class FlatPageAdmin(admin.ModelAdmin):\n    fields = ["url", "title", "content"]\n
\n

I exemplet ovan visas endast fälten url, title och content i tur och ordning i formuläret. fields kan innehålla värden som definieras i ModelAdmin.readonly_fields för att visas som skrivskyddade.

\n

För mer komplexa layoutbehov, se alternativet fieldsets.

\n

Alternativet fields accepterar samma typer av värden som list_display, förutom att callables och __-uppslagningar för relaterade fält inte accepteras. Namn på modell- och modelladministrationsmetoder kommer endast att användas om de listas i readonly_fields.

\n

Om du vill visa flera fält på samma rad, paketerar du fälten i en egen tupel. I det här exemplet kommer fälten url och title att visas på samma rad och fältet content kommer att visas under dem på en egen rad:

\n
Code
class FlatPageAdmin(admin.ModelAdmin):\n    fields = [("url", "title"), "content"]\n
\n\n

Om varken fields eller fieldsets-alternativen är närvarande, kommer Django som standard att visa varje fält som inte är ett AutoField och har editable=True, i en enda fieldset, i samma ordning som fälten definieras i modellen, följt av alla fält som definieras i readonly_fields.

\n
\n\n
\n
\nModelAdmin.fieldsetsLink to this definition#
\n

Ställ in fieldsets för att styra layouten på adminsidorna ”add” och ”change”.

\n

fieldsets är en lista med 2-tupler, där varje 2-tupel representerar en <fieldset> på sidan med adminformuläret. (En <fieldset> är en ”sektion” av formuläret.)

\n

De 2-tuplarna är i formatet (name, field_options), där name är en sträng som representerar titeln på fieldset och field_options är en ordbok med information om fieldset, inklusive en lista över fält som ska visas i det.

\n

Ett fullständigt exempel, hämtat från modellen django.contrib.flatpages.models.FlatPage:

\n
Code
from django.contrib import admin\n\n\nclass FlatPageAdmin(admin.ModelAdmin):\n    fieldsets = [\n        (\n            None,\n            {\n                "fields": ["url", "title", "content", "sites"],\n            },\n        ),\n        (\n            "Advanced options",\n            {\n                "classes": ["collapse"],\n                "fields": ["registration_required", "template_name"],\n            },\n        ),\n    ]\n
\n

Detta resulterar i en administratörssida som ser ut som följer:

\n\"/sv/6.1/_images/fieldsets.png\"\n

Om varken fieldsets eller fields-alternativen är närvarande, kommer Django som standard att visa varje fält som inte är ett AutoField och har editable=True, i ett enda fieldset, i samma ordning som fälten definieras i modellen.

\n

Ordlistan field_options kan ha följande nycklar:

\n
    \n
  • \n
    fält

    En lista eller tupel med fältnamn som ska visas i denna fieldset. Denna nyckel är obligatorisk.

    \n

    Exempel:

    \n
    Code
    {\n    "fields": ["first_name", "last_name", "address", "city", "state"],\n}\n
    \n

    Precis som med alternativet fields kan du visa flera fält på samma rad genom att lägga in fälten i en egen tupel. I det här exemplet kommer fälten first_name och last_name att visas på samma rad:

    \n
    Code
    {\n    "fields": [("first_name", "last_name"), "address", "city", "state"],\n}\n
    \n

    fields kan innehålla värden som definieras i readonly_fields för att visas som skrivskyddade.

    \n

    Om du lägger till namnet på en callable i fields gäller samma regel som med alternativet fields: callable måste listas i readonly_fields.

    \n
    \n
    \n
    • \n
  • \n
    klasser

    En lista eller tupel med extra CSS-klasser som ska tillämpas på fältuppsättningen. Den kan innehålla valfri anpassad CSS-klass som definieras i projektet, liksom CSS-klassen som tillhandahålls av Django: collapse.

    \n

    Exempel:

    \n
    Code
    {\n    "classes": ["collapse"],\n}\n
    \n

    Fältuppsättningar med ett namn och stilen collapse är inledningsvis hopfällda och använder en expanderbar widget med en växlare för att ändra deras synlighet.

    \n\n
    \n
    \n
    • \n
  • \n
    Beskrivning

    En sträng med valfri extra text som ska visas högst upp i varje fältmängd, under fältmängdens rubrik.

    \n

    Observera att detta värde inte är HTML-escaped när det visas i admin-gränssnittet. Detta gör att du kan inkludera HTML om du så önskar. Alternativt kan du använda vanlig text och django.utils.html.escape() för att undkomma eventuella HTML-specialtecken.

    \n
    \n
    \n
    • \n
\n\n
\n\n
\n
\nModelAdmin.filter_horizontalLink to this definition#
\n

Som standard visas en ManyToManyField på administratörssidan med en <select multiple>. Flervalslådor kan dock vara svåra att använda när man väljer många objekt. Om du lägger till en ManyToManyField till den här listan används istället ett snyggt, diskret JavaScript-”filter”-gränssnitt som gör det möjligt att söka bland alternativen. De omarkerade och markerade alternativen visas i två rutor sida vid sida. Se filter_vertical för att använda ett vertikalt gränssnitt.

\n
\n\n
\n
\nModelAdmin.filter_verticalLink to this definition#
\n

Samma som filter_horizontal, men använder en vertikal visning av filtergränssnittet där rutan med omarkerade alternativ visas ovanför rutan med markerade alternativ.

\n
\n\n
\n
\nModelAdmin.formLink to this definition#
\n

Som standard skapas ett ModelForm dynamiskt för din modell. Det används för att skapa formuläret som visas på både tilläggs- och ändringssidorna. Du kan enkelt tillhandahålla din egen ModelForm för att åsidosätta alla standardformulärbeteenden på tilläggs-/ändringssidorna. Alternativt kan du anpassa standardformuläret i stället för att ange ett helt nytt genom att använda metoden ModelAdmin.get_form().

\n

För ett exempel, se avsnittet Lägga till anpassad validering i admin.

\n\n\n
\n\n
\n
\nModelAdmin.formfield_overridesLink to this definition#
\n

Detta ger ett snabbt och enkelt sätt att åsidosätta några av Field-alternativen för användning i admin. formfield_overrides är en ordbok som mappar en fältklass till en dikt av argument som ska skickas till fältet vid konstruktionstid.

\n

Eftersom det är lite abstrakt, låt oss titta på ett konkret exempel. Den vanligaste användningen av formfield_overrides är att lägga till en anpassad widget för en viss typ av fält. Så, tänk dig att vi har skrivit en RichTextEditorWidget som vi skulle vilja använda för stora textfält istället för standard <textarea>. Så här skulle vi göra det:

\n
Code
from django.contrib import admin\nfrom django.db import models\n\n# Import our custom widget and our model from where they're defined\nfrom myapp.models import MyModel\nfrom myapp.widgets import RichTextEditorWidget\n\n\nclass MyModelAdmin(admin.ModelAdmin):\n    formfield_overrides = {\n        models.TextField: {"widget": RichTextEditorWidget},\n    }\n
\n

Observera att nyckeln i ordlistan är den faktiska fältklassen, inte en sträng. Värdet är en annan dictionary; dessa argument kommer att skickas till formulärfältets __init__()-metod. Se API för formulär för mer information.

\n\n
\n\n
\n
\nModelAdmin.inlinesLink to this definition#
\n

Se InlineModelAdmin-objekt nedan samt ModelAdmin.get_formsets_with_inlines().

\n
\n\n
\n
\nModelAdmin.list_displayLink to this definition#
\n

Ställ in list_display för att styra vilka fält som ska visas på sidan med ändringslistan i admin.

\n

Exempel:

\n
Code
list_display = ["first_name", "last_name"]\n
\n

Om du inte ställer in list_display kommer administratörssidan att visa en enda kolumn som visar __str__()-representationen av varje objekt.

\n

Det finns fem typer av värden som kan användas i list_display. Alla utom den enklaste kan använda display()-dekoratorn, som används för att anpassa hur fältet presenteras:

\n
    \n

  • Namnet på ett modellfält. Till exempel:

    \n
    Code
    class PersonAdmin(admin.ModelAdmin):\n    list_display = ["first_name", "last_name"]\n
    \n
    • \n

  • Namnet på ett relaterat fält med hjälp av notationen __. Till exempel:

    \n
    Code
    class PersonAdmin(admin.ModelAdmin):\n    list_display = ["city__name"]\n
    \n
    • \n

  • En anropsbar funktion som accepterar ett argument, modellinstansen. Till exempel:

    \n
    Code
    @admin.display(description="Name")\ndef upper_case_name(obj):\n    return f"{obj.first_name} {obj.last_name}".upper()\n\n\nclass PersonAdmin(admin.ModelAdmin):\n    list_display = [upper_case_name]\n
    \n
    • \n

  • En sträng som representerar en ModelAdmin-metod som accepterar ett argument, modellinstansen. Till exempel:

    \n
    Code
    class PersonAdmin(admin.ModelAdmin):\n    list_display = ["upper_case_name"]\n\n    @admin.display(description="Name")\n    def upper_case_name(self, obj):\n        return f"{obj.first_name} {obj.last_name}".upper()\n
    \n
    • \n

  • En sträng som representerar ett modellattribut eller en metod (utan några obligatoriska argument). Till exempel:

    \n
    Code
    from django.contrib import admin\nfrom django.db import models\n\n\nclass Person(models.Model):\n    name = models.CharField(max_length=50)\n    birthday = models.DateField()\n\n    @admin.display(description="Birth decade")\n    def decade_born_in(self):\n        decade = self.birthday.year // 10 * 10\n        return f"{decade}’s"\n\n\nclass PersonAdmin(admin.ModelAdmin):\n    list_display = ["name", "decade_born_in"]\n
    \n
    • \n
\n

Några specialfall att notera om list_display:

\n
    \n

  • Om fältet är en ForeignKey, kommer Django att visa __str__() för det relaterade objektet.

    • \n

  • fält av typen ManyToManyField stöds inte, eftersom det skulle innebära att en separat SQL-sats måste köras för varje rad i tabellen. Om du ändå vill göra det här kan du ge din modell en anpassad metod och lägga till metodens namn i list_display. (Se nedan för mer information om anpassade metoder i list_display)

    • \n

  • Om fältet är en BooleanField, kommer Django att visa en vacker ”ja”, ”nej” eller ”okänd” ikon istället för True, False eller None.

    • \n

  • Om den angivna strängen är en metod för modellen, ModelAdmin eller en anropsbar, kommer Django att HTML-escape utdata som standard. Använd format_html() för att undkomma användarens inmatning och tillåta dina egna taggar som inte är escapade.

    \n

    Här är ett fullständigt exempel på en modell:

    \n
    Code
    from django.contrib import admin\nfrom django.db import models\nfrom django.utils.html import format_html\n\n\nclass Person(models.Model):\n    first_name = models.CharField(max_length=50)\n    last_name = models.CharField(max_length=50)\n    color_code = models.CharField(max_length=6)\n\n    @admin.display\n    def colored_name(self):\n        return format_html(\n            '<span style="color: #{};">{} {}</span>',\n            self.color_code,\n            self.first_name,\n            self.last_name,\n        )\n\n\nclass PersonAdmin(admin.ModelAdmin):\n    list_display = ["first_name", "last_name", "colored_name"]\n
    \n
    • \n

  • Som några exempel redan har visat, när du använder en anropbar, en modellmetod eller en ModelAdmin-metod, kan du anpassa kolumnens titel genom att linda in den anropbara med display()-dekoratorn och skicka argumentet description.

    • \n

  • Om värdet på ett fält är None, en tom sträng eller en iterabel utan element, kommer Django att visa - (ett streck). Du kan åsidosätta detta med AdminSite.empty_value_display:

    \n
    Code
    from django.contrib import admin\n\nadmin.site.empty_value_display = "(None)"\n
    \n

    Du kan också använda ModelAdmin.empty_value_display:

    \n
    Code
    class PersonAdmin(admin.ModelAdmin):\n    empty_value_display = "unknown"\n
    \n

    Eller på fältnivå:

    \n
    Code
    class PersonAdmin(admin.ModelAdmin):\n    list_display = ["name", "birth_date_view"]\n\n    @admin.display(empty_value="unknown")\n    def birth_date_view(self, obj):\n        return obj.birth_date\n
    \n
    • \n

  • Om den angivna strängen är en metod för modellen, ModelAdmin eller en anropsbar som returnerar True, False eller None, kommer Django att visa en vacker ”ja”, ”nej” eller ”okänd” ikon om du lindar in metoden med display() dekoratorn som passerar boolean argumentet med värdet inställt på True:

    \n
    Code
    from django.contrib import admin\nfrom django.db import models\n\n\nclass Person(models.Model):\n    first_name = models.CharField(max_length=50)\n    birthday = models.DateField()\n\n    @admin.display(boolean=True)\n    def born_in_fifties(self):\n        return 1950 <= self.birthday.year < 1960\n\n\nclass PersonAdmin(admin.ModelAdmin):\n    list_display = ["name", "born_in_fifties"]\n
    \n
    • \n

  • Metoden __str__() är precis lika giltig i list_display som alla andra modellmetoder, så det är helt OK att göra detta:

    \n
    Code
    list_display = ["__str__", "some_other_field"]\n
    \n
    • \n

  • Vanligtvis kan element i list_display som inte är faktiska databasfält inte användas i sortering (eftersom Django gör all sortering på databasnivå).

    \n

    Men om ett element i list_display representerar ett visst databasfält kan du ange detta genom att använda display()-dekoratorn på metoden och skicka argumentet ordering:

    \n
    Code
    from django.contrib import admin\nfrom django.db import models\nfrom django.utils.html import format_html\n\n\nclass Person(models.Model):\n    first_name = models.CharField(max_length=50)\n    color_code = models.CharField(max_length=6)\n\n    @admin.display(ordering="first_name")\n    def colored_first_name(self):\n        return format_html(\n            '<span style="color: #{};">{}</span>',\n            self.color_code,\n            self.first_name,\n        )\n\n\nclass PersonAdmin(admin.ModelAdmin):\n    list_display = ["first_name", "colored_first_name"]\n
    \n

    Ovanstående kommer att tala om för Django att ordna efter fältet förnamn när man försöker sortera efter färgat_förnamn i admin.

    \n

    För att ange fallande ordning med argumentet ordering kan du använda ett bindestrecksprefix på fältnamnet. Med hjälp av ovanstående exempel skulle detta se ut som:

    \n
    Code
    @admin.display(ordering="-first_name")\ndef colored_first_name(self): ...\n
    \n

    Argumentet ordering stöder frågeuppslagningar för att sortera efter värden i relaterade modeller. Detta exempel innehåller en kolumn ”författarens förnamn” i listvisningen och gör det möjligt att sortera den efter förnamn:

    \n
    Code
    class Blog(models.Model):\n    title = models.CharField(max_length=255)\n    author = models.ForeignKey(Person, on_delete=models.CASCADE)\n\n\nclass BlogAdmin(admin.ModelAdmin):\n    list_display = ["title", "author", "author_first_name"]\n\n    @admin.display(ordering="author__first_name")\n    def author_first_name(self, obj):\n        return obj.author.first_name\n
    \n

    Query expressions kan användas med argumentet ordering:

    \n
    Code
    from django.db.models import Value\nfrom django.db.models.functions import Concat\n\n\nclass Person(models.Model):\n    first_name = models.CharField(max_length=50)\n    last_name = models.CharField(max_length=50)\n\n    @admin.display(ordering=Concat("first_name", Value(" "), "last_name"))\n    def full_name(self):\n        return self.first_name + " " + self.last_name\n
    \n
    • \n

  • Element i list_display kan också vara egenskaper

    \n
    Code
    class Person(models.Model):\n    first_name = models.CharField(max_length=50)\n    last_name = models.CharField(max_length=50)\n\n    @property\n    @admin.display(\n        ordering="last_name",\n        description="Full name of the person",\n        boolean=False,\n    )\n    def full_name(self):\n        return self.first_name + " " + self.last_name\n\n\nclass PersonAdmin(admin.ModelAdmin):\n    list_display = ["full_name"]\n
    \n

    Observera att @property måste stå över @display. Om du använder det gamla sättet - att ställa in de display-relaterade attributen direkt istället för att använda display()-dekoratorn - var medveten om att funktionen property() och inte @property-dekoratorn måste användas:

    \n
    Code
    def my_property(self):\n    return self.first_name + " " + self.last_name\n\n\nmy_property.short_description = "Full name of the person"\nmy_property.admin_order_field = "last_name"\nmy_property.boolean = False\n\nfull_name = property(my_property)\n
    \n
    • \n

  • Fältnamnen i list_display kommer också att visas som CSS-klasser i HTML-utdata, i form av column-<field_name> på varje <th>-element. Detta kan till exempel användas för att ställa in kolumnbredder i en CSS-fil.

    • \n

  • Django kommer att försöka tolka varje element i list_display i denna ordning:

    \n
      \n

    • Ett område av modellen eller från ett relaterat område.

      • \n

    • En anropsbar enhet.

      • \n

    • En sträng som representerar ett ModelAdmin-attribut.

      • \n

    • En sträng som representerar ett modellattribut.

      • \n
    \n

    Om du t.ex. har first_name som ett modellfält och som ett ModelAdmin-attribut, kommer modellfältet att användas.

    \n
    • \n
\n
\n\n
\n
\nModelAdmin.list_display_linksLink to this definition#
\n

Använd list_display_links för att styra om och vilka fält i list_display som ska länkas till ”change”-sidan för ett objekt.

\n

Som standard kommer sidan med ändringslistan att länka den första kolumnen - det första fältet som anges i list_display - till ändringssidan för varje objekt. Men med list_display_links kan du ändra detta:

\n
    \n

  • Ställ in den på None för att inte få några länkar alls.

    • \n

  • Ange en lista eller tupel av fält (i samma format som list_display) vars kolumner du vill konvertera till länkar.

    \n

    Du kan ange ett eller flera fält. Så länge fälten visas i list_display bryr sig Django inte om hur många (eller hur få) fält som är länkade. Det enda kravet är att om du vill använda list_display_links på det här sättet måste du definiera list_display.

    \n
    • \n
\n

I det här exemplet kommer fälten ”förnamn” och ”efternamn” att länkas på sidan för ändringslistan:

\n
Code
class PersonAdmin(admin.ModelAdmin):\n    list_display = ["first_name", "last_name", "birthday"]\n    list_display_links = ["first_name", "last_name"]\n
\n

I det här exemplet har rutnätet för sidan med ändringslistan inga länkar:

\n
Code
class AuditEntryAdmin(admin.ModelAdmin):\n    list_display = ["timestamp", "message"]\n    list_display_links = None\n
\n
\n\n
\n
\nModelAdmin.list_editableLink to this definition#
\n

Ange list_editable till en lista med fältnamn i modellen som kan redigeras på sidan med ändringslistan. Det innebär att fält som listas i list_editable kommer att visas som formulärwidgets på sidan med ändringslistan, så att användarna kan redigera och spara flera rader samtidigt.

\n\n
\n\n
\n
\nModelAdmin.list_filterLink to this definition#
\n

Ställ in list_filter för att aktivera filter i höger sidofält på sidan med ändringslistan i admin.

\n

I sin enklaste form tar list_filter en lista eller tupel av fältnamn för att aktivera filtrering på, men flera mer avancerade alternativ finns tillgängliga. Se ModelAdmin Lista Filter för mer information.

\n
\n\n
\n
\nModelAdmin.list_max_show_allLink to this definition#
\n

Ställ in list_max_show_all för att styra hur många objekt som kan visas på en ”Visa alla”-sida för adminändringslistan. Administratören kommer att visa en ”Visa alla”-länk på ändringslistan endast om det totala antalet resultat är mindre än eller lika med denna inställning. Som standard är detta inställt på 200.

\n
\n\n
\n
\nModelAdmin.list_per_pageLink to this definition#
\n

Ställ in list_per_page för att styra hur många objekt som visas på varje paginerad sida i listan över adminändringar. Som standard är detta inställt på 100.

\n
\n\n
\n
\nModelAdmin.list_select_relatedLink to this definition#
\n

Ställ in list_select_related för att tala om för Django att använda select_related() vid hämtning av listan över objekt på sidan med adminändringslistan. Detta kan spara dig en massa databasfrågor.

\n

Värdet ska vara antingen en boolean, en lista eller en tupel. Standardvärdet är False.

\n

När värdet är True, kommer select_related() alltid att anropas. När värdet är satt till False, kommer Django att titta på list_display och anropa select_related() om någon ForeignKey finns.

\n

Om du behöver mer finkornig kontroll kan du använda en tupel (eller lista) som värde för list_select_related. Tom tuple kommer att förhindra Django från att anropa select_related överhuvudtaget. Alla andra tupler kommer att skickas direkt till select_related som parametrar. Till exempel:

\n
Code
class ArticleAdmin(admin.ModelAdmin):\n    list_select_related = ["author", "category"]\n
\n

kommer att anropa select_related('author', 'category').

\n

Om du behöver ange ett dynamiskt värde baserat på begäran kan du implementera en get_list_select_related()-metod.

\n\n\n
\n\n
\n
\nModelAdmin.orderingLink to this definition#
\n

Ange ordering för att specificera hur listor med objekt ska ordnas i Django admin-vyerna. Detta bör vara en lista eller tupel i samma format som en modells ordering parameter.

\n

Om detta inte anges kommer Django-administratören att använda modellens standardbeställning.

\n

Om du behöver ange en dynamisk ordning (t.ex. beroende på användare eller språk) kan du implementera en get_ordering()-metod.

\n\n
\n\n
\n
\nModelAdmin.paginatorLink to this definition#
\n

Den paginatorklass som ska användas för paginering. Som standard används django.core.paginator.Paginator. Om den anpassade paginatorklassen inte har samma konstruktörsgränssnitt som django.core.paginator.Paginator, måste du också tillhandahålla en implementering för ModelAdmin.get_paginator().

\n
\n\n
\n
\nModelAdmin.prepopulated_fieldsLink to this definition#
\n

Ange prepopulated_fields till en ordbok som mappar fältnamn till de fält som den ska förinställa från:

\n
Code
class ArticleAdmin(admin.ModelAdmin):\n    prepopulated_fields = {"slug": ["title"]}\n
\n

När den är inställd kommer de angivna fälten att använda lite JavaScript för att fyllas i från de tilldelade fälten. Den huvudsakliga användningen av denna funktion är att automatiskt generera värdet för ”SlugField”-fälten från ett eller flera andra fält. Det genererade värdet skapas genom att sammanfoga värdena i källfälten och sedan omvandla resultatet till en giltig slug (t.ex. genom att ersätta mellanslag med bindestreck och ASCII-bokstäver med gemener).

\n

Förfyllda fält ändras inte av JavaScript efter att ett värde har sparats. Det är vanligtvis inte önskvärt att sluggar ändras (vilket skulle leda till att ett objekts URL ändras om sluggen används i det).

\n

prepopulated_fields accepterar inte fälten DateTimeField, ForeignKey, OneToOneField och ManyToManyField.

\n
\n\n
\n
\nModelAdmin.preserve_filtersLink to this definition#
\n

Som standard bevaras tillämpade filter i listvyn efter att ett objekt har skapats, redigerats eller tagits bort. Du kan rensa bort filter genom att ställa in detta attribut på False.

\n
\n\n
\n
\nModelAdmin.show_facetsLink to this definition#
\n

Styr om antalet facetter ska visas för filter i adminändringslistan. Standardvärde är ShowFacets.ALLOW.

\n

När de visas uppdateras antalet facetter i linje med de filter som används för tillfället.

\n
\n
\nclass ShowFacetsLink to this definition#
\n

En lista över tillåtna värden för ModelAdmin.show_facets.

\n
\n
\nALWAYSLink to this definition#
\n

Visa alltid att fasetten räknas.

\n
\n\n
\n
\nALLOWLink to this definition#
\n

Visa facettantal när parametern _facets för frågesträng anges.

\n
\n\n
\n
\nNEVERLink to this definition#
\n

Visa aldrig antalet fasetter.

\n
\n\n
\n\n

Ställ in show_facets till önskat värde för ShowFacets. Om du t.ex. alltid vill visa antalet facetter utan att behöva ange frågeparametern:

\n
Code
from django.contrib import admin\n\n\nclass MyModelAdmin(admin.ModelAdmin):\n    ...\n    # Have facets always shown for this model admin.\n    show_facets = admin.ShowFacets.ALWAYS\n
\n\n
\n\n
\n
\nModelAdmin.radio_fieldsLink to this definition#
\n

Som standard använder Djangos admin ett select-box-gränssnitt (<select>) för fält som är ForeignKey eller har choices inställt. Om ett fält finns i radio_fields kommer Django att använda ett radioknappsgränssnitt istället. Förutsatt att group är en ForeignKey på Person modellen:

\n
Code
class PersonAdmin(admin.ModelAdmin):\n    radio_fields = {"group": admin.VERTICAL}\n
\n

Du kan välja att använda HORIZONTAL eller VERTICAL från modulen django.contrib.admin.

\n

Inkludera inte ett fält i radio_fields om det inte är en ForeignKey eller har choices inställt.

\n
\n\n
\n
\nModelAdmin.autocomplete_fieldsLink to this definition#
\n

autocomplete_fields är en lista över ForeignKey och/eller ManyToManyField fält som du vill ändra till Select2 autokompletteringsinmatningar.

\n

Som standard använder administratören ett select-box-gränssnitt (<select>) för dessa fält. Ibland vill du inte ta på dig omkostnader för att välja alla relaterade instanser som ska visas i rullgardinsmenyn.

\n

Select2-inmatningen liknar standardinmatningen men har en sökfunktion som laddar alternativen asynkront. Detta är snabbare och mer användarvänligt om den relaterade modellen har många instanser.

\n

Du måste definiera search_fields på det relaterade objektets ModelAdmin eftersom autokompletteringssökningen använder den.

\n

För att undvika obehörigt utlämnande av data måste användare ha behörigheten view eller change till det relaterade objektet för att kunna använda autokomplettering.

\n

Ordning och paginering av resultaten styrs av den relaterade ModelAdmin get_ordering() och get_paginator() metoderna.

\n

I följande exempel har ChoiceAdmin ett fält för autokomplettering av ForeignKey till Question. Resultaten filtreras efter fältet question_text och sorteras efter fältet date_created:

\n
Code
class QuestionAdmin(admin.ModelAdmin):\n    ordering = ["date_created"]\n    search_fields = ["question_text"]\n\n\nclass ChoiceAdmin(admin.ModelAdmin):\n    autocomplete_fields = ["question"]\n
\n\n
\n\n
\n
\nModelAdmin.raw_id_fieldsLink to this definition#
\n

Som standard använder Djangos admin ett gränssnitt med en valbox (<select>) för fält som är ForeignKey. Ibland vill du inte ta på dig omkostnaderna för att behöva välja alla relaterade instanser som ska visas i rullgardinsmenyn.

\n

raw_id_fields är en lista över fält som du vill ändra till en Input widget för antingen en ForeignKey eller ManyToManyField:

\n
Code
class ArticleAdmin(admin.ModelAdmin):\n    raw_id_fields = ["newspaper"]\n
\n

Widgeten Input för raw_id_fields ska innehålla en primärnyckel om fältet är ForeignKey, eller en kommaseparerad lista med värden om fältet är ManyToManyField. Widgeten raw_id_fields visar en knapp med förstoringsglas bredvid fältet som låter användare söka efter och välja ett värde:

\n\"/sv/6.1/_images/raw_id_fields.png\"\n
\n\n
\n
\nModelAdmin.readonly_fieldsLink to this definition#
\n

Som standard visar administratören alla fält som redigerbara. Alla fält i detta alternativ (som bör vara en list eller tuple) kommer att visa sina data som de är och inte redigerbara; de är också uteslutna från ModelForm som används för att skapa och redigera. Observera att när du anger ModelAdmin.fields eller ModelAdmin.fieldsets måste de skrivskyddade fälten vara närvarande för att visas (annars ignoreras de).

\n

Om readonly_fields används utan att definiera explicit ordning genom ModelAdmin.fields eller ModelAdmin.fieldsets kommer de att läggas till sist efter alla redigerbara fält.

\n

Ett skrivskyddat fält kan inte bara visa data från en modells fält, det kan också visa utdata från en modells metod eller en metod i själva klassen ModelAdmin. Detta är mycket likt det sätt som ModelAdmin.list_display fungerar på. Detta ger ett sätt att använda admin-gränssnittet för att ge feedback om statusen för de objekt som redigeras, till exempel:

\n
Code
from django.contrib import admin\nfrom django.utils.html import format_html_join\nfrom django.utils.safestring import mark_safe\n\n\nclass PersonAdmin(admin.ModelAdmin):\n    readonly_fields = ["address_report"]\n\n    # description functions like a model field's verbose_name\n    @admin.display(description="Address")\n    def address_report(self, instance):\n        # assuming get_full_address() returns a list of strings\n        # for each line of the address and you want to separate each\n        # line by a linebreak\n        return format_html_join(\n            mark_safe("<br>"),\n            "{}",\n            ((line,) for line in instance.get_full_address()),\n        ) or mark_safe("<span class='errors'>I can't determine this address.</span>")\n
\n
\n\n
\n
\nModelAdmin.save_asLink to this definition#
\n

Ställ in save_as för att aktivera en ”spara som ny”-funktion på adminändringsformulär.

\n

Normalt har objekt tre sparalternativ: ”Spara”, ”Spara och fortsätt redigera” och ”Spara och lägg till en annan”. Om save_as är True kommer ”Save and add another” att ersättas av en ”Save as new”-knapp som skapar ett nytt objekt (med ett nytt ID) i stället för att uppdatera det befintliga objektet.

\n

Som standard är save_as inställd på False.

\n
\n\n
\n
\nModelAdmin.save_as_continueLink to this definition#
\n

När save_as=True är standardomdirigeringen efter att det nya objektet har sparats till ändringsvyn för det objektet. Om du anger save_as_continue=False kommer omdirigeringen att ske till vyn för ändringslistan.

\n

Som standard är save_as_continue inställd på True.

\n
\n\n
\n
\nModelAdmin.save_on_topLink to this definition#
\n

Ställ in save_on_top för att lägga till sparaknappar överst i dina ändringsformulär för administratörer.

\n

Normalt visas sparaknapparna bara längst ned i formulären. Om du anger save_on_top kommer knapparna att visas både överst och nederst.

\n

Som standard är save_on_top inställd på False.

\n
\n\n
\n
\nModelAdmin.search_fieldsLink to this definition#
\n

Ställ in search_fields för att aktivera en sökruta på sidan för adminändringslistan. Detta bör ställas in på en lista med fältnamn som kommer att sökas när någon skickar in en sökfråga i den textrutan.

\n

Dessa fält är vanligen textfält som CharField eller TextField, men även icke-textfält som IntegerField kan sökas. Genom att lägga till ett uttryckligt uppslag, såsom age__exact, kan sökningen använda uppslaget direkt i stället för att omvandla värdet till text. Du kan också utföra ett relaterat uppslag på ett ForeignKey eller ManyToManyField med uppslags-API:ets ”follow”-notation:

\n
Code
search_fields = ["foreign_key__related_fieldname"]\n
\n

Om du t.ex. har ett blogginlägg med en författare skulle följande definition göra det möjligt att söka efter blogginlägg med hjälp av författarens e-postadress:

\n
Code
search_fields = ["user__email"]\n
\n

När någon söker i admins sökruta delar Django upp sökfrågan i söktermer och returnerar alla objekt som innehåller var och en av dem i minst ett av search_fields. Som standard används uppslaget icontains för textfält. För icke-textfält med ett uttryckligt uppslag (t.ex. age__exact) används det angivna uppslaget, och söktermer som är ogiltiga för den fälttypen hoppas över.

\n

Om search_fields till exempel är satt till ['first_name', 'last_name', 'age__exact'] och en användare söker efter john 25, gör Django motsvarigheten till följande SQL-WHERE-sats:

\n
SQL
WHERE (first_name ILIKE '%john%' OR last_name ILIKE '%john%')\nAND (first_name ILIKE '%25%' OR last_name ILIKE '%25%' OR age = 25)\n
\n

Observera att john inte söks efter i age eftersom det inte är ett giltigt heltal, medan 25 söks efter i alla tre fält.

\n

Sökfrågan kan innehålla citerade fraser med mellanslag. Till exempel:, om en användare söker efter "john winston" eller 'john winston', kommer Django att göra motsvarande denna SQL WHERE klausul:

\n
SQL
WHERE (first_name ILIKE '%john winston%' OR last_name ILIKE '%john winston%')\n
\n

Om du inte vill använda icontains som uppslagsord kan du använda vilket uppslagsord som helst genom att lägga till det i fältet. Du kan till exempel använda exact genom att ställa in search_fields till ['first_name__exact'].

\n

Vissa (äldre) genvägar för att ange en fältuppslagning finns också tillgängliga. Du kan prefixa ett fält i search_fields med följande tecken och det motsvarar att lägga till __<lookup> till fältet:

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Prefix

Uppslag

^

istartswith

=

iexact

@

search

Inget

ikoner

\n
\n

Om du behöver anpassa sökningen kan du använda ModelAdmin.get_search_results() för att tillhandahålla ytterligare eller alternativt sökbeteende.

\n\n
\n\n
\n
\nModelAdmin.search_help_textLink to this definition#
\n

Ange search_help_text för att ange en beskrivande text för sökrutan som kommer att visas under den.

\n
\n\n
\n
\nModelAdmin.show_full_result_countLink to this definition#
\n

Ställ in show_full_result_count för att styra om hela antalet objekt ska visas på en filtrerad adminsida (t.ex. 99 resultat (103 totalt)). Om detta alternativ är inställt på False visas istället en text som 99 resultat (Visa alla).

\n

Standardvärdet show_full_result_count=True genererar en fråga för att utföra en fullständig räkning av tabellen, vilket kan vara dyrt om tabellen innehåller ett stort antal rader.

\n
\n\n
\n
\nModelAdmin.sortable_byLink to this definition#
\n

Som standard tillåter sidan med ändringslistan sortering efter alla modellfält (och anropsbara som använder argumentet ordering till dekoratorn display() eller har attributet admin_order_field) som anges i list_display.

\n

Om du vill inaktivera sortering för vissa kolumner anger du ortable_by till en samling (t.ex. list, tuple eller set) av den delmängd av list_display som du vill ska vara sorterbar. En tom samling inaktiverar sortering för alla kolumner.

\n

Om du behöver ange den här listan dynamiskt, implementera en get_sortable_by()-metod istället.

\n
\n\n
\n
\nModelAdmin.view_on_siteLink to this definition#
\n

Ställ in view_on_site för att styra om länken ”View on site” ska visas eller inte. Den här länken ska leda dig till en URL där du kan visa det sparade objektet.

\n

Detta värde kan vara antingen en boolesk flagga eller en callable. Om True (standard) kommer objektets get_absolute_url()-metod att användas för att generera webbadressen.

\n

Om din modell har en get_absolute_url()-metod men du inte vill att knappen ”Visa på webbplatsen” ska visas, behöver du bara ställa in view_on_site till False:

\n
Code
from django.contrib import admin\n\n\nclass PersonAdmin(admin.ModelAdmin):\n    view_on_site = False\n
\n

Om det är en callable accepterar den modellinstansen som en parameter. Till exempel:

\n
Code
from django.contrib import admin\nfrom django.urls import reverse\n\n\nclass PersonAdmin(admin.ModelAdmin):\n    def view_on_site(self, obj):\n        url = reverse("person-detail", kwargs={"slug": obj.slug})\n        return "https://example.com" + url\n
\n
\n\n
\n

Anpassade mallalternativLink to this heading#

\n

Avsnittet Åsidosätta adminmallar beskriver hur du åsidosätter eller utökar standardadminmallarna. Använd följande alternativ för att åsidosätta standardmallarna som används av vyerna i ModelAdmin:

\n
\n
\nModelAdmin.add_form_templateLink to this definition#
\n

Sökväg till en anpassad mall som används av add_view().

\n
\n\n
\n
\nModelAdmin.change_form_templateLink to this definition#
\n

Sökväg till en anpassad mall som används av change_view().

\n
\n\n
\n
\nModelAdmin.change_list_templateLink to this definition#
\n

Sökväg till en anpassad mall som används av changelist_view().

\n
\n\n
\n
\nModelAdmin.delete_confirmation_templateLink to this definition#
\n

Sökväg till en anpassad mall som används av delete_view() för att visa en bekräftelsesida när ett eller flera objekt tas bort.

\n
\n\n
\n
\nModelAdmin.delete_selected_confirmation_templateLink to this definition#
\n

Sökväg till en anpassad mall som används av åtgärdsmetoden delete_selected för att visa en bekräftelsesida när ett eller flera objekt tas bort. Se dokumentation om åtgärder.

\n
\n\n
\n
\nModelAdmin.delete_confirmation_max_displayLink to this definition#
\n
\n

Sätt delete_confirmation_max_display för att styra hur många objekt som visas på sidorna för borttagningsbekräftelse innan återstoden trunkeras med en ellips.

\n

Gränsen gäller det totala antalet visade objekt i hela relationshierarkin. Detta är endast en visningsinställning och påverkar inte det totala antalet objekt som hämtas från databasen.

\n

Detta gäller delete_view() och åtgärden delete_selected om det anges för ModelAdmin, samt valideringsmeddelanden för skyddad borttagning om det anges för InlineModelAdmin. Standardvärdet är None (ingen trunkering).

\n
\n\n
\n
\nModelAdmin.object_history_templateLink to this definition#
\n

Sökväg till en anpassad mall som används av history_view().

\n
\n\n
\n
\nModelAdmin.popup_response_templateLink to this definition#
\n

Sökväg till en anpassad mall som används av response_add(), response_change() och response_delete().

\n
\n\n
\n
\n
\n

metoder för ModelAdminLink to this heading#

\n\n
\n
\nModelAdmin.save_model(request, obj, form, change)Link to this definition#
\n

Metoden save_model får HttpRequest, en modellinstans, en ModelForm-instans och ett booleanskt värde baserat på om den lägger till eller ändrar objektet. Genom att åsidosätta denna metod kan man göra för- eller eftersparande operationer. Anropa super().save_model() för att spara objektet med Model.save().

\n

Till exempel: för att koppla request.user till objektet innan det sparas:

\n
Code
from django.contrib import admin\n\n\nclass ArticleAdmin(admin.ModelAdmin):\n    def save_model(self, request, obj, form, change):\n        obj.user = request.user\n        super().save_model(request, obj, form, change)\n
\n
\n\n
\n
\nModelAdmin.delete_model(request, obj)Link to this definition#
\n

Metoden delete_model får HttpRequest och en modellinstans. Genom att åsidosätta denna metod kan du göra åtgärder före eller efter borttagning. Anropa super().delete_model() för att radera objektet med Model.delete().

\n
\n\n
\n
\nModelAdmin.delete_queryset(request, queryset)Link to this definition#
\n

Metoden delete_queryset() får HttpRequest och en QuerySet med objekt som ska tas bort. Åsidosätt metoden för att anpassa borttagningsprocessen för åtgärden ”ta bort markerade objekt”.

\n
\n\n
\n
\nModelAdmin.save_formset(request, form, formset, change)Link to this definition#
\n

Metoden save_formset får HttpRequest, den överordnade ModelForm-instansen och ett boolean-värde baserat på om den lägger till eller ändrar det överordnade objektet.

\n

Till exempel:, för att koppla request.user till varje ändrad formulärmodellinstans:

\n
Code
class ArticleAdmin(admin.ModelAdmin):\n    def save_formset(self, request, form, formset, change):\n        instances = formset.save(commit=False)\n        for obj in formset.deleted_objects:\n            obj.delete()\n        for instance in instances:\n            instance.user = request.user\n            instance.save()\n        formset.save_m2m()\n
\n

Se även Spara objekt i formuläret.

\n
\n\n\n
\n
\nModelAdmin.get_ordering(request)Link to this definition#
\n

Metoden get_ordering tar en request som parameter och förväntas returnera en list eller tuple för ordning på liknande sätt som attributet ordering. Till exempel:

\n
Code
class PersonAdmin(admin.ModelAdmin):\n    def get_ordering(self, request):\n        if request.user.is_superuser:\n            return ["name", "rank"]\n        else:\n            return ["name"]\n
\n
\n\n
\n
\nModelAdmin.get_search_results(request, queryset, search_term)Link to this definition#
\n

Metoden get_search_results ändrar listan över objekt som visas till de som matchar den angivna söktermen. Den accepterar begäran, en queryset som tillämpar de aktuella filtren och den sökterm som användaren angett. Den returnerar en tupel som innehåller en queryset som modifierats för att genomföra sökningen och en boolean som anger om resultaten kan innehålla dubbletter.

\n

Standardimplementeringen söker i de fält som anges i ModelAdmin.search_fields.

\n

Denna metod kan åsidosättas med din egen anpassade sökmetod. Du kanske t.ex. vill söka efter ett heltalsfält eller använda ett externt verktyg som Solr eller Haystack. Du måste fastställa om de ändringar i queryset som genomförs av din sökmetod kan leda till dubbletter i resultaten och returnera True i det andra elementet i returvärdet.

\n

Om du t.ex. vill söka efter namn och ålder kan du använda:

\n
Code
class PersonAdmin(admin.ModelAdmin):\n    list_display = ["name", "age"]\n    search_fields = ["name"]\n\n    def get_search_results(self, request, queryset, search_term):\n        queryset, may_have_duplicates = super().get_search_results(\n            request,\n            queryset,\n            search_term,\n        )\n        try:\n            search_term_as_int = int(search_term)\n        except ValueError:\n            pass\n        else:\n            queryset |= self.model.objects.filter(age=search_term_as_int)\n        return queryset, may_have_duplicates\n
\n

Denna implementering är effektivare än search_fields = ('name', '= age') vilket resulterar i en strängjämförelse för det numeriska fältet, till exempel `` … ELLER UPPER (”polls_choice”.”votes”::text) = UPPER (’4’)`` på PostgreSQL.

\n
\n\n
\n
\nModelAdmin.save_related(request, form, formsets, change)Link to this definition#
\n

Metoden save_related får HttpRequest, den överordnade ModelForm-instansen, listan över inline-formulär och ett boolean-värde som baseras på om den överordnade instansen läggs till eller ändras. Här kan du göra alla för- eller eftersparingsåtgärder för objekt som är relaterade till föräldern. Observera att det överordnade objektet och dess formulär redan har sparats vid denna tidpunkt.

\n
\n\n
\n
\nModelAdmin.get_autocomplete_fields(request)Link to this definition#
\n

Metoden get_autocomplete_fields() får HttpRequest och förväntas returnera en list eller tuple med fältnamn som kommer att visas med en widget för autokomplettering enligt beskrivningen ovan i avsnittet ModelAdmin.autocomplete_fields.

\n
\n\n
\n
\nModelAdmin.get_readonly_fields(request, obj=None)Link to this definition#
\n

Metoden get_readonly_fields får HttpRequest och obj som redigeras (eller None i ett add-formulär) och förväntas returnera en list eller tuple med fältnamn som ska visas som skrivskyddade, enligt beskrivningen ovan i avsnittet ModelAdmin.readonly_fields.

\n
\n\n
\n
\nModelAdmin.get_prepopulated_fields(request, obj=None)Link to this definition#
\n

Metoden get_prepopulated_fields får HttpRequest och obj som redigeras (eller None i ett add-formulär) och förväntas returnera en dictionary, enligt beskrivningen ovan i avsnittet ModelAdmin.prepopulated_fields.

\n
\n\n
\n
\nModelAdmin.get_list_display(request)Link to this definition#
\n

Metoden get_list_display ges HttpRequest och förväntas returnera en lista eller tupel med fältnamn som kommer att visas i vyn med ändringslistan enligt beskrivningen ovan i avsnittet ModelAdmin.list_display.

\n
\n\n
\n
\nModelAdmin.get_list_display_links(request, list_display)Link to this definition#
\n

Metoden get_list_display_links får HttpRequest och den list eller tuple som returneras av ModelAdmin.get_list_display(). Den förväntas returnera antingen None eller en list eller tuple med fältnamn på changelistan som kommer att länkas till ändringsvyn, enligt beskrivningen i avsnittet ModelAdmin.list_display_links.

\n
\n\n
\n
\nModelAdmin.get_exclude(request, obj=None)Link to this definition#
\n

Metoden get_exclude får HttpRequest och obj som redigeras (eller None i ett add-formulär) och förväntas returnera en lista med fält, enligt beskrivningen i ModelAdmin.exclude.

\n
\n\n
\n
\nModelAdmin.get_fields(request, obj=None)Link to this definition#
\n

Metoden get_fields får HttpRequest och obj som redigeras (eller None i ett add-formulär) och förväntas returnera en lista med fält, enligt beskrivningen ovan i avsnittet ModelAdmin.fields.

\n
\n\n
\n
\nModelAdmin.get_fieldsets(request, obj=None)Link to this definition#
\n

Metoden get_fieldsets får HttpRequest och obj som redigeras (eller None på ett add-formulär) och förväntas returnera en lista med 2-tupler, där varje 2-tupel representerar en <fieldset> på admin-formulärsidan, enligt beskrivningen ovan i avsnittet ModelAdmin.fieldsets.

\n
\n\n
\n
\nModelAdmin.get_list_filter(request)Link to this definition#
\n

Metoden get_list_filter ges HttpRequest och förväntas returnera samma typ av sekvenstyp som för attributet list_filter.

\n
\n\n
\n
\nModelAdmin.get_list_select_related(request)Link to this definition#
\n

Metoden get_list_select_related ges till HttpRequest och bör returnera en boolean eller lista som ModelAdmin.list_select_related gör.

\n\n
\n\n
\n
\nModelAdmin.get_search_fields(request)Link to this definition#
\n

Metoden get_search_fields ges HttpRequest och förväntas returnera samma typ av sekvenstyp som för attributet search_fields.

\n
\n\n
\n
\nModelAdmin.get_sortable_by(request)Link to this definition#
\n

Metoden get_sortable_by() skickas till HttpRequest och förväntas returnera en samling (t.ex. list, tuple eller set) av fältnamn som kommer att kunna sorteras på sidan med ändringslistan.

\n

Dess standardimplementering returnerar sortable_by om den är inställd, annars hänvisar den till get_list_display().

\n

Till exempel: för att förhindra att en eller flera kolumner är sorterbara:

\n
Code
class PersonAdmin(admin.ModelAdmin):\n    def get_sortable_by(self, request):\n        return {*self.get_list_display(request)} - {"rank"}\n
\n
\n\n
\n
\nModelAdmin.get_inline_instances(request, obj=None)Link to this definition#
\n

Metoden get_inline_instances får HttpRequest och obj som redigeras (eller None i ett add-formulär) och förväntas returnera en list eller tuple av InlineModelAdmin-objekt, enligt beskrivningen nedan i avsnittet InlineModelAdmin. Följande skulle till exempel returnera inlines utan standardfiltrering baserat på behörigheter för att lägga till, ändra, ta bort och visa:

\n
Code
class MyModelAdmin(admin.ModelAdmin):\n    inlines = [MyInline]\n\n    def get_inline_instances(self, request, obj=None):\n        return [inline(self.model, self.admin_site) for inline in self.inlines]\n
\n

Om du åsidosätter den här metoden måste du se till att de returnerade inlines är instanser av de klasser som definieras i inlines, annars kan du få ett ”Bad Request”-fel när du lägger till relaterade objekt.

\n
\n\n
\n
\nModelAdmin.get_inlines(request, obj)Link to this definition#
\n

Metoden get_inlines får HttpRequest och obj som redigeras (eller None i ett add-formulär) och förväntas returnera en iterabel med inlines. Du kan åsidosätta den här metoden för att dynamiskt lägga till inlines baserat på begäran eller modellinstansen istället för att ange dem i ModelAdmin.inlines.

\n
\n\n
\n
\nModelAdmin.get_urls()Link to this definition#
\n

Metoden get_urls för en ModelAdmin returnerar de URL:er som ska användas för den ModelAdmin på samma sätt som en URLconf. Du kan därför utöka dem enligt dokumentationen i URL-distributör, med omslutningen AdminSite.admin_view() kring dina vyer:

\n
Code
from django.contrib import admin\nfrom django.template.response import TemplateResponse\nfrom django.urls import path\n\n\nclass MyModelAdmin(admin.ModelAdmin):\n    def get_urls(self):\n        urls = super().get_urls()\n        my_urls = [path("my_view/", self.admin_site.admin_view(self.my_view))]\n        return my_urls + urls\n\n    def my_view(self, request):\n        # ...\n        context = dict(\n            # Include common variables for rendering the admin template.\n            self.admin_site.each_context(request),\n            # Anything else you want in the context...\n            key=value,\n        )\n        return TemplateResponse(request, "sometemplate.html", context)\n
\n

Om du vill använda adminlayouten, förläng från admin/base_site.html:

\n
Django template
{% extends "admin/base_site.html" %}\n{% block content %}\n...\n{% endblock %}\n
\n\n\n

Om sidan kan cachas, men du ändå vill att behörighetskontrollen ska utföras, kan du skicka ett cacheable=True-argument till AdminSite.admin_view():

\n
Code
path("my_view/", self.admin_site.admin_view(self.my_view, cacheable=True))\n
\n

vyerna ModelAdmin har attributen model_admin. Andra AdminSite-vyer har admin_site-attribut.

\n
\n\n
\n
\nModelAdmin.get_form(request, obj=None, **kwargs)Link to this definition#
\n

Returnerar en ModelForm-klass för användning i admin-vyerna för tillägg och ändring, se add_view() och change_view().

\n

Basimplementeringen använder modelform_factory() för att underklassa form, modifierad av attribut som fields och exclude. Så om du till exempel vill erbjuda ytterligare fält till superanvändare kan du byta ut ett annat basformulär så här:

\n
Code
class MyModelAdmin(admin.ModelAdmin):\n    def get_form(self, request, obj=None, **kwargs):\n        if request.user.is_superuser:\n            kwargs["form"] = MySuperuserForm\n        return super().get_form(request, obj, **kwargs)\n
\n

Du kan också returnera en anpassad ModelForm-klass direkt.

\n
\n\n
\n
\nModelAdmin.get_formsets_with_inlines(request, obj=None)Link to this definition#
\n

Ger (FormSet, InlineModelAdmin) par för användning i admin-vyer för tillägg och ändring.

\n

Om du t.ex. vill visa en viss inline endast i ändringsvyn kan du åsidosätta get_formsets_with_inlines på följande sätt:

\n
Code
class MyModelAdmin(admin.ModelAdmin):\n    inlines = [MyInline, SomeOtherInline]\n\n    def get_formsets_with_inlines(self, request, obj=None):\n        for inline in self.get_inline_instances(request, obj):\n            # hide MyInline in the add view\n            if not isinstance(inline, MyInline) or obj is not None:\n                yield inline.get_formset(request, obj), inline\n
\n
\n\n
\n
\nModelAdmin.formfield_for_foreignkey(db_field, request, **kwargs)Link to this definition#
\n

Med metoden formfield_for_foreignkey på en ModelAdmin kan du åsidosätta standardformfältet för ett främmande nyckelfält. Till exempel:, för att returnera en delmängd av objekt för detta främmande nyckelfält baserat på användaren:

\n
Code
class MyModelAdmin(admin.ModelAdmin):\n    def formfield_for_foreignkey(self, db_field, request, **kwargs):\n        if db_field.name == "car":\n            kwargs["queryset"] = Car.objects.filter(owner=request.user)\n        return super().formfield_for_foreignkey(db_field, request, **kwargs)\n
\n

Detta använder HttpRequest-instansen för att filtrera främmande nyckelfältet Car för att endast visa de bilar som ägs av User-instansen.

\n

För mer komplexa filter kan du använda metoden ModelForm.__init__() för att filtrera baserat på en instans av din modell (se Fält som hanterar relationer). Till exempel:

\n
Code
class CountryAdminForm(forms.ModelForm):\n    def __init__(self, *args, **kwargs):\n        super().__init__(*args, **kwargs)\n        self.fields["capital"].queryset = self.instance.cities.all()\n\n\nclass CountryAdmin(admin.ModelAdmin):\n    form = CountryAdminForm\n
\n
\n\n
\n
\nModelAdmin.formfield_for_manytomany(db_field, request, **kwargs)Link to this definition#
\n

I likhet med metoden formfield_for_foreignkey kan metoden formfield_for_manytomany åsidosättas för att ändra standardformulärsfältet för ett många till många-fält. Om t.ex. en ägare kan äga flera bilar och bilar kan tillhöra flera ägare - en många till många-relation - kan du filtrera främmande nyckelfältet Car så att det bara visar de bilar som ägs av User:

\n
Code
class MyModelAdmin(admin.ModelAdmin):\n    def formfield_for_manytomany(self, db_field, request, **kwargs):\n        if db_field.name == "cars":\n            kwargs["queryset"] = Car.objects.filter(owner=request.user)\n        return super().formfield_for_manytomany(db_field, request, **kwargs)\n
\n
\n\n
\n
\nModelAdmin.formfield_for_choice_field(db_field, request, **kwargs)Link to this definition#
\n

Precis som metoderna formfield_for_foreignkey och formfield_for_manytomany kan metoden formfield_for_choice_field åsidosättas för att ändra standardformulärsfältet för ett fält som har deklarerade val. Om t.ex. de val som är tillgängliga för en superanvändare ska vara annorlunda än de som är tillgängliga för den vanliga personalen, kan du göra på följande sätt:

\n
Code
class MyModelAdmin(admin.ModelAdmin):\n    def formfield_for_choice_field(self, db_field, request, **kwargs):\n        if db_field.name == "status":\n            kwargs["choices"] = [\n                ("accepted", "Accepted"),\n                ("denied", "Denied"),\n            ]\n            if request.user.is_superuser:\n                kwargs["choices"].append(("ready", "Ready for deployment"))\n        return super().formfield_for_choice_field(db_field, request, **kwargs)\n
\n\n
\n\n
\n
\nModelAdmin.get_changelist(request, **kwargs)Link to this definition#
\n

Returnerar klassen Changelist som ska användas för listning. Som standard används django.contrib.admin.views.main.ChangeList. Genom att ärva denna klass kan du ändra beteendet för listningen.

\n
\n\n
\n
\nModelAdmin.get_changelist_form(request, **kwargs)Link to this definition#
\n

Returnerar en ModelForm-klass för användning i Formset på changelist-sidan. För att använda ett anpassat formulär, till exempel:

\n
Code
from django import forms\n\n\nclass MyForm(forms.ModelForm):\n    pass\n\n\nclass MyModelAdmin(admin.ModelAdmin):\n    def get_changelist_form(self, request, **kwargs):\n        return MyForm\n
\n\n
\n\n
\n
\nModelAdmin.get_changelist_formset(request, **kwargs)Link to this definition#
\n

Returnerar en ModelFormSet-klass för användning på sidan med ändringslistan om list_editable används. Om du vill använda en anpassad formuläruppsättning, till exempel:

\n
Code
from django.forms import BaseModelFormSet\n\n\nclass MyAdminFormSet(BaseModelFormSet):\n    pass\n\n\nclass MyModelAdmin(admin.ModelAdmin):\n    def get_changelist_formset(self, request, **kwargs):\n        kwargs["formset"] = MyAdminFormSet\n        return super().get_changelist_formset(request, **kwargs)\n
\n
\n\n
\n
\nModelAdmin.lookup_allowed(lookup, value, request)Link to this definition#
\n

Objekten på sidan med ändringslistan kan filtreras med hjälp av uppslagningar från URL:ens frågesträng. Det är så här list_filter fungerar, till exempel. Uppslagningarna liknar det som används i QuerySet.filter() (t.ex. user__email=user@example.com). Eftersom sökningarna i frågesträngen kan manipuleras av användaren måste de rensas för att förhindra obehörig exponering av data.

\n

Metoden lookup_allowed() får en sökväg från frågesträngen (t.ex. 'user__email'), motsvarande värde (t.ex. 'user@example.com') och begäran, och returnerar en boolean som anger om filtrering av changelistans QuerySet med parametrarna är tillåten. Om lookup_allowed() returnerar False, aktiveras DisallowedModelAdminLookup (underklass till SuspiciousOperation).

\n

Som standard tillåter lookup_allowed() åtkomst till en modells lokala fält, fältsökvägar som används i list_filter (men inte sökvägar från get_list_filter()) och uppslagningar som krävs för att limit_choices_to ska fungera korrekt i raw_id_fields.

\n

Åsidosätt denna metod för att anpassa de tillåtna uppslagningarna för din ModelAdmin-underklass.

\n
\n\n
\n
\nModelAdmin.has_view_permission(request, obj=None)Link to this definition#
\n

Ska returnera True om användaren har behörighet att komma åt ändrings- eller historikvyn för obj, annars False. Om obj är None ska True eller False returneras för att ange om visning av objekt av den här typen är tillåten generellt (t.ex. tolkas False som att den aktuella användaren inte har behörighet att visa något objekt av den här typen).

\n

Standardimplementeringen returnerar True om användaren har antingen behörigheten ”change” eller ”view”.

\n\n
\n\n
\n
\nModelAdmin.has_add_permission(request)Link to this definition#
\n

Ska returnera True om det är tillåtet att lägga till ett objekt, annars False.

\n
\n\n
\n
\nModelAdmin.has_change_permission(request, obj=None)Link to this definition#
\n

Bör returnera True om det är tillåtet att redigera obj, annars False. Om obj är None, bör returnera True eller False för att ange om redigering av objekt av denna typ är tillåten i allmänhet (t.ex. kommer False att tolkas som att den aktuella användaren inte får redigera något objekt av denna typ).

\n
\n\n
\n
\nModelAdmin.has_delete_permission(request, obj=None)Link to this definition#
\n

Bör returnera True om det är tillåtet att radera obj, annars False. Om obj är None, bör returnera True eller False för att ange om det är tillåtet att radera objekt av denna typ i allmänhet (t.ex. kommer False att tolkas som att den aktuella användaren inte får radera något objekt av denna typ).

\n
\n\n
\n
\nModelAdmin.has_module_permission(request)Link to this definition#
\n

Bör returnera True om det är tillåtet att visa modulen på adminindexsidan och komma åt modulens indexsida, annars False. Använder User.has_module_perms() som standard. Att åsidosätta det begränsar inte åtkomsten till vyn, lägg till, ändra eller ta bort vyer, has_view_permission(), has_add_permission(), has_change_permission() och has_delete_permission() bör användas för det.

\n
\n\n
\n
\nModelAdmin.get_queryset(request)Link to this definition#
\n

Metoden get_queryset på en ModelAdmin returnerar en QuerySet av alla modellinstanser som kan redigeras av administratörswebbplatsen. Ett användningsfall för att åsidosätta den här metoden är att visa objekt som ägs av den inloggade användaren:

\n
Code
class MyModelAdmin(admin.ModelAdmin):\n    def get_queryset(self, request):\n        qs = super().get_queryset(request)\n        if request.user.is_superuser:\n            return qs\n        return qs.filter(author=request.user)\n
\n
\n\n
\n
\nModelAdmin.message_user(request, message, level=messages.INFO, extra_tags='', fail_silently=False)Link to this definition#
\n

Skickar ett meddelande till användaren med backenden django.contrib.messages. Se exemplet med anpassad ModelAdmin.

\n

Med nyckelordsargument kan du ändra meddelandenivån, lägga till extra CSS-taggar eller misslyckas tyst om ramverket contrib.messages inte är installerat. Dessa nyckelordsargument matchar dem för django.contrib.messages.add_message(), se den funktionens dokumentation för mer information. En skillnad är att nivån kan skickas som en strängetikett utöver heltal/konstant.

\n
\n\n
\n
\nModelAdmin.get_paginator(request, queryset, per_page, orphans=0, allow_empty_first_page=True)Link to this definition#
\n

Returnerar en instans av den paginator som ska användas för den här vyn. Som standard instansieras en instans av paginator.

\n
\n\n
\n
\nModelAdmin.response_add(request, obj, post_url_continue=None)Link to this definition#
\n

Bestämmer HttpResponse för add_view()-steget.

\n

response_add anropas efter att adminformuläret har skickats in och precis efter att objektet och alla relaterade instanser har skapats och sparats. Du kan åsidosätta det för att ändra standardbeteendet efter att objektet har skapats.

\n
\n\n
\n
\nModelAdmin.response_change(request, obj)Link to this definition#
\n

Bestämmer HttpResponse för change_view()-steget.

\n

response_change anropas efter att adminformuläret har skickats in och precis efter att objektet och alla relaterade instanser har sparats. Du kan åsidosätta den för att ändra standardbeteendet efter att objektet har ändrats.

\n
\n\n
\n
\nModelAdmin.response_delete(request, obj_display, obj_id)Link to this definition#
\n

Bestämmer HttpResponse för delete_view()-steget.

\n

response_delete anropas efter att objektet har tagits bort. Du kan åsidosätta det för att ändra standardbeteendet efter att objektet har tagits bort.

\n

obj_display är en sträng med namnet på det borttagna objektet.

\n

obj_id är den serialiserade identifieraren som används för att hämta det objekt som ska raderas.

\n
\n\n
\n
\nModelAdmin.get_formset_kwargs(request, obj, inline, prefix)Link to this definition#
\n

En hook för att anpassa de nyckelordsargument som skickas till konstruktören för ett formulär. Till exempel:, för att skicka request till formuläret forms:

\n
Code
class MyModelAdmin(admin.ModelAdmin):\n    def get_formset_kwargs(self, request, obj, inline, prefix):\n        return {\n            **super().get_formset_kwargs(request, obj, inline, prefix),\n            "form_kwargs": {"request": request},\n        }\n
\n

Du kan också använda den för att ställa in initial för formulär.

\n
\n\n
\n
\nModelAdmin.get_changeform_initial_data(request)Link to this definition#
\n

En hook för initialdata i formulär för adminändringar. Som standard ges fält initiala värden från GET-parametrar. Till exempel: kommer ?name=initial_value att ställa in fältet name initiala värde till att vara initial_value.

\n

Denna metod ska returnera en ordbok i form av {'fieldname': 'fieldval'}:

\n
Code
def get_changeform_initial_data(self, request):\n    return {"name": "custom_initial_value"}\n
\n
\n\n
\n
\nModelAdmin.get_deleted_objects(objs, request)Link to this definition#
\n

En hook för att anpassa borttagningsprocessen i delete_view() och åtgärden ”ta bort markerade objekt”.

\n

Argumentet objs är en homogen iterabel av objekt (en QuerySet eller en lista av modellinstanser) som ska raderas, och request är HttpRequest.

\n

Denna metod måste returnera en 4-tupel av (deleted_objects, model_count, perms_needed, protected).

\n

deleted_objects är en lista med strängar som representerar alla objekt som kommer att raderas. Om det finns några relaterade objekt som ska raderas, är listan nästlad och inkluderar dessa relaterade objekt. Listan formateras i mallen med hjälp av filtret unordered_list.

\n

model_count är en ordbok som mappar varje modells verbose_name_plural till antalet objekt som kommer att raderas.

\n

perms_needed är en uppsättning verbose_name` av de modeller som användaren inte har behörighet att ta bort.

\n

protected är en lista med strängar som representerar alla skyddade relaterade objekt som inte kan tas bort. Listan visas i mallen.

\n
\n\n
\n

Andra metoderLink to this heading#

\n
\n
\nModelAdmin.add_view(request, form_url='', extra_context=None)Link to this definition#
\n

Django-vy för sidan med tillägg av modellinstans. Se anmärkning nedan.

\n
\n\n
\n
\nModelAdmin.change_view(request, object_id, form_url='', extra_context=None)Link to this definition#
\n

Django-vy för sidan för redigering av modellinstanser. Se anmärkning nedan.

\n
\n\n
\n
\nModelAdmin.changelist_view(request, extra_context=None)Link to this definition#
\n

Django-vy för sidan med ändringslista/åtgärder för modellinstanser. Se anmärkning nedan.

\n
\n\n
\n
\nModelAdmin.delete_view(request, object_id, extra_context=None)Link to this definition#
\n

Django-vy för bekräftelsesidan för borttagning av modellinstans(er). Se anmärkning nedan.

\n
\n\n
\n
\nModelAdmin.history_view(request, object_id, extra_context=None)Link to this definition#
\n

Djangovy för sidan som visar ändringshistoriken för en given modellinstans.

\n
\n\n

Till skillnad från hook-typen ModelAdmin-metoder som beskrivs i föregående avsnitt, är dessa fem metoder i verkligheten utformade för att anropas som Django-vyer från admin-applikationens URL-distributionshanterare för att rendera de sidor som hanterar CRUD-operationer för modellinstanser. Som ett resultat kommer fullständig åsidosättande av dessa metoder att avsevärt ändra beteendet hos adminapplikationen.

\n

En vanlig anledning till att åsidosätta dessa metoder är att utöka de kontextdata som tillhandahålls till den mall som renderar vyn. I följande exempel åsidosätts change-vyn så att den renderade mallen får lite extra mappningsdata som annars inte skulle vara tillgänglig:

\n
Code
class MyModelAdmin(admin.ModelAdmin):\n    # A template for a very customized change view:\n    change_form_template = "admin/myapp/extras/openstreetmap_change_form.html"\n\n    def get_osm_info(self):\n        # ...\n        pass\n\n    def change_view(self, request, object_id, form_url="", extra_context=None):\n        extra_context = extra_context or {}\n        extra_context["osm_data"] = self.get_osm_info()\n        return super().change_view(\n            request,\n            object_id,\n            form_url,\n            extra_context=extra_context,\n        )\n
\n

Dessa vyer returnerar TemplateResponse-instanser som gör att du enkelt kan anpassa svarsdata före rendering. För mer information, se TemplateResponse-dokumentation.

\n
\n
\n
\n

ModelAdmin tillgångsdefinitionerLink to this heading#

\n

Det finns tillfällen då du vill lägga till lite CSS och/eller JavaScript i vyerna för att lägga till/ändra. Detta kan åstadkommas genom att använda en Media inre klass på din ModelAdmin:

\n
Code
class ArticleAdmin(admin.ModelAdmin):\n    class Media:\n        css = {\n            "all": ["my_styles.css"],\n        }\n        js = ["my_code.js"]\n
\n

Appen staticfiles app prependlar STATIC_URL (eller MEDIA_URL om STATIC_URL är None) till alla sökvägar för tillgångar. Samma regler gäller som för regelbundna tillgångsdefinitioner på formulär.

\n
\n

jQueryLink to this heading#

\n

Django admin JavaScript använder sig av biblioteket jQuery.

\n

För att undvika konflikter med skript eller bibliotek som tillhandahålls av användaren, är Djangos jQuery (version 3.7.1) namngivet som django.jQuery. Om du vill använda jQuery i din egen admin JavaScript utan att inkludera en andra kopia kan du använda objektet django.jQuery på changelist och add/edit-vyer. Dessutom måste dina egna adminformulär eller widgets som är beroende av django.jQuery ange js=['admin/js/jquery.init.js', ...] när declaring form media assets.

\n

Klassen ModelAdmin kräver jQuery som standard, så det finns inget behov av att lägga till jQuery i listan över mediaresurser i ModelAdmin om du inte har ett specifikt behov. Om du t.ex. behöver jQuery-biblioteket i det globala namnområdet (t.ex. när du använder jQuery-plugins från tredje part) eller om du behöver en nyare version av jQuery måste du inkludera en egen kopia.

\n

Django tillhandahåller både okomprimerade och ’minifierade’ versioner av jQuery, som jquery.js respektive jquery.min.js.

\n

ModelAdmin och InlineModelAdmin har en media-egenskap som returnerar en lista med Media-objekt som lagrar sökvägar till JavaScript-filerna för formulären och/eller formuläruppsättningarna. Om DEBUG är True kommer den att returnera de okomprimerade versionerna av de olika JavaScript-filerna, inklusive jquery.js; om inte, kommer den att returnera de ’minifierade’ versionerna.

\n
\n
\n
\n
\n

objekt av typen ``InlineModelAdminLink to this heading#

\n
\n
\nclass InlineModelAdminLink to this definition#
\n
\n\n
\n
\nclass TabularInlineLink to this definition#
\n
\n\n
\n
\nclass StackedInlineLink to this definition#
\n

I administratörsgränssnittet finns möjlighet att redigera modeller på samma sida som en överordnad modell. Dessa kallas inlines. Anta att du har dessa två modeller:

\n
Code
from django.db import models\n\n\nclass Author(models.Model):\n    name = models.CharField(max_length=100)\n\n\nclass Book(models.Model):\n    author = models.ForeignKey(Author, on_delete=models.CASCADE)\n    title = models.CharField(max_length=100)\n
\n

Du kan redigera de böcker som en författare har skrivit på författarsidan. Du lägger till inlines i en modell genom att ange dem i en ModelAdmin.inlines:

\n
Code
from django.contrib import admin\nfrom myapp.models import Author, Book\n\n\nclass BookInline(admin.TabularInline):\n    model = Book\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n    inlines = [\n        BookInline,\n    ]\n\n\nadmin.site.register(Author, AuthorAdmin)\n
\n

Django tillhandahåller två underklasser av InlineModelAdmin och de är:

\n\n

Skillnaden mellan dessa två är bara den mall som används för att rendera dem.

\n
\n\n
\n

InlineModelAdmin alternativLink to this heading#

\n

InlineModelAdmin delar många av samma funktioner som ModelAdmin och lägger till några egna (de delade funktionerna definieras faktiskt i superklassen BaseModelAdmin). De delade funktionerna är:

\n\n

Klassen InlineModelAdmin lägger till eller anpassar:

\n
\n
\nInlineModelAdmin.modelLink to this definition#
\n

Den modell som inline använder. Detta är obligatoriskt.

\n
\n\n
\n
\nInlineModelAdmin.fk_nameLink to this definition#
\n

Namnet på den främmande nyckeln i modellen. I de flesta fall hanteras detta automatiskt, men fk_name måste anges explicit om det finns mer än en främmande nyckel till samma överordnade modell.

\n
\n\n
\n
\nInlineModelAdmin.formsetLink to this definition#
\n

Detta är standardvärdet för BaseInlineFormSet. Att använda din egen formuläruppsättning kan ge dig många möjligheter till anpassning. Inlines är uppbyggda kring model formsets.

\n
\n\n
\n
\nInlineModelAdmin.formLink to this definition#
\n

Värdet för form är som standard ModelForm. Detta är vad som skickas till inlineformset_factory() när formuläret för denna inline skapas.

\n

För ett exempel, se avsnittet Lägga till anpassad validering i admin.

\n
\n\n\n
\n
\nInlineModelAdmin.classesLink to this definition#
\n

En lista eller tupel som innehåller extra CSS-klasser som ska tillämpas på den fältuppsättning som återges för inlines. Standardvärdet är None. Precis som med klasser som konfigureras i fieldsets, kommer inlines med en collapse-klass att initialt kollapsas med hjälp av en expanderbar widget.

\n
\n\n
\n
\nInlineModelAdmin.extraLink to this definition#
\n

Detta styr antalet extra formulär som formuläruppsättningen ska visa utöver de ursprungliga formulären. Standardvärdet är 3. Mer information finns i dokumentationen för formulär.

\n

För användare med JavaScript-aktiverade webbläsare finns en ”Add another”-länk som gör det möjligt att lägga till ytterligare inlines utöver de som följer av argumentet extra.

\n

Den dynamiska länken visas inte om antalet formulär som visas för närvarande överstiger max_num, eller om användaren inte har JavaScript aktiverat.

\n

InlineModelAdmin.get_extra() gör det också möjligt att anpassa antalet extra formulär.

\n
\n\n
\n
\nInlineModelAdmin.max_numLink to this definition#
\n

Detta styr det maximala antalet formulär som ska visas i inline. Detta korrelerar inte direkt med antalet objekt, men kan göra det om värdet är tillräckligt litet. Se Begränsa antalet redigerbara objekt för mer information.

\n

InlineModelAdmin.get_max_num() gör det också möjligt att anpassa det maximala antalet extra formulär.

\n
\n\n
\n
\nInlineModelAdmin.min_numLink to this definition#
\n

Detta styr det minsta antalet formulär som ska visas i inline. Se modelformset_factory() för mer information.

\n

InlineModelAdmin.get_min_num() kan du också anpassa det minsta antalet formulär som visas.

\n
\n\n
\n
\nInlineModelAdmin.raw_id_fieldsLink to this definition#
\n

Som standard använder Djangos admin ett gränssnitt med en valbox (<select>) för fält som är ForeignKey. Ibland vill du inte ta på dig omkostnaderna för att behöva välja alla relaterade instanser som ska visas i rullgardinsmenyn.

\n

raw_id_fields är en lista över fält som du vill ändra till en Input widget för antingen en ForeignKey eller ManyToManyField:

\n
Code
class BookInline(admin.TabularInline):\n    model = Book\n    raw_id_fields = ["pages"]\n
\n
\n\n
\n
\nInlineModelAdmin.templateLink to this definition#
\n

Den mall som används för att återge inline på sidan.

\n
\n\n
\n
\nInlineModelAdmin.verbose_nameLink to this definition#
\n

En åsidosättning av verbose_name från modellens inre Meta-klass.

\n
\n\n
\n
\nInlineModelAdmin.verbose_name_pluralLink to this definition#
\n

En åsidosättning av verbose_name_plural från modellens inre Meta-klass. Om detta inte ges och InlineModelAdmin.verbose_name är definierat, kommer Django att använda InlineModelAdmin.verbose_name + 's'.

\n
\n\n
\n
\nInlineModelAdmin.can_deleteLink to this definition#
\n

Anger om inline-objekt kan raderas i inline eller inte. Standardvärdet är True.

\n
\n\n
\n
\nInlineModelAdmin.show_change_linkLink to this definition#
\n

Anger om inline-objekt som kan ändras i admin har en länk till ändringsformuläret eller inte. Standardvärdet är False.

\n
\n\n
\n
\nInlineModelAdmin.get_formset(request, obj=None, **kwargs)Link to this definition#
\n

Returnerar en BaseInlineFormSet-klass för användning i administratörsvyer för tillägg/ändring. obj är det överordnade objektet som redigeras eller None när du lägger till en ny överordnad. Se exemplet för ModelAdmin.get_formsets_with_inlines.

\n
\n\n
\n
\nInlineModelAdmin.get_extra(request, obj=None, **kwargs)Link to this definition#
\n

Returnerar antalet extra inline-formulär som ska användas. Som standard returneras attributet InlineModelAdmin.extra.

\n

Åsidosätt denna metod för att programmatiskt bestämma antalet extra inline-formulär. Detta kan t.ex. baseras på modellinstansen (som skickas som nyckelordsargumentet obj):

\n
Code
class BinaryTreeAdmin(admin.TabularInline):\n    model = BinaryTree\n\n    def get_extra(self, request, obj=None, **kwargs):\n        extra = 2\n        if obj:\n            return extra - obj.binarytree_set.count()\n        return extra\n
\n
\n\n
\n
\nInlineModelAdmin.get_max_num(request, obj=None, **kwargs)Link to this definition#
\n

Returnerar det maximala antalet extra inline-formulär som ska användas. Som standard returneras attributet InlineModelAdmin.max_num.

\n

Åsidosätt denna metod för att programmatiskt bestämma det maximala antalet inline-formulär. Detta kan t.ex. baseras på modellinstansen (som skickas som nyckelordsargumentet obj):

\n
Code
class BinaryTreeAdmin(admin.TabularInline):\n    model = BinaryTree\n\n    def get_max_num(self, request, obj=None, **kwargs):\n        max_num = 10\n        if obj and obj.parent:\n            return max_num - 5\n        return max_num\n
\n
\n\n
\n
\nInlineModelAdmin.get_min_num(request, obj=None, **kwargs)Link to this definition#
\n

Returnerar det minsta antalet inline-formulär som ska användas. Som standard returneras attributet InlineModelAdmin.min_num.

\n

Åsidosätt denna metod för att programmatiskt bestämma det minsta antalet inline-formulär. Detta kan t.ex. baseras på modellinstansen (som skickas som nyckelordsargumentet obj).

\n
\n\n
\n
\nInlineModelAdmin.has_add_permission(request, obj)Link to this definition#
\n

Ska returnera True om det är tillåtet att lägga till ett inline-objekt, annars False. obj är det överordnade objektet som redigeras eller None när du lägger till ett nytt överordnat objekt.

\n
\n\n
\n
\nInlineModelAdmin.has_change_permission(request, obj=None)Link to this definition#
\n

Ska returnera True om det är tillåtet att redigera ett inline-objekt, annars False. obj är det överordnade objektet som redigeras.

\n
\n\n
\n
\nInlineModelAdmin.has_delete_permission(request, obj=None)Link to this definition#
\n

Ska returnera True om det är tillåtet att ta bort ett inline-objekt, annars False. obj är det överordnade objektet som redigeras.

\n
\n\n\n
\n
\n

Arbeta med en modell med två eller flera främmande nycklar till samma överordnade modellLink to this heading#

\n

Det är ibland möjligt att ha mer än en främmande nyckel till samma modell. Ta den här modellen till exempel:

\n
Code
from django.db import models\n\n\nclass Person(models.Model):\n    name = models.CharField(max_length=128)\n\n\nclass Friendship(models.Model):\n    to_person = models.ForeignKey(\n        Person, on_delete=models.CASCADE, related_name="friends"\n    )\n    from_person = models.ForeignKey(\n        Person, on_delete=models.CASCADE, related_name="from_friends"\n    )\n
\n

Om du vill visa en inline på sidorna för tillägg/ändring av administratörer för Person måste du uttryckligen definiera den främmande nyckeln eftersom den inte kan göra det automatiskt:

\n
Code
from django.contrib import admin\nfrom myapp.models import Friendship, Person\n\n\nclass FriendshipInline(admin.TabularInline):\n    model = Friendship\n    fk_name = "to_person"\n\n\nclass PersonAdmin(admin.ModelAdmin):\n    inlines = [\n        FriendshipInline,\n    ]\n\n\nadmin.site.register(Person, PersonAdmin)\n
\n
\n
\n

Arbeta med många-till-många-modellerLink to this heading#

\n

Som standard kommer admin-widgets för många-till-många-relationer att visas på den modell som innehåller den faktiska referensen till ManyToManyField. Beroende på din ModelAdmin-definition kommer varje many-to-many-fält i din modell att representeras av en standard HTML <select multiple>, ett horisontellt eller vertikalt filter eller en raw_id_fields-widget. Det är dock också möjligt att ersätta dessa widgetar med inlines.

\n

Anta att vi har följande modeller:

\n
Code
from django.db import models\n\n\nclass Person(models.Model):\n    name = models.CharField(max_length=128)\n\n\nclass Group(models.Model):\n    name = models.CharField(max_length=128)\n    members = models.ManyToManyField(Person, related_name="groups")\n
\n

Om du vill visa många-till-många-relationer med hjälp av en inline kan du göra det genom att definiera ett InlineModelAdmin-objekt för relationen:

\n
Code
from django.contrib import admin\nfrom myapp.models import Group\n\n\nclass MembershipInline(admin.TabularInline):\n    model = Group.members.through\n\n\nclass GroupAdmin(admin.ModelAdmin):\n    inlines = [\n        MembershipInline,\n    ]\n    exclude = ["members"]\n\n\nadmin.site.register(Group, GroupAdmin)\n
\n

Det finns två funktioner som är värda att notera i detta exempel.

\n

För det första - klassen MembershipInline refererar till Group.members.through. Attributet through är en referens till den modell som hanterar relationen många-till-många. Denna modell skapas automatiskt av Django när du definierar ett många-till-många-fält.

\n

För det andra måste GroupAdmin manuellt utesluta fältet members. Django visar en admin-widget för ett många-till-många-fält på den modell som definierar relationen (i det här fallet Group). Om du vill använda en inline-modell för att representera many-to-many-relationen måste du tala om för Djangos admin att inte visa denna widget - annars kommer du att få två widgets på din admin-sida för att hantera relationen.

\n

Observera att när du använder den här tekniken utlöses inte m2m_changed-signalerna. Detta beror på att när det gäller administratören är through bara en modell med två främmande nyckelfält snarare än en många-till-många-relation.

\n

I alla andra avseenden är InlineModelAdmin exakt samma som alla andra. Du kan anpassa utseendet med hjälp av någon av de normala egenskaperna för ModelAdmin.

\n
\n
\n

Arbeta med många-till-manga förmedlingsmodellerLink to this heading#

\n

När du anger en mellanliggande modell med argumentet through till en ManyToManyField, kommer administratören inte att visa en widget som standard. Detta beror på att varje instans av den mellanliggande modellen kräver mer information än vad som kan visas i en enda widget, och den layout som krävs för flera widgetar varierar beroende på den mellanliggande modellen.

\n

Vi vill dock fortfarande kunna redigera den informationen inline. Lyckligtvis kan vi göra detta med inline admin-modeller. Anta att vi har följande modeller:

\n
Code
from django.db import models\n\n\nclass Person(models.Model):\n    name = models.CharField(max_length=128)\n\n\nclass Group(models.Model):\n    name = models.CharField(max_length=128)\n    members = models.ManyToManyField(Person, through="Membership")\n\n\nclass Membership(models.Model):\n    person = models.ForeignKey(Person, on_delete=models.CASCADE)\n    group = models.ForeignKey(Group, on_delete=models.CASCADE)\n    date_joined = models.DateField()\n    invite_reason = models.CharField(max_length=64)\n\n    class Meta:\n        constraints = [\n            models.UniqueConstraint(\n                fields=["person", "group"], name="unique_person_group"\n            )\n        ]\n
\n

Det första steget för att visa denna mellanliggande modell i admin är att definiera en inline-klass för modellen Membership:

\n
Code
class MembershipInline(admin.TabularInline):\n    model = Membership\n    extra = 1\n
\n

I det här exemplet används standardvärdena för InlineModelAdmin för modellen Membership och de extra tilläggsformulären begränsas till ett. Detta kan anpassas med hjälp av något av de alternativ som är tillgängliga för klasserna InlineModelAdmin.

\n

Skapa nu adminvyer för modellerna Person och Group:

\n
Code
class PersonAdmin(admin.ModelAdmin):\n    inlines = [MembershipInline]\n\n\nclass GroupAdmin(admin.ModelAdmin):\n    inlines = [MembershipInline]\n
\n

Slutligen registrerar du dina modeller Person och Group på administratörssidan:

\n
Code
admin.site.register(Person, PersonAdmin)\nadmin.site.register(Group, GroupAdmin)\n
\n

Nu är din administratörswebbplats inställd för att redigera Membership-objekt inline från antingen Person eller Group detaljsidorna.

\n
\n
\n

Använda generiska relationer som en inlineLink to this heading#

\n

Det är möjligt att använda en inline med generiskt relaterade objekt. Låt oss säga att du har följande modeller:

\n
Code
from django.contrib.contenttypes.fields import GenericForeignKey\nfrom django.contrib.contenttypes.models import ContentType\nfrom django.db import models\n\n\nclass Image(models.Model):\n    image = models.ImageField(upload_to="images")\n    content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)\n    object_id = models.PositiveIntegerField()\n    content_object = GenericForeignKey("content_type", "object_id")\n\n\nclass Product(models.Model):\n    name = models.CharField(max_length=100)\n
\n

Om du vill tillåta redigering och skapande av en Image-instans på Product, lägga till/ändra vyer kan du använda GenericTabularInline eller GenericStackedInline (båda underklasserna till GenericInlineModelAdmin) som tillhandahålls av admin. De implementerar visuella layouter med tabeller och staplar för de formulär som representerar inline-objekten, precis som deras icke-generiska motsvarigheter. De beter sig precis som alla andra inline. I din admin.py för den här exempelappen:

\n
Code
from django.contrib import admin\nfrom django.contrib.contenttypes.admin import GenericTabularInline\n\nfrom myapp.models import Image, Product\n\n\nclass ImageInline(GenericTabularInline):\n    model = Image\n\n\nclass ProductAdmin(admin.ModelAdmin):\n    inlines = [\n        ImageInline,\n    ]\n\n\nadmin.site.register(Product, ProductAdmin)\n
\n

Se contenttypes-dokumentationen för mer specifik information.

\n
\n
\n
\n

Lägga till anpassad validering i adminLink to this heading#

\n

Admin använder ModelForm. För att lägga till anpassad validering tillhandahåller du en egen ModelForm:

\n
Code
class ArticleForm(forms.ModelForm):\n    def clean_name(self):\n        # do something that validates your data\n        return self.cleaned_data["name"]\n
\n

Konfigurera sedan ModelAdmin att använda formuläret:

\n
Code
class ArticleAdmin(admin.ModelAdmin):\n    form = ArticleForm\n
\n

Eller konfigurera en InlineModelAdmin att använda formuläret:

\n
Code
class ArticleInline(admin.TabularInline):\n    model = Article\n    form = ArticleForm\n
\n

Det är viktigt att du använder en ModelForm; annars kan saker gå sönder. Se dokumentationen om formulär och anpassad validering, samt särskilt anmärkningarna om validering av modellformulär, för mer information.

\n
\n
\n

Åsidosätta adminmallarLink to this heading#

\n

Du kan åsidosätta många av de mallar som adminmodulen använder för att generera de olika sidorna på en adminwebbplats. Du kan till och med åsidosätta några av dessa mallar för en viss app eller en viss modell.

\n
\n

Konfigurera projektets kataloger för adminmallarLink to this heading#

\n

Mallfilerna för admin finns i katalogen django/contrib/admin/templates/admin.

\n

För att åsidosätta en eller flera av dem skapar du först en admin-katalog i ditt projekts templates-katalog. Detta kan vara någon av de kataloger som du angav i DIRS alternativet för DjangoTemplates backend i TEMPLATES inställningen. Om du har anpassat alternativet 'loaders', se till att 'django.template.loaders.filesystem.Loader' visas före 'django.template.loaders.app_directories.Loader' så att dina anpassade mallar kommer att hittas av mallinläsningssystemet före de som ingår i django.contrib.admin.

\n

I denna admin-katalog skapar du underkataloger med namn efter din app. Inom dessa app-underkataloger skapar du underkataloger med namn efter dina modeller. Observera att admin-appen kommer att skriva modellnamnet med gemener när den letar efter katalogen, så se till att du namnger katalogen med gemener om du ska köra din app på ett filsystem som är skiftlägeskänsligt.

\n

För att åsidosätta en adminmall för en specifik app, kopiera och redigera mallen från django/contrib/admin/templates/admin-katalogen och spara den i en av de kataloger du just skapat.

\n

Om vi t.ex. vill lägga till ett verktyg i ändringslistan för alla modeller i en app med namnet ”min_app”, kopierar vi ”contrib/admin/templates/admin/change_list.html” till katalogen ”templates/admin/my_app/” i vårt projekt och gör de ändringar som krävs.

\n

Om vi vill lägga till ett verktyg i ändringslistan för endast en specifik modell med namnet ”Page”, skulle vi kopiera samma fil till katalogen ”templates/admin/my_app/page” i vårt projekt.

\n
\n
\n

Åsidosätta eller ersätta en administratörsmallLink to this heading#

\n

På grund av adminmallarnas modulära design är det vanligtvis varken nödvändigt eller tillrådligt att ersätta en hel mall. Det är nästan alltid bättre att åsidosätta endast den del av mallen som du behöver ändra.

\n

För att fortsätta exemplet ovan vill vi lägga till en ny länk bredvid verktyget History för modellen Page. Efter att ha tittat på change_form.html konstaterar vi att vi bara behöver åsidosätta blocket object-tools-items. Här är därför vår nya change_form.html :

\n
Django template
{% extends "admin/change_form.html" %}\n{% load i18n admin_urls %}\n{% block object-tools-items %}\n    <li>\n        <a href="{% url opts|admin_urlname:'history' original.pk|admin_urlquote %}" class="historylink">{% translate "History" %}</a>\n    </li>\n    <li>\n        <a href="mylink/" class="historylink">My Link</a>\n    </li>\n    {% if has_absolute_url %}\n        <li>\n            <a href="{% url 'admin:view_on_site' content_type_id original.pk %}" class="viewsitelink">{% translate "View on site" %}</a>\n        </li>\n    {% endif %}\n{% endblock %}\n
\n

Och så är det klart! Om vi placerade den här filen i katalogen templates/admin/my_app skulle vår länk visas på ändringsformuläret för alla modeller inom my_app.

\n
\n
\n

Mallar som kan åsidosättas per app eller modellLink to this heading#

\n

Inte alla mallar i contrib/admin/templates/admin kan åsidosättas per app eller per modell. Följande kan det:

\n\n

För de mallar som inte kan åsidosättas på detta sätt kan du ändå åsidosätta dem för hela ditt projekt genom att placera den nya versionen i katalogen templates/admin. Detta är särskilt användbart för att skapa anpassade 404- och 500-sidor.

\n\n
\n
\n

Rot- och inloggningsmallarLink to this heading#

\n

Om du vill ändra index-, inloggnings- eller utloggningsmallarna är det bättre att skapa en egen instans av AdminSite (se nedan) och ändra egenskaperna AdminSite.index_template , AdminSite.login_template eller AdminSite.logout_template.

\n
\n
\n
\n

Stöd för tematiseringLink to this heading#

\n

Administratören använder CSS-variabler för att definiera färger och teckensnitt. Detta gör det möjligt att ändra teman utan att behöva åsidosätta många enskilda CSS-regler. Om du t.ex. föredrar lila i stället för blått kan du lägga till en admin/base.html-mallöverskrivning i ditt projekt:

\n
Django template
{% extends 'admin/base.html' %}\n\n{% block extrastyle %}{{ block.super }}\n<style>\nhtml[data-theme="light"], :root {\n  --primary: #9774d5;\n  --secondary: #785cab;\n  --link-fg: #7c449b;\n  --link-selected-fg: #8f5bb2;\n}\n</style>\n{% endblock %}\n
\n

Listan över CSS-variabler definieras i django/contrib/admin/static/admin/css/base.css.

\n

Variabler för mörkt läge, som respekterar mediefrågan prefers-color-scheme, definieras i django/contrib/admin/static/admin/css/dark_mode.css. Detta är länkat till dokumentet i {% block dark-mode-vars %}.

\n
\n
\n

extrabody-blockLink to this heading#

\n

Du kan lägga till anpassad HTML, JavaScript eller annat innehåll som ska visas precis före den avslutande taggen </body> i mallar som utökar admin/base.html genom att utöka blocket extrabody. Om du t.ex. vill att en varning ska visas vid sidladdning kan du lägga till en mallöverskrivning för admin/base.html i ditt projekt:

\n
Django template
{% extends 'admin/base.html' %}\n\n{% block extrabody %}\n    {{ block.super }}\n    <script>\n        document.addEventListener('DOMContentLoaded', function() {\n            window.alert('Welcome!');\n        });\n    </script>\n{% endblock extrabody %}\n
\n
\n
\n

objekt av typen AdminSiteLink to this heading#

\n
\n
\nclass AdminSite(name='admin')Link to this definition#
\n

En Django administrativ webbplats representeras av en instans av django.contrib.admin.sites.AdminSite; som standard skapas en instans av denna klass som django.contrib.admin.site och du kan registrera dina modeller och ModelAdmin-instanser med den.

\n

Om du vill anpassa standardwebbplatsen för administratörer kan du åsidosätta den.

\n

När du konstruerar en instans av en AdminSite kan du ange ett unikt instansnamn med hjälp av argumentet name till konstruktören. Detta instansnamn används för att identifiera instansen, särskilt när reversing admin URLs. Om inget instansnamn anges kommer ett standardinstansnamn på admin att användas. Se Anpassning av AdminSite-klassen för ett exempel på anpassning av klassen AdminSite.

\n
\n\n
\n
\ndjango.contrib.admin.sites.all_sitesLink to this definition#
\n

En WeakSet innehåller alla instanser av administratörsplatser.

\n
\n\n
\n

attribut för AdminSiteLink to this heading#

\n

Mallar kan åsidosätta eller utöka basadministratörsmallar enligt beskrivningen i Åsidosätta adminmallar.

\n
\n
\nAdminSite.site_headerLink to this definition#
\n

Den text som ska placeras högst upp på varje administratörssida, som en <div> (en sträng). Som standard är detta ”Django administration”.

\n
\n\n
\n
\nAdminSite.site_titleLink to this definition#
\n

Texten som ska placeras i slutet av varje administratörssidas <title> (en sträng). Som standard är detta ”Django site admin”.

\n
\n\n
\n
\nAdminSite.site_urlLink to this definition#
\n

URL:en för länken ”View site” högst upp på varje administratörssida. Som standard är site_url /. Ställ in den på None för att ta bort länken.

\n

För webbplatser som körs på en underväg kontrollerar metoden each_context() om den aktuella begäran har request.META['SCRIPT_NAME'] inställt och använder det värdet om site_url inte är inställt på något annat än /.

\n
\n\n
\n
\nAdminSite.index_titleLink to this definition#
\n

Den text som ska placeras högst upp på sidan med adminindex (en sträng). Som standard är detta ”Webbplatsadministration”.

\n
\n\n
\n
\nAdminSite.index_templateLink to this definition#
\n

Sökväg till en anpassad mall som kommer att användas av huvudindexvyn på adminwebbplatsen.

\n
\n\n
\n
\nAdminSite.app_index_templateLink to this definition#
\n

Sökväg till en anpassad mall som kommer att användas av indexvyn för appen för administratörswebbplatsen.

\n
\n\n
\n
\nAdminSite.empty_value_displayLink to this definition#
\n

Den sträng som ska användas för att visa tomma värden i adminwebbplatsens ändringslista. Standardvärdet är ett streck. Värdet kan också åsidosättas per ModelAdmin och för ett anpassat fält inom en ModelAdmin genom att ange ett empty_value_display-attribut för fältet. Se ModelAdmin.empty_value_display för exempel.

\n
\n\n
\n
\nAdminSite.enable_nav_sidebarLink to this definition#
\n

Ett booleskt värde som avgör om navigationssidofältet ska visas på större skärmar. Som standard är det inställt på True.

\n
\n\n
\n
\nAdminSite.final_catch_all_viewLink to this definition#
\n

Ett booleskt värde som avgör om en sista vy ska läggas till i admin som omdirigerar oautentiserade användare till inloggningssidan. Som standard är det inställt på True.

\n\n
\n\n
\n
\nAdminSite.login_templateLink to this definition#
\n

Sökväg till en anpassad mall som kommer att användas av inloggningsvyn för adminwebbplatsen.

\n
\n\n
\n
\nAdminSite.login_formLink to this definition#
\n

Underklass till AuthenticationForm som kommer att användas av inloggningsvyn på adminsidan.

\n
\n\n
\n
\nAdminSite.logout_templateLink to this definition#
\n

Sökväg till en anpassad mall som kommer att användas av inloggningsvyn för adminwebbplatsen.

\n
\n\n
\n
\nAdminSite.password_change_formLink to this definition#
\n
\n

Underklass till PasswordChangeForm som används av administrationswebbplatsens vy för lösenordsbyte.

\n
\n\n
\n
\nAdminSite.password_change_templateLink to this definition#
\n

Sökväg till en anpassad mall som kommer att användas av vyn för ändring av lösenord på adminwebbplatsen.

\n
\n\n
\n
\nAdminSite.password_change_done_templateLink to this definition#
\n

Sökväg till en anpassad mall som kommer att användas av vyn för ändring av lösenord på administratörssidan.

\n
\n\n
\n
\n

metoder för AdminSiteLink to this heading#

\n
\n
\nAdminSite.each_context(request)Link to this definition#
\n

Returnerar en ordlista med variabler som ska läggas in i mallkontexten för varje sida på administratörssajten.

\n

Innehåller följande variabler och värden som standard:

\n
    \n

  • site_header: AdminSite.site_header

    • \n

  • site_title: AdminSite.site_title

    • \n

  • site_url: AdminSite.site_url

    • \n

  • has_permission: AdminSite.has_permission()

    • \n

  • available_apps: en lista över applikationer från application registry som är tillgängliga för den aktuella användaren. Varje post i listan är en dict som representerar en applikation med följande nycklar:

    \n
      \n

    • app_label: applikationens etikett

      • \n

    • app_url: URL:en för applikationsindexet i admin

      • \n

    • has_module_perms: ett boolean som anger om visning av och åtkomst till modulens indexsida är tillåten för den aktuella användaren

      • \n

    • models: en lista över de modeller som är tillgängliga i applikationen

      • \n
    \n

    Varje modell är en diktafon med följande tangenter:

    \n
      \n

    • model: modellklassen

      • \n

    • object_name: modellens klassnamn

      • \n

    • namn: modellens namn i plural

      • \n

    • perms: ett dict som spårar add, change, delete och view-behörigheter

      • \n

    • admin_url: URL för modellens ändringslista för administratörer

      • \n

    • add_url: administratörs-URL för att lägga till en ny modellinstans

      • \n
    \n
    • \n

  • is_popup: om den aktuella sidan visas i ett popup-fönster

    • \n

  • is_nav_sidebar_enabled: AdminSite.enable_nav_sidebar

    • \n

  • log_entries: AdminSite.get_log_entries()

    • \n
\n
\n\n
\n
\nAdminSite.get_app_list(request, app_label=None)Link to this definition#
\n

Returnerar en lista över applikationer från applikationsregistret som är tillgängliga för den aktuella användaren. Du kan eventuellt skicka ett app_label-argument för att få detaljer för en enda app. Varje post i listan är en ordbok som representerar en applikation med följande nycklar:

\n
    \n

  • app_label: applikationens etikett

    • \n

  • app_url: URL:en för applikationsindexet i admin

    • \n

  • has_module_perms: ett boolean som anger om visning av och åtkomst till modulens indexsida är tillåten för den aktuella användaren

    • \n

  • models: en lista över de modeller som är tillgängliga i applikationen

    • \n

  • name: namnet på applikationen

    • \n
\n

Varje modell är en ordbok med följande nycklar:

\n
    \n

  • model: modellklassen

    • \n

  • object_name: modellens klassnamn

    • \n

  • namn: modellens namn i plural

    • \n

  • perms: ett dict som spårar add, change, delete och view-behörigheter

    • \n

  • admin_url: URL för modellens ändringslista för administratörer

    • \n

  • add_url: administratörs-URL för att lägga till en ny modellinstans

    • \n
\n

Listor över applikationer och modeller sorteras alfabetiskt efter deras namn. Du kan åsidosätta den här metoden för att ändra standardordningen på adminindexsidan.

\n
\n\n
\n
\nAdminSite.has_permission(request)Link to this definition#
\n

Returnerar True om användaren för den givna HttpRequest har behörighet att visa minst en sida på adminsidan. Standardinställningen är att både User.is_active och User.is_staff måste vara True.

\n
\n\n
\n
\nAdminSite.register(model_or_iterable, admin_class=None, **options)Link to this definition#
\n

Registrerar den angivna modellklassen (eller iterabeln av klasser) med den angivna admin_class. admin_class är som standard ModelAdmin (standardadministratörsalternativ). Om nyckelordsargument ges - t.ex. list_display - kommer de att tillämpas som alternativ för adminklassen.

\n

Ger upphov till ImproperlyConfigured om en modell är abstrakt, och django.contrib.admin.exceptions.AlreadyRegistered om en modell redan är registrerad.

\n
\n\n
\n
\nAdminSite.unregister(model_or_iterable)Link to this definition#
\n

Avregistrerar den angivna modellklassen (eller en iterabel av klasser).

\n

Utlöser django.contrib.admin.exceptions.NotRegistered om en modell inte redan är registrerad.

\n
\n\n
\n
\nAdminSite.get_model_admin(model)Link to this definition#
\n

Returnerar en adminklass för den angivna modellklassen. Utlöser django.contrib.admin.exceptions.NotRegistered om en modell inte är registrerad.

\n
\n\n
\n
\nAdminSite.get_log_entries(request)Link to this definition#
\n

Returnerar en frågeuppsättning för de relaterade LogEntry-instanser som visas på webbplatsens indexsida. Denna metod kan åsidosättas för att filtrera loggposterna efter andra kriterier.

\n
\n\n
\n
\n

Koppla in AdminSite-instanser i din URLconfLink to this heading#

\n

Det sista steget när Django-admin konfigureras är att koppla instansen av AdminSite till din URLconf. Gör detta genom att peka en angiven URL på metoden AdminSite.urls. Det är inte nödvändigt att använda include().

\n

I det här exemplet registrerar vi standardinstansen AdminSite django.contrib.admin.site på webbadressen /admin/

\n
Code
# urls.py\nfrom django.contrib import admin\nfrom django.urls import path\n\nurlpatterns = [\n    path("admin/", admin.site.urls),\n]\n
\n
\n
\n

Anpassning av AdminSite-klassenLink to this heading#

\n

Om du vill skapa din egen administratörssajt med anpassat beteende kan du underklassa AdminSite och åsidosätta eller lägga till vad du vill. Skapa sedan en instans av din AdminSite-underklass (på samma sätt som du instansierar vilken annan Python-klass som helst) och registrera dina modeller och ModelAdmin-underklasser med den istället för med standardwebbplatsen. Uppdatera slutligen myproject/urls.py för att referera till din AdminSite-underklass.

\n
myapp/admin.py
\n
Python
from django.contrib import admin\n\nfrom .models import MyModel\n\n\nclass MyAdminSite(admin.AdminSite):\n    site_header = "Monty Python administration"\n\n\nadmin_site = MyAdminSite(name="myadmin")\nadmin_site.register(MyModel)\n
\n
myproject/urls.py
\n
Python
from django.urls import path\n\nfrom myapp.admin import admin_site\n\nurlpatterns = [\n    path("myadmin/", admin_site.urls),\n]\n
\n

Observera att du kanske inte vill ha autodiscovery av admin-moduler när du använder din egen AdminSite-instans eftersom du troligen kommer att importera alla admin-moduler per app i din myproject.admin-modul. Detta innebär att du måste sätta 'django.contrib.admin.apps.SimpleAdminConfig' istället för 'django.contrib.admin' i din INSTALLED_APPS inställning.

\n
\n
\n

Åsidosätta standardwebbplatsen för administratörerLink to this heading#

\n

Du kan åsidosätta standard django.contrib.admin.site genom att ställa in attributet default_site` i en anpassad AppConfig till den prickade importsökvägen för antingen en AdminSite-underklass eller en anropbar som returnerar en webbplatsinstans.

\n
myproject/admin.py
\n
Python
from django.contrib import admin\n\n\nclass MyAdminSite(admin.AdminSite): ...\n
\n
myproject/apps.py
\n
Python
from django.contrib.admin.apps import AdminConfig\n\n\nclass MyAdminConfig(AdminConfig):\n    default_site = "myproject.admin.MyAdminSite"\n
\n
myproject/settings.py
\n
Python
INSTALLED_APPS = [\n    # ...\n    "myproject.apps.MyAdminConfig",  # replaces 'django.contrib.admin'\n    # ...\n]\n
\n
\n
\n

Flera administratörswebbplatser i samma URLconfLink to this heading#

\n

Du kan skapa flera instanser av adminwebbplatsen på samma Django-drivna webbplats. Skapa flera instanser av AdminSite och placera var och en på en annan URL.

\n

I det här exemplet innehåller webbadresserna /basic-admin/ och /advanced-admin/ separata versioner av administratörswebbplatsen - med AdminSite-instanserna myproject.admin.basic_site respektive myproject.admin.advanced_site:

\n
Code
# urls.py\nfrom django.urls import path\nfrom myproject.admin import advanced_site, basic_site\n\nurlpatterns = [\n    path("basic-admin/", basic_site.urls),\n    path("advanced-admin/", advanced_site.urls),\n]\n
\n

AdminSite instanser tar ett enda argument till sin konstruktör, deras namn, som kan vara vad du vill. Detta argument blir prefixet till URL-namnen i syfte att reversera dem. Detta är endast nödvändigt om du använder mer än en AdminSite.

\n
\n
\n

Lägga till vyer på administratörssidorLink to this heading#

\n

Precis som ModelAdmin tillhandahåller AdminSite en metod get_urls() som kan åsidosättas för att definiera ytterligare vyer för webbplatsen. För att lägga till en ny vy på din adminwebbplats utökar du basmetoden get_urls() så att den innehåller ett mönster för den nya vyn.

\n\n
\n
\n

Lägga till en funktion för återställning av lösenordLink to this heading#

\n

Du kan lägga till en funktion för återställning av lösenord på adminwebbplatsen genom att lägga till några rader i URLconf. Lägg särskilt till dessa fyra mönster:

\n
Code
from django.contrib import admin\nfrom django.contrib.auth import views as auth_views\n\npath(\n    "admin/password_reset/",\n    auth_views.PasswordResetView.as_view(\n        extra_context={"site_header": admin.site.site_header}\n    ),\n    name="admin_password_reset",\n),\npath(\n    "admin/password_reset/done/",\n    auth_views.PasswordResetDoneView.as_view(\n        extra_context={"site_header": admin.site.site_header}\n    ),\n    name="password_reset_done",\n),\npath(\n    "reset/<uidb64>/<token>/",\n    auth_views.PasswordResetConfirmView.as_view(\n        extra_context={"site_header": admin.site.site_header}\n    ),\n    name="password_reset_confirm",\n),\npath(\n    "reset/done/",\n    auth_views.PasswordResetCompleteView.as_view(\n        extra_context={"site_header": admin.site.site_header}\n    ),\n    name="password_reset_complete",\n),\n
\n

(Detta förutsätter att du har lagt till administratören på admin/ och kräver att du lägger till de webbadresser som börjar med ^admin/ före raden som innehåller själva admin-appen).

\n

Närvaron av den namngivna URL:en admin_password_reset kommer att leda till att en länk ”har du glömt ditt lösenord?” visas på standardinloggningssidan för administratörer under lösenordsrutan.

\n
\n
\n
\n

objekt av typen LogEntryLink to this heading#

\n
\n
\nclass models.LogEntryLink to this definition#
\n

Klassen LogEntry spårar tillägg, ändringar och borttagningar av objekt som görs via administratörsgränssnittet.

\n
\n\n
\n

LogEntry attributLink to this heading#

\n
\n
\nLogEntry.action_timeLink to this definition#
\n

Datum och tid för åtgärden.

\n
\n\n
\n
\nLogEntry.userLink to this definition#
\n

Den användare (en instans av AUTH_USER_MODEL) som utförde åtgärden.

\n
\n\n
\n
\nLogEntry.content_typeLink to this definition#
\n

Det modifierade objektets ContentType.

\n
\n\n
\n
\nLogEntry.object_idLink to this definition#
\n

Den textuella representationen av det modifierade objektets primärnyckel.

\n
\n\n
\n
\nLogEntry.object_reprLink to this definition#
\n

Objektets repr() efter modifieringen.

\n
\n\n
\n
\nLogEntry.action_flagLink to this definition#
\n

Typ av åtgärd som loggas: TILLÄGG, ÄNDRING, RADERING.

\n

Om du t.ex. vill få en lista över alla tillägg som gjorts via admin:

\n
Code
from django.contrib.admin.models import ADDITION, LogEntry\n\nLogEntry.objects.filter(action_flag=ADDITION)\n
\n
\n\n
\n
\nLogEntry.change_messageLink to this definition#
\n

En detaljerad beskrivning av ändringen. I fallet med en redigering innehåller meddelandet till exempel en lista över de redigerade fälten. Django-adminsidan formaterar detta innehåll som en JSON-struktur, så att get_change_message() kan komponera ett meddelande som översätts till det aktuella användarspråket. Anpassad kod kan dock ställa in detta som en vanlig sträng. Du rekommenderas att använda metoden get_change_message() för att hämta detta värde istället för att komma åt det direkt.

\n
\n\n
\n
\n

metoder för LogEntryLink to this heading#

\n
\n
\nLogEntry.get_edited_object()Link to this definition#
\n

En genväg som returnerar det refererade objektet.

\n
\n\n
\n
\nLogEntry.get_change_message()Link to this definition#
\n

Formaterar och översätter change_message till det aktuella användarspråket. Meddelanden som skapats före Django 1.10 kommer alltid att visas på det språk som de loggades på.

\n
\n\n
\n
\n
\n

Omvända administratörsadresserLink to this heading#

\n

När en AdminSite distribueras, är de vyer som tillhandahålls av den webbplatsen tillgängliga med Djangos URL reversing system.

\n

Klassen AdminSite tillhandahåller följande namngivna URL-mönster:

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Sida

URL-namn

Parametrar

Index

index

Logga in

login

Logga ut

logout

Ändra lösenord

lösenord_ändring

Lösenordsändring genomförd

lösenord_byte_gjort

i18n JavaScript

jsi18n

Applikationens indexsida

app_lista

app_label

Omdirigera till objektets sida

Visa_på_sajten

content_type_id, object_id

\n
\n

Varje ModelAdmin-instans tillhandahåller ytterligare en uppsättning namngivna URL:er:

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Sida

URL-namn

Parametrar

Changelist

{{ app_label }}_{{ model_name }}_changelist

Lägg till

{{app_label }}_{{modellnamn }}_add

Historik

{{ app_label }}_{{ model_name }}_history

objekt_id

Radera

{{app_label }}_{{modellnamn }}_delete

objekt_id

Ändra

{{app_label }}_{{modellnamn }}_change

objekt_id

\n
\n

I UserAdmin finns en namngiven URL:

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n

Sida

URL-namn

Parametrar

Ändra lösenord

auth_user_password_change

användar_id

\n
\n

Dessa namngivna webbadresser registreras med applikationsnamnområdet admin och med ett instansnamnområde som motsvarar namnet på Site-instansen.

\n

Så - om du vill få en referens till Change-vyn för ett visst Choice-objekt (från polls-programmet) i standardadministratören, skulle du ringa:

\n
Python console
>>> from django.urls import reverse\n>>> c = Choice.objects.get(...)\n>>> change_url = reverse("admin:polls_choice_change", args=(c.id,))\n
\n

Detta kommer att hitta den första registrerade instansen av admin-applikationen (oavsett instansens namn), och lösa till vyn för att ändra poll.Choice-instanser i den instansen.

\n

Om du vill hitta en URL i en specifik administratörsinstans anger du namnet på den instansen som en current_app-hint till det omvända anropet. Om du till exempel specifikt ville ha adminvyn från admininstansen med namnet custom, skulle du behöva anropa:

\n
Python console
>>> change_url = reverse("admin:polls_choice_change", args=(c.id,), current_app="custom")\n
\n

Mer information finns i dokumentationen om reversing namespaced URLs.

\n

För att göra det lättare att vända på admin-webbadresser i mallar tillhandahåller Django ett filter admin_urlname som tar en åtgärd som argument:

\n
Django template
{% load admin_urls %}\n<a href="{% url opts|admin_urlname:'add' %}">Add user</a>\n<a href="{% url opts|admin_urlname:'delete' user.pk %}">Delete this user</a>\n
\n

Åtgärden i exemplen ovan matchar den sista delen av URL-namnen för ModelAdmin-instanser som beskrivs ovan. Variabeln opts kan vara vilket objekt som helst som har attributen app_label och model_name och som vanligtvis tillhandahålls av adminvyerna för den aktuella modellen.

\n
\n
\n

Dekorationselementet displayLink to this heading#

\n
\n
\ndisplay(*, boolean=None, ordering=None, description=None, empty_value=None)Link to this definition#
\n

Denna dekorator kan användas för att ställa in specifika attribut på anpassade visningsfunktioner som kan användas med list_display eller readonly_fields:

\n
Code
@admin.display(\n    boolean=True,\n    ordering="-publish_date",\n    description="Is Published?",\n)\ndef is_published(self, obj):\n    return obj.publish_date is not None\n
\n

Detta motsvarar att ange vissa attribut (med de ursprungliga, längre namnen) på funktionen direkt:

\n
Code
def is_published(self, obj):\n    return obj.publish_date is not None\n\n\nis_published.boolean = True\nis_published.admin_order_field = "-publish_date"\nis_published.short_description = "Is Published?"\n
\n

Observera också att dekoratorparametern empty_value mappar till attributet empty_value_display som tilldelas direkt till funktionen. Den kan inte användas tillsammans med boolean - de är ömsesidigt uteslutande.

\n

Det är inte obligatoriskt att använda denna dekorator för att skapa en displayfunktion, men det kan vara användbart att använda den utan argument som en markör i källan för att identifiera syftet med funktionen:

\n
Code
@admin.display\ndef published_year(self, obj):\n    return obj.publish_date.year\n
\n

I detta fall kommer det inte att lägga till några attribut till funktionen.

\n
\n\n
\n
\n

Dekoratorn staff_member_required (personalmedlem krävs)Link to this heading#

\n
\n
\nstaff_member_required(redirect_field_name='next', login_url='admin:login')Link to this definition#
\n

Denna dekorator används på de adminvyer som kräver auktorisering. En vy som är dekorerad med denna funktion kommer att ha följande beteende:

\n
    \n

  • Om användaren är inloggad, tillhör personalen (User.is_staff=True) och är aktiv (User.is_active=True), körs vyn normalt.

    • \n

  • Annars omdirigeras begäran till den URL som anges av parametern login_url, med den ursprungligen begärda sökvägen i en frågesträngvariabel som anges av redirect_field_name. Till exempel: /admin/login/?next=/admin/polls/question/3/.

    • \n
\n

Exempel på användning:

\n
Code
from django.contrib.admin.views.decorators import staff_member_required\n\n\n@staff_member_required\ndef my_view(request): ...\n
\n
\n\n
","rootId":"module-django.contrib.admin","toc":[{"title":"Översikt","anchor":"overview","children":[{"title":"Övriga ämnen","anchor":"other-topics","children":[]}]},{"title":"ModelAdmin-objekt","anchor":"modeladmin-objects","children":[{"title":"Dekoratorn ”register","anchor":"the-register-decorator","children":[]},{"title":"Upptäckt av adminfiler","anchor":"discovery-of-admin-files","children":[]},{"title":"ModelAdmin alternativ","anchor":"modeladmin-options","children":[{"title":"Anpassade mallalternativ","anchor":"custom-template-options","children":[]}]},{"title":"metoder för ModelAdmin","anchor":"modeladmin-methods","children":[{"title":"Andra metoder","anchor":"other-methods","children":[]}]},{"title":"ModelAdmin tillgångsdefinitioner","anchor":"modeladmin-asset-definitions","children":[{"title":"jQuery","anchor":"jquery","children":[]}]}]},{"title":"objekt av typen ``InlineModelAdmin","anchor":"inlinemodeladmin-objects","children":[{"title":"InlineModelAdmin alternativ","anchor":"inlinemodeladmin-options","children":[]},{"title":"Arbeta med en modell med två eller flera främmande nycklar till samma överordnade modell","anchor":"working-with-a-model-with-two-or-more-foreign-keys-to-the-same-parent-model","children":[]},{"title":"Arbeta med många-till-många-modeller","anchor":"working-with-many-to-many-models","children":[]},{"title":"Arbeta med många-till-manga förmedlingsmodeller","anchor":"working-with-many-to-many-intermediary-models","children":[]},{"title":"Använda generiska relationer som en inline","anchor":"using-generic-relations-as-an-inline","children":[]}]},{"title":"Lägga till anpassad validering i admin","anchor":"adding-custom-validation-to-the-admin","children":[]},{"title":"Åsidosätta adminmallar","anchor":"overriding-admin-templates","children":[{"title":"Konfigurera projektets kataloger för adminmallar","anchor":"set-up-your-project-s-admin-template-directories","children":[]},{"title":"Åsidosätta eller ersätta en administratörsmall","anchor":"overriding-vs-replacing-an-admin-template","children":[]},{"title":"Mallar som kan åsidosättas per app eller modell","anchor":"templates-which-may-be-overridden-per-app-or-model","children":[]},{"title":"Rot- och inloggningsmallar","anchor":"root-and-login-templates","children":[]}]},{"title":"Stöd för tematisering","anchor":"theming-support","children":[]},{"title":"extrabody-block","anchor":"extrabody-block","children":[]},{"title":"objekt av typen AdminSite","anchor":"adminsite-objects","children":[{"title":"attribut för AdminSite","anchor":"adminsite-attributes","children":[]},{"title":"metoder för AdminSite","anchor":"adminsite-methods","children":[]},{"title":"Koppla in AdminSite-instanser i din URLconf","anchor":"hooking-adminsite-instances-into-your-urlconf","children":[]},{"title":"Anpassning av AdminSite-klassen","anchor":"customizing-the-adminsite-class","children":[]},{"title":"Åsidosätta standardwebbplatsen för administratörer","anchor":"overriding-the-default-admin-site","children":[]},{"title":"Flera administratörswebbplatser i samma URLconf","anchor":"multiple-admin-sites-in-the-same-urlconf","children":[]},{"title":"Lägga till vyer på administratörssidor","anchor":"adding-views-to-admin-sites","children":[]},{"title":"Lägga till en funktion för återställning av lösenord","anchor":"adding-a-password-reset-feature","children":[]}]},{"title":"objekt av typen LogEntry","anchor":"logentry-objects","children":[{"title":"LogEntry attribut","anchor":"logentry-attributes","children":[]},{"title":"metoder för LogEntry","anchor":"logentry-methods","children":[]}]},{"title":"Omvända administratörsadresser","anchor":"reversing-admin-urls","children":[]},{"title":"Dekorationselementet display","anchor":"the-display-decorator","children":[]},{"title":"Dekoratorn staff_member_required (personalmedlem krävs)","anchor":"the-staff-member-required-decorator","children":[]}],"breadcrumbs":[{"docname":"ref/index","title":"API-referens","url":"/sv/6.1/ref/"},{"docname":"ref/contrib/index","title":"contrib paket","url":"/sv/6.1/ref/contrib/"}],"prev":{"docname":"ref/contrib/index","title":"contrib paket","url":"/sv/6.1/ref/contrib/"},"next":{"docname":"ref/contrib/admin/actions","title":"Administrativa åtgärder","url":"/sv/6.1/ref/contrib/admin/actions/"},"formats":{"html":"/sv/6.1/ref/contrib/admin/","markdown":"/sv/6.1/ref/contrib/admin.md","json":"/sv/6.1/ref/contrib/admin.json"},"source":"https://github.com/django/django/blob/stable/6.1.x/docs/ref/contrib/admin/index.txt","official":"https://docs.djangoproject.com/sv/6.1/ref/contrib/admin/","inVersions":["6.1","6.0","5.2"],"inLocales":["en","sv","zh-hans","ga","fr","ja","id","it","pt-br","ko","es","el","pl"]}