ModelAdmin-objektLink to this heading#
\n- \n
- \nclass ModelAdminLink to this definition# \n
Klassen
\nModelAdminär representationen av en modell i admin-gränssnittet. Vanligtvis lagras dessa i en fil med namnetadmin.pyi din applikation. Låt oss ta en titt på ett exempel påModelAdmin:\n\nfrom django.contrib import admin\nfrom myapp.models import Author\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n pass\n\n\nadmin.site.register(Author, AuthorAdmin)\n
Dekoratorn ”registerLink to this heading#
\n- \n
- \nregister(*models, site=django.contrib.admin.sites.site)Link to this definition# \n
Det finns också en dekorator för att registrera dina
\nModelAdmin-klasser:\nfrom django.contrib import admin\nfrom .models import Author\n\n\n@admin.register(Author)\nclass AuthorAdmin(admin.ModelAdmin):\n pass\nDen får en eller flera modellklasser att registrera med
\nModelAdmin. Om du använder en anpassadAdminSite, skicka den med nyckelordsargumentetsite:\nfrom django.contrib import admin\nfrom .models import Author, Editor, Reader\nfrom myproject.admin_site import custom_admin_site\n\n\n@admin.register(Author, Reader, Editor, site=custom_admin_site)\nclass PersonAdmin(admin.ModelAdmin):\n pass\nDu kan inte använda denna dekorator om du måste referera till din modelladministratörsklass i dess
\n__init__()-metod, t.ex.super(PersonAdmin, self).__init__(*args, **kwargs). Du kan användasuper().__init__(*args, **kwargs).
Upptäckt av adminfilerLink to this heading#
\nNär du lägger till 'django.contrib.admin i din INSTALLED_APPS-inställning, letar Django automatiskt efter en admin-modul i varje applikation och importerar den.
- \n
- \nclass apps.AdminConfigLink to this definition# \n
This is the default
\nAppConfigclass for the admin.\nIt callsautodiscover()when Django starts.
- \n
- \nclass apps.SimpleAdminConfigLink to this definition# \n
This class works like
\nAdminConfig,\nexcept it doesn’t callautodiscover().- \n
- \ndefault_siteLink to this definition# \n
En prickad importsökväg till standardadministratörswebbplatsens klass eller till en anropsbar som returnerar en webbplatsinstans. Standard är
\n'django.contrib.admin.sites.AdminSite'. Se Åsidosätta standardwebbplatsen för administratörer för användning.
- \n
- \nautodiscover()Link to this definition# \n
Denna funktion försöker importera en ”admin”-modul i varje installerad applikation. Sådana moduler förväntas registrera modeller med administratören.
\nVanligtvis behöver du inte anropa den här funktionen direkt eftersom
\nAdminConfiganropar 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 alternativLink to this heading#
\nModelAdmin ä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\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n date_hierarchy = "pub_date"\n- \n
- \nModelAdmin.actionsLink to this definition# \n
En lista över åtgärder som ska göras tillgängliga på sidan med ändringslistan. Se Administrativa åtgärder för mer information.
\n
- \n
- \nModelAdmin.actions_on_topLink to this definition# \n
- \n
- \nModelAdmin.actions_on_bottomLink to this definition# \n
Styr var på sidan åtgärdsfältet visas. Som standard visar adminändringslistan åtgärder längst upp på sidan (
\nactions_on_top = True; actions_on_bottom = False).
- \n
- \nModelAdmin.actions_selection_counterLink to this definition# \n
Styr om en urvalsräknare ska visas bredvid rullgardinsmenyn för åtgärder. Som standard visas den i admin-changellistan (
\nactions_selection_counter = True).
- \n
- \nModelAdmin.date_hierarchyLink to this definition# \n
Ange
\ndate_hierarchytill namnet på enDateFieldellerDateTimeFieldi din modell, så kommer sidan med ändringslistan att innehålla en datumbaserad drilldown-navigering efter det fältet.Exempel:
\n\ndate_hierarchy = "pub_date"\nDu kan också ange ett fält i en relaterad modell med hjälp av
\n__lookup, till exempel:\ndate_hierarchy = "author__pub_date"\nDetta kommer att fylla i sig självt på ett intelligent sätt baserat på tillgängliga data, t.ex. om alla datum är i en månad kommer det bara att visa drill-down på dagsnivå.
\n\n
- \n
- \nModelAdmin.empty_value_displayLink to this definition# \n
Detta attribut åsidosätter standardvisningsvärdet för postfält som är tomma (
\nNone, tom sträng, etc.). Standardvärdet är-(ett streck). Till exempel:\nfrom django.contrib import admin\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n empty_value_display = "-empty-"\nDu kan också åsidosätta
\nempty_value_displayför alla adminsidor medAdminSite.empty_value_display, eller för specifika fält så här:\nfrom django.contrib import admin\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n list_display = ["name", "title", "view_birth_date"]\n\n @admin.display(empty_value="???")\n def view_birth_date(self, obj):\n return obj.birth_date\n
- \n
- \nModelAdmin.excludeLink to this definition# \n
Detta attribut, om det anges, bör vara en lista över fältnamn som ska uteslutas från formuläret.
\nLåt oss till exempel betrakta följande modell:
\n\nfrom django.db import models\n\n\nclass Author(models.Model):\n name = models.CharField(max_length=100)\n title = models.CharField(max_length=3)\n birth_date = models.DateField(blank=True, null=True)\nOm du vill ha ett formulär för modellen
\nAuthorsom bara innehåller fältennameochtitleanger dufieldsellerexcludeså här:\nfrom django.contrib import admin\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n fields = ["name", "title"]\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n exclude = ["birth_date"]\nEftersom modellen Author bara har tre fält,
\nname,titleochbirth_date, kommer de formulär som blir resultatet av ovanstående deklarationer att innehålla exakt samma fält.
- \n
- \nModelAdmin.fieldsLink to this definition# \n
Använd alternativet
\nfieldsfö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 modellendjango.contrib.flatpages.models.FlatPageenligt följande:\nclass FlatPageAdmin(admin.ModelAdmin):\n fields = ["url", "title", "content"]\nI exemplet ovan visas endast fälten
\nurl,titleochcontenti tur och ordning i formuläret.fieldskan innehålla värden som definieras iModelAdmin.readonly_fieldsför att visas som skrivskyddade.För mer komplexa layoutbehov, se alternativet
\nfieldsets.Alternativet
\nfieldsaccepterar samma typer av värden somlist_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 ireadonly_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
\nurlochtitleatt visas på samma rad och fältetcontentkommer att visas under dem på en egen rad:\n\nclass FlatPageAdmin(admin.ModelAdmin):\n fields = [("url", "title"), "content"]\nOm varken
\nfieldsellerfieldsets-alternativen är närvarande, kommer Django som standard att visa varje fält som inte är ettAutoFieldoch hareditable=True, i en enda fieldset, i samma ordning som fälten definieras i modellen, följt av alla fält som definieras ireadonly_fields.
- \n
- \nModelAdmin.fieldsetsLink to this definition# \n
Ställ in
\nfieldsetsför att styra layouten på adminsidorna ”add” och ”change”.
\nfieldsetsä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
\n(name, field_options), därnameär en sträng som representerar titeln på fieldset ochfield_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
\ndjango.contrib.flatpages.models.FlatPage:\nfrom django.contrib import admin\n\n\nclass FlatPageAdmin(admin.ModelAdmin):\n fieldsets = [\n (\n None,\n {\n "fields": ["url", "title", "content", "sites"],\n },\n ),\n (\n "Advanced options",\n {\n "classes": ["collapse"],\n "fields": ["registration_required", "template_name"],\n },\n ),\n ]\nDetta resulterar i en administratörssida som ser ut som följer:
\n![\"/sv/6.0/_images/fieldsets.png\"](\"/sv/6.0/_images/fieldsets.png\")
\nOm varken
\nfieldsetsellerfields-alternativen är närvarande, kommer Django som standard att visa varje fält som inte är ettAutoFieldoch hareditable=True, i ett enda fieldset, i samma ordning som fälten definieras i modellen.Ordlistan
\nfield_optionskan ha följande nycklar:- \n
- \n
fältEn lista eller tupel med fältnamn som ska visas i denna fieldset. Denna nyckel är obligatorisk.
\nExempel:
\n\n{\n "fields": ["first_name", "last_name", "address", "city", "state"],\n}\nPrecis som med alternativet
\nfieldskan 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ältenfirst_nameochlast_nameatt visas på samma rad:\n{\n "fields": [("first_name", "last_name"), "address", "city", "state"],\n}\n
\nfieldskan innehålla värden som definieras ireadonly_fieldsför att visas som skrivskyddade.Om du lägger till namnet på en callable i
\nfieldsgäller samma regel som med alternativetfields: callable måste listas ireadonly_fields. \n
\n- \n
klasserEn 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:
\ncollapseochwide.Exempel:
\n\n{\n "classes": ["wide", "collapse"],\n}\nFältuppsättningar med stilen
\nwidefår extra horisontellt utrymme i admin-gränssnittet. Fältuppsättningar med ett namn och stilencollapsekommer initialt att vara kollapsade, med hjälp av en expanderbar widget med en växling för att växla deras synlighet. \n
\n- \n
BeskrivningEn sträng med valfri extra text som ska visas högst upp i varje fältmängd, under fältmängdens rubrik.
\nObservera 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
\ndjango.utils.html.escape()för att undkomma eventuella HTML-specialtecken. \n
\n
- \n
- \nModelAdmin.filter_horizontalLink to this definition# \n
Som standard visas en
\nManyToManyFieldpå 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 enManyToManyFieldtill 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. Sefilter_verticalför att använda ett vertikalt gränssnitt.
- \n
- \nModelAdmin.filter_verticalLink to this definition# \n
Samma som
\nfilter_horizontal, men använder en vertikal visning av filtergränssnittet där rutan med omarkerade alternativ visas ovanför rutan med markerade alternativ.
- \n
- \nModelAdmin.formLink to this definition# \n
Som standard skapas ett
\nModelFormdynamiskt 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 egenModelFormfö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 metodenModelAdmin.get_form().För ett exempel, se avsnittet Lägga till anpassad validering i admin.
\n\n\n
- \n
- \nModelAdmin.formfield_overridesLink to this definition# \n
Detta ger ett snabbt och enkelt sätt att åsidosätta några av
\nField-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
\nformfield_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 enRichTextEditorWidgetsom vi skulle vilja använda för stora textfält istället för standard<textarea>. Så här skulle vi göra det:\nfrom django.contrib import admin\nfrom django.db import models\n\n# Import our custom widget and our model from where they're defined\nfrom myapp.models import MyModel\nfrom myapp.widgets import RichTextEditorWidget\n\n\nclass MyModelAdmin(admin.ModelAdmin):\n formfield_overrides = {\n models.TextField: {"widget": RichTextEditorWidget},\n }\nObservera 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
\n\n__init__()-metod. Se API för formulär för mer information.
- \n
- \nModelAdmin.inlinesLink to this definition# \n
Se
\nInlineModelAdmin-objekt nedan samtModelAdmin.get_formsets_with_inlines().
- \n
- \nModelAdmin.list_displayLink to this definition# \n
Ställ in
\nlist_displayför att styra vilka fält som ska visas på sidan med ändringslistan i admin.Exempel:
\n\nlist_display = ["first_name", "last_name"]\nOm du inte ställer in
\nlist_displaykommer 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
\nlist_display. Alla utom den enklaste kan användadisplay()-dekoratorn, som används för att anpassa hur fältet presenteras:- \n
Namnet på ett modellfält. Till exempel:
\n\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["first_name", "last_name"]\n\nNamnet på ett relaterat fält med hjälp av notationen
\n__. Till exempel:\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["city__name"]\n\nEn anropsbar funktion som accepterar ett argument, modellinstansen. Till exempel:
\n\n@admin.display(description="Name")\ndef upper_case_name(obj):\n return f"{obj.first_name} {obj.last_name}".upper()\n\n\nclass PersonAdmin(admin.ModelAdmin):\n list_display = [upper_case_name]\n\nEn sträng som representerar en
\nModelAdmin-metod som accepterar ett argument, modellinstansen. Till exempel:\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["upper_case_name"]\n\n @admin.display(description="Name")\n def upper_case_name(self, obj):\n return f"{obj.first_name} {obj.last_name}".upper()\n\nEn sträng som representerar ett modellattribut eller en metod (utan några obligatoriska argument). Till exempel:
\n\nfrom django.contrib import admin\nfrom django.db import models\n\n\nclass Person(models.Model):\n name = models.CharField(max_length=50)\n birthday = models.DateField()\n\n @admin.display(description="Birth decade")\n def decade_born_in(self):\n decade = self.birthday.year // 10 * 10\n return f"{decade}’s"\n\n\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["name", "decade_born_in"]\n\n
Några specialfall att notera om
\nlist_display:- \n
Om fältet är en
ForeignKey, kommer Django att visa__str__()för det relaterade objektet. \nfält av typen
ManyToManyFieldstö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 ilist_display. (Se nedan för mer information om anpassade metoder ilist_display) \nOm fältet är en
BooleanField, kommer Django att visa en vacker ”ja”, ”nej” eller ”okänd” ikon istället förTrue,FalseellerNone. \nOm den angivna strängen är en metod för modellen,
\nModelAdmineller en anropsbar, kommer Django att HTML-escape utdata som standard. Användformat_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:
\n\nfrom django.contrib import admin\nfrom django.db import models\nfrom django.utils.html import format_html\n\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n last_name = models.CharField(max_length=50)\n color_code = models.CharField(max_length=6)\n\n @admin.display\n def colored_name(self):\n return format_html(\n '<span style="color: #{};">{} {}</span>',\n self.color_code,\n self.first_name,\n self.last_name,\n )\n\n\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["first_name", "last_name", "colored_name"]\n\nSom 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 meddisplay()-dekoratorn och skicka argumentetdescription. \nOm värdet på ett fält är
\nNone, en tom sträng eller en iterabel utan element, kommer Django att visa-(ett streck). Du kan åsidosätta detta medAdminSite.empty_value_display:\nfrom django.contrib import admin\n\nadmin.site.empty_value_display = "(None)"\nDu kan också använda
\nModelAdmin.empty_value_display:\nclass PersonAdmin(admin.ModelAdmin):\n empty_value_display = "unknown"\nEller på fältnivå:
\n\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["name", "birth_date_view"]\n\n @admin.display(empty_value="unknown")\n def birth_date_view(self, obj):\n return obj.birth_date\n\nOm den angivna strängen är en metod för modellen,
\nModelAdmineller en anropsbar som returnerarTrue,FalseellerNone, kommer Django att visa en vacker ”ja”, ”nej” eller ”okänd” ikon om du lindar in metoden meddisplay()dekoratorn som passerarbooleanargumentet med värdet inställt påTrue:\nfrom django.contrib import admin\nfrom django.db import models\n\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n birthday = models.DateField()\n\n @admin.display(boolean=True)\n def born_in_fifties(self):\n return 1950 <= self.birthday.year < 1960\n\n\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["name", "born_in_fifties"]\n\nMetoden
\n__str__()är precis lika giltig ilist_displaysom alla andra modellmetoder, så det är helt OK att göra detta:\nlist_display = ["__str__", "some_other_field"]\n\nVanligtvis kan element i
\nlist_displaysom inte är faktiska databasfält inte användas i sortering (eftersom Django gör all sortering på databasnivå).Men om ett element i
\nlist_displayrepresenterar ett visst databasfält kan du ange detta genom att användadisplay()-dekoratorn på metoden och skicka argumentetordering:\nfrom django.contrib import admin\nfrom django.db import models\nfrom django.utils.html import format_html\n\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n color_code = models.CharField(max_length=6)\n\n @admin.display(ordering="first_name")\n def colored_first_name(self):\n return format_html(\n '<span style="color: #{};">{}</span>',\n self.color_code,\n self.first_name,\n )\n\n\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["first_name", "colored_first_name"]\nOvanstående kommer att tala om för Django att ordna efter fältet
\nförnamnnär man försöker sortera efterfärgat_förnamni admin.För att ange fallande ordning med argumentet
\norderingkan du använda ett bindestrecksprefix på fältnamnet. Med hjälp av ovanstående exempel skulle detta se ut som:\n@admin.display(ordering="-first_name")\ndef colored_first_name(self): ...\nArgumentet
\norderingstö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:\nclass Blog(models.Model):\n title = models.CharField(max_length=255)\n author = models.ForeignKey(Person, on_delete=models.CASCADE)\n\n\nclass BlogAdmin(admin.ModelAdmin):\n list_display = ["title", "author", "author_first_name"]\n\n @admin.display(ordering="author__first_name")\n def author_first_name(self, obj):\n return obj.author.first_name\nQuery expressions kan användas med argumentet
\nordering:\nfrom django.db.models import Value\nfrom django.db.models.functions import Concat\n\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n last_name = models.CharField(max_length=50)\n\n @admin.display(ordering=Concat("first_name", Value(" "), "last_name"))\n def full_name(self):\n return self.first_name + " " + self.last_name\n\nElement i
\nlist_displaykan också vara egenskaper\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n last_name = models.CharField(max_length=50)\n\n @property\n @admin.display(\n ordering="last_name",\n description="Full name of the person",\n boolean=False,\n )\n def full_name(self):\n return self.first_name + " " + self.last_name\n\n\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["full_name"]\nObservera att
\n@propertymå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ändadisplay()-dekoratorn - var medveten om att funktionenproperty()och inte@property-dekoratorn måste användas:\ndef my_property(self):\n return self.first_name + " " + self.last_name\n\n\nmy_property.short_description = "Full name of the person"\nmy_property.admin_order_field = "last_name"\nmy_property.boolean = False\n\nfull_name = property(my_property)\n\nFältnamnen i
list_displaykommer också att visas som CSS-klasser i HTML-utdata, i form avcolumn-<field_name>på varje<th>-element. Detta kan till exempel användas för att ställa in kolumnbredder i en CSS-fil. \nDjango kommer att försöka tolka varje element i
\nlist_displayi denna ordning:- \n
Ett område av modellen eller från ett relaterat område.
\nEn anropsbar enhet.
\nEn sträng som representerar ett
ModelAdmin-attribut. \nEn sträng som representerar ett modellattribut.
\n
Om du t.ex. har
\nfirst_namesom ett modellfält och som ettModelAdmin-attribut, kommer modellfältet att användas. \n
- \n
- \nModelAdmin.list_display_linksLink to this definition# \n
Använd
\nlist_display_linksför att styra om och vilka fält ilist_displaysom 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
\nlist_display- till ändringssidan för varje objekt. Men medlist_display_linkskan du ändra detta:- \n
Ställ in den på
Noneför att inte få några länkar alls. \nAnge en lista eller tupel av fält (i samma format som
\nlist_display) vars kolumner du vill konvertera till länkar.Du kan ange ett eller flera fält. Så länge fälten visas i
\nlist_displaybryr 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ändalist_display_linkspå det här sättet måste du definieralist_display. \n
I det här exemplet kommer fälten ”förnamn” och ”efternamn” att länkas på sidan för ändringslistan:
\n\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["first_name", "last_name", "birthday"]\n list_display_links = ["first_name", "last_name"]\nI det här exemplet har rutnätet för sidan med ändringslistan inga länkar:
\n\nclass AuditEntryAdmin(admin.ModelAdmin):\n list_display = ["timestamp", "message"]\n list_display_links = None\n
- \n
- \nModelAdmin.list_editableLink to this definition# \n
Ange
\n\nlist_editabletill en lista med fältnamn i modellen som kan redigeras på sidan med ändringslistan. Det innebär att fält som listas ilist_editablekommer att visas som formulärwidgets på sidan med ändringslistan, så att användarna kan redigera och spara flera rader samtidigt.
- \n
- \nModelAdmin.list_filterLink to this definition# \n
Ställ in
\nlist_filterför att aktivera filter i höger sidofält på sidan med ändringslistan i admin.I sin enklaste form tar
\nlist_filteren lista eller tupel av fältnamn för att aktivera filtrering på, men flera mer avancerade alternativ finns tillgängliga. Se ModelAdmin Lista Filter för mer information.
- \n
- \nModelAdmin.list_max_show_allLink to this definition# \n
Ställ in
\nlist_max_show_allför att styra hur många objekt som kan visas på en ”Visa alla”-sida för adminändringslistan. Administratören kommer att visa en ”Visa alla”-länk på ändringslistan endast om det totala antalet resultat är mindre än eller lika med denna inställning. Som standard är detta inställt på200.
- \n
- \nModelAdmin.list_per_pageLink to this definition# \n
Ställ in
\nlist_per_pageför att styra hur många objekt som visas på varje paginerad sida i listan över adminändringar. Som standard är detta inställt på100.
- \n\n
Ställ in
\nlist_select_relatedför att tala om för Django att användaselect_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
\nFalse.När värdet är
\nTrue, kommerselect_related()alltid att anropas. När värdet är satt tillFalse, kommer Django att titta pålist_displayoch anropaselect_related()om någonForeignKeyfinns.Om du behöver mer finkornig kontroll kan du använda en tupel (eller lista) som värde för
\nlist_select_related. Tom tuple kommer att förhindra Django från att anropaselect_relatedöverhuvudtaget. Alla andra tupler kommer att skickas direkt tillselect_relatedsom parametrar. Till exempel:\nclass ArticleAdmin(admin.ModelAdmin):\n list_select_related = ["author", "category"]\nkommer att anropa
\nselect_related('author', 'category').Om du behöver ange ett dynamiskt värde baserat på begäran kan du implementera en
\n\nget_list_select_related()-metod.
- \n
- \nModelAdmin.orderingLink to this definition# \n
Ange
\norderingfö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 modellsorderingparameter.Om detta inte anges kommer Django-administratören att använda modellens standardbeställning.
\nOm du behöver ange en dynamisk ordning (t.ex. beroende på användare eller språk) kan du implementera en
\n\nget_ordering()-metod.
- \n
- \nModelAdmin.paginatorLink to this definition# \n
Den paginatorklass som ska användas för paginering. Som standard används
\ndjango.core.paginator.Paginator. Om den anpassade paginatorklassen inte har samma konstruktörsgränssnitt somdjango.core.paginator.Paginator, måste du också tillhandahålla en implementering förModelAdmin.get_paginator().
- \n
- \nModelAdmin.prepopulated_fieldsLink to this definition# \n
Ange
\nprepopulated_fieldstill en ordbok som mappar fältnamn till de fält som den ska förinställa från:\nclass ArticleAdmin(admin.ModelAdmin):\n prepopulated_fields = {"slug": ["title"]}\nNä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).
\nFörfyllda fält ändras inte av JavaScript efter att ett värde har sparats. Det är vanligtvis inte önskvärt att sluggar ändras (vilket skulle leda till att ett objekts URL ändras om sluggen används i det).
\n
\nprepopulated_fieldsaccepterar inte fältenDateTimeField,ForeignKey,OneToOneFieldochManyToManyField.
- \n
- \nModelAdmin.preserve_filtersLink to this definition# \n
Som standard bevaras tillämpade filter i listvyn efter att ett objekt har skapats, redigerats eller tagits bort. Du kan rensa bort filter genom att ställa in detta attribut på
\nFalse.
- \n
- \nModelAdmin.show_facetsLink to this definition# \n
Styr om antalet facetter ska visas för filter i adminändringslistan. Standardvärde är
\nShowFacets.ALLOW.När de visas uppdateras antalet facetter i linje med de filter som används för tillfället.
\n- \n
- \nclass ShowFacetsLink to this definition# \n
En lista över tillåtna värden för
\nModelAdmin.show_facets.- \n
- \nALWAYSLink to this definition# \n
Visa alltid att fasetten räknas.
\n
- \n
- \nALLOWLink to this definition# \n
Visa facettantal när parametern
\n_facetsför frågesträng anges.
- \n
- \nNEVERLink to this definition# \n
Visa aldrig antalet fasetter.
\n
Ställ in
\nshow_facetstill önskat värde förShowFacets. Om du t.ex. alltid vill visa antalet facetter utan att behöva ange frågeparametern:\n\nfrom django.contrib import admin\n\n\nclass MyModelAdmin(admin.ModelAdmin):\n ...\n # Have facets always shown for this model admin.\n show_facets = admin.ShowFacets.ALWAYS\n
- \n
- \nModelAdmin.radio_fieldsLink to this definition# \n
Som standard använder Djangos admin ett select-box-gränssnitt (<select>) för fält som är
\nForeignKeyeller harchoicesinställt. Om ett fält finns iradio_fieldskommer Django att använda ett radioknappsgränssnitt istället. Förutsatt attgroupär enForeignKeypåPersonmodellen:\nclass PersonAdmin(admin.ModelAdmin):\n radio_fields = {"group": admin.VERTICAL}\nDu kan välja att använda
\nHORIZONTALellerVERTICALfrån modulendjango.contrib.admin.Inkludera inte ett fält i
\nradio_fieldsom det inte är enForeignKeyeller harchoicesinställt.
- \n
- \nModelAdmin.autocomplete_fieldsLink to this definition# \n
\nautocomplete_fieldsär en lista överForeignKeyoch/ellerManyToManyFieldfält som du vill ändra till Select2 autokompletteringsinmatningar.Som standard använder administratören ett select-box-gränssnitt (
\n<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.
\nDu måste definiera
\nsearch_fieldspå det relaterade objektetsModelAdmineftersom autokompletteringssökningen använder den.För att undvika obehörigt utlämnande av data måste användare ha behörigheten
\nviewellerchangetill det relaterade objektet för att kunna använda autokomplettering.Ordning och paginering av resultaten styrs av den relaterade
\nModelAdminget_ordering()ochget_paginator()metoderna.I följande exempel har
\nChoiceAdminett fält för autokomplettering avForeignKeytillQuestion. Resultaten filtreras efter fältetquestion_textoch sorteras efter fältetdate_created:\n\nclass QuestionAdmin(admin.ModelAdmin):\n ordering = ["date_created"]\n search_fields = ["question_text"]\n\n\nclass ChoiceAdmin(admin.ModelAdmin):\n autocomplete_fields = ["question"]\n
- \n
- \nModelAdmin.raw_id_fieldsLink to this definition# \n
Som standard använder Djangos admin ett gränssnitt med en valbox (<select>) för fält som är
\nForeignKey. Ibland vill du inte ta på dig omkostnaderna för att behöva välja alla relaterade instanser som ska visas i rullgardinsmenyn.
\nraw_id_fieldsär en lista över fält som du vill ändra till enInputwidget för antingen enForeignKeyellerManyToManyField:\nclass ArticleAdmin(admin.ModelAdmin):\n raw_id_fields = ["newspaper"]\nThe
\nraw_id_fieldsInputwidget should contain a primary key if the\nfield is aForeignKeyor a comma separated list of values if the field\nis aManyToManyField. Theraw_id_fieldswidget shows a magnifying\nglass button next to the field which allows users to search for and select\na value:![\"/sv/6.0/_images/raw_id_fields.png\"](\"/sv/6.0/_images/raw_id_fields.png\")
\n
- \n
- \nModelAdmin.readonly_fieldsLink to this definition# \n
Som standard visar administratören alla fält som redigerbara. Alla fält i detta alternativ (som bör vara en
\nlistellertuple) kommer att visa sina data som de är och inte redigerbara; de är också uteslutna frånModelFormsom används för att skapa och redigera. Observera att när du angerModelAdmin.fieldsellerModelAdmin.fieldsetsmåste de skrivskyddade fälten vara närvarande för att visas (annars ignoreras de).Om
\nreadonly_fieldsanvänds utan att definiera explicit ordning genomModelAdmin.fieldsellerModelAdmin.fieldsetskommer 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
\nModelAdmin. Detta är mycket likt det sätt somModelAdmin.list_displayfungerar 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:\nfrom django.contrib import admin\nfrom django.utils.html import format_html_join\nfrom django.utils.safestring import mark_safe\n\n\nclass PersonAdmin(admin.ModelAdmin):\n readonly_fields = ["address_report"]\n\n # description functions like a model field's verbose_name\n @admin.display(description="Address")\n def address_report(self, instance):\n # assuming get_full_address() returns a list of strings\n # for each line of the address and you want to separate each\n # line by a linebreak\n return format_html_join(\n mark_safe("<br>"),\n "{}",\n ((line,) for line in instance.get_full_address()),\n ) or mark_safe("<span class='errors'>I can't determine this address.</span>")\n
- \n
- \nModelAdmin.save_asLink to this definition# \n
Ställ in
\nsave_asfö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
\nsave_asärTruekommer ”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
\nsave_asinställd påFalse.
- \n
- \nModelAdmin.save_as_continueLink to this definition# \n
När
\nsave_as=Trueär standardomdirigeringen efter att det nya objektet har sparats till ändringsvyn för det objektet. Om du angersave_as_continue=Falsekommer omdirigeringen att ske till vyn för ändringslistan.Som standard är
\nsave_as_continueinställd påTrue.
- \n
- \nModelAdmin.save_on_topLink to this definition# \n
Ställ in
\nsave_on_topfö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
\nsave_on_topkommer knapparna att visas både överst och nederst.Som standard är
\nsave_on_topinställd påFalse.
- \n
- \nModelAdmin.search_fieldsLink to this definition# \n
Ställ in
\nsearch_fieldsfö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
\nCharFieldellerTextField. Du kan också utföra en relaterad sökning på enForeignKeyellerManyToManyFieldmed API:s sökning ”follow”-notation:\nsearch_fields = ["foreign_key__related_fieldname"]\nOm du t.ex. har ett blogginlägg med en författare skulle följande definition göra det möjligt att söka efter blogginlägg med hjälp av författarens e-postadress:
\n\nsearch_fields = ["user__email"]\nNä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
\nicontainslookup), där varje ord måste finnas i minst ett avsearch_fields. Till exempel:, omsearch_fieldsär inställd på['first_name', 'last_name']och en användare söker efterjohn lennon, kommer Django att göra motsvarande denna SQLWHEREklausul:\nWHERE (first_name ILIKE '%john%' OR last_name ILIKE '%john%')\nAND (first_name ILIKE '%lennon%' OR last_name ILIKE '%lennon%')\nSökfrågan kan innehålla citerade fraser med mellanslag. Till exempel:, om en användare söker efter
\n"john winston"eller'john winston', kommer Django att göra motsvarande denna SQLWHEREklausul:\nWHERE (first_name ILIKE '%john winston%' OR last_name ILIKE '%john winston%')\nOm du inte vill använda
\nicontainssom uppslagsord kan du använda vilket uppslagsord som helst genom att lägga till det i fältet. Du kan till exempel användaexactgenom att ställa insearch_fieldstill['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
\nsearch_fieldsmed följande tecken och det motsvarar att lägga till__<lookup>till fältet:\n\n\n
\nPrefix
Uppslag
^
\n =
\n @
\n Inget
ikonerOm du behöver anpassa sökningen kan du använda
\nModelAdmin.get_search_results()för att tillhandahålla ytterligare eller alternativt sökbeteende.
- \n
- \nModelAdmin.search_help_textLink to this definition# \n
Ange
\nsearch_help_textför att ange en beskrivande text för sökrutan som kommer att visas under den.
- \n
- \nModelAdmin.show_full_result_countLink to this definition# \n
Ställ in
\nshow_full_result_countfö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åFalsevisas istället en text som99 resultat (Visa alla).Standardvärdet
\nshow_full_result_count=Truegenererar en fråga för att utföra en fullständig räkning av tabellen, vilket kan vara dyrt om tabellen innehåller ett stort antal rader.
- \n
- \nModelAdmin.sortable_byLink to this definition# \n
Som standard tillåter sidan med ändringslistan sortering efter alla modellfält (och anropsbara som använder argumentet
\norderingtill dekoratorndisplay()eller har attributetadmin_order_field) som anges ilist_display.Om du vill inaktivera sortering för vissa kolumner anger du
\nortable_bytill en samling (t.ex.list,tupleellerset) av den delmängd avlist_displaysom 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
\nget_sortable_by()-metod istället.
- \n
- \nModelAdmin.view_on_siteLink to this definition# \n
Ställ in
\nview_on_sitefö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
\nTrue(standard) kommer objektetsget_absolute_url()-metod att användas för att generera webbadressen.Om din modell har en
\nget_absolute_url()-metod men du inte vill att knappen ”Visa på webbplatsen” ska visas, behöver du bara ställa inview_on_sitetillFalse:\nfrom django.contrib import admin\n\n\nclass PersonAdmin(admin.ModelAdmin):\n view_on_site = False\nOm det är en callable accepterar den modellinstansen som en parameter. Till exempel:
\n\nfrom django.contrib import admin\nfrom django.urls import reverse\n\n\nclass PersonAdmin(admin.ModelAdmin):\n def view_on_site(self, obj):\n url = reverse("person-detail", kwargs={"slug": obj.slug})\n return "https://example.com" + url\n
Anpassade mallalternativLink to this heading#
\nThe Åsidosätta adminmallar section describes how to override or\nextend the default admin templates. Use the following options to override the\ndefault templates used by the ModelAdmin views:
- \n
- \nModelAdmin.add_form_templateLink to this definition# \n
Sökväg till en anpassad mall som används av
\nadd_view().
- \n
- \nModelAdmin.change_form_templateLink to this definition# \n
Sökväg till en anpassad mall som används av
\nchange_view().
- \n
- \nModelAdmin.change_list_templateLink to this definition# \n
Sökväg till en anpassad mall som används av
\nchangelist_view().
- \n
- \nModelAdmin.delete_confirmation_templateLink to this definition# \n
Sökväg till en anpassad mall som används av
\ndelete_view()för att visa en bekräftelsesida när ett eller flera objekt tas bort.
- \n
- \nModelAdmin.delete_selected_confirmation_templateLink to this definition# \n
Sökväg till en anpassad mall som används av åtgärdsmetoden
\ndelete_selectedför att visa en bekräftelsesida när ett eller flera objekt tas bort. Se dokumentation om åtgärder.
- \n
- \nModelAdmin.object_history_templateLink to this definition# \n
Sökväg till en anpassad mall som används av
\nhistory_view().
- \n
- \nModelAdmin.popup_response_templateLink to this definition# \n
Sökväg till en anpassad mall som används av
\nresponse_add(),response_change()ochresponse_delete().
metoder för ModelAdminLink to this heading#
\n\n- \n
- \nModelAdmin.save_model(request, obj, form, change)Link to this definition# \n
Metoden
\nsave_modelfårHttpRequest, en modellinstans, enModelForm-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. Anropasuper().save_model()för att spara objektet medModel.save().Till exempel: för att koppla
\nrequest.usertill objektet innan det sparas:\nfrom django.contrib import admin\n\n\nclass ArticleAdmin(admin.ModelAdmin):\n def save_model(self, request, obj, form, change):\n obj.user = request.user\n super().save_model(request, obj, form, change)\n
- \n
- \nModelAdmin.delete_model(request, obj)Link to this definition# \n
Metoden
\ndelete_modelfårHttpRequestoch en modellinstans. Genom att åsidosätta denna metod kan du göra åtgärder före eller efter borttagning. Anropasuper().delete_model()för att radera objektet medModel.delete().
- \n
- \nModelAdmin.delete_queryset(request, queryset)Link to this definition# \n
The
\ndelete_queryset()method is given theHttpRequestand a\nQuerySetof objects to be deleted. Override this method to customize\nthe deletion process for the ”delete selected objects” action.
- \n
- \nModelAdmin.save_formset(request, form, formset, change)Link to this definition# \n
Metoden
\nsave_formsetfårHttpRequest, den överordnadeModelForm-instansen och ett boolean-värde baserat på om den lägger till eller ändrar det överordnade objektet.Till exempel:, för att koppla
\nrequest.usertill varje ändrad formulärmodellinstans:\nclass ArticleAdmin(admin.ModelAdmin):\n def save_formset(self, request, form, formset, change):\n instances = formset.save(commit=False)\n for obj in formset.deleted_objects:\n obj.delete()\n for instance in instances:\n instance.user = request.user\n instance.save()\n formset.save_m2m()\nSe även Spara objekt i formuläret.
\n
- \n
- \nModelAdmin.get_ordering(request)Link to this definition# \n
Metoden
\nget_orderingtar enrequestsom parameter och förväntas returnera enlistellertupleför ordning på liknande sätt som attributetordering. Till exempel:\nclass PersonAdmin(admin.ModelAdmin):\n def get_ordering(self, request):\n if request.user.is_superuser:\n return ["name", "rank"]\n else:\n return ["name"]\n
- \n
- \nModelAdmin.get_search_results(request, queryset, search_term)Link to this definition# \n
Metoden
\nget_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
\nModelAdmin.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
\nTruei det andra elementet i returvärdet.Om du t.ex. vill söka efter
\nnamnochålderkan du använda:\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["name", "age"]\n search_fields = ["name"]\n\n def get_search_results(self, request, queryset, search_term):\n queryset, may_have_duplicates = super().get_search_results(\n request,\n queryset,\n search_term,\n )\n try:\n search_term_as_int = int(search_term)\n except ValueError:\n pass\n else:\n queryset |= self.model.objects.filter(age=search_term_as_int)\n return queryset, may_have_duplicates\nDenna implementering är effektivare än
\nsearch_fields = ('name', '= age')vilket resulterar i en strängjämförelse för det numeriska fältet, till exempel `` … ELLER UPPER (”polls_choice”.”votes”::text) = UPPER (’4’)`` på PostgreSQL.
- \n\n
Metoden
\nsave_relatedfårHttpRequest, den överordnadeModelForm-instansen, listan över inline-formulär och ett boolean-värde som baseras på om den överordnade instansen läggs till eller ändras. Här kan du göra alla för- eller eftersparingsåtgärder för objekt som är relaterade till föräldern. Observera att det överordnade objektet och dess formulär redan har sparats vid denna tidpunkt.
- \n
- \nModelAdmin.get_autocomplete_fields(request)Link to this definition# \n
Metoden
\nget_autocomplete_fields()fårHttpRequestoch förväntas returnera enlistellertuplemed fältnamn som kommer att visas med en widget för autokomplettering enligt beskrivningen ovan i avsnittetModelAdmin.autocomplete_fields.
- \n
- \nModelAdmin.get_readonly_fields(request, obj=None)Link to this definition# \n
Metoden
\nget_readonly_fieldsfårHttpRequestochobjsom redigeras (ellerNonei ett add-formulär) och förväntas returnera enlistellertuplemed fältnamn som ska visas som skrivskyddade, enligt beskrivningen ovan i avsnittetModelAdmin.readonly_fields.
- \n
- \nModelAdmin.get_prepopulated_fields(request, obj=None)Link to this definition# \n
Metoden
\nget_prepopulated_fieldsfårHttpRequestochobjsom redigeras (ellerNonei ett add-formulär) och förväntas returnera endictionary, enligt beskrivningen ovan i avsnittetModelAdmin.prepopulated_fields.
- \n
- \nModelAdmin.get_list_display(request)Link to this definition# \n
Metoden
\nget_list_displaygesHttpRequestoch förväntas returnera enlistaellertupelmed fältnamn som kommer att visas i vyn med ändringslistan enligt beskrivningen ovan i avsnittetModelAdmin.list_display.
- \n
- \nModelAdmin.get_list_display_links(request, list_display)Link to this definition# \n
Metoden
\nget_list_display_linksfårHttpRequestoch denlistellertuplesom returneras avModelAdmin.get_list_display(). Den förväntas returnera antingenNoneeller enlistellertuplemed fältnamn på changelistan som kommer att länkas till ändringsvyn, enligt beskrivningen i avsnittetModelAdmin.list_display_links.
- \n
- \nModelAdmin.get_exclude(request, obj=None)Link to this definition# \n
Metoden
\nget_excludefårHttpRequestochobjsom redigeras (ellerNonei ett add-formulär) och förväntas returnera en lista med fält, enligt beskrivningen iModelAdmin.exclude.
- \n
- \nModelAdmin.get_fields(request, obj=None)Link to this definition# \n
Metoden
\nget_fieldsfårHttpRequestochobjsom redigeras (ellerNonei ett add-formulär) och förväntas returnera en lista med fält, enligt beskrivningen ovan i avsnittetModelAdmin.fields.
- \n
- \nModelAdmin.get_fieldsets(request, obj=None)Link to this definition# \n
Metoden
\nget_fieldsetsfårHttpRequestochobjsom redigeras (ellerNonepå 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 avsnittetModelAdmin.fieldsets.
- \n
- \nModelAdmin.get_list_filter(request)Link to this definition# \n
Metoden
\nget_list_filtergesHttpRequestoch förväntas returnera samma typ av sekvenstyp som för attributetlist_filter.
- \n\n
Metoden
\nget_list_select_relatedges tillHttpRequestoch bör returnera en boolean eller lista somModelAdmin.list_select_relatedgör.
- \n
- \nModelAdmin.get_search_fields(request)Link to this definition# \n
Metoden
\nget_search_fieldsgesHttpRequestoch förväntas returnera samma typ av sekvenstyp som för attributetsearch_fields.
- \n
- \nModelAdmin.get_sortable_by(request)Link to this definition# \n
Metoden
\nget_sortable_by()skickas tillHttpRequestoch förväntas returnera en samling (t.ex.list,tupleellerset) av fältnamn som kommer att kunna sorteras på sidan med ändringslistan.Dess standardimplementering returnerar
\nsortable_byom den är inställd, annars hänvisar den tillget_list_display().Till exempel: för att förhindra att en eller flera kolumner är sorterbara:
\n\nclass PersonAdmin(admin.ModelAdmin):\n def get_sortable_by(self, request):\n return {*self.get_list_display(request)} - {"rank"}\n
- \n
- \nModelAdmin.get_inline_instances(request, obj=None)Link to this definition# \n
Metoden
\nget_inline_instancesfårHttpRequestochobjsom redigeras (ellerNonei ett add-formulär) och förväntas returnera enlistellertupleavInlineModelAdmin-objekt, enligt beskrivningen nedan i avsnittetInlineModelAdmin. Följande skulle till exempel returnera inlines utan standardfiltrering baserat på behörigheter för att lägga till, ändra, ta bort och visa:\nclass MyModelAdmin(admin.ModelAdmin):\n inlines = [MyInline]\n\n def get_inline_instances(self, request, obj=None):\n return [inline(self.model, self.admin_site) for inline in self.inlines]\nOm du åsidosätter den här metoden måste du se till att de returnerade inlines är instanser av de klasser som definieras i
\ninlines, annars kan du få ett ”Bad Request”-fel när du lägger till relaterade objekt.
- \n
- \nModelAdmin.get_inlines(request, obj)Link to this definition# \n
Metoden
\nget_inlinesfårHttpRequestochobjsom redigeras (ellerNonei 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 iModelAdmin.inlines.
- \n
- \nModelAdmin.get_urls()Link to this definition# \n
The
\nget_urlsmethod on aModelAdminreturns the URLs to be used for\nthat ModelAdmin in the same way as a URLconf. Therefore you can extend\nthem as documented in URL-distributör, using the\nAdminSite.admin_view()wrapper on your views:\nfrom django.contrib import admin\nfrom django.template.response import TemplateResponse\nfrom django.urls import path\n\n\nclass MyModelAdmin(admin.ModelAdmin):\n def get_urls(self):\n urls = super().get_urls()\n my_urls = [path("my_view/", self.admin_site.admin_view(self.my_view))]\n return my_urls + urls\n\n def my_view(self, request):\n # ...\n context = dict(\n # Include common variables for rendering the admin template.\n self.admin_site.each_context(request),\n # Anything else you want in the context...\n key=value,\n )\n return TemplateResponse(request, "sometemplate.html", context)\nOm du vill använda adminlayouten, förläng från
\nadmin/base_site.html:\n\n\n{% extends "admin/base_site.html" %}\n{% block content %}\n...\n{% endblock %}\nOm sidan kan cachas, men du ändå vill att behörighetskontrollen ska utföras, kan du skicka ett
\ncacheable=True-argument tillAdminSite.admin_view():\npath("my_view/", self.admin_site.admin_view(self.my_view, cacheable=True))\nvyerna
\nModelAdminhar attributenmodel_admin. AndraAdminSite-vyer haradmin_site-attribut.
- \n
- \nModelAdmin.get_form(request, obj=None, **kwargs)Link to this definition# \n
Returnerar en
\nModelForm-klass för användning i admin-vyerna för tillägg och ändring, seadd_view()ochchange_view().Basimplementeringen använder
\nmodelform_factory()för att underklassaform, modifierad av attribut somfieldsochexclude. Så om du till exempel vill erbjuda ytterligare fält till superanvändare kan du byta ut ett annat basformulär så här:\nclass MyModelAdmin(admin.ModelAdmin):\n def get_form(self, request, obj=None, **kwargs):\n if request.user.is_superuser:\n kwargs["form"] = MySuperuserForm\n return super().get_form(request, obj, **kwargs)\nDu kan också returnera en anpassad
\nModelForm-klass direkt.
- \n
- \nModelAdmin.get_formsets_with_inlines(request, obj=None)Link to this definition# \n
Ger (
\nFormSet,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
\nget_formsets_with_inlinespå följande sätt:\nclass MyModelAdmin(admin.ModelAdmin):\n inlines = [MyInline, SomeOtherInline]\n\n def get_formsets_with_inlines(self, request, obj=None):\n for inline in self.get_inline_instances(request, obj):\n # hide MyInline in the add view\n if not isinstance(inline, MyInline) or obj is not None:\n yield inline.get_formset(request, obj), inline\n
- \n
- \nModelAdmin.formfield_for_foreignkey(db_field, request, **kwargs)Link to this definition# \n
Med metoden
\nformfield_for_foreignkeypå enModelAdminkan 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:\nclass MyModelAdmin(admin.ModelAdmin):\n def formfield_for_foreignkey(self, db_field, request, **kwargs):\n if db_field.name == "car":\n kwargs["queryset"] = Car.objects.filter(owner=request.user)\n return super().formfield_for_foreignkey(db_field, request, **kwargs)\nDetta använder
\nHttpRequest-instansen för att filtrera främmande nyckelfältetCarför att endast visa de bilar som ägs avUser-instansen.För mer komplexa filter kan du använda metoden
\nModelForm.__init__()för att filtrera baserat på eninstansav din modell (se Fält som hanterar relationer). Till exempel:\nclass CountryAdminForm(forms.ModelForm):\n def __init__(self, *args, **kwargs):\n super().__init__(*args, **kwargs)\n self.fields["capital"].queryset = self.instance.cities.all()\n\n\nclass CountryAdmin(admin.ModelAdmin):\n form = CountryAdminForm\n
- \n
- \nModelAdmin.formfield_for_manytomany(db_field, request, **kwargs)Link to this definition# \n
I likhet med metoden
\nformfield_for_foreignkeykan metodenformfield_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ältetCarså att det bara visar de bilar som ägs avUser:\nclass MyModelAdmin(admin.ModelAdmin):\n def formfield_for_manytomany(self, db_field, request, **kwargs):\n if db_field.name == "cars":\n kwargs["queryset"] = Car.objects.filter(owner=request.user)\n return super().formfield_for_manytomany(db_field, request, **kwargs)\n
- \n
- \nModelAdmin.formfield_for_choice_field(db_field, request, **kwargs)Link to this definition# \n
Precis som metoderna
\nformfield_for_foreignkeyochformfield_for_manytomanykan metodenformfield_for_choice_fieldåsidosättas för att ändra standardformulärsfältet för ett fält som har deklarerade val. Om t.ex. de val som är tillgängliga för en superanvändare ska vara annorlunda än de som är tillgängliga för den vanliga personalen, kan du göra på följande sätt:\n\nclass MyModelAdmin(admin.ModelAdmin):\n def formfield_for_choice_field(self, db_field, request, **kwargs):\n if db_field.name == "status":\n kwargs["choices"] = [\n ("accepted", "Accepted"),\n ("denied", "Denied"),\n ]\n if request.user.is_superuser:\n kwargs["choices"].append(("ready", "Ready for deployment"))\n return super().formfield_for_choice_field(db_field, request, **kwargs)\n
- \n
- \nModelAdmin.get_changelist(request, **kwargs)Link to this definition# \n
Returnerar klassen
\nChangelistsom ska användas för listning. Som standard användsdjango.contrib.admin.views.main.ChangeList. Genom att ärva denna klass kan du ändra beteendet för listningen.
- \n
- \nModelAdmin.get_changelist_form(request, **kwargs)Link to this definition# \n
Returnerar en
\nModelForm-klass för användning iFormsetpå changelist-sidan. För att använda ett anpassat formulär, till exempel:\n\nfrom django import forms\n\n\nclass MyForm(forms.ModelForm):\n pass\n\n\nclass MyModelAdmin(admin.ModelAdmin):\n def get_changelist_form(self, request, **kwargs):\n return MyForm\n
- \n
- \nModelAdmin.get_changelist_formset(request, **kwargs)Link to this definition# \n
Returnerar en ModelFormSet-klass för användning på sidan med ändringslistan om
\nlist_editableanvänds. Om du vill använda en anpassad formuläruppsättning, till exempel:\nfrom django.forms import BaseModelFormSet\n\n\nclass MyAdminFormSet(BaseModelFormSet):\n pass\n\n\nclass MyModelAdmin(admin.ModelAdmin):\n def get_changelist_formset(self, request, **kwargs):\n kwargs["formset"] = MyAdminFormSet\n return super().get_changelist_formset(request, **kwargs)\n
- \n
- \nModelAdmin.lookup_allowed(lookup, value, request)Link to this definition# \n
Objekten på sidan med ändringslistan kan filtreras med hjälp av uppslagningar från URL:ens frågesträng. Det är så här
\nlist_filterfungerar, till exempel. Uppslagningarna liknar det som används iQuerySet.filter()(t.ex.user__email=user@example.com). Eftersom sökningarna i frågesträngen kan manipuleras av användaren måste de rensas för att förhindra obehörig exponering av data.Metoden
\nlookup_allowed()får en sökväg från frågesträngen (t.ex.'user__email'), motsvarande värde (t.ex.'user@example.com') och begäran, och returnerar en boolean som anger om filtrering av changelistansQuerySetmed parametrarna är tillåten. Omlookup_allowed()returnerarFalse, aktiverasDisallowedModelAdminLookup(underklass tillSuspiciousOperation).Som standard tillåter
\nlookup_allowed()åtkomst till en modells lokala fält, fältsökvägar som används ilist_filter(men inte sökvägar frånget_list_filter()) och uppslagningar som krävs för attlimit_choices_toska fungera korrekt iraw_id_fields.Åsidosätt denna metod för att anpassa de tillåtna uppslagningarna för din
\nModelAdmin-underklass.
- \n
- \nModelAdmin.has_view_permission(request, obj=None)Link to this definition# \n
Ska returnera
\nTrueom det är tillåtet att visaobj, annarsFalse. Om obj ärNone, bör returneraTrueellerFalseför att ange om visning av objekt av denna typ är tillåten i allmänhet (t.ex. kommerFalseatt tolkas som att den aktuella användaren inte får visa något objekt av denna typ).Standardimplementeringen returnerar
\nTrueom användaren har antingen behörigheten ”change” eller ”view”.
- \n
- \nModelAdmin.has_add_permission(request)Link to this definition# \n
Ska returnera
\nTrueom det är tillåtet att lägga till ett objekt, annarsFalse.
- \n
- \nModelAdmin.has_change_permission(request, obj=None)Link to this definition# \n
Bör returnera
\nTrueom det är tillåtet att redigeraobj, annarsFalse. OmobjärNone, bör returneraTrueellerFalseför att ange om redigering av objekt av denna typ är tillåten i allmänhet (t.ex. kommerFalseatt tolkas som att den aktuella användaren inte får redigera något objekt av denna typ).
- \n
- \nModelAdmin.has_delete_permission(request, obj=None)Link to this definition# \n
Bör returnera
\nTrueom det är tillåtet att raderaobj, annarsFalse. OmobjärNone, bör returneraTrueellerFalseför att ange om det är tillåtet att radera objekt av denna typ i allmänhet (t.ex. kommerFalseatt tolkas som att den aktuella användaren inte får radera något objekt av denna typ).
- \n
- \nModelAdmin.has_module_permission(request)Link to this definition# \n
Bör returnera
\nTrueom det är tillåtet att visa modulen på adminindexsidan och komma åt modulens indexsida, annarsFalse. AnvänderUser.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()ochhas_delete_permission()bör användas för det.
- \n
- \nModelAdmin.get_queryset(request)Link to this definition# \n
Metoden
\nget_querysetpå enModelAdminreturnerar enQuerySetav 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:\nclass MyModelAdmin(admin.ModelAdmin):\n def get_queryset(self, request):\n qs = super().get_queryset(request)\n if request.user.is_superuser:\n return qs\n return qs.filter(author=request.user)\n
- \n
- \nModelAdmin.message_user(request, message, level=messages.INFO, extra_tags='', fail_silently=False)Link to this definition# \n
Sends a message to the user using the
\ndjango.contrib.messages\nbackend. See the custom ModelAdmin example.Med nyckelordsargument kan du ändra meddelandenivån, lägga till extra CSS-taggar eller misslyckas tyst om ramverket
\ncontrib.messagesinte är installerat. Dessa nyckelordsargument matchar dem fördjango.contrib.messages.add_message(), se den funktionens dokumentation för mer information. En skillnad är att nivån kan skickas som en strängetikett utöver heltal/konstant.
- \n
- \nModelAdmin.get_paginator(request, queryset, per_page, orphans=0, allow_empty_first_page=True)Link to this definition# \n
Returnerar en instans av den paginator som ska användas för den här vyn. Som standard instansieras en instans av
\npaginator.
- \n
- \nModelAdmin.response_add(request, obj, post_url_continue=None)Link to this definition# \n
Bestämmer
\nHttpResponseföradd_view()-steget.
\nresponse_addanropas efter att adminformuläret har skickats in och precis efter att objektet och alla relaterade instanser har skapats och sparats. Du kan åsidosätta det för att ändra standardbeteendet efter att objektet har skapats.
- \n
- \nModelAdmin.response_change(request, obj)Link to this definition# \n
Bestämmer
\nHttpResponseförchange_view()-steget.
\nresponse_changeanropas efter att adminformuläret har skickats in och precis efter att objektet och alla relaterade instanser har sparats. Du kan åsidosätta den för att ändra standardbeteendet efter att objektet har ändrats.
- \n
- \nModelAdmin.response_delete(request, obj_display, obj_id)Link to this definition# \n
Bestämmer
\nHttpResponsefördelete_view()-steget.
\nresponse_deleteanropas efter att objektet har tagits bort. Du kan åsidosätta det för att ändra standardbeteendet efter att objektet har tagits bort.
\nobj_displayär en sträng med namnet på det borttagna objektet.
\nobj_idär den serialiserade identifieraren som används för att hämta det objekt som ska raderas.
- \n
- \nModelAdmin.get_formset_kwargs(request, obj, inline, prefix)Link to this definition# \n
En hook för att anpassa de nyckelordsargument som skickas till konstruktören för ett formulär. Till exempel:, för att skicka
\nrequesttill formuläret forms:\nclass MyModelAdmin(admin.ModelAdmin):\n def get_formset_kwargs(self, request, obj, inline, prefix):\n return {\n **super().get_formset_kwargs(request, obj, inline, prefix),\n "form_kwargs": {"request": request},\n }\nDu kan också använda den för att ställa in
\ninitialför formulär.
- \n
- \nModelAdmin.get_changeform_initial_data(request)Link to this definition# \n
En hook för initialdata i formulär för adminändringar. Som standard ges fält initiala värden från
\nGET-parametrar. Till exempel: kommer?name=initial_valueatt ställa in fältetnameinitiala värde till att varainitial_value.Denna metod ska returnera en ordbok i form av
\n{'fieldname': 'fieldval'}:\ndef get_changeform_initial_data(self, request):\n return {"name": "custom_initial_value"}\n
- \n
- \nModelAdmin.get_deleted_objects(objs, request)Link to this definition# \n
A hook for customizing the deletion process of the
\ndelete_view()and\nthe ”delete selected” action.Argumentet
\nobjsär en homogen iterabel av objekt (enQuerySeteller en lista av modellinstanser) som ska raderas, ochrequestärHttpRequest.Denna metod måste returnera en 4-tupel av
\n(deleted_objects, model_count, perms_needed, protected).
\ndeleted_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 filtretunordered_list.
\nmodel_countär en ordbok som mappar varje modellsverbose_name_pluraltill antalet objekt som kommer att raderas.
\nperms_neededär en uppsättningverbose_name`av de modeller som användaren inte har behörighet att ta bort.
\nprotectedär en lista med strängar som representerar alla skyddade relaterade objekt som inte kan tas bort. Listan visas i mallen.
Andra metoderLink to this heading#
\n- \n
- \nModelAdmin.add_view(request, form_url='', extra_context=None)Link to this definition# \n
Django-vy för sidan med tillägg av modellinstans. Se anmärkning nedan.
\n
- \n
- \nModelAdmin.change_view(request, object_id, form_url='', extra_context=None)Link to this definition# \n
Django-vy för sidan för redigering av modellinstanser. Se anmärkning nedan.
\n
- \n
- \nModelAdmin.changelist_view(request, extra_context=None)Link to this definition# \n
Django-vy för sidan med ändringslista/åtgärder för modellinstanser. Se anmärkning nedan.
\n
- \n
- \nModelAdmin.delete_view(request, object_id, extra_context=None)Link to this definition# \n
Django-vy för bekräftelsesidan för borttagning av modellinstans(er). Se anmärkning nedan.
\n
- \n
- \nModelAdmin.history_view(request, object_id, extra_context=None)Link to this definition# \n
Djangovy för sidan som visar ändringshistoriken för en given modellinstans.
\n
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:
\nclass MyModelAdmin(admin.ModelAdmin):\n # A template for a very customized change view:\n change_form_template = "admin/myapp/extras/openstreetmap_change_form.html"\n\n def get_osm_info(self):\n # ...\n pass\n\n def change_view(self, request, object_id, form_url="", extra_context=None):\n extra_context = extra_context or {}\n extra_context["osm_data"] = self.get_osm_info()\n return super().change_view(\n request,\n object_id,\n form_url,\n extra_context=extra_context,\n )\nDessa 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ångsdefinitionerLink to this heading#
\nDet 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):\n class Media:\n css = {\n "all": ["my_styles.css"],\n }\n js = ["my_code.js"]\nAppen staticfiles app prependlar STATIC_URL (eller MEDIA_URL om STATIC_URL är None) till alla sökvägar för tillgångar. Samma regler gäller som för regelbundna tillgångsdefinitioner på formulär.
jQueryLink to this heading#
\nDjango admin JavaScript använder sig av biblioteket jQuery.
\nFö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.