Objets ModelAdminLien vers cette rubrique#
\n- \n
- \nclass ModelAdminLien vers cette définition# \n
La classe
\nModelAdminest la représentation d’un modèle dans l’interface d’administration. Normalement, ces classes sont stockées dans un fichier nomméadmin.pydans votre application. Jetons un œil à un exemple deModelAdmin:\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
Le décorateur registerLien vers cette rubrique#
\n- \n
- \nregister(*models, site=django.contrib.admin.sites.site)Lien vers cette définition# \n
Il existe aussi un décorateur pour l’enregistrement des classes
\nModelAdmin:\nfrom django.contrib import admin\nfrom .models import Author\n\n\n@admin.register(Author)\nclass AuthorAdmin(admin.ModelAdmin):\n pass\nIl reçoit une ou plusieurs classes de modèles à inscrire à
\nModelAdmin. Si vous utilisez une classeAdminSitepersonnalisée, transmettez-la en utilisant le paramètre nommésite:\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\nVous ne pouvez pas utiliser ce décorateur si devez faire référence à la classe d’administration de modèle dans la méthode
\n__init__(), par ex.super(PersonAdmin, self).__init__(*args, **kwargs). Vous pouvez utilisersuper().__init__(*args, **kwargs).
Découvert des fichiers d’administrationLien vers cette rubrique#
\nLorsque vous placez 'django.contrib.admin' dans votre réglage INSTALLED_APPS, Django recherche automatiquement un module admin dans chaque application et l’importe.
- \n
- \nclass apps.AdminConfigLien vers cette définition# \n
Il s’agit de la classe
\nAppConfigpar défaut pour l’administration. Elle appelleautodiscover()au démarrage de Django.
- \n
- \nclass apps.SimpleAdminConfigLien vers cette définition# \n
Cette classe fonctionne comme
\nAdminConfig, sauf qu’elle n’appelle pasautodiscover().- \n
- \ndefault_siteLien vers cette définition# \n
Un chemin d’importation à syntaxe pointée vers la classe de site d’administration par défaut ou vers un objet exécutable renvoyant une instance de site. La valeur par défaut est
\n'django.contrib.admin.sites.AdminSite'. Voir Surcharge du site d’administration par défaut pour les instructions d’utilisation.
- \n
- \nautodiscover()Lien vers cette définition# \n
Cette fonction tente d’importer un module
\nadmindans chaque application installée. Ces modules sont supposés inscrire des modèles à l’application d’administration.Typiquement, il n’est pas nécessaire d’appeler cette fonction directement car
\nAdminConfigl’appelle au démarrage de Django.
Si vous utilisez un AdminSite personnalisé, il est courant d’importer toutes les sous-classes de ModelAdmin dans son code et de les inscrire auprès du site AdminSite personnalisé. Dans ce cas et dans l’optique de désactiver la découverte automatique, il s’agit de remplacer 'django.contrib.admin' par 'django.contrib.admin.apps.SimpleAdminConfig' dans le réglage INSTALLED_APPS.
Options de ModelAdminLien vers cette rubrique#
\nModelAdmin est une classe très flexible. Elle dispose de plusieurs options pour pouvoir personnaliser l’interface. Toutes les options sont définies sur la sous-classe ModelAdmin:
from django.contrib import admin\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n date_hierarchy = "pub_date"\n- \n
- \nModelAdmin.actionsLien vers cette définition# \n
Une liste d’actions disponibles sur la page de liste pour modification. Voir Actions d’administration pour plus de détails.
\n
- \n
- \nModelAdmin.actions_on_topLien vers cette définition# \n
- \n
- \nModelAdmin.actions_on_bottomLien vers cette définition# \n
Contrôle où s’affiche la barre d’actions sur la page. Par défaut, la page de liste pour modification de l’administration affiche les actions en haut de la page (
\nactions_on_top = True; actions_on_bottom = False).
- \n
- \nModelAdmin.actions_selection_counterLien vers cette définition# \n
Contrôle si un compteur de sélection est affiché à côté de la liste déroulante d’actions. Par défaut, la page de liste pour modification de l’administration l’affichera (
\nactions_selection_counter = True).
- \n
- \nModelAdmin.date_hierarchyLien vers cette définition# \n
Attribuez à
\ndate_hierarchyle nom d’un champDateFieldouDateTimeFieldde votre modèle, et la page de liste pour modification inclura une navigation par filtres sélectifs basés sur les dates en fonction de ce champ.Exemple :
\n\ndate_hierarchy = "pub_date"\nIl est aussi possible d’indiquer un champ d’un modèle lié en utilisant la syntaxe d’accès
\n__, par exemple :\ndate_hierarchy = "author__pub_date"\nLe contenu de cette navigation est formé intelligemment d’après les données disponibles. Par exemple, si toutes les dates sont dans un seul mois, elle contiendra uniquement les filtres par jour.
\n\n
- \n
- \nModelAdmin.empty_value_displayLien vers cette définition# \n
Cet attribut surcharge la valeur d’affichage par défaut pour les champs de l’enregistrement qui sont vides (
\nNone, chaîne vide, etc.). La valeur par défaut est-(un tiret). Par exemple :\nfrom django.contrib import admin\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n empty_value_display = "-empty-"\nVous pouvez aussi surcharger
\nempty_value_displaypour toutes les pages d’administration avecAdminSite.empty_value_display, ou pour des champs spécifiques comme ceci :\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.excludeLien vers cette définition# \n
Cet attribut, si fourni, doit être une liste de noms de champs à exclure du formulaire.
\nPar exemple, considérons le modèle suivant :
\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)\nSi vous souhaitez un formulaire pour le modèle
\nAuthorqui ne comprenne que les champsnameettitle, voici comment vous devez spécifierfieldsouexclude:\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"]\nComme le modèle
\nAuthora seulement trois champs,name,titleetbirth_date, les formulaires obtenus par les déclarations ci-dessus contiendront exactement les mêmes champs.
- \n
- \nModelAdmin.fieldsLien vers cette définition# \n
Utilisez l’option
\nfieldssi vous avez besoin de réaliser de simples changements dans la disposition des formulaires des pages « ajouter » et « modifier », comme afficher uniquement un sous-ensemble des champs disponibles, modifier leur ordre ou les regrouper en lignes. Par exemple, vous pouvez définir une version simplifiée du formulaire d’administration pour le modèledjango.contrib.flatpages.models.FlatPagecomme suit :\nclass FlatPageAdmin(admin.ModelAdmin):\n fields = ["url", "title", "content"]\nDans l’exemple ci-dessus, seuls les champs
\nurl,titleetcontentseront affichés dans le formulaire, de manière séquentielle.fieldspeut contenir des valeurs définies dansModelAdmin.readonly_fieldspour être affichées en lecture seule.Pour des besoins de mise en page plus complexes, voir l’option
\nfieldsets.L’option
\nfieldsaccepte les mêmes types de valeurs quelist_display, sauf que les objets exécutables et les accès aux champs liés par__ne sont pas admis. Les noms de méthodes de modèles ou de modèles d’administration ne sont utilisés que s’ils apparaissent dansreadonly_fields.Pour afficher plusieurs champs sur la même ligne, insérez ces champs dans leur propre tuple. Dans cet exemple, les champs
\nurlettitles’affichent sur la même ligne et le champcontentsera affiché en dessous d’eux sur sa propre ligne :\n\nclass FlatPageAdmin(admin.ModelAdmin):\n fields = [("url", "title"), "content"]\nSi ni l’option
\nfields, ni l’optionfieldsetsne sont présentes, Django affiche par défaut chaque champ qui n’est pas unAutoFieldet qui aeditable=Truedans un groupe de champs unique et dans le même ordre de définition des champs que dans le modèle, suivis par les champs définis dansreadonly_fields, s’il y en a.
- \n
- \nModelAdmin.fieldsetsLien vers cette définition# \n
Définissez
\nfieldsetspour contrôler la mise en page des pages d’administration « ajouter » et « modifier ».
\nfieldsetsest une liste de tuples binaires, où chaque tuple représente une balise<fieldset>dans la page du formulaire d’administration (<fieldset>est une « section » d’un formulaire).Les tuples binaires sont au format
\n(nom, options_champs), oùnomest une chaîne représentant le titre du groupe de champs etoptions_champsest un dictionnaire d’informations sur le groupe de champs, y compris une liste des champs à afficher à l’intérieur.Un exemple complet, tiré du modèle
\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 ]\nIl en résulte une page d’administration qui ressemble à :
\n![\"/fr/5.2/_images/fieldsets.png\"](\"/fr/5.2/_images/fieldsets.png\")
\nSi ni l’option
\nfieldsets, ni l’optionfieldsne sont présentes, Django affiche par défaut chaque champ qui n’est pas unAutoFieldet qui aeditable=Truedans un groupe de champs unique et dans le même ordre de définition des champs que dans le modèle.Le dictionnaire
\nfield_optionspeut contenir les clés suivantes :- \n
- \n
fieldsUne liste ou un tuple de noms de champs à afficher dans ce groupe de champs. Cette clé est obligatoire.
\nExemple :
\n\n{\n "fields": ["first_name", "last_name", "address", "city", "state"],\n}\nComme pour l’option
\nfields, on peut afficher plusieurs champs sur la même ligne en les incluant dans un tuple. Dans cet exemple, les champsfirst_nameetlast_names’affichent sur la même ligne :\n{\n "fields": [("first_name", "last_name"), "address", "city", "state"],\n}\n
\nfieldspeut contenir des valeurs définies dansreadonly_fieldspour être affichées en lecture seule.Si vous placez le nom d’un objet exécutable dans
\nfields, c’est la même règle qu’avec l’optionfieldsqui s’applique : l’objet exécutable doit figurer dansreadonly_fields. \n
\n- \n
classesUne liste ou un tuple contenant du CSS supplémentaire à appliquer au groupe de champs. Cela peut inclure toute classe CSS personnalisée définie au niveau du projet, aussi bien que des classes CSS fournies par Django. Dans la feuille de style CSS par défaut du site d’administration, deux classes particulièrement utiles sont définies :
\ncollapseetwide.Exemple :
\n\n{\n "classes": ["wide", "collapse"],\n}\nLes groupes de champs avec le style
\n\nwidereçoivent de l’espace horizontal supplémentaire dans l’interface d’administration. Les groupes de champs nommés et ayant le stylecollapsesont initialement condensés, et présentent un composant d’extension avec un symbole pour inverser leur visibilité. \n
\n- \n
descriptionUne chaîne de texte facultative à afficher en plus au sommet de chaque groupe de champs, sous l’en-tête du groupe.
\nNotez que cette valeur ne passe pas par le filtre d’échappement HTML quand elle est affichée dans l’interface d’administration. Cela vous permet d’inclure du code HTML si vous le désirez. Sinon, vous pouvez utiliser du texte brut avec la fonction
\ndjango.utils.html.escape()pour échapper les caractères spéciaux HTML. \n
\n
- \n
- \nModelAdmin.filter_horizontalLien vers cette définition# \n
Par défaut, un champ
\nManyToManyFieldest affiché dans le site d’administration avec un<select multiple>. Cependant, les boîtes à sélection multiple peuvent être difficiles à utiliser lors de la sélection de nombreux éléments. En ajoutant un champManyToManyFieldà cette liste, cette boîte sera remplacée par une discrète et astucieuse interface de « filtre » JavaScript permettant de rechercher dans les options. Les options non sélectionnés et sélectionnés apparaissent dans deux boîtes côte à côte. Voirfilter_verticalpour utiliser une interface verticale.
- \n
- \nModelAdmin.filter_verticalLien vers cette définition# \n
Identique à
\nfilter_horizontal, mais utilise un affichage vertical de l’interface de filtre avec la boîte d’options non sélectionnées apparaissant au-dessus de la boîte d’options sélectionnées.
- \n
- \nModelAdmin.formLien vers cette définition# \n
Par défaut, un formulaire
\nModelFormest créé dynamiquement pour les modèles. Il est utilisé pour créer le formulaire présenté sur les pages d’ajout/édition. Vous pouvez facilement fournir votre propreModelFormpour surcharger toute forme de comportement par défaut sur les pages d’ajout/édition. Alternativement, vous pouvez personnaliser le formulaire par défaut plutôt que d’en définir un entièrement nouveau en utilisant la méthodeModelAdmin.get_form().Pour un exemple, voir la section Ajout de validation personnalisée à l’administration.
\n\n\n
- \n
- \nModelAdmin.formfield_overridesLien vers cette définition# \n
Cet attribut fournit une solution « à la va-vite » pour surcharger une partie des options
\nFieldutilisées dans l’interface d’administration.formfield_overridesest un dictionnaire associant une classe de champ à un dictionnaire de paramètres à passer audit champ au moment de sa construction.Comme c’est un peu abstrait, examinons un exemple concret. L’utilisation la plus courante de
\nformfield_overridesest d’ajouter un composant personnalisé pour un certain type de champ. Ainsi, imaginons que nous avons écrit un composantRichTextEditorWidgetque nous aimerions utiliser pour les champs de texte étendus en lieu et place du<textarea>par défaut . Voici comment nous pourrions le faire :\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 }\nNotez que la clé dans le dictionnaire est la véritable classe du champ, et non pas une chaîne. La valeur est un autre dictionnaire ; ces paramètres seront passés à la méthode
\n\n__init__()du champ de formulaire. Voir L’API des formulaires pour plus de détails.
- \n
- \nModelAdmin.inlinesLien vers cette définition# \n
Voir les objets
\nInlineModelAdminci-dessous ainsi queModelAdmin.get_formsets_with_inlines().
- \n
- \nModelAdmin.list_displayLien vers cette définition# \n
Définissez
\nlist_displaypour contrôler quels champs sont affichés sur la page de liste pour modification de l’interface d’administration.Exemple :
\n\nlist_display = ["first_name", "last_name"]\nSi
\nlist_displayn’est pas défini, le site d’administration affichera une seule colonne avec la représentation__str__()de chaque objet.Il y a cinq types de valeurs qui peuvent être utilisées dans
\nlist_display. Excepté pour la première méthode, il est possible d’utiliser le décorateurdisplay()pour personnaliser la façon dont le champ est présenté :- \n
Le nom d’un champ de modèle. Par exemple :
\n\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["first_name", "last_name"]\n\nLe nom d’un champ de modèle lié, en utilisant la notation
\n__. Par exemple :\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["city__name"]\n\nUn objet exécutable qui accepte un paramètre, l’instance de modèle. Par exemple :
\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\nUne chaîne représentant une méthode de
\nModelAdminacceptant un paramètre, l’instance de modèle. Par exemple :\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\nUne chaîne représentant un attribut ou une méthode de modèle (sans paramètre obligatoire). Par exemple :
\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
Quelques cas particuliers à signaler à propos de
\nlist_display:- \n
Si ce champ est une clé
ForeignKey, Django affichera le__str__()de l’objet correspondant. \nLes champs
ManyToManyFieldne sont pas pris en charge, parce que cela impliquerait l’exécution d’une instruction SQL pour chaque ligne de la table. Si vous voulez néanmoins le faire, donnez à votre modèle une méthode personnalisée, et ajouter le nom de cette méthode àlist_display. (Voir ci-dessous pour en savoir plus sur les méthodes personnalisées danslist_display.) \nSi le champ est un
BooleanField, Django affiche une jolie icône « Oui », « Non », « Inconnu » au lieu des valeursTrue,FalseouNone. \nSi la chaîne donnée est une méthode du modèle, un
\nModelAdminou un objet exécutable, Django échappe par défaut le résultat HTML obtenu. Pour échapper les données fournies par l’utilisateur et autoriser vos propres balises non échappées, utilisezformat_html().Voici un exemple complet de modèle :
\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\nComme certains exemples l’ont déjà montré, lorsqu’on fait référence à un objet exécutable, une méthode de modèle ou de
ModelAdmin, il est possible de personnaliser le titre de la colonne en enveloppant l’exécutable dans le décorateurdisplay()et en lui passant l’argumentdescription. \nSi la valeur d’un champ est
\nNone, une chaîne vide ou une itération vide, Django affichera-(un tiret). Vous pouvez surcharger cela avecAdminSite.empty_value_display:\nfrom django.contrib import admin\n\nadmin.site.empty_value_display = "(None)"\nVous pouvez aussi utiliser
\nModelAdmin.empty_value_display:\nclass PersonAdmin(admin.ModelAdmin):\n empty_value_display = "unknown"\nOu au niveau d’un champ :
\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\nSi la chaîne donnée est une méthode du modèle, un
\nModelAdminou un objet exécutable qui renvoieTrue,FalseouNone, Django affiche une jolie icône « Oui », « Non », « Inconnu » si vous enveloppez la méthode dans le décorateurdisplay()en lui passant l’argumentbooleanavec la valeurTrue:\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\nLa méthode
\n__str__()est tout aussi valable pourlist_displayque pour toute autre méthode de modèle, il est donc tout à fait correct d’écrire :\nlist_display = ["__str__", "some_other_field"]\n\nHabituellement, les éléments de
\nlist_displayqui ne sont pas de véritables champs de base de données ne peuvent pas être utilisés dans le tri (parce que Django réalise tout le tri au niveau de la base de données).Cependant, si un élément de
\nlist_displayreprésente un certain champ de base de données, vous pouvez indiquer ce fait en appliquant le décorateurdisplay()à la méthode et en lui passant l’argumentordering:\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"]\nCe qui précède indique à Django de trier selon le champ
\nfirst_namelorsqu’on essaye de trier parcolored_first_namedans l’administration.Pour indiquer un ordre décroissant avec l’argument
\nordering, vous pouvez préfixer le nom de champ par un tiret. En utilisant l’exemple ci-dessus, cela ressemblerait à :\n@admin.display(ordering="-first_name")\ndef colored_first_name(self): ...\nL’argument
\norderingsait gérer les requêtes triées par valeurs de modèles liés. Cet exemple inclut une colonne « author first name » dans l’affichage en liste et permet de le trier en fonction du prénom (first name) :\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\nLes expressions de requête peuvent être utilisées dans l’argument
\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\nLes éléments de
\nlist_displaypeuvent aussi être des propriétés\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"]\nNotez que
\n@propertydoit figurer avant@display. Si vous utilisez l’ancienne pratique en définissant les attributs d’affichage directement plutôt que par l’intermédiaire du décorateurdisplay(), vous devez savoir que vous devez utiliser la fonctionproperty()et non pas le décorateur@property:\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\nLes noms de champs dans
list_displayapparaissent également comme des classes CSS dans le résultat HTML, sous la formecolonne-<nom_de_champ>sur chaque élément<th>. Cela peut être utilisé par exemple pour définir la largeur des colonnes dans un fichier CSS. \nDjango essaie d’interpréter chaque élément de
\nlist_displaydans cet ordre :- \n
Un champ du modèle ou un champ d’un modèle lié.
\nUn objet exécutable.
\nUne chaîne représentant un attribut
ModelAdmin. \nUne chaîne représentant un attribut de modèle.
\n
Par exemple, si
\nfirst_nameest à la fois un champ de modèle et un attributModelAdmin, c’est le champ de modèle qui sera utilisé. \n
- \n
- \nModelAdmin.list_display_linksLien vers cette définition# \n
Utilisez
\nlist_display_linkspour contrôler le cas échéant quels champs delist_displaydoivent faire le lien vers la page de modification d’un objet.Par défaut, la page de liste pour modification lie la première colonne – le premier champ figurant dans
\nlist_display– à la page de modification de chaque élément. Maislist_display_linkspermet de modifier cela :- \n
Définissez-le à
Nonepour qu’aucun lien n’apparaisse. \nDéfinissez-le à une liste ou un tuple de champs (dans le même format que
\nlist_display) dont les colonnes doivent être converties en liens.Vous pouvez indiquer un ou plusieurs champs. Tant que les champs apparaissent dans
\nlist_display, Django ne se soucie pas de combien (ou comment) les champs sont liés. La seule exigence est que si vous souhaitez utiliserlist_display_linksde cette façon, vous devez définirlist_display. \n
Dans cet exemple, les champs
\nfirst_nameetlast_nameferont toutes deux office de lien sur la page de liste pour modification :\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["first_name", "last_name", "birthday"]\n list_display_links = ["first_name", "last_name"]\nDans cet exemple, la page de liste pour modification ne contient aucun lien :
\n\nclass AuditEntryAdmin(admin.ModelAdmin):\n list_display = ["timestamp", "message"]\n list_display_links = None\n
- \n
- \nModelAdmin.list_editableLien vers cette définition# \n
Définissez
\n\nlist_editableà une liste de noms de champs de modèle afin de permettre l’édition de ces champs sur la page de liste pour modification. C’est-à-dire que les champs répertoriés danslist_editableseront affichés sous forme de composants de formulaire sur la page de liste pour modification, permettant aux utilisateurs de modifier et d’enregistrer plusieurs lignes à la fois.
- \n
- \nModelAdmin.list_filterLien vers cette définition# \n
Définissez
\nlist_filterpour activer des filtres dans la barre de droite de la page de liste pour modification de l’administration.L’usage le plus simple de
\nlist_filterest d’indiquer une liste ou un tuple de noms de champs pour lesquels activer le filtrage, mais il existe aussi plusieurs autres options avancées. Voir Filtres de listes ModelAdmin pour plus de détails.
- \n
- \nModelAdmin.list_max_show_allLien vers cette définition# \n
Définissez
\nlist_max_show_allpour contrôler le nombre d’éléments pouvant figurer sur la page de liste pour modification « Tout afficher » de l’administration. L’administration affiche un lien « Tout afficher » sur la liste pour modification seulement si le nombre total de résultats est inférieur ou égal à la valeur de cet attribut. Par défaut, cette option est définie à200.
- \n
- \nModelAdmin.list_per_pageLien vers cette définition# \n
Définissez
\nlist_per_pagepour contrôler le nombre d’éléments paginés apparaissant sur chaque page de la liste pour modification de l’administration. Par défaut, cette option est définie à100.
- \n\n
Définissez
\nlist_select_relatedpour indiquer à Django d’utiliserselect_related()lors de la récupération de la liste des objets sur la page de liste pour modification de l’administration. Cela peut vous épargner un bon nombre de requêtes en base de données.La valeur peut être soit une valeur booléenne, soit une liste ou un tuple. La valeur par défaut est
\nFalse.Lorsque la valeur est
\nTrue,select_related()sera toujours appelée. Lorsque la valeur est réglée surFalse, Django examinelist_displayet n’appelleselect_related()que si une cléForeignKeyest présente.Si vous avez besoin d’un contrôle plus fin, utilisez un tuple (ou une liste) comme valeur de
\nlist_select_related. Un tuple vide empêchera Django d’appelerselect_relateddans tous les cas. Tout autre tuple sera directement transmis àselect_relatedcomme paramètres. Par exemple :\nclass ArticleAdmin(admin.ModelAdmin):\n list_select_related = ["author", "category"]\nappellera
\nselect_related('author', 'category').Si vous avez besoin de définir une valeur dynamique en fonction de la requête, vous pouvez implémenter une méthode
\n\nget_list_select_related().
- \n
- \nModelAdmin.orderingLien vers cette définition# \n
Définissez
\norderingpour préciser comment les listes d’objets doivent être ordonnées dans les vues d’administration de Django. La valeur doit être une liste ou un tuple dans le même format que le paramètre de modèleordering.Si ce paramètre n’est pas renseigné, l’administration de Django utilise l’ordre de tri par défaut du modèle.
\nSi vous avez besoin de définir un ordre dynamique (par exemple en fonction de l’utilisateur ou de la langue), vous pouvez implémenter une méthode
\n\nget_ordering().
- \n
- \nModelAdmin.paginatorLien vers cette définition# \n
La classe de pagination à utiliser pour la pagination. Par défaut,
\ndjango.core.paginator.Paginatorest utilisée. Si la classe de pagination personnalisée n’a pas la même interface de constructeur quedjango.core.paginator.Paginator, vous devez également fournir une implémentation pourModelAdmin.get_paginator().
- \n
- \nModelAdmin.prepopulated_fieldsLien vers cette définition# \n
Définissez
\nprepopulated_fieldsà un dictionnaire associant des noms de champs aux champs à partir desquels ils doivent être pré-remplis :\nclass ArticleAdmin(admin.ModelAdmin):\n prepopulated_fields = {"slug": ["title"]}\nLorsque cet attribut est défini, lesdits champs utiliseront un peu de JavaScript pour se pré-remplir à partir des champs désignés. L’utilisation principale de cette fonctionnalité est de générer automatiquement la valeur des champs
\nSlugFieldà partir d’un ou plusieurs autres champs. La valeur générée est produite par la concaténation des valeurs des champs source, puis par transformation de ce résultat en une étiquette courte et valide, le « slug » (par ex. le remplacement des espaces par des tirets et la mise en minuscules des lettres ASCII).Les champs préremplis ne sont pas modifiés par JavaScript après qu’une valeur a été enregistrée. Il n’est généralement pas souhaitable que les « slugs » changent (ce qui provoquerait le changement de l’URL de l’objet si le slug en fait partie).
\n
\nprepopulated_fieldsn’accepte pas les champsDateTimeField,ForeignKey,OneToOneFieldouManyToManyField.
- \n
- \nModelAdmin.preserve_filtersLien vers cette définition# \n
Par défaut, les filtres appliqués sur la vue de liste après la création, l’édition ou la suppression d’un objet sont préservés. Vous pouvez forcer la réinitialisation des filtres en définissant cet attribut à
\nFalse.
- \n
- \nModelAdmin.show_facetsLien vers cette définition# \n
Contrôle l’affichage ou non des nombres des facettes pour les filtres dans la liste pour modifications du site d’administration. Contient pas défaut
\nShowFacets.ALLOW.Lorsqu’ils sont affichés, les nombres des facettes se mettent à jour en fonction des filtres actuellement appliqués.
\n- \n
- \nclass ShowFacetsLien vers cette définition# \n
Classe d’énumération des valeurs autorisées pour
\nModelAdmin.show_facets.- \n
- \nALWAYSLien vers cette définition# \n
Affiche toujours les nombres des facettes.
\n
- \n
- \nALLOWLien vers cette définition# \n
Affiche les nombres des facettes lorsque le paramètre de chaîne de requête
\n_facetsest indiqué.
- \n
- \nNEVERLien vers cette définition# \n
N’affiche jamais les nombres des facettes.
\n
Définissez show_facets` à la valeur souhaitée de
\nShowFacets. Par exemple, pour toujours afficher les nombres des facettes sans avoir besoin d’indiquer quoi que ce soit dans les paramètres de requête :\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_fieldsLien vers cette définition# \n
Par défaut, l’interface d’administration de Django utilise une interface de boîte de sélection (<select>) pour les champs
\nForeignKeyou ceux qui ont un attributchoicesdéfini. Si un champ est présent dansradio_fields, Django utilise plutôt une interface de type boutons-radio. En supposant quegroupest une cléForeignKeysur le modèlePerson:\nclass PersonAdmin(admin.ModelAdmin):\n radio_fields = {"group": admin.VERTICAL}\nVous avez le choix d’utiliser
\nHORIZONTALouVERTICALdu moduledjango.contrib.admin.N’incluez un champ dans
\nradio_fieldsque s’il s’agit d’un champForeignKeyou que son attributchoicesest défini.
- \n
- \nModelAdmin.autocomplete_fieldsLien vers cette définition# \n
\nautocomplete_fieldsest une liste de champsForeignKeyet/ouManyToManyFieldque vous souhaitez transformer en composants auto-complétés Select2.Par défaut, l’interface d’administration utilise une interface de boîte de sélection (
\n<select>) pour ces champs. Parfois, vous ne voulez pas subir la lenteur engendrée par la sélection de toutes les instances liées pour l’affichage dans la liste déroulante.Le composant Select2 ressemble à la liste déroulante par défaut mais apporte une fonction de recherche qui charge les options de manière asynchrone. C’est plus rapide et plus intuitif dans les cas où le modèle lié possède de nombreuses instances.
\nVous devez définir
\nsearch_fieldsdans la classeModelAdminde l’objet lié dans la mesure où la recherche d’auto-complétion l’utilise.Pour empêcher la divulgation non autorisée de données, les utilisateurs doivent posséder la permission d’affichage ou de modification sur l’objet lié pour pouvoir utiliser l’autocomplétion.
\nLe tri et la pagination des résultats sont contrôlés par les méthodes
\nget_ordering()etget_paginator()duModelAdminlié correspondant.Dans l’exemple suivant,
\nChoiceAdminpossède un champ auto-complété pour la cléForeignKeyversQuestion. Les résultats sont filtrés par le champquestion_textet triés par le champdate_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_fieldsLien vers cette définition# \n
Par défaut, l’interface d’administration de Django utilise une interface de boîte de sélection (<select>) pour les champs
\nForeignKey. Parfois, vous ne voulez pas subir la lenteur engendrée par la sélection de toutes les instances liées pour l’affichage dans la liste déroulante.
\nraw_id_fieldsest une liste de champs que vous souhaitez modifier par un simple composantInput, que ce soit un champForeignKeyouManyToManyField:\nclass ArticleAdmin(admin.ModelAdmin):\n raw_id_fields = ["newspaper"]\nLe composant
\nInputderaw_id_fieldsdoit contenir une clé primaire si le champ est une cléForeignKeyou une liste de valeurs séparées par des virgules si le champ est unManyToManyField. Le composantraw_id_fieldsprésente un bouton en forme de loupe à côté du champ permettant aux utilisateurs de rechercher et de sélectionner une valeur :![\"/fr/5.2/_images/raw_id_fields.png\"](\"/fr/5.2/_images/raw_id_fields.png\")
\n
- \n
- \nModelAdmin.readonly_fieldsLien vers cette définition# \n
Par défaut, l’interface d’administration affiche tous les champs de manière éditable. Tous les champs présents dans cette option (qui doit être une liste ou un tuple) afficheront leurs données en l’état et seront non modifiables ; ils seront également exclus du formulaire
\nModelFormutilisé pour la création et l’édition. Notez que lorsque vous renseignezModelAdmin.fieldsouModelAdmin.fieldsets, les champs en lecture seule doivent être présents si vous voulez qu’ils apparaissent (sinon, ils sont ignorés).Si
\nreadonly_fieldsest utilisé sans ordre explicite défini parModelAdmin.fieldsouModelAdmin.fieldsets, ils seront ajoutés en dernier après tous les champs modifiables.Un champ en lecture seule n’est pas limité à l’affichage des données d’un champ de modèle, il peut également afficher le résultat d’une méthode de modèle ou d’une méthode de la classe
\nModelAdmin. C’est très similaire à la façon dontModelAdmin.list_displayfonctionne. Cela fournit un moyen pour faire présenter à l’interface d’administration des informations sur l’état des objets en cours d’édition, par exemple :\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_asLien vers cette définition# \n
Définissez
\nsave_aspour activer la fonctionnalité « enregistrer comme nouveau » des formulaires d’édition de l’administration.Normalement, les objets ont trois options d’enregistrement : « Enregistrer », « Enregistrer et continuer les modifications » et « Enregistrer et ajouter un nouveau ». Si
\nsave_asvautTrue, « Enregistrer et ajouter un nouveau » est remplacé par un bouton « Enregistrer comme nouveau » qui crée un nouvel objet (avec un nouvel identifiant) plutôt que de mettre à jour l’objet existant.Par défaut,
\nsave_asest défini àFalse.
- \n
- \nModelAdmin.save_as_continueLien vers cette définition# \n
Lorsque
\nsave_as=True, la redirection par défaut après l’enregistrement du nouvel objet se fait vers la vue pour modification de cet objet. Si vous définissezsave_as_continue=False, la redirection se fera vers la vue de liste pour modification.Par défaut,
\nsave_as_continueest défini àTrue.
- \n
- \nModelAdmin.save_on_topLien vers cette définition# \n
Définissez
\nsave_on_toppour ajouter les boutons d’enregistrement au sommet des formulaires d’édition de l’administration.Normalement, les boutons d’enregistrement apparaissent uniquement au bas des formulaires. Si vous définissez
\nsave_on_top, les boutons apparaîtront à la fois en haut et en bas.Par défaut,
\nsave_on_topest défini àFalse.
- \n
- \nModelAdmin.search_fieldsLien vers cette définition# \n
Définissez
\nsearch_fieldspour activer une boîte de recherche sur la page de liste pour édition de l’administration. Cet attribut doit contenir une liste de noms de champs qui seront recherchés chaque fois que quelqu’un soumet une requête de recherche dans cette zone de texte.Ces champs doivent être de type texte, tel que
\nCharFieldouTextField. Vous pouvez également effectuer une recherche connexe sur une cléForeignKeyou un champManyToManyFieldavec la notation « relationnelle » de l’API de recherche :\nsearch_fields = ["foreign_key__related_fieldname"]\nPar exemple, si une entrée de blog contient un auteur, la définition suivante permettrait de rechercher les entrées du blog selon l’adresse électronique de l’auteur :
\n\nsearch_fields = ["user__email"]\nLorsque quelqu’un effectue une recherche via la boîte de recherche de l’administration, Django divise la requête de recherche en mots et renvoie tous les objets qui contiennent tous les mots, insensibles à la casse (en utilisant la recherche
\nicontains), où chaque mot doit être dans au moins un des champssearch_fields. Par exemple, sisearch_fieldsest défini à['first_name', 'last_name']et qu’un utilisateur recherchejohn lennon, Django exécutera l’équivalent de cette clause SQLWHERE:\nWHERE (first_name ILIKE '%john%' OR last_name ILIKE '%john%')\nAND (first_name ILIKE '%lennon%' OR last_name ILIKE '%lennon%')\nLa requête de recherche peut contenir des phrases entre guillemets (anglais). Par exemple, si quelqu’un recherche
\n"john winston"ou'john winston', Django produit une requête équivalente à cette clause SQLWHERE:\nWHERE (first_name ILIKE '%john winston%' OR last_name ILIKE '%john winston%')\nSi vous ne souhaitez pas utiliser la recherche
\nicontains, vous pouvez forcer une autre recherche en l’ajoutant à la suite du champ. Par exemple, il est possible d’utiliserexacten définissantsearch_fieldsà['first_name__exact'].Certains (anciens) raccourcis pour l’indication de recherche de champ sont aussi disponibles. Vous pouvez préfixer un champ de
\nsearch_fieldspar les caractères suivants qui sont équivalents à l’ajout de__<recherche>à la suite du champ :\n\n\n
\nPréfixe
Requête
^
\n =
\n @
\n Aucun(e)
\n Si vous avez besoin de personnaliser la recherche, vous pouvez utiliser
\nModelAdmin.get_search_results()pour fournir un comportement de recherche supplémentaire ou différent.
- \n
- \nModelAdmin.search_help_textLien vers cette définition# \n
Définissez
\nsearch_help_textpour indiquer un texte descriptif pour la boîte de recherche et qui sera affiché au-dessous d’elle.
- \n
- \nModelAdmin.show_full_result_countLien vers cette définition# \n
Définissez
\nshow_full_result_countpour définir si le nombre total d’objets doit être affiché sur une page d’administration filtrée (par exemple99 résultats (103 au total)). Si cette option est définie àFalse, un texte du style99 résultats (tout afficher)s’affiche à la place.La valeur par défaut
\nshow_full_result_count=Truegénère une requête pour connaître le nombre total d’objets de la table, ce qui peut être coûteux si la table contient un grand nombre de lignes.
- \n
- \nModelAdmin.sortable_byLien vers cette définition# \n
Par défaut, la page de liste pour modification autorise le tri selon tous les champs de modèles (et les objets exécutables utilisant l’argument
\norderingdu décorateurdisplay()ou ayant l’attributadmin_order_field) indiqués danslist_display.Si vous souhaitez désactiver le tri pour certaines colonnes, définissez
\nsortable_byà une collection (par ex.list,tupleouset) sous-ensemble delist_displayqui sont susceptibles d’être triés. Une collection vide désactive le tri pour toutes les colonnes.Si vous avez besoin de définir cette liste dynamiquement, vous pouvez implémenter une méthode
\nget_sortable_by().
- \n
- \nModelAdmin.view_on_siteLien vers cette définition# \n
Définissez
\nview_on_sitepour contrôler l’affichage du lien « Voir sur le site ». Ce lien est censé diriger vers une URL où l’objet enregistré peut être affiché.Cet attribut peut soit être une valeur booléenne, soit un objet exécutable. Quand il vaut
\nTrue(par défaut), la méthodeget_absolute_url()de l’objet est utilisée pour générer l’URL.Si un modèle possède une méthode
\nget_absolute_url()mais que vous ne souhaitez pas faire apparaître le bouton « Voir sur le site », il suffit de définirview_on_siteàFalse:\nfrom django.contrib import admin\n\n\nclass PersonAdmin(admin.ModelAdmin):\n view_on_site = False\nDans le cas où il s’agit d’un objet exécutable, celui-ci accepte une instance de modèle en paramètre. Par exemple :
\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
Options de gabarit personnaliséesLien vers cette rubrique#
\nLa section Redéfinition des gabarits d’administration décrit comment surcharger ou étendre les gabarits d’administration par défaut. Utilisez les options suivantes pour remplacer les gabarits par défaut utilisés par les vues ModelAdmin:
- \n
- \nModelAdmin.add_form_templateLien vers cette définition# \n
Chemin d’accès vers un gabarit personnalisé, utilisé par
\nadd_view().
- \n
- \nModelAdmin.change_form_templateLien vers cette définition# \n
Chemin d’accès vers un gabarit personnalisé, utilisé par
\nchange_view().
- \n
- \nModelAdmin.change_list_templateLien vers cette définition# \n
Chemin d’accès vers un gabarit personnalisé, utilisé par
\nchangelist_view().
- \n
- \nModelAdmin.delete_confirmation_templateLien vers cette définition# \n
Chemin d’accès vers un gabarit personnalisé, utilisé par
\ndelete_view()pour l’affichage d’une page de confirmation lors de la suppression d’un ou plusieurs objets.
- \n
- \nModelAdmin.delete_selected_confirmation_templateLien vers cette définition# \n
Chemin d’accès vers un gabarit personnalisé, utilisé par la méthode d’action
\ndelete_selectedpour l’affichage d’une page de confirmation lors de la suppression d’un ou plusieurs objets. Voir la documentation des actions.
- \n
- \nModelAdmin.object_history_templateLien vers cette définition# \n
Chemin d’accès vers un gabarit personnalisé, utilisé par
\nhistory_view().
- \n
- \nModelAdmin.popup_response_templateLien vers cette définition# \n
Chemin d’accès vers un gabarit personnalisé, utilisé par
\nresponse_add(),response_change()etresponse_delete().
Méthodes de ModelAdminLien vers cette rubrique#
\n\n- \n
- \nModelAdmin.save_model(request, obj, form, change)Lien vers cette définition# \n
La méthode
\nsave_modelreçoit la requêteHttpRequest, une instance de modèle, une instance deModelFormet une valeur booléenne indiquant si elle ajoute ou modifie l’objet. La surcharge de cette méthode permet d’effectuer des opérations d’avant ou d’après enregistrement. Appelezsuper().save_model()pour enregistrer l’objet avecModel.save().Par exemple, pour lier l’utilisateur
\nrequest.userà l’objet avant d’enregistrer :\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)Lien vers cette définition# \n
La méthode
\ndelete_modelreçoit la requêteHttpRequestet une instance de modèle. La surcharge de cette méthode permet d’effectuer des opérations d’avant ou d’après suppression. Appelezsuper().delete_model()pour supprimer l’objet avecModel.delete().
- \n
- \nModelAdmin.delete_queryset(request, queryset)Lien vers cette définition# \n
La méthode
\ndelete_queryset()reçoit une requêteHttpRequestet un jeuQuerySetd’objets à supprimer. Surchargez cette méthode pour personnaliser le processus de suppression de l’action « Supprimer les objets sélectionnés ».
- \n
- \nModelAdmin.save_formset(request, form, formset, change)Lien vers cette définition# \n
La méthode
\nsave_formsetreçoit la requêteHttpRequest, l’instance parenteModelFormet une valeur booléenne indiquant si elle ajoute ou modifie l’objet parent.Par exemple, pour lier l’utilisateur
\nrequest.userà chaque instance de modèle modifiée dans le formulaire groupé :\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()\nVoir aussi Enregistrement des objets des formulaires groupés.
\n
- \n
- \nModelAdmin.get_ordering(request)Lien vers cette définition# \n
La méthode
\nget_orderingreçoit un paramètrerequestet doit renvoyer un objetlistoutupledéterminant l’ordre de tri de manière similaire à l’attributordering. Par exemple :\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)Lien vers cette définition# \n
La méthode
\nget_search_resultsmodifie la liste des objets affichés en fonction de ceux qui correspondent au terme de recherche fourni. Elle accepte la requête HTTP, un jeu de requête qui applique les filtres courants et le terme de recherche fourni par l’utilisateur. Elle renvoie un tuple contenant un jeu de requête modifié pour appliquer la recherche, ainsi qu’une valeur booléenne indiquant si les résultats peuvent contenir des doublons.L’implémentation par défaut recherche dans les champs figurant dans
\nModelAdmin.search_fields.Cette méthode peut être redéfinie par votre propre méthode de recherche personnalisée. Par exemple, il peut être intéressant de rechercher via un champ nombre entier, ou d’utiliser un outil externe comme Solr ou Haystack. Vous devez déterminer si les changements de jeu de requête mis en œuvre par votre méthode de recherche peuvent présenter des doublons dans les résultats, et le cas échéant, renvoyer
\nTruedans le second élément du tuple renvoyé.Par exemple, pour rechercher par
\nnameetage, vous pourriez écrire :\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\nCette implémentation est plus efficace que
\nsearch_fields = ('name', '=age')qui résulterait dans une comparaison de chaînes pour le champ numérique, par exemple... OR UPPER("polls_choice"."votes"::text) = UPPER('4')avec PostgreSQL.
- \n\n
La méthode
\nsave_relatedreçoit la requêteHttpRequest, l’instance parente duModelForm, la liste des formulaires groupés en ligne et une valeur booléenne indiquant si le parent est ajouté ou modifié. C’est l’endroit pour procéder à des opérations d’avant ou d’après enregistrement sur les objets liés au parent. Notez qu’à ce stade, l’objet parent et son formulaire ont déjà été enregistrés.
- \n
- \nModelAdmin.get_autocomplete_fields(request)Lien vers cette définition# \n
La méthode
\nget_autocomplete_fields()reçoit la requêteHttpRequestet est censée renvoyer unelistoutuplede noms de champs qui seront affichés avec un composant d’auto-complétion, comme décrit ci-dessus dans la sectionModelAdmin.autocomplete_fields.
- \n
- \nModelAdmin.get_readonly_fields(request, obj=None)Lien vers cette définition# \n
La méthode
\nget_readonly_fieldsreçoit la requêteHttpRequestet l’objetobjen cours d’édition (ouNonesur un formulaire d’ajout) ; elle est censée renvoyer un objetlistoutuplede noms de champs qui seront affichés en lecture seule, tel que décrit ci-dessus dans la sectionModelAdmin.readonly_fields.
- \n
- \nModelAdmin.get_prepopulated_fields(request, obj=None)Lien vers cette définition# \n
La méthode
\nget_prepopulated_fieldsreçoit la requêteHttpRequestet l’objetobjen cours d’édition (ouNonesur un formulaire d’ajout) ; elle est censée renvoyer un dictionnaire, tel que décrit ci-dessus dans la sectionModelAdmin.prepopulated_fields.
- \n
- \nModelAdmin.get_list_display(request)Lien vers cette définition# \n
La méthode
\nget_list_displayreçoit la requêteHttpRequestet est censée renvoyer unelistoutuplede noms de champs qui seront affichés sur la vue de liste pour modification, comme décrit ci-dessus dans la sectionModelAdmin.list_display.
- \n
- \nModelAdmin.get_list_display_links(request, list_display)Lien vers cette définition# \n
La méthode
\nget_list_display_linksreçoit la requêteHttpRequestet lalistou letuplerenvoyé parModelAdmin.get_list_display(). Elle est censée renvoyerNoneou unelistou untuplede noms de champs apparaissant dans la page de liste pour modification qui seront liés à la vue d’édition, comme décrit dans la sectionModelAdmin.list_display_links.
- \n
- \nModelAdmin.get_exclude(request, obj=None)Lien vers cette définition# \n
La méthode
\nget_excludereçoit la requêteHttpRequestet l’objetobjen cours d’édition (ouNonepour un formulaire d’ajout) et est censée renvoyer une liste de champs, comme décrit dansModelAdmin.exclude.
- \n
- \nModelAdmin.get_fields(request, obj=None)Lien vers cette définition# \n
La méthode
\nget_fieldsreçoit la requêteHttpRequestet l’objetobjen cours d’édition (ouNonepour un formulaire d’ajout) et est censée renvoyer une liste de champs, comme décrit ci-dessus dans la sectionModelAdmin.fields.
- \n
- \nModelAdmin.get_fieldsets(request, obj=None)Lien vers cette définition# \n
La méthode
\nget_fieldsetsreçoit la requêteHttpRequestet l’objetobjen cours d’édition (ouNonesur un formulaire d’ajout) et est censée renvoyer une liste de tuples binaires, où chaque tuple représente une section<fieldset>sur la page du formulaire d’administration, tel que décrit ci-dessus dans la sectionModelAdmin.fieldsets.
- \n
- \nModelAdmin.get_list_filter(request)Lien vers cette définition# \n
La méthode
\nget_list_filterreçoit la requêteHttpRequestet est censée renvoyer le même genre de séquence que pour l’attributlist_filter.
- \n\n
La méthode
\nget_list_select_relatedreçoit la requêteHttpRequestet est censée renvoyer une valeur booléenne ou une liste comme le faitlist_select_related.
- \n
- \nModelAdmin.get_search_fields(request)Lien vers cette définition# \n
La méthode
\nget_search_fieldsreçoit la requêteHttpRequestet est censée renvoyer le même genre de type de séquence que pour l’attributsearch_fields.
- \n
- \nModelAdmin.get_sortable_by(request)Lien vers cette définition# \n
La méthode
\nget_sortable_by()reçoit la requêteHttpRequestet est censée renvoyer une collection (list,tupleouset) de noms de champs qui pourront être triés sur la page de liste pour modification.Son implémentation par défaut renvoie
\nsortable_bysi celui-ci est défini, sinon il fait appel àget_list_display().Par exemple, pour empêcher le tri d’une ou de plusieurs colonnes
\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)Lien vers cette définition# \n
La méthode
\nget_inline_instancesreçoit la requêteHttpRequestet l’objetobjen cours d’édition (ouNonesur un formulaire d’ajout) et est censée renvoyer un objetlistoutupleformé d’objetsInlineModelAdmin, comme décrit ci-dessous dans la sectionInlineModelAdmin. Par exemple, l’exemple suivant renvoie des sous-formulaires sans le filtrage par défaut basé sur les permissions d’ajout, de modification, de suppression et d’affichage :\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]\nSi vous surchargez cette méthode, assurez-vous que les sous-formulaires renvoyés sont des instances de classes définies dans
\ninlines, sinon vous pouvez vous attendre à recevoir des erreurs « Bad Request » lors de l’ajout d’objets liés.
- \n
- \nModelAdmin.get_inlines(request, obj)Lien vers cette définition# \n
La méthode
\nget_inlinesreçoit la requêteHttpRequestet l’objetobjen cours d’édition (ouNonepour un formulaire d’ajout) et est censée renvoyer un objet itérable de sous-formulaires. Vous pouvez surcharger cette méthode pour ajouter dynamiquement des sous-formulaires en fonction de la requête ou de l’instance de modèle au lieu de les définir dansModelAdmin.inlines.
- \n
- \nModelAdmin.get_urls()Lien vers cette définition# \n
La méthode
\nget_urlssur unModelAdminrenvoie les URL à utiliser pour ceModelAdminde la même manière qu’une configuration d’URL. Par conséquent, vous pouvez les enrichir comme documenté dans Distribution des URL, en enveloppant les vues parAdminSite.admin_view():\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)\nSi vous souhaitez utiliser la disposition d’administration, basez-vous sur
\nadmin/base_site.html:\n\n\n{% extends "admin/base_site.html" %}\n{% block content %}\n...\n{% endblock %}\nSi la page peut être mise en cache, mais que vous voulez quand même effectuer le contrôle d’autorisation, vous pouvez passer un paramètre
\ncacheable=TrueàAdminSite.admin_view():\npath("my_view/", self.admin_site.admin_view(self.my_view, cacheable=True))\nLes vues
\nModelAdminont des attributsmodel_admin. Les autres vuesAdminSiteont des attributsadmin_site.
- \n
- \nModelAdmin.get_form(request, obj=None, **kwargs)Lien vers cette définition# \n
Renvoie une classe
\nModelFormutilisée dans les vues d’ajout et d’édition de l’administration, voiradd_view()etchange_view().L’implémentation de base utilise
\nmodelform_factory()comme sous-classe deform, modifié par des attributs tels quefieldsetexclude. Donc par exemple, si vous vouliez ajouter des champs supplémentaires pour les superutilisateurs, il serait possible d’insérer un formulaire de base différent comme ceci :\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)\nIl est aussi possible de renvoyer directement une classe
\nModelFormpersonnalisée.
- \n
- \nModelAdmin.get_formsets_with_inlines(request, obj=None)Lien vers cette définition# \n
Génère des paires (
\nFormSet,InlineModelAdmin) utilisées dans les vues d’ajout et d’édition de l’administration.Par exemple, si vous souhaitez afficher un sous-formulaire particulier et uniquement dans la vue d’édition, vous pouvez redéfinir
\nget_formsets_with_inlinescomme suit\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)Lien vers cette définition# \n
La méthode
\nformfield_for_foreignkeyd’unModelAdminpermet de surcharger le champ de formulaire par défaut pour un champ de clé étrangère. Par exemple, pour renvoyer un sous-ensemble d’objets de ce champ de clé étrangère en fonction de l’utilisateur :\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)\nCet exemple utilise l’instance
\nHttpRequestpour filtrer le champ de clé étrangèreCarafin de n’afficher que les voitures appartenant à l’instanceUser.Pour des filtres plus complexes, vous pouvez utiliser la méthode
\nModelForm.__init__()pour filtrer en fonction d’uneinstancedu modèle (voir Champs dédiés aux relations). Par exemple\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)Lien vers cette définition# \n
Tout comme la méthode
\nformfield_for_foreignkey, la méthodeformfield_for_manytomanypeut être redéfinie pour modifier le champ de formulaire par défaut d’un champ plusieurs-à-plusieurs. Par exemple, si un propriétaire peut posséder plusieurs voitures et que les voitures peuvent appartenir à plusieurs propriétaires – une relation plusieurs-à-plusieurs – vous pouvez filtrer le champ de clé étrangèreCarpour n’afficher que les voitures appartenant à l’utilisateurUser:\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)Lien vers cette définition# \n
Tout comme les méthodes
\nformfield_for_foreignkeyetformfield_for_manytomany, la méthodeformfield_for_choice_fieldpeut être redéfinie pour modifier le champ de formulaire par défaut pour un champ avec des choix définis. Par exemple, si les choix qui s’offrent à un super-utilisateur doivent être différents de ceux disponibles pour les utilisateurs réguliers, vous pouvez procéder comme suit :\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)Lien vers cette définition# \n
Renvoie la classe
\nChangelistà utiliser pour la liste d’édition. Par défaut, il s’agit de la classedjango.contrib.admin.views.main.ChangeList. En héritant de cette classe, vous pouvez modifier le comportement de la liste d’édition.
- \n
- \nModelAdmin.get_changelist_form(request, **kwargs)Lien vers cette définition# \n
Renvoie une classe
\nModelFormutilisée dans le jeu de formulaires sur la page de liste pour modification. Pour utiliser un formulaire personnalisé, par exemple :\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)Lien vers cette définition# \n
Renvoie une classe ModelFormSet utilisée sur la page de liste pour modification quand
\nlist_editableest utilisé. Pour utiliser un jeu de formulaires personnalisé, par exemple :\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)Lien vers cette définition# \n
Les objets dans la page de liste pour modification de l’interface d’administration peuvent être filtrés par des expressions de recherche depuis la chaîne de requête GET de l’URL. C’est par exemple de cette manière que fonctionne
\nlist_filter. Les expressions de recherche sont similaires à ce qui est utilisé avecQuerySet.filter()(ex. :user__email=user@example.com). Comme les expressions de recherche peuvent être manipulées par l’utilisateur, elles doivent être nettoyées pour éviter l’exposition non autorisée de données.La méthode
\nlookup_allowed()reçoit un chemin de recherche à partir de la chaîne de requête (p. ex.'user__email'`), de la valeur correspondante (p. ex.'user@example.com') et de la requête, et renvoie un booléen indiquant si le filtrage duQuerySetde la page de modification utilisant les paramètres est autorisé. Silookup_allowed()renvoieFalse,DisallowedModelAdminLookup(sous-classe deSuspiciousOperation) est générée.Par défaut,
\nlookup_allowed()permet d’accéder aux champs locaux d’un modèle, aux chemins des champs utilisés danslist_filter(mais pas les chemins deget_list_filter()) et aux expressions de recherches nécessaires pour quelimit_choices_tofonctionne correctement dansraw_id_fields.Surchargez cette méthode pour personnaliser les expressions de recherches autorisées pour votre sous-classe de
\nModelAdmin.
- \n
- \nModelAdmin.has_view_permission(request, obj=None)Lien vers cette définition# \n
Doit renvoyer
\nTruesi l’affichage deobjest autorisé,Falsesinon. SiobjvautNone, la valeurTrueouFalserenvoyée doit indiquer si l’affichage d’objets de ce type est autorisé en général (par ex. le renvoi de la valeurFalsesignifie que l’utilisateur actuel n’est pas autorisé à afficher un objet de ce type).L’implémentation par défaut renvoie
\nTruesi l’utilisateur possède la permission de modification ou d’affichage.
- \n
- \nModelAdmin.has_add_permission(request)Lien vers cette définition# \n
Doit renvoyer
\nTruesi l’ajout d’un objet est autorisé,Falsesinon.
- \n
- \nModelAdmin.has_change_permission(request, obj=None)Lien vers cette définition# \n
Doit renvoyer
\nTruesi l’édition deobjest autorisée,Falsesinon. SiobjvautNone, la valeurTrueouFalserenvoyée doit indiquer si la modification d’objets de ce type est autorisée en général (par ex. le renvoi de la valeurFalsesignifie que l’utilisateur actuel n’est pas autorisé à modifier un objet de ce type).
- \n
- \nModelAdmin.has_delete_permission(request, obj=None)Lien vers cette définition# \n
Doit renvoyer
\nTruesi la suppression deobjest autorisée,Falsesinon. SiobjvautNone, la valeurTrueouFalserenvoyée doit indiquer si la suppression des objets de ce type est autorisée en général (par ex. le renvoi de la valeurFalsesignifie que l’utilisateur actuel n’est pas autorisé à supprimer un objet de ce type).
- \n
- \nModelAdmin.has_module_permission(request)Lien vers cette définition# \n
Devrait renvoyer
\nTruesi le module est affiché sur la page d’accueil de l’administration et que l’accès à la page d’accueil du module est autorisé, ouFalsedans le cas contraire. Utilise par défautUser.has_module_perms(). En surchargeant cette méthode, vous ne limitez pas l’accès aux vues d’affichage, d’ajout, d’édition ou de suppression ; pour cela, utilisezhas_view_permission(),has_add_permission(),has_change_permission()ethas_delete_permission().
- \n
- \nModelAdmin.get_queryset(request)Lien vers cette définition# \n
La méthode
\nget_querysetd’unModelAdminrenvoie un objetQuerySetde toutes les instances de modèle qui peuvent être modifiées par le site d’administration. Un cas d’utilisation de la redéfinition de cette méthode est celui de l’affichage des objets appartenant à l’utilisateur connecté :\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)Lien vers cette définition# \n
Envoie un message à l’utilisateur en utilisant le moteur
\ndjango.contrib.messages. Voir l’exemple de ModelAdmin personnalisé.Les paramètres nommés permettent de modifier le niveau de message, d’ajouter des balises CSS supplémentaires ou d’échouer silencieusement si le moteur
\ncontrib.messagesn’est pas installé. Ces paramètres nommés correspondent à ceux dedjango.contrib.messages.add_message(), voir la documentation de cette fonction pour plus de détails. Une des différences est que le niveau peut être passé comme une chaîne de caractères en plus d’un entier ou d’une constante.
- \n
- \nModelAdmin.get_paginator(request, queryset, per_page, orphans=0, allow_empty_first_page=True)Lien vers cette définition# \n
Renvoie une instance de la pagination à utiliser pour cette vue. Par défaut, c’est une instance de
\npaginatorqui est créée.
- \n
- \nModelAdmin.response_add(request, obj, post_url_continue=None)Lien vers cette définition# \n
Détermine la réponse
\nHttpResponsede l’étapeadd_view().
\nresponse_addest appelée après l’envoi du formulaire d’administration et juste après que l’objet et ses instances liées ont été créés et enregistrés. Vous pouvez la surcharger pour modifier le comportement par défaut à la suite de la création de l’objet.
- \n
- \nModelAdmin.response_change(request, obj)Lien vers cette définition# \n
Détermine la réponse
\nHttpResponsede l’étapechange_view().
\nresponse_changeest appelée après l’envoi du formulaire d’administration et juste après que l’objet et ses instances liées ont été enregistrés. Vous pouvez la surcharger pour modifier le comportement par défaut à la suite de la modification de l’objet.
- \n
- \nModelAdmin.response_delete(request, obj_display, obj_id)Lien vers cette définition# \n
Détermine la réponse
\nHttpResponsede l’étapedelete_view().
\nresponse_deleteest appelée après la suppression de l’objet. Vous pouvez la surcharger pour modifier le comportement par défaut à la suite de la suppression de l’objet.
\nobj_displayest une chaîne contenant le nom de l’objet supprimé.
\nobj_idest l’identifiant sérialisé utiliser pour récupérer l’objet à supprimer.
- \n
- \nModelAdmin.get_formset_kwargs(request, obj, inline, prefix)Lien vers cette définition# \n
Un point d’entrée pour personnaliser les arguments mots-clés transmis au constructeur d’un jeu de formulaires. Par exemple, pour passer
\nrequestaux formulaires d’un jeu de formulaires\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 }\nVous pouvez aussi l’utiliser pour définir
\ninitialdes formulaires du jeu de formulaires.
- \n
- \nModelAdmin.get_changeform_initial_data(request)Lien vers cette définition# \n
Un point d’extension pour les données initiales pour les formulaires de modification dans l’administration. Par défaut, les champs reçoivent des valeurs initiales à partir des paramètres
\nGET. Par exemple,?name=initial_valuedéfinit la valeur initiale du champnameàinitial_value.Cette méthode doit renvoyer un dictionnaire sous la forme
\n{'nom_de_champ': 'valeur_de_champ'}:\ndef get_changeform_initial_data(self, request):\n return {"name": "custom_initial_value"}\n
- \n
- \nModelAdmin.get_deleted_objects(objs, request)Lien vers cette définition# \n
Un point d’entrée pour personnaliser le processus de suppression de la vue
\ndelete_view()et de l’action « suppression des éléments sélectionnés ».Le paramètre
\nobjsest une suite d’objets homogènes (unQuerySetou une liste d’instances de modèles) à supprimer, etrequestest la requêteHttpRequest.Cette méthode doit renvoyer un tuple à 4 de
\n(objets_supprimés, nombre_de_modèles, permissions_nécessaires, protégés).
\nobjets_supprimésest une liste de chaînes représentant tous les objets qui seront supprimés. S’il y a des objets liés à supprimer, la liste est imbriquée et contient ces objets liés. La liste est mise en forme dans le gabarit en utilisant le filtreunordered_list.
\nnombre_de_modèlesest un dictionnaire de correspondance entre l’attributverbose_name_pluralde chaque modèle et le nombre d’objets à supprimer de ce modèle.
\npermissions_nécessairesest un ensemble de nomsverbose_namedes modèles pour lesquels l’utilisateur n’a pas le droit de suppression.
\nprotégésest une liste de chaînes représentant tous les objets liés protégés qui ne peuvent pas être supprimés. La liste est affichée dans le gabarit.
Autres méthodesLien vers cette rubrique#
\n- \n
- \nModelAdmin.add_view(request, form_url='', extra_context=None)Lien vers cette définition# \n
La vue Django pour la page d’ajout d’une instance de modèle. Voir la note ci-dessous.
\n
- \n
- \nModelAdmin.change_view(request, object_id, form_url='', extra_context=None)Lien vers cette définition# \n
La vue Django pour la page d’édition d’une instance de modèle. Voir la note ci-dessous.
\n
- \n
- \nModelAdmin.changelist_view(request, extra_context=None)Lien vers cette définition# \n
La vue Django pour les pages de liste pour modification et d’actions sur les instances de modèle. Voir la note ci-dessous.
\n
- \n
- \nModelAdmin.delete_view(request, object_id, extra_context=None)Lien vers cette définition# \n
La vue Django pour la page de confirmation de suppression d’instance de modèle. Voir la note ci-dessous.
\n
- \n
- \nModelAdmin.history_view(request, object_id, extra_context=None)Lien vers cette définition# \n
La vue Django pour la page affichant l’historique de modification d’une instance de modèle donnée.
\n
Contrairement aux méthodes de type « point d’entrée » utilisées pour l’extension de ModelAdmin décrites dans la section précédente, ces cinq méthodes sont en réalité destinées à être invoquées comme des vues Django par le gestionnaire de distribution d’URL de l’application d’administration afin de produire les pages qui gèrent les opérations CRUD sur les instances de modèle. En conséquence, la redéfinition complète de ces méthodes modifierait notablement le comportement de l’application d’administration.
Une cause fréquente de la redéfinition de ces méthodes consiste à enrichir les données de contexte qui sont fournies au gabarit qui rend la vue. Dans l’exemple suivant, la vue d’édition est redéfinie de sorte que des données associatives supplémentaires sont fournies au gabarit de production de page :
\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 )\nCes vues renvoient des instances TemplateResponse permettant de personnaliser facilement les données de réponse avant le processus de rendu. Pour plus de détails, consultez la documentation de TemplateResponse.
Définitions des fichiers annexes de ModelAdminLien vers cette rubrique#
\nIl peut arriver que du contenu CSS ou JavaScript puisse être utile dans les vues d’ajout ou d’édition. Ceci peut se faire en utilisant une classe Media interne à la classe ModelAdmin:
class ArticleAdmin(admin.ModelAdmin):\n class Media:\n css = {\n "all": ["my_styles.css"],\n }\n js = ["my_code.js"]\nL’application staticfiles préfixe tous les chemins des fichiers statiques par STATIC_URL (ou MEDIA_URL si STATIC_URL vaut None). Les mêmes règles s’appliquent que pour la définition de fichiers annexes sur les formulaires.
jQueryLien vers cette rubrique#
\nLe code JavaScript de l’administration de Django utilise la bibliothèque jQuery.
\nPour éviter des conflits avec des scripts ou des bibliothèques fournies par l’utilisateur, la version Django de jQuery (version 3.7.1) est définie dans l’espace de nom django.jQuery. Si vous souhaitez utiliser jQuery dans votre propre code JavaScript d’administration sans inclure une deuxième copie, vous pouvez utiliser l’objet django.jQuery dans les vues de liste pour modification ou d’ajout/modification. De plus, vos propres formulaires ou composants d’administration dépendants de django.jQuery doivent indiquer js=['admin/js/jquery.init.js', …] lors de la déclaration des fichiers statiques de formulaire.
La classe ModelAdmin requiert jQuery par défaut, il n’y a donc pas besoin d’ajouter jQuery à la liste des ressources media des classes ModelAdmin sauf besoin particulier. Par exemple, si vous avez besoin que la bibliothèque jQuery soit placée dans l’espace de nom global (par exemple pour utiliser des greffons jQuery externes) ou que vous avez besoin d’une version plus récente de jQuery, il est alors utile d’inclure votre propre copie de cette bibliothèque.
Django fournit à la fois des versions non compressée et « minimisée » de jQuery, en tant que jquery.js et jquery.min.js respectivement.
Les classes ModelAdmin et InlineModelAdmin ont une propriété media qui renvoie une liste d’objets Media qui stockent des chemins d’accès aux fichiers JavaScript pour les formulaires et les formulaires groupés. Quand DEBUG vaut True, les versions non compressées des différents fichiers JavaScript sont renvoyées, y compris pour jquery.js; sinon, ce sont les versions « minimisées » qui sont renvoyées.
Ajout de validation personnalisée à l’administrationLien vers cette rubrique#
\nVous pouvez aussi ajouter de la validation personnalisée des données dans l’administration. L’interface d’administration automatique réutilise django.forms, et la classe ModelAdmin vous donne la possibilité de définir votre propre formulaire :
class ArticleAdmin(admin.ModelAdmin):\n form = MyArticleAdminForm\nMyArticleAdminForm peut être défini n’importe où tant que vous l’importez là où vous l’utilisez. Ensuite, à l’intérieur de votre formulaire, vous pouvez ajouter votre propre validation personnalisée pour n’importe quel champ :
class MyArticleAdminForm(forms.ModelForm):\n def clean_name(self):\n # do something that validates your data\n return self.cleaned_data["name"]\nIl est important d’utiliser un ModelForm ici, sinon les choses peuvent mal se passer. Voir la documentation des formulaires sur la validation personnalisée et plus particulièrement, les notes sur la validation des formulaires de modèle pour plus d’informations.