Django-administratörens webbplats

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.

Administratören har många krokar för anpassning, men akta dig för att försöka använda dessa krokar 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.

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

Översikt

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

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

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. 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. 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. Haka på administratörens webbadresser i din URLconf.

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

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.

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.

Övriga ämnen

• Administrativa åtgärder
• ModelAdmin Lista Filter
• Generatorn för Django-administratörsdokumentation
• JavaScript-anpassningar i administratören

Se även

Information om hur du serverar de statiska filer (bilder, JavaScript och CSS) som är kopplade till administratören i produktion finns i Servering av filer.

Har du problem? Prova FRÅGOR OCH SVAR: Adminsidan.

ModelAdmin-objekt

class ModelAdmin[source]

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:

from django.contrib import admin
from myapp.models import Author


class AuthorAdmin(admin.ModelAdmin):
    pass


admin.site.register(Author, AuthorAdmin)

Behöver du ett ModelAdmin-objekt alls?

I det föregående exemplet definierar klassen ModelAdmin inte några anpassade värden (ännu). Som ett resultat kommer standardadministratörsgränssnittet att tillhandahållas. Om du är nöjd med standardadministratörsgränssnittet behöver du inte definiera ett ModelAdmin-objekt alls - du kan registrera modellklassen utan att tillhandahålla en ModelAdmin-beskrivning. Det föregående exemplet kan förenklas till:

from django.contrib import admin
from myapp.models import Author

admin.site.register(Author)

Dekoratorn ”register

register(*models, site=django.contrib.admin.sites.site)[source]

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

from django.contrib import admin
from .models import Author


@admin.register(Author)
class AuthorAdmin(admin.ModelAdmin):
    pass

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

from django.contrib import admin
from .models import Author, Editor, Reader
from myproject.admin_site import custom_admin_site


@admin.register(Author, Reader, Editor, site=custom_admin_site)
class PersonAdmin(admin.ModelAdmin):
    pass

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

Upptäckt av adminfiler

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.

class apps.AdminConfig

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

class apps.SimpleAdminConfig

Den här klassen fungerar som AdminConfig, förutom att den inte anropar autodiscover().

default_site

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.

autodiscover()[source]

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

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

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.

ModelAdmin alternativ

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

from django.contrib import admin


class AuthorAdmin(admin.ModelAdmin):
    date_hierarchy = "pub_date"

ModelAdmin.actions

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

ModelAdmin.actions_on_top

ModelAdmin.actions_on_bottom

Styr var på sidan åtgärdsfältet visas. Som standard visar adminändringslistan åtgärder längst upp på sidan (actions_on_top = True; actions_on_bottom = False).

ModelAdmin.actions_selection_counter

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

ModelAdmin.date_hierarchy

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.

Exempel:

date_hierarchy = "pub_date"

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

date_hierarchy = "author__pub_date"

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å.

Observera

date_hierarchy använder QuerySet.datetimes() internt. Se dess dokumentation för vissa försiktighetsåtgärder när stöd för tidszoner är aktiverat (USE_TZ = True).

ModelAdmin.empty_value_display

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:

from django.contrib import admin


class AuthorAdmin(admin.ModelAdmin):
    empty_value_display = "-empty-"

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:

from django.contrib import admin


class AuthorAdmin(admin.ModelAdmin):
    list_display = ["name", "title", "view_birth_date"]

    @admin.display(empty_value="???")
    def view_birth_date(self, obj):
        return obj.birth_date

ModelAdmin.exclude

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

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

from django.db import models


class Author(models.Model):
    name = models.CharField(max_length=100)
    title = models.CharField(max_length=3)
    birth_date = models.DateField(blank=True, null=True)

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:

from django.contrib import admin


class AuthorAdmin(admin.ModelAdmin):
    fields = ["name", "title"]


class AuthorAdmin(admin.ModelAdmin):
    exclude = ["birth_date"]

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.

ModelAdmin.fields

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:

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

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.

För mer komplexa layoutbehov, se alternativet fieldsets.

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.

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:

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

Möjlig förvirring med alternativet ModelAdmin.fieldsets

Det här alternativet fields ska inte förväxlas med ordboksnyckeln fields som finns i alternativet fieldsets, som beskrivs i nästa avsnitt.

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.

ModelAdmin.fieldsets

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

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

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.

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

from django.contrib import admin


class FlatPageAdmin(admin.ModelAdmin):
    fieldsets = [
        (
            None,
            {
                "fields": ["url", "title", "content", "sites"],
            },
        ),
        (
            "Advanced options",
            {
                "classes": ["collapse"],
                "fields": ["registration_required", "template_name"],
            },
        ),
    ]

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

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.

Ordlistan field_options kan ha följande nycklar:

• fält

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

  Exempel:

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

  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:

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

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

  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.

• klasser

  En lista eller tupel som innehåller extra CSS-klasser som ska tillämpas på fältuppsättningen. Detta kan inkludera alla anpassade CSS-klasser som definieras i projektet, samt alla CSS-klasser som tillhandahålls av Django. Inom standard CSS-stilmallen för adminwebbplatsen definieras två särskilt användbara klasser: collapse och wide.

  Exempel:

  {
      "classes": ["wide", "collapse"],
  }
  

  Fältuppsättningar med stilen wide får extra horisontellt utrymme i admin-gränssnittet. Fältuppsättningar med ett namn och stilen collapse kommer initialt att vara kollapsade, med hjälp av en expanderbar widget med en växling för att växla deras synlighet.

  Changed in Django 5.1:

  fieldsets som använder collapse klassen använder nu <details> och <summary> element, förutsatt att de definierar ett name.

• Beskrivning

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

  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.

TabularInline har begränsat stöd för fieldsets

Att använda fieldsets med TabularInline har begränsad funktionalitet. Du kan ange vilka fält som ska visas och deras ordning inom layouten TabularInline genom att definiera fields i ordlistan field_options.

Alla andra funktioner stöds inte. Detta inkluderar användning av name för att definiera en titel för en grupp fält.

ModelAdmin.filter_horizontal

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.

ModelAdmin.filter_vertical

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.

ModelAdmin.form

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().

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

Utelämna attributet Meta.model

Om du definierar attributet Meta.model på en ModelForm, måste du också definiera attributet Meta.fields (eller attributet Meta.exclude). Men eftersom administratören har sitt eget sätt att definiera fält kommer attributet Meta.fields att ignoreras.

Om ModelForm bara ska användas för administratören är den enklaste lösningen att utelämna attributet Meta.model, eftersom ModelAdmin kommer att tillhandahålla rätt modell att använda. Alternativt kan du ställa in fields = [] i klassen Meta för att uppfylla valideringen på ModelForm.

ModelAdmin.exclude har företräde

Om både ModelForm och ModelAdmin definierar ett exclude-alternativ har ModelAdmin företräde:

from django import forms
from django.contrib import admin
from myapp.models import Person


class PersonForm(forms.ModelForm):
    class Meta:
        model = Person
        exclude = ["name"]


class PersonAdmin(admin.ModelAdmin):
    exclude = ["age"]
    form = PersonForm

I exemplet ovan kommer fältet ”age” att uteslutas, men fältet ”name” kommer att ingå i det genererade formuläret.

ModelAdmin.formfield_overrides

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.

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:

from django.contrib import admin
from django.db import models

# Import our custom widget and our model from where they're defined
from myapp.models import MyModel
from myapp.widgets import RichTextEditorWidget


class MyModelAdmin(admin.ModelAdmin):
    formfield_overrides = {
        models.TextField: {"widget": RichTextEditorWidget},
    }

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.

Varning

Om du vill använda en anpassad widget med ett relationsfält (dvs. ForeignKey eller ManyToManyField), se till att du inte har inkluderat fältets namn i raw_id_fields, radio_fields eller autocomplete_fields.

`formfield_overrides låter dig inte ändra widgeten på relationsfält som har raw_id_fields, radio_fields eller autocomplete_fields inställda. Det beror på att raw_id_fields, radio_fields och autocomplete_fields innebär egna anpassade widgetar.

ModelAdmin.inlines

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

ModelAdmin.list_display

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

Exempel:

list_display = ["first_name", "last_name"]

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

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:

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

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

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

  class PersonAdmin(admin.ModelAdmin):
      list_display = ["city__name"]
  

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

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

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

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

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

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

Changed in Django 5.1:

Stöd för att använda __ lookups har lagts till, när man riktar in sig på relaterade fält.

Några specialfall att notera om list_display:

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

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

• 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.

• 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.

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

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

• 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.

• 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:

  from django.contrib import admin
  
  admin.site.empty_value_display = "(None)"
  

  Du kan också använda ModelAdmin.empty_value_display:

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

  Eller på fältnivå:

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

• 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:

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

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

  list_display = ["__str__", "some_other_field"]
  

• 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å).

  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:

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

  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.

  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:

  @admin.display(ordering="-first_name")
  def colored_first_name(self): ...
  

  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:

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

  Query expressions kan användas med argumentet ordering:

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

• Element i list_display kan också vara egenskaper

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

  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:

  def my_property(self):
      return self.first_name + " " + self.last_name
  
  
  my_property.short_description = "Full name of the person"
  my_property.admin_order_field = "last_name"
  my_property.boolean = False
  
  full_name = property(my_property)
  

• 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.

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

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

  • En anropsbar enhet.

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

  • En sträng som representerar ett modellattribut.

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

ModelAdmin.list_display_links

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.

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:

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

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

  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.

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

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

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

class AuditEntryAdmin(admin.ModelAdmin):
    list_display = ["timestamp", "message"]
    list_display_links = None

ModelAdmin.list_editable

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.

Observera

list_editable samverkar med ett par andra alternativ på särskilda sätt; du bör notera följande regler:

• Alla fält i list_editable måste också finnas i list_display. Du kan inte redigera ett fält som inte visas!

• Samma fält kan inte listas i både list_editable och list_display_links - ett fält kan inte vara både ett formulär och en länk.

Du får ett valideringsfel om någon av dessa regler inte följs.

ModelAdmin.list_filter

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

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.

ModelAdmin.list_max_show_all

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.

ModelAdmin.list_per_page

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.

ModelAdmin.list_select_related

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.

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

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.

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:

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

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

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

Observera

ModelAdmin ignorerar detta attribut när select_related`() redan anropats på changelistans QuerySet.

ModelAdmin.ordering

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.

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

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

Prestandaöverväganden vid beställning och sortering

För att säkerställa en deterministisk ordning av resultaten lägger ändringslistan till pk till ordningen om den inte kan hitta en enda eller unik uppsättning fält som ger total ordning.

Om standardordningen till exempel är efter ett icke-unikt fält name, sorteras ändringslistan efter name och pk. Detta kan fungera dåligt om du har många rader och inte har ett index på name och pk.

ModelAdmin.paginator

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().

ModelAdmin.prepopulated_fields

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

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

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

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

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

ModelAdmin.preserve_filters

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.

ModelAdmin.show_facets

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

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

class ShowFacets

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

ALWAYS

Visa alltid att fasetten räknas.

ALLOW

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

NEVER

Visa aldrig antalet fasetter.

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:

from django.contrib import admin


class MyModelAdmin(admin.ModelAdmin):
    ...
    # Have facets always shown for this model admin.
    show_facets = admin.ShowFacets.ALWAYS

Prestandaöverväganden med fasetter

Om du aktiverar facettfilter kommer antalet frågor på sidan med adminändringslistan att öka i takt med antalet filter. Dessa förfrågningar kan orsaka prestandaproblem, särskilt för stora datamängder. I dessa fall kan det vara lämpligt att ställa in show_facets till ShowFacets.NEVER för att helt inaktivera facettering.

ModelAdmin.radio_fields

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:

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

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

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

ModelAdmin.autocomplete_fields

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

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.

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.

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

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.

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

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:

class QuestionAdmin(admin.ModelAdmin):
    ordering = ["date_created"]
    search_fields = ["question_text"]


class ChoiceAdmin(admin.ModelAdmin):
    autocomplete_fields = ["question"]

Prestandaöverväganden för stora datamängder

Beställning med ModelAdmin.ordering kan orsaka prestandaproblem eftersom sortering på en stor frågeuppsättning blir långsam.

Om dina sökfält innehåller fält som inte indexeras av databasen kan du också få dålig prestanda i extremt stora tabeller.

I dessa fall är det en bra idé att skriva en egen ModelAdmin.get_search_results()-implementering med hjälp av en indexerad fulltextsökning.

Du kanske också vill ändra Paginator på mycket stora tabeller eftersom standardpaginatorn alltid utför en count()-fråga. Du kan t.ex. åsidosätta standardimplementeringen av egenskapen Paginator.count.

ModelAdmin.raw_id_fields

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.

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

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

Widgeten Input raw_id_fields bör innehålla en primärnyckel om fältet är en ForeignKey eller en kommaseparerad lista med värden om fältet är en ManyToManyField. Widgeten raw_id_fields visar en förstoringsglassknapp bredvid fältet som gör det möjligt för användare att söka efter och välja ett värde:

ModelAdmin.readonly_fields

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

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.

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:

from django.contrib import admin
from django.utils.html import format_html_join
from django.utils.safestring import mark_safe


class PersonAdmin(admin.ModelAdmin):
    readonly_fields = ["address_report"]

    # description functions like a model field's verbose_name
    @admin.display(description="Address")
    def address_report(self, instance):
        # assuming get_full_address() returns a list of strings
        # for each line of the address and you want to separate each
        # line by a linebreak
        return format_html_join(
            mark_safe("<br>"),
            "{}",
            ((line,) for line in instance.get_full_address()),
        ) or mark_safe("<span class='errors'>I can't determine this address.</span>")

ModelAdmin.save_as

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

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.

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

ModelAdmin.save_as_continue

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.

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

ModelAdmin.save_on_top

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

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.

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

ModelAdmin.search_fields

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.

Dessa fält bör vara någon form av textfält, till exempel CharField eller TextField. Du kan också utföra en relaterad sökning på en ForeignKey eller ManyToManyField med API:s sökning ”follow”-notation:

search_fields = ["foreign_key__related_fieldname"]

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:

search_fields = ["user__email"]

När någon gör en sökning i admins sökruta delar Django upp sökfrågan i ord och returnerar alla objekt som innehåller vart och ett av orden, skiftlägesokänsligt (med hjälp av icontains lookup), där varje ord måste finnas i minst ett av search_fields. Till exempel:, om search_fields är inställd på ['first_name', 'last_name'] och en användare söker efter john lennon, kommer Django att göra motsvarande denna SQL WHERE klausul:

WHERE (first_name ILIKE '%john%' OR last_name ILIKE '%john%')
AND (first_name ILIKE '%lennon%' OR last_name ILIKE '%lennon%')

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:

WHERE (first_name ILIKE '%john winston%' OR last_name ILIKE '%john winston%')

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'].

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:

Prefix	Uppslag
^	istartswith
=	iexact
@	search
Inget	ikoner

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.

ModelAdmin.search_help_text

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

ModelAdmin.show_full_result_count

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

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.

ModelAdmin.sortable_by

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.

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.

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

ModelAdmin.view_on_site

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.

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.

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:

from django.contrib import admin


class PersonAdmin(admin.ModelAdmin):
    view_on_site = False

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

from django.contrib import admin
from django.urls import reverse


class PersonAdmin(admin.ModelAdmin):
    def view_on_site(self, obj):
        url = reverse("person-detail", kwargs={"slug": obj.slug})
        return "https://example.com" + url

Anpassade mallalternativ

I avsnittet Åsidosätta adminmallar beskrivs hur du åsidosätter eller utökar standardmallarna för admin. Använd följande alternativ för att åsidosätta de standardmallar som används av vyerna i ModelAdmin:

ModelAdmin.add_form_template

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

ModelAdmin.change_form_template

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

ModelAdmin.change_list_template

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

ModelAdmin.delete_confirmation_template

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.

ModelAdmin.delete_selected_confirmation_template

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.

ModelAdmin.object_history_template

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

ModelAdmin.popup_response_template

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

metoder för ModelAdmin

Varning

När du åsidosätter ModelAdmin.save_model() och ModelAdmin.delete_model() måste din kod spara/radera objektet. De är inte avsedda för vetoändamål, utan ger dig möjlighet att utföra extra operationer.

ModelAdmin.save_model(request, obj, form, change)[source]

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().

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

from django.contrib import admin


class ArticleAdmin(admin.ModelAdmin):
    def save_model(self, request, obj, form, change):
        obj.user = request.user
        super().save_model(request, obj, form, change)

ModelAdmin.delete_model(request, obj)[source]

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().

ModelAdmin.delete_queryset(request, queryset)[source]

Metoden delete_queryset() får en HttpRequest och en QuerySet med objekt som ska raderas. Åsidosätt denna metod för att anpassa borttagningsprocessen för ”delete selected objects” action.

ModelAdmin.save_formset(request, form, formset, change)[source]

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.

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

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

Se även Spara objekt i formuläret.

Varning

Alla hooks som returnerar en ModelAdmin-egenskap returnerar själva egenskapen snarare än en kopia av dess värde. Dynamisk modifiering av värdet kan leda till överraskande resultat.

Låt oss ta ModelAdmin.get_readonly_fields() som ett exempel:

class PersonAdmin(admin.ModelAdmin):
    readonly_fields = ["name"]

    def get_readonly_fields(self, request, obj=None):
        readonly = super().get_readonly_fields(request, obj)
        if not request.user.is_superuser:
            readonly.append("age")  # Edits the class attribute.
        return readonly

Detta resulterar i att readonly_fields blir ["name", "age", "age", ...], även för en superanvändare, eftersom "age" läggs till varje gång en icke-superanvändare besöker sidan.

ModelAdmin.get_ordering(request)

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:

class PersonAdmin(admin.ModelAdmin):
    def get_ordering(self, request):
        if request.user.is_superuser:
            return ["name", "rank"]
        else:
            return ["name"]

ModelAdmin.get_search_results(request, queryset, search_term)[source]

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.

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

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.

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

class PersonAdmin(admin.ModelAdmin):
    list_display = ["name", "age"]
    search_fields = ["name"]

    def get_search_results(self, request, queryset, search_term):
        queryset, may_have_duplicates = super().get_search_results(
            request,
            queryset,
            search_term,
        )
        try:
            search_term_as_int = int(search_term)
        except ValueError:
            pass
        else:
            queryset |= self.model.objects.filter(age=search_term_as_int)
        return queryset, may_have_duplicates

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.

ModelAdmin.save_related(request, form, formsets, change)[source]

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.

ModelAdmin.get_autocomplete_fields(request)

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.

ModelAdmin.get_readonly_fields(request, obj=None)

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.

ModelAdmin.get_prepopulated_fields(request, obj=None)

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.

ModelAdmin.get_list_display(request)[source]

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.

ModelAdmin.get_list_display_links(request, list_display)[source]

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.

ModelAdmin.get_exclude(request, obj=None)

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.

ModelAdmin.get_fields(request, obj=None)

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.

ModelAdmin.get_fieldsets(request, obj=None)

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.

ModelAdmin.get_list_filter(request)[source]

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

ModelAdmin.get_list_select_related(request)[source]

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

ModelAdmin.get_search_fields(request)[source]

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

ModelAdmin.get_sortable_by(request)

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.

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

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

class PersonAdmin(admin.ModelAdmin):
    def get_sortable_by(self, request):
        return {*self.get_list_display(request)} - {"rank"}

ModelAdmin.get_inline_instances(request, obj=None)[source]

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:

class MyModelAdmin(admin.ModelAdmin):
    inlines = [MyInline]

    def get_inline_instances(self, request, obj=None):
        return [inline(self.model, self.admin_site) for inline in self.inlines]

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.

ModelAdmin.get_inlines(request, obj)

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.

ModelAdmin.get_urls()[source]

Metoden get_urls på en ModelAdmin returnerar de webbadresser som ska användas för den ModelAdmin på samma sätt som en URLconf. Därför kan du utöka dem som dokumenterat i URL-distributör, med hjälp av AdminSite.admin_view() wrapper på dina vyer:

from django.contrib import admin
from django.template.response import TemplateResponse
from django.urls import path


class MyModelAdmin(admin.ModelAdmin):
    def get_urls(self):
        urls = super().get_urls()
        my_urls = [path("my_view/", self.admin_site.admin_view(self.my_view))]
        return my_urls + urls

    def my_view(self, request):
        # ...
        context = dict(
            # Include common variables for rendering the admin template.
            self.admin_site.each_context(request),
            # Anything else you want in the context...
            key=value,
        )
        return TemplateResponse(request, "sometemplate.html", context)

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

{% extends "admin/base_site.html" %}
{% block content %}
...
{% endblock %}

Observera

Lägg märke till hur funktionen self.my_view är inkapslad i self.admin_site.admin_view. Detta är viktigt, eftersom det säkerställer två saker:

1. Behörighetskontroller körs för att säkerställa att endast aktiva personalanvändare kan komma åt vyn.

2. Dekoratorn django.views.decorators.cache.never_cache() används för att förhindra cachelagring, vilket säkerställer att den returnerade informationen är uppdaterad.

Observera

Observera att de anpassade mönstren inkluderas före de vanliga admin-URL:erna: admin-URL-mönstren är mycket tillåtande och matchar nästan vad som helst, så du vill vanligtvis lägga till dina anpassade URL:er före de inbyggda.

I det här exemplet kommer my_view att nås via /admin/myapp/mymodel/my_view/ (förutsatt att administratörens webbadresser finns i /admin/)

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():

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

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

ModelAdmin.get_form(request, obj=None, **kwargs)[source]

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

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:

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

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

ModelAdmin.get_formsets_with_inlines(request, obj=None)[source]

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

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:

class MyModelAdmin(admin.ModelAdmin):
    inlines = [MyInline, SomeOtherInline]

    def get_formsets_with_inlines(self, request, obj=None):
        for inline in self.get_inline_instances(request, obj):
            # hide MyInline in the add view
            if not isinstance(inline, MyInline) or obj is not None:
                yield inline.get_formset(request, obj), inline

ModelAdmin.formfield_for_foreignkey(db_field, request, **kwargs)

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:

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

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.

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:

class CountryAdminForm(forms.ModelForm):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.fields["capital"].queryset = self.instance.cities.all()


class CountryAdmin(admin.ModelAdmin):
    form = CountryAdminForm

ModelAdmin.formfield_for_manytomany(db_field, request, **kwargs)

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:

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

ModelAdmin.formfield_for_choice_field(db_field, request, **kwargs)

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:

class MyModelAdmin(admin.ModelAdmin):
    def formfield_for_choice_field(self, db_field, request, **kwargs):
        if db_field.name == "status":
            kwargs["choices"] = [
                ("accepted", "Accepted"),
                ("denied", "Denied"),
            ]
            if request.user.is_superuser:
                kwargs["choices"].append(("ready", "Ready for deployment"))
        return super().formfield_for_choice_field(db_field, request, **kwargs)

val begränsningar

Alla choices-attribut som anges på formulärfältet begränsas endast till formulärfältet. Om motsvarande fält i modellen har val inställda, måste de val som tillhandahålls i formuläret vara en giltig delmängd av dessa val, annars kommer formuläret att misslyckas med en ValidationError när modellen själv valideras innan den sparas.

ModelAdmin.get_changelist(request, **kwargs)[source]

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.

ModelAdmin.get_changelist_form(request, **kwargs)[source]

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

from django import forms


class MyForm(forms.ModelForm):
    pass


class MyModelAdmin(admin.ModelAdmin):
    def get_changelist_form(self, request, **kwargs):
        return MyForm

Utelämna attributet Meta.model

Om du definierar attributet Meta.model på en ModelForm, måste du också definiera attributet Meta.fields (eller attributet Meta.exclude). Men ModelAdmin ignorerar detta värde och åsidosätter det med attributet ModelAdmin.list_editable. Den enklaste lösningen är att utelämna attributet Meta.model, eftersom ModelAdmin kommer att tillhandahålla den korrekta modellen att använda.

ModelAdmin.get_changelist_formset(request, **kwargs)[source]

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:

from django.forms import BaseModelFormSet


class MyAdminFormSet(BaseModelFormSet):
    pass


class MyModelAdmin(admin.ModelAdmin):
    def get_changelist_formset(self, request, **kwargs):
        kwargs["formset"] = MyAdminFormSet
        return super().get_changelist_formset(request, **kwargs)

ModelAdmin.lookup_allowed(lookup, value, request)

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=[e-mail]). 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.

Metoden lookup_allowed() får en sökväg från frågesträngen (t.ex. 'user__email'), motsvarande värde (t.ex. '[e-mail]') 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).

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.

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

ModelAdmin.has_view_permission(request, obj=None)

Ska returnera True om det är tillåtet att visa obj, annars False. Om obj är None, bör returnera True eller False för att ange om visning 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 visa något objekt av denna typ).

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

ModelAdmin.has_add_permission(request)

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

ModelAdmin.has_change_permission(request, obj=None)

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

ModelAdmin.has_delete_permission(request, obj=None)

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

ModelAdmin.has_module_permission(request)

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.

ModelAdmin.get_queryset(request)

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:

class MyModelAdmin(admin.ModelAdmin):
    def get_queryset(self, request):
        qs = super().get_queryset(request)
        if request.user.is_superuser:
            return qs
        return qs.filter(author=request.user)

ModelAdmin.message_user(request, message, level=messages.INFO, extra_tags='', fail_silently=False)[source]

Skickar ett meddelande till användaren med hjälp av django.contrib.messages backend. Se custom ModelAdmin example.

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.

ModelAdmin.get_paginator(request, queryset, per_page, orphans=0, allow_empty_first_page=True)[source]

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

ModelAdmin.response_add(request, obj, post_url_continue=None)[source]

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

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.

ModelAdmin.response_change(request, obj)[source]

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

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.

ModelAdmin.response_delete(request, obj_display, obj_id)[source]

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

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.

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

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

ModelAdmin.get_formset_kwargs(request, obj, inline, prefix)[source]

En krok 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:

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

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

ModelAdmin.get_changeform_initial_data(request)[source]

En krok 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.

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

def get_changeform_initial_data(self, request):
    return {"name": "custom_initial_value"}

ModelAdmin.get_deleted_objects(objs, request)[source]

En krok för att anpassa borttagningsprocessen för delete_view() och ”delete selected” action.

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

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

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.

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

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

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

Andra metoder

ModelAdmin.add_view(request, form_url='', extra_context=None)[source]

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

ModelAdmin.change_view(request, object_id, form_url='', extra_context=None)[source]

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

ModelAdmin.changelist_view(request, extra_context=None)[source]

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

ModelAdmin.delete_view(request, object_id, extra_context=None)[source]

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

ModelAdmin.history_view(request, object_id, extra_context=None)[source]

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

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.

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:

class MyModelAdmin(admin.ModelAdmin):
    # A template for a very customized change view:
    change_form_template = "admin/myapp/extras/openstreetmap_change_form.html"

    def get_osm_info(self):
        # ...
        pass

    def change_view(self, request, object_id, form_url="", extra_context=None):
        extra_context = extra_context or {}
        extra_context["osm_data"] = self.get_osm_info()
        return super().change_view(
            request,
            object_id,
            form_url,
            extra_context=extra_context,
        )

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

ModelAdmin tillgångsdefinitioner

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:

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

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 :ref:``regelbundna tillgångsdefinitioner på formulär <form-asset-paths>`.

jQuery

Django admin JavaScript använder sig av biblioteket jQuery.

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.

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.

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

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.

Lägga till anpassad validering i admin

Du kan också lägga till anpassad validering av data i admin. Det automatiska admin-gränssnittet återanvänder django.forms, och klassen ModelAdmin ger dig möjlighet att definiera ditt eget formulär:

class ArticleAdmin(admin.ModelAdmin):
    form = MyArticleAdminForm

MyArticleAdminForm kan definieras var som helst så länge du importerar där det behövs. Nu i ditt formulär kan du lägga till din egen anpassade validering för alla fält:

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

Det är viktigt att du använder en ModelForm här annars kan saker gå sönder. Se forms dokumentation om custom validation och, mer specifikt, model form validation notes för mer information.

objekt av typen ``InlineModelAdmin

class InlineModelAdmin

class TabularInline[source]

class StackedInline[source]

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:

from django.db import models


class Author(models.Model):
    name = models.CharField(max_length=100)


class Book(models.Model):
    author = models.ForeignKey(Author, on_delete=models.CASCADE)
    title = models.CharField(max_length=100)

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:

from django.contrib import admin
from myapp.models import Author, Book


class BookInline(admin.TabularInline):
    model = Book


class AuthorAdmin(admin.ModelAdmin):
    inlines = [
        BookInline,
    ]


admin.site.register(Author, AuthorAdmin)

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

• :klass:`~django.contrib.admin.TabularInline`

• StackedInline

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

InlineModelAdmin alternativ

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:

• form

• fieldsets

• fields

• formfield_overrides

• exclude

• filter_horizontal

• filter_vertical

• ordering

• prepopulated_fields

• get_fieldsets()

• get_queryset()

• radio_fields

• readonly_fields

• raw_id_fields

• formfield_for_choice_field()

• formfield_for_foreignkey()

• formfield_for_manytomany()

• has_module_permission()

Klassen InlineModelAdmin lägger till eller anpassar:

InlineModelAdmin.model

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

InlineModelAdmin.fk_name

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.

InlineModelAdmin.formset

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 :ref:``model formsets <model-formsets>`.

InlineModelAdmin.form

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.

Varning

När du skriver anpassad validering för formuläret InlineModelAdmin bör du vara försiktig med att skriva validering som förlitar sig på funktioner i den överordnade modellen. Om den överordnade modellen inte valideras kan den lämnas i ett inkonsekvent tillstånd enligt beskrivningen i varningen i Validering på en ModelForm.

InlineModelAdmin.classes

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.

Changed in Django 5.1:

fieldsets som använder collapse klassen använder nu <details> och <summary> element, förutsatt att de definierar ett name.

InlineModelAdmin.extra

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.

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.

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.

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

InlineModelAdmin.max_num

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.

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

InlineModelAdmin.min_num

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

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

InlineModelAdmin.raw_id_fields

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.

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

class BookInline(admin.TabularInline):
    model = Book
    raw_id_fields = ["pages"]

InlineModelAdmin.template

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

InlineModelAdmin.verbose_name

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

InlineModelAdmin.verbose_name_plural

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'.

InlineModelAdmin.can_delete

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

InlineModelAdmin.show_change_link

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

InlineModelAdmin.get_formset(request, obj=None, **kwargs)

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.

InlineModelAdmin.get_extra(request, obj=None, **kwargs)

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

Å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):

class BinaryTreeAdmin(admin.TabularInline):
    model = BinaryTree

    def get_extra(self, request, obj=None, **kwargs):
        extra = 2
        if obj:
            return extra - obj.binarytree_set.count()
        return extra

InlineModelAdmin.get_max_num(request, obj=None, **kwargs)

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

Å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):

class BinaryTreeAdmin(admin.TabularInline):
    model = BinaryTree

    def get_max_num(self, request, obj=None, **kwargs):
        max_num = 10
        if obj and obj.parent:
            return max_num - 5
        return max_num

InlineModelAdmin.get_min_num(request, obj=None, **kwargs)

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

Å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).

InlineModelAdmin.has_add_permission(request, obj)

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.

InlineModelAdmin.has_change_permission(request, obj=None)

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

InlineModelAdmin.has_delete_permission(request, obj=None)

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

Observera

Argumentet obj som skickas till metoderna InlineModelAdmin är det överordnade objekt som redigeras eller None när ett nytt överordnat objekt läggs till.

Arbeta med en modell med två eller flera främmande nycklar till samma överordnade modell

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

from django.db import models


class Person(models.Model):
    name = models.CharField(max_length=128)


class Friendship(models.Model):
    to_person = models.ForeignKey(
        Person, on_delete=models.CASCADE, related_name="friends"
    )
    from_person = models.ForeignKey(
        Person, on_delete=models.CASCADE, related_name="from_friends"
    )

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:

from django.contrib import admin
from myapp.models import Friendship, Person


class FriendshipInline(admin.TabularInline):
    model = Friendship
    fk_name = "to_person"


class PersonAdmin(admin.ModelAdmin):
    inlines = [
        FriendshipInline,
    ]


admin.site.register(Person, PersonAdmin)

Arbeta med många-till-många-modeller

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.

Anta att vi har följande modeller:

from django.db import models


class Person(models.Model):
    name = models.CharField(max_length=128)


class Group(models.Model):
    name = models.CharField(max_length=128)
    members = models.ManyToManyField(Person, related_name="groups")

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:

from django.contrib import admin
from myapp.models import Group


class MembershipInline(admin.TabularInline):
    model = Group.members.through


class GroupAdmin(admin.ModelAdmin):
    inlines = [
        MembershipInline,
    ]
    exclude = ["members"]


admin.site.register(Group, GroupAdmin)

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

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.

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.

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.

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.

Arbeta med många-till-manga förmedlingsmodeller

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.

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:

from django.db import models


class Person(models.Model):
    name = models.CharField(max_length=128)


class Group(models.Model):
    name = models.CharField(max_length=128)
    members = models.ManyToManyField(Person, through="Membership")


class Membership(models.Model):
    person = models.ForeignKey(Person, on_delete=models.CASCADE)
    group = models.ForeignKey(Group, on_delete=models.CASCADE)
    date_joined = models.DateField()
    invite_reason = models.CharField(max_length=64)

    class Meta:
        constraints = [
            models.UniqueConstraint(
                fields=["person", "group"], name="unique_person_group"
            )
        ]

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

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

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.

Skapa nu adminvyer för modellerna Person och Group:

class PersonAdmin(admin.ModelAdmin):
    inlines = [MembershipInline]


class GroupAdmin(admin.ModelAdmin):
    inlines = [MembershipInline]

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

admin.site.register(Person, PersonAdmin)
admin.site.register(Group, GroupAdmin)

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

Använda generiska relationer som en inline

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

from django.contrib.contenttypes.fields import GenericForeignKey
from django.contrib.contenttypes.models import ContentType
from django.db import models


class Image(models.Model):
    image = models.ImageField(upload_to="images")
    content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
    object_id = models.PositiveIntegerField()
    content_object = GenericForeignKey("content_type", "object_id")


class Product(models.Model):
    name = models.CharField(max_length=100)

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:

from django.contrib import admin
from django.contrib.contenttypes.admin import GenericTabularInline

from myapp.models import Image, Product


class ImageInline(GenericTabularInline):
    model = Image


class ProductAdmin(admin.ModelAdmin):
    inlines = [
        ImageInline,
    ]


admin.site.register(Product, ProductAdmin)

Se contenttypes-dokumentationen för mer specifik information.

Åsidosätta adminmallar

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.

Konfigurera mallkataloger för projektadministratörer

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

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.

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.

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.

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.

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.

Åsidosätta eller ersätta en administratörsmall

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.

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 :

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

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.

Mallar som kan åsidosättas per app eller modell

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

• actions.html

• app_index.html

• ändra_formulär.html

• ändra_formulär_objekt_verktyg.html

• ändra_lista.html

• ändra_lista_objekt_verktyg.html

• ändra_lista_resultat.html

• datum_hierarki.html

• delete_confirmation.html

• objekt_historia.html

• pagination.html

• popup_response.html

• förpopulerade_fält_js.html

• search_form.html

• submit_line.html

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.

Observera

Vissa av adminmallarna, t.ex. change_list_results.html, används för att återge anpassade inkluderingstaggar. Dessa kan åsidosättas, men i sådana fall är det förmodligen bättre att du skapar din egen version av taggen i fråga och ger den ett annat namn. På så sätt kan du använda den selektivt.

Rot- och inloggningsmallar

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.

Stöd för tematisering

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:

{% extends 'admin/base.html' %}

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

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

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 %}.

extra kropp block

New in Django 5.2.

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:

{% extends 'admin/base.html' %}

{% block extrabody %}
    {{ block.super }}
    <script>
        document.addEventListener('DOMContentLoaded', function() {
            window.alert('Welcome!');
        });
    </script>
{% endblock extrabody %}

objekt av typen AdminSite

class AdminSite(name='admin')[source]

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.

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

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 :ref:reversing admin URLs <admin-reverse-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.

django.contrib.admin.sites.all_sites

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

attribut för AdminSite

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

AdminSite.site_header

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

AdminSite.site_title

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

AdminSite.site_url

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.

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 /.

AdminSite.index_title

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

AdminSite.index_template

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

AdminSite.app_index_template

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

AdminSite.empty_value_display

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.

AdminSite.enable_nav_sidebar

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.

AdminSite.final_catch_all_view

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.

Varning

Det rekommenderas inte att ställa in detta på ”false” eftersom vyn skyddar mot ett potentiellt integritetsproblem med modelluppräkning.

AdminSite.login_template

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

AdminSite.login_form

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

AdminSite.logout_template

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

AdminSite.password_change_template

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

AdminSite.password_change_done_template

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

metoder för AdminSite

AdminSite.each_context(request)[source]

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

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

• site_header: AdminSite.site_header

• site_title: AdminSite.site_title

• site_url: AdminSite.site_url

• has_permission: AdminSite.has_permission()

• 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:

  • app_label: applikationens etikett

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

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

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

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

  • model: modellklassen

  • object_name: modellens klassnamn

  • namn: modellens namn i plural

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

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

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

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

• is_nav_sidebar_enabled: AdminSite.enable_nav_sidebar

• log_entries: AdminSite.get_log_entries()

AdminSite.get_app_list(request, app_label=None)[source]

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:

• app_label: applikationens etikett

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

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

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

• name: namnet på applikationen

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

• model: modellklassen

• object_name: modellens klassnamn

• namn: modellens namn i plural

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

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

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

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.

AdminSite.has_permission(request)[source]

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.

AdminSite.register(model_or_iterable, admin_class=None, **options)[source]

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.

Utlöser ImproperlyConfigured om en modell är abstrakt. och django.contrib.admin.exceptions.AlreadyRegistered om en modell redan är registrerad.

AdminSite.unregister(model_or_iterable)[source]

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

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

AdminSite.get_model_admin(model)[source]

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

AdminSite.get_log_entries(request)[source]

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.

Koppla in AdminSite-instanser i din URLconf

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

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

# urls.py
from django.contrib import admin
from django.urls import path

urlpatterns = [
    path("admin/", admin.site.urls),
]

Anpassning av AdminSite-klassen

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.

myapp/admin.py

from django.contrib import admin

from .models import MyModel


class MyAdminSite(admin.AdminSite):
    site_header = "Monty Python administration"


admin_site = MyAdminSite(name="myadmin")
admin_site.register(MyModel)

myproject/urls.py

from django.urls import path

from myapp.admin import admin_site

urlpatterns = [
    path("myadmin/", admin_site.urls),
]

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.

Åsidosätta standardwebbplatsen för administratörer

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.

myproject/admin.py

from django.contrib import admin


class MyAdminSite(admin.AdminSite): ...

myproject/apps.py

from django.contrib.admin.apps import AdminConfig


class MyAdminConfig(AdminConfig):
    default_site = "myproject.admin.MyAdminSite"

myproject/settings.py

INSTALLED_APPS = [
    # ...
    "myproject.apps.MyAdminConfig",  # replaces 'django.contrib.admin'
    # ...
]

Flera administratörswebbplatser i samma URLconf

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.

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:

# urls.py
from django.urls import path
from myproject.admin import advanced_site, basic_site

urlpatterns = [
    path("basic-admin/", basic_site.urls),
    path("advanced-admin/", advanced_site.urls),
]

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 :ref:reversera dem<admin-reverse-urls>`. Detta är endast nödvändigt om du använder mer än en ``AdminSite.

Lägga till vyer på administratörssidor

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

Observera

Alla vyer du renderar som använder admin-mallarna, eller utökar bas-admin-mallen, bör ställa in request.current_app innan du renderar mallen. Den bör sättas till antingen self.name om din vy är på en AdminSite eller self.admin_site.name om din vy är på en ModelAdmin.

Lägga till en funktion för återställning av lösenord

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:

from django.contrib import admin
from django.contrib.auth import views as auth_views

path(
    "admin/password_reset/",
    auth_views.PasswordResetView.as_view(
        extra_context={"site_header": admin.site.site_header}
    ),
    name="admin_password_reset",
),
path(
    "admin/password_reset/done/",
    auth_views.PasswordResetDoneView.as_view(
        extra_context={"site_header": admin.site.site_header}
    ),
    name="password_reset_done",
),
path(
    "reset/<uidb64>/<token>/",
    auth_views.PasswordResetConfirmView.as_view(
        extra_context={"site_header": admin.site.site_header}
    ),
    name="password_reset_confirm",
),
path(
    "reset/done/",
    auth_views.PasswordResetCompleteView.as_view(
        extra_context={"site_header": admin.site.site_header}
    ),
    name="password_reset_complete",
),

(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ä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.

objekt av typen LogEntry

class models.LogEntry

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

LogEntry attribut

LogEntry.action_time

Datum och tid för åtgärden.

LogEntry.user

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

LogEntry.content_type

Det modifierade objektets :klass:`~django.contrib.contenttypes.models.ContentType`.

LogEntry.object_id

Den textuella representationen av det modifierade objektets primärnyckel.

LogEntry.object_repr

Objektets repr() efter modifieringen.

LogEntry.action_flag

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

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

from django.contrib.admin.models import ADDITION, LogEntry

LogEntry.objects.filter(action_flag=ADDITION)

LogEntry.change_message

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.

metoder för LogEntry

LogEntry.get_edited_object()[source]

En genväg som returnerar det refererade objektet.

LogEntry.get_change_message()[source]

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å.

Omvända administratörsadresser

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

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

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

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

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

I UserAdmin finns en namngiven URL:

Sida	URL-namn	Parametrar
Ändra lösenord	auth_user_password_change	användar_id

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

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:

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

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.

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:

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

Mer information finns i dokumentationen om :ref:``reversing namespaced URLs <topics-http-reversing-url-namespaces>`.

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:

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

Å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.

Dekorationselementet display

display(*, boolean=None, ordering=None, description=None, empty_value=None)[source]

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:

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

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

def is_published(self, obj):
    return obj.publish_date is not None


is_published.boolean = True
is_published.admin_order_field = "-publish_date"
is_published.short_description = "Is Published?"

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.

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:

@admin.display
def published_year(self, obj):
    return obj.publish_date.year

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

Dekoratorn staff_member_required (personalmedlem krävs)

staff_member_required(redirect_field_name='next', login_url='admin:login')[source]

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:

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

• 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/.

Exempel på användning:

from django.contrib.admin.views.decorators import staff_member_required


@staff_member_required
def my_view(request): ...