ModelAdmin のオブジェクトLink to this heading#
\n- \n
- \nclass ModelAdminLink to this definition# \n
\nModelAdminクラスは、admin インターフェース内でモデルを表現する方法です。通常、アプリケーション内のadmin.pyに記述されます。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
register デコレータLink to this heading#
\n- \n
- \nregister(*models, site=django.contrib.admin.sites.site)Link to this definition# \n
\nModelAdminを登録するために、デレコータも用意されています:\nfrom django.contrib import admin\nfrom .models import Author\n\n\n@admin.register(Author)\nclass AuthorAdmin(admin.ModelAdmin):\n pass\n1 つ以上のモデルが与えられ、
\nModelAdminに登録されます。カスタムのAdminSiteを使用している場合、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\nこのデコレータは、model admin クラスをその
\n__init__()メソッド内で参照する必要がある場合（例：super(PersonAdmin, self).__init__(*args, **kwargs)）には使用できません。代わりにsuper().__init__(*args, **kwargs)のようにします。
admin ファイルを見つけるLink to this heading#
\nINSTALLED_APPS 設定内に 'django.contrib.admin' を記述すると、Django は自動的に各アプリケーション内で admin モジュールを探してインポートします。
- \n
- \nclass apps.AdminConfigLink to this definition# \n
これは、admin に対するデフォルトの
\nAppConfigクラスです。Django が開始するとautodiscover()を呼び出します。
- \n
- \nclass apps.SimpleAdminConfigLink to this definition# \n
このクラスは
\nAdminConfigと同じように動作しますが、autodiscover()を呼び出しません。- \n
- \ndefault_siteLink to this definition# \n
これはデフォルトの admin サイトのクラスやサイトインスタンスを返す呼び出し可能オブジェクトへのドット区切りのインポートパスです。デフォルトは
\n'django.contrib.admin.sites.AdminSite'です。使い方は デフォルトの admin サイトをオーバーライドする を参照してください。
- \n
- \nautodiscover()Link to this definition# \n
この関数は、インストールされた各アプリケーション内で
\nadminモジュールをインポートするよう試みます。これらのモジュールは admin にモデルが登録されているものと想定されます。通常、この機能を手動で呼び出す必要はありません。Django が開始するとき
\nAdminConfigが呼び出してくれます。
カスタム AdminSite を使用している場合、通常はすべての ModelAdmin サブクラスをコードにインポートし、それらをカスタム AdminSite に登録します。その場合、自動検出を無効にするには、INSTALLED_APPS 設定で 'django.contrib.admin' の代わりに 'django.contrib.admin.apps.SimpleAdminConfig' を指定する必要があります。
ModelAdmin のオプションLink to this heading#
\nModelAdmin は非常に柔軟にできています。インターフェイスをカスタマイズするために、様々なオプションが用意されています。すべてのプションは 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
チェンジリストページで有効化するアクションのリストです。詳細は 管理アクション を参照してください。
\n
- \n
- \nModelAdmin.actions_on_topLink to this definition# \n
- \n
- \nModelAdmin.actions_on_bottomLink to this definition# \n
ページ上のどこにアクションバーが表示されかをコントロールします。デフォルトでは、admin チェンジリストはページのトップにアクションを表示します (
\nactions_on_top = True; actions_on_bottom = False)。
- \n
- \nModelAdmin.actions_selection_counterLink to this definition# \n
アクションのドロップダウンの隣に選択用カウンターを表示するかどうかをコントロールします。デフォルトでは、admin チェンジリストは表示するようになっています (
\nactions_selection_counter = True)。
- \n
- \nModelAdmin.date_hierarchyLink to this definition# \n
\ndate_hierarchyをモデル内のDateFieldかDateTimeFieldの名前にセットすると、チェンジリストのページがそのフィールドによる日付ベースのドリルダウンナビゲーションを含むようになります。実装例:
\n\ndate_hierarchy = "pub_date"\n
\n__ルックアップを使用して、関連するモデルのフィールドを指定することもできます。たとえば:\ndate_hierarchy = "author__pub_date"\nこの機能は、有効なデータに基づいて、適切に変化させます。たとえば、すべての日付が 1 月に収まっている場合、日のドリルダウンのみを表示します。
\n\n
- \n
- \nModelAdmin.empty_value_displayLink to this definition# \n
この属性は、空(
\nNone、空の文字列、等)のレコードのフィールドに対するデフォルトの表示値をオーバーライドします。デフォルト値は-(ダッシュ)です。たとえば:\nfrom django.contrib import admin\n\n\nclass AuthorAdmin(admin.ModelAdmin):\n empty_value_display = "-empty-"\n
\nAdminSite.empty_value_displayですべての admin ページもしくは特定のフィールドに対してempty_value_displayをオーバーライドすることもできます:\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
この属性を使用する場合、フォームから除外するフィールドの名称をリストで指定します。
\nたとえば、以下のモデルを考えてみましょう:
\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)\n
\nAuthorモデルに対するフォームがnameとtitleの 2 つのフィールドのみを含むようにしたい場合、以下のようにfieldsかexcludeを指定することになります:\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"]\nAuthor モデルが 3 つのフィールド (
\nname、title、birth_date) しか持っていないので、上記の宣言によって生成されるフォームはまったく同じフィールドを持つことになります。
- \n
- \nModelAdmin.fieldsLink to this definition# \n
"add" と "change" 上のフォームでシンプルなレイアウト変更 (有効なフィールドのみ表示、順序の変更、行のグルーピングなど) を行うには、
\nfieldsオプションを使用してください。たとえば、以下のように、django.contrib.flatpages.models.FlatPageモデルに対して admin フォームのよりシンプルなバージョンを定義できます。\nclass FlatPageAdmin(admin.ModelAdmin):\n fields = ["url", "title", "content"]\n上記の例では、指定したフィールド (
\nurl、title、content) だけが (結果として) フォーム上で表示されます。fieldsはModelAdmin.readonly_fieldsで定義される値を持つことができ、読み取り専用で表示されます。より複雑なレイアウトを作るには、
\nfieldsetsオプションを参照してください。
\nfieldsオプションは、list_displayと同じタイプの値を受け付けますが、呼び出し可能オブジェクトを受け付けないところが異なります。readonly_fieldsにリスト化されている場合、モデルの名前とモデルの admin メソッドのみが使用されます。1 つの行に複数のフィールドを表示するには、タプルで囲んでください。この例では、
\nurlとtitleフィールドが同じ行に表示され、contentフィールドは次の行に表示されます:\n\nclass FlatPageAdmin(admin.ModelAdmin):\n fields = [("url", "title"), "content"]\n
\nfieldsとfieldsetsオプションのどちらも存在しない場合、Django はデフォルトでAutoFieldとeditable=True以外の各フィールドを、単一のフィールドセットで、モデル内でフィールドが定義されたとおりの順番で表示します。
- \n
- \nModelAdmin.fieldsetsLink to this definition# \n
admin の "add" と "change" ページのレイアウトをコントロールするには、
\nfieldsetsをセットしてください。
\nfieldsetsは、2 値タプルのリストで、各 2 値タプルは admin フォームページの<fieldset>を表します。 (<fieldset>はフォームの "section" です。)2 値タプルのフォーマットは
\n(name, field_options)で、nameはフィールドセットのタイトル文字列を表し、field_optionsフィールドセットに関する情報のディクショナリで、表示するフィールドのリストを含みます。
\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 ]\nこれにより、admin ページは以下のような見た目となります:
\n![\"/ja/5.0/_images/fieldsets.png\"](\"/ja/5.0/_images/fieldsets.png\")
\n
\nfieldsetsとfieldsオプションのどちらも存在しない場合、Django はデフォルトでAutoFieldとeditable=True以外の各フィールドを、単一のフィールドセットで、モデル内でフィールドが定義されたとおりの順番で表示します。
\nfield_optionsディクショナリは以下のキーを持つことができます:- \n
- \n
fieldsフィールドセット内に表示するフィールド名のリストまたはタプルです。このキーは必須です。
\n実装例:
\n\n{\n "fields": ["first_name", "last_name", "address", "city", "state"],\n}\n
\nfieldsオプションと同様に、複数のフィールドを 1 行に表示するにはタプルでこれらのフィールドを囲んでください。この例では、first_nameとlast_nameフィールドが 1 つの行に表示されます。\n{\n "fields": [("first_name", "last_name"), "address", "city", "state"],\n}\n
\nfieldsはModelAdmin.readonly_fieldsで定義される値を持つことができ、読み取り専用で表示されます。
\nfieldsに呼び出し可能オブジェクトの名前を追加した場合、fieldsオプションと同じルールが適用されます: 呼び出し可能オブジェクトはreadonly_fields内でリスト化される必要があります。 \n
\n- \n
classesフィールドセットに適用する追加的な CSS を含むリストないしタプルです。
\n実装例:
\n\n{\n "classes": ["wide", "extrapretty"],\n}\n
\ncollapseとwideの 2 つの便利なクラスがデフォルトの admin サイトのスタイルシートで定義されています。collapseスタイルのフィールドセットは初期状態では admin 内で折りたたまれており、"click to expand" リンクで置き換えられています。wideスタイルのフィールドセットは水平方向の追加的な余白が与えられます。 \n
\n- \n
description各フィールドセットの上部、フィールドセットの見出しの下に表示されるオプションの追加テキストの文字列です。この文字列は
\nTabularInlineのレイアウト上、レンダリングされません。この値は、管理インターフェイスに表示されるときにはHTMLエスケープされないことに注意してください。これにより、HTML を含めることができます。あるいは、プレーンテキストと
\ndjango.utils.html.escape()を使って HTML の特殊文字をエスケープすることもできます。 \n
\n
- \n
- \nModelAdmin.filter_horizontalLink to this definition# \n
デフォルトでは、
\nManyToManyFieldは<select multiple>で admin サイトで表示されます。複数選択のボックスは、たくさんのアイテムを選択するには不向きです。ManyToManyFieldをこのリストに加えると、代わりにかっこよくて控えめな JavaScript の "filter" インターフェースを使用します。非選択および選択済みのオプションは 2 つのボックスに並べて表示されます。垂直方向のインターフェースを使用するにはfilter_verticalを参照してください。
- \n
- \nModelAdmin.filter_verticalLink to this definition# \n
\nfilter_horizontalと同じですが、フィルタインターフェイスを垂直方向に表示し、非選択のオプションは選択済みのオプションの上部に表示されます。
- \n
- \nModelAdmin.formLink to this definition# \n
デフォルトではモデルに対して
\nModelFormが動的に生成されます。追加と変更の両方のページで使用されるフォームです。独自のModelFormを定義すれば、追加と変更のページでフォームの挙動を簡単にオーバーライドできます。あるいは、まったく新しいモデルフォームを作る代わりに、ModelAdmin.get_form()メソッドを使ってデフォルトのフォームをカスタムすることもできます。例については カスタムのバリデーションを admin に追加する を参照してください。
\n\n\n
- \n
- \nModelAdmin.formfield_overridesLink to this definition# \n
admin 内で使用するための
\nFieldのうちある程度の部分をオーバーライドする簡単 (だけど汚い) 方法を提供します。formfield_overridesはディクショナリで、フィールドクラスの構成時にフィールドに渡す引数のディクショナリをマッピングします。これでは抽象的すぎるので、具体的な例を見てみましょう。
\nformfield_overridesのもっとも一般的な使い道は、特定のタイプのフィールドに対してカスタムしたウィジェットを追加することです。大きなテキストフィールドを使用するために、デフォルトの<textarea>の代わりにRichTextEditorWidgetを使いたいとしましょう。この場合、以下のように記述します。\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 }\nディクショナリ内のキーは文字列 ではなく 実際のフィールドクラスである点に注意してください。値は別のディクショナリです; これらの引数はフォームフィールドの
\n\n__init__()メソッドに渡されます。詳細は フォーム API を参照してください。
- \n
- \nModelAdmin.inlinesLink to this definition# \n
後述の
\nInlineModelAdminオブジェクトとModelAdmin.get_formsets_with_inlines()を参照してください。
- \n
- \nModelAdmin.list_displayLink to this definition# \n
admin のチェンジリストページでどのフィールドを表示するかコントロールするために、
\nlist_displayをセットします。実装例:
\n\nlist_display = ["first_name", "last_name"]\n
\nlist_displayをセットしない場合、admin サイトは各オブジェクトの__str__()表現を表示する単一の列を表示します。
\nlist_displayで使用できる値は 4 種類あります。最も単純なもの以外は、フィールドの表示方法をカスタマイズするためにdisplay()デコレータを使用できます。- \n
モデルフィールドの名前。次に例を示します。
\n\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["first_name", "last_name"]\n\n1 つの引数 (モデルのインスタンス) を受け入れる呼び出し可能オブジェクトです。次に例を示します。
\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\n1 つの引数 (モデルのインスタンス) を受け入れる
\nModelAdminメソッドを表す文字列です。次に例を示します。\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\nモデルの属性や (必須の引数を持たない) メソッドを表す文字列です。次に例を示します。
\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
\nlist_displayに関する特殊な状況の注意点があります。- \n
フィールドが
ForeignKeyの場合、 Django はリレーション先オブジェクトの__str__()を表示します。 \nManyToManyFieldフィールドは、テーブル内で各行に対して個別の SQL ステートメントを実行する可能性があるため、サポートされていません。それでも使いたい場合は、モデルにカスタムメソッドを作成し、そのメソッドの名前をlist_displayに追加してください。 (list_display内でのカスタムメソッドについてより詳しくは下記を参照してください。) \nフィールドが
BooleanFieldの場合、Django はTrue,False,Noneの代わりに、かわいい "yes", "no", "unknown" アイコンを表示します。 \n与えられた文字列がモデル、
\nModelAdmin、呼び出し可能オブジェクトのどれかの場合、Django はデフォルトで HTML エスケープして出力します。ユーザーの入力をエスケープしたり非エスケープのタグを使う場合、format_html()を使用してください。以下は、モデルの例です。
\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\nこれまでの例で見てきたように、呼び出し可能オブジェクト、モデルメソッド、または
ModelAdminメソッドを使用する場合、display()デコレータで呼び出し可能オブジェクトをラップし、description引数を渡すことで、カラムのタイトルをカスタマイズできます。 \nフィールドの値が
\nNone、空の文字列、エレメントを持たない iterable のいずれかの場合、Django は-(ダッシュ) を表示します。この挙動はAdminSite.empty_value_displayでオーバーライドできます。\nfrom django.contrib import admin\n\nadmin.site.empty_value_display = "(None)"\n
\nModelAdmin.empty_value_displayも使用できます。\nclass PersonAdmin(admin.ModelAdmin):\n empty_value_display = "unknown"\nもしくは、フィールドレベルで以下のようにできます。
\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\n与えられた文字列がモデル
\nModelAdminのメソッドか、True,False,Noneを返す呼び出し可能オブジェクトの場合、 Django はそのメソッドをdisplay()デコレータでラップし、boolean引数をTrueで渡すと、かわいい "yes", "no", "unknown" アイコンを表示します。\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\n
\n__str__()メソッドは、他のモデルメソッドとまったく同様にlist_display内でも有効です。つまり、以下のような書き方は完璧に OK です。\nlist_display = ["__str__", "some_other_field"]\n\n通常、実際のデータベースフィールドではない
\nlist_displayの要素は、ソートに使用できません (Django のソートはすべてデータベースレベルで実行されるためです)。しかし、
\nlist_displayの要素が特定のデータベースフィールドを表す場合、メソッドにdisplay()デコレータを使用し、ordering引数を渡すことで、その事実を伝えることができます。\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"]\n上記のコードは、admin 内で
\ncolored_first_nameで ソートしようとするとき、first_nameフィールドで並べ替えるよう Django に伝えます。引数
\norderingで降順を示すには、フィールド名の前にハイフンをつけます。上記の例を使うと、次のようになります。\n@admin.display(ordering="-first_name")\ndef colored_first_name(self): ...\n引数
\nLorderingはリレーション先モデルの値でソートするクエリのルックアップをサポートします。この例では、"author first name" カラムをリストに表示し、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\nクエリ式 は
\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\n
\nlist_displayの要素はプロパティにすることもできます。\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"]\nただし、
\n@propertyは@displayより上でなければなりません。display()デコレータを使用するのではなく、直接表示関連の属性を設定する古い方法を使用している場合は、@propertyデコレータではなく、property()関数を使用しなければならないことに注意してください。\n\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\nlist_displayのフィールド名はHTMLの出力でも<th>要素にcolumn-<field_name>という形でCSSクラスとして表示されます。これは例えばCSSファイルでカラムの幅を設定するのに使うことができます。 \nDjango は、
\nlist_displayの各要素を以下の順番で解釈しようとします。- \n
モデルのフィールド。
\n呼び出し可能オブジェクト。
\nModelAdmin属性を表す文字列。 \nモデル属性を表す文字列。
\n
たとえば、
\nfirst_nameがモデルフィールドとModelAdmin属性の両方で存在する場合、モデルフィールドの方が使用されます。 \n
- \n
- \nModelAdmin.list_display_linksLink to this definition# \n
\nlist_display内のフィールドにおいて "変更" ページへのリンクをコントロールするには、list_display_linksを使用してください。デフォルトでは、チェンジリストページは最初のカラム (
\nlist_displayで最初に指定したフィールド) に各アイテムの変更ページへのリンクが貼られています。しかし、list_display_linksを使って変更できます。- \n
リンクを貼らない場合は
Noneをセットしてください。 \n(
\nlist_displayと同様のフォーマットで) リンクに変換したいカラムのフィールドのリストないしタプルをセットしてください。1 つないし複数のフィールドを指定できます。
\nlist_displayにある限り、Django はいくつのフィールドがリンクになろうと気にしません。唯一の要件は、list_display_linksをこの方式で使いたいときはlist_displayを指定することです。 \n
以下の例では、
\nfirst_nameとlast_nameフィールドがチェンジリストページでリンクされます。\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ["first_name", "last_name", "birthday"]\n list_display_links = ["first_name", "last_name"]\n以下の例では、チェンジリストページのグリッドにはリンクがなくなります。
\n\nclass AuditEntryAdmin(admin.ModelAdmin):\n list_display = ["timestamp", "message"]\n list_display_links = None\n
- \n
- \nModelAdmin.list_editableLink to this definition# \n
チェンジリストページ上での編集を有効にしたいモデルのフィールド名のリストを
\n\nlist_editableにセットしてください。list_editableに指定されたフィールドは、チェンジリストページ上でフォームウィジェットとして表示され、ユーザーは複数の行を一度に編集して保存できます。
- \n
- \nModelAdmin.list_filterLink to this definition# \n
admin のチェンジリストページの右サイドバーのフィルタを有効化するには、
\nlist_filterをセットしてください。最もシンプルな
\nlist_filterはフィルタリングを有効にするフィールド名のリストまたはタプルを受け取りますが、より高度なオプションもいくつか用意されています。詳細は ModelAdmin リストフィルタ を参照してください。
- \n
- \nModelAdmin.list_max_show_allLink to this definition# \n
"Show all" の admin チェンジリストページで表示するアイテム数をコントロールするには、
\nlist_max_show_allをセットしてください。チェンジリストページの "Show all" リンクは、この設定値以下の場合のみ表示されます。デフォルトでは200にセットされています。
- \n
- \nModelAdmin.list_per_pageLink to this definition# \n
ページ分割された admin のチェンジリストページに表示するアイテム数をコントロールするには、
\nlist_per_pageをセットしてください。デフォルトでは100にセットされています。
- \n\n
admin のチェンジリストページでオブジェクトのリストを検索するときに
\nselect_related()を使用するよう Django に伝えるには、list_select_relatedをセットしてください。これにより多くのデータベースクエリを削減できます。値は真偽値、リスト、タプルのどれかでなければなりません。デフォルトは
\nFalseです。値が
\nTrueのとき、常にselect_related()が呼ばれます。Falseのときは、ForeignKeyが存在する場合 Django はlist_displayを参照してselect_related()を呼び出します。よりきめ細やかにコントロールする場合は、
\nlist_select_relatedの値にタプル (ないしリスト) を使用してください。空のタプルは、Django がselect_relatedを一切呼び出さないようにします。他のタプルは、パラメータとして直接select_relatedに渡されます。次に例を示します。\nclass ArticleAdmin(admin.ModelAdmin):\n list_select_related = ["author", "category"]\nこれは
\nselect_related('author', 'category')を呼び出します。リクエストに基づいた動的な値を指定する場合は、
\n\nget_list_select_related()メソッドを実装できます。
- \n
- \nModelAdmin.orderingLink to this definition# \n
Django の admin ビューでオブジェクトのリストをどのようにソートするかを指定するには、
\norderingをセットしてください。モデルのorderingパラメータと同じフォーマットでリストかタプルを与えてください。指定がない場合、Django admin はモデルのデフォルトの並び順を使用します。
\n動的なソートを指定する場合 (例えばユーザーや言語に応じて変更する場合など)、
\n\nget_ordering()メソッドを実装できます。
- \n
- \nModelAdmin.paginatorLink to this definition# \n
ページ分割に使われる paginator クラスです。デフォルトでは
\ndjango.core.paginator.Paginatorが使われます。カスタムの paginator クラスがdjango.core.paginator.Paginatorと同じコンストラクタインターフェースを持たない場合、ModelAdmin.get_paginator()に対する実装も行う必要があります。
- \n
- \nModelAdmin.prepopulated_fieldsLink to this definition# \n
\nprepopulated_fieldsを、フィールド名と事前入力するフィールドをマッピングした辞書に設定します。\nclass ArticleAdmin(admin.ModelAdmin):\n prepopulated_fields = {"slug": ["title"]}\n設定された場合、指定されたフィールドは割り当てられたフィールドから入力するために JavaScript を使用します。この機能の主な用途は、1つ以上の他のフィールドから
\nSlugFieldフィールドの値を自動的に生成することです。生成される値はソースフィールドの値を連結し、その結果を有効なスラグに変換することで生成されます (たとえば、ダッシュをスペースに置き換えたり、ASCII 文字を小文字にしたりします)。事前入力されたフィールドは値が保存された後に JavaScript によって変更されることはありません。通常、スラグが変更されることは望ましくありません (スラグがオブジェクトで使用されている場合、オブジェクトの URL が変更されることになります)。
\n
\nprepopulated_fieldsはDateTimeField、ForeignKey、OneToOneField、ManyToManyFieldフィールドを受け入れません。
- \n
- \nModelAdmin.preserve_filtersLink to this definition# \n
デフォルトでは、オブジェクトを作成、編集、削除しても、適用されたフィルタはリストビューに保存されます。この属性を
\nFalseに設定することで、フィルタをクリアできます。
- \n
- \nModelAdmin.show_facetsLink to this definition# \n
- \n
管理画面のチェンジリストのフィルタにファセット数を表示するかどうかを制御します。デフォルトは
\nShowFacets.ALLOWです。表示されている場合、ファセット数は現在適用されているフィルタに合わせて更新されます。
\n- \n
- \nclass ShowFacetsLink to this definition# \n
- \n
\nModelAdmin.show_facetsに指定できる値の Enum。- \n
- \nALWAYSLink to this definition# \n
常にファセット数を表示します。
\n
- \n
- \nALLOWLink to this definition# \n
クエリ文字列パラメータ
\n_facetsが指定された場合に、ファセット数を表示します。
- \n
- \nNEVERLink to this definition# \n
ファセット数を表示しません。
\n
\nshow_facetsに必要なShowFacetsの値を指定します。例えば、クエリパラメータを指定することなく常にファセット数を表示したい場合:\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
デフォルトでは、
\nForeignKeyやchoicesがセットされたフィールドに対して、Django の admin はセレクトボックスのインターフェース (<select>) を使用します。フィールドがradio_fieldsに指定された場合、Django は代わりに ラジオボタンのインターフェースを使用します。groupがPersonモデルのForeignKeyだと仮定すると、次のようになります。\nclass PersonAdmin(admin.ModelAdmin):\n radio_fields = {"group": admin.VERTICAL}\n
\ndjango.contrib.adminモジュールからHORIZONTALかVERTICALのどちらを使用するか選択してください。
\nForeignKeyないしchoicesがセットされたフィールド以外は、radio_fieldsに含めないでください。
- \n
- \nModelAdmin.autocomplete_fieldsLink to this definition# \n
\nautocomplete_fieldsは、Select2 オートコンプリート入力に変更したいForeignKeyないしManyToManyFieldフィールドのリストです。デフォルトでは、これらのフィールドに対して admin はセレクトボックスのインターフェース (
\n<select>) を使用します。ドロップダウン内に表示する関係インスタンスをすべて選択するオーバーヘッドから逃れたいこともあるでしょう。Select2 入力はデフォルトの入力と似た見た目ですが、非同期的にオプションを読み込む検索機能を持っています。こちらの方が高速で、特に関係モデルに多くのインスタンスがある場合にはユーザーフレンドリーです。
\nオートコンプリート検索はリレーション先オブジェクトの
\nModelAdminを使用するため、ModelAdminにsearch_fieldsを定義する必要があります。認可されていないデータが漏洩されるのを防ぐため、オートコンプリートを使うには、ユーザーは必ずリレーション先オブジェクトに対する
\nviewかchange権限を持っていなければなりません。結果のソートおよびページ分割は、関係する
\nModelAdminのget_ordering()とget_paginator()メソッドでコントロールします。以下の例では、
\nChoiceAdminフィールドはQuestionへのForeignKeyに対するオートコンプリートフィールドを持ちます。結果はquestion_textフィールドによりフィルタされ、またdate_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
デフォルトでは、
\nForeignKeyのフィールドに対して Django の admin はセレクトボックスのインターフェース (<select>) を使用します。ドロップダウン内に表示する関係インスタンスをすべて選択するオーバーヘッドから逃れたいこともあるでしょう。
\nraw_id_fieldsは、ForeignKeyやManyToManyFieldに対するInputウィジェットを適用したいフィールドのリストです:\nclass ArticleAdmin(admin.ModelAdmin):\n raw_id_fields = ["newspaper"]\n
\nraw_id_fieldsInputウィジェットには、ForeignKeyの場合はプライマリキーを、ManyToManyFieldの場合はカンマで区切った値のリストを入力します。raw_id_fieldsウィジェットには、ユーザーが値を検索および選択できるよう、隣にルーペボタンがあります:![\"/ja/5.0/_images/raw_id_fields.png\"](\"/ja/5.0/_images/raw_id_fields.png\")
\n
- \n
- \nModelAdmin.readonly_fieldsLink to this definition# \n
デフォルトでは、すべてのフィールドが編集可能となっています。このオプションに含まれるフィールド (
\nlistかtupleで指定します) は、データをそのまま表示するだけで編集できなくなります。また、追加と編集に使われるModelFormからも除外されます。ModelAdmin.fieldsかModelAdmin.fieldsetsを指定した場合、read-only のフィールドは表示のために存在している必要があります (存在しなければ無視されます)。
\nModelAdmin.fieldsやModelAdmin.fieldsetsで明示的に並び順を定義しないでreadonly_fieldsを使った場合、これらのフィールドはすべての編集可能なフィールドの後に表示されます。read-only のフィールドはモデルのフィールドからデータを表示するだけではなく、モデルや
\nModelAdminクラス自身のメソッドの出力を表示させることもできます。これはModelAdmin.list_displayの挙動に似ています。これにより、編集中のオブジェクトのステータスのフィードバックを admin インターフェースに与えることができるようになります。たとえば:\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
admin のチェンジーフォームで "新規に保存" 機能を有効化するには
\nsave_asをセットしてください。通常、オブジェクトには 3 つの保存オプションがあります: "保存"、"保存して編集を続ける"、"保存して 1 つ追加" です。
\nsave_asがTrueの場合、"保存して 1 つ追加" が "新規に保存" ボタンに変更され、既存のオブジェクトを変更するのではなく (新しい ID) で新規のオブジェクトが作成されるようになります。デフォルトでは
\nsave_asはFalseにセットされています。
- \n
- \nModelAdmin.save_as_continueLink to this definition# \n
\nsave_as=Trueのとき、新規オブジェクトを保存した後のデフォルトのリダイレクト先はそのオブジェクトの変更ビューです。save_as_continue=Falseにセットすると、リダイレクト先がチェンジリストビューになります。デフォルトでは
\nsave_as_continueはTrueにセットされています。
- \n
- \nModelAdmin.save_on_topLink to this definition# \n
admin のチェンジフォームの上部に保存ボタンを追加するには
\nsave_on_topをセットしてください。通常、保存ボタンはフォームの下部のみに表示されます。
\nsave_on_topをセットすると、ボタンは上部と下部の両方に表示されるようになります。デフォルトでは
\nsave_on_topはFalseにセットされています。
- \n
- \nModelAdmin.search_fieldsLink to this definition# \n
admin のチェンジリストページで検索ボックスを有効化するには
\nsearch_fieldsをセットしてください。セットするのはフィールド名のリストで、ここで指定したフィールドはテキストボックス内での検索クエリの対象となります。指定するフィールドの種類は、
\nCharFieldやTextFieldといったテキストフィールドである必要があります。ルックアップ API の "follow" 記法を使えばForeignKeyやManyToManyFieldをルックアップすることもできます。\nsearch_fields = ["foreign_key__related_fieldname"]\nたとえば、著者の情報を持つブログエントリーの場合、以下の定義により、著者のメールアドレスによるブログエントリーの検索が可能となります。
\n\nsearch_fields = ["user__email"]\n検索ボックスで検索が行われるとき、Django は検索クエリを単語に分割し、(
\nicontainsルックアップを使って) 大文字と小文字を区別しない各単語を含むオブジェクトを返します。各単語は最低 1 つのsearch_fieldsに含まれている必要があります。例えば、search_fieldsが['first_name', 'last_name']にセットされ、ユーザーがjohn lennonと検索した場合、Django は SQL のWHERE節と同等の検索を実行します。\nWHERE (first_name ILIKE '%john%' OR last_name ILIKE '%john%')\nAND (first_name ILIKE '%lennon%' OR last_name ILIKE '%lennon%')\n検索クエリには空白を含む引用句を含めることができます。たとえば、ユーザが
\n"john winston"や'john winston'を検索した場合、 Django はこの SQL のWHERE句と等価な処理を行います。\nWHERE (first_name ILIKE '%john winston%' OR last_name ILIKE '%john winston%')\nもし
\nicontainsルックアップを使用したくない場合は、フィールドに追加することで任意のルックアップを使用できます。例えば、search_fieldsを['first_name__exact']に設定することで、exactを使用できます。いくつかの (古い) ショートカットを使って、フィールドルックアップを指定することもできます。以下の文字で
\nsearch_fields内のフィールドにプレフィックスを追加できます。これはフィールドに__<lookup>を追加するのと同等です。\n\n\n
\nプレフィックス
ルックアップ
^
\n =
\n @
\n None
\n 検索方法をカスタムする必要がある場合は、
\nModelAdmin.get_search_results()を使って追加的もしくは代替の検索方法を提供できます。
- \n
- \nModelAdmin.search_help_textLink to this definition# \n
\nsearch_help_textには検索ボックスの下に表示される説明文を指定します。
- \n
- \nModelAdmin.show_full_result_countLink to this definition# \n
フィルタリングされた admin ページにオブジェクトのカウント (例:
\n99 results (103 total)) を表示するかどうかをコントロールするには、show_full_result_countをセットしてください。Falseにセットすると、代わりに99 results (Show all)のような文字列が表示されるようになります。デフォルトの
\nshow_full_result_count=Trueは、テーブル内の全アイテムをカウントするクエリを発行するため、多くの行を含むテーブルではパフォーマンス低下の原因となります。
- \n
- \nModelAdmin.sortable_byLink to this definition# \n
デフォルトでは、チェンジリストページでは
\nlist_displayで指定された全てのモデルフィールド (およびdisplay()デコレータのordering引数を使用する呼び出し可能オブジェクト、またはadmin_order_field属性を持つ呼び出し可能オブジェクト) によるソートが可能です。特定のカラムでのソートを無効化したい場合、
\nsortable_byにlist_displayサブセットのコレクション (例:list、tuple、set) をセットしてください。空のコレクションを指定すると、すべてのカラムでソート不可となります。リストを動的に指定する必要があるときは、代わりに
\nget_sortable_by()メソッドを実装してください。
- \n
- \nModelAdmin.view_on_siteLink to this definition# \n
"サイトで見る" リンクを表示するか否かをコントロールするには、
\nview_on_siteをセットしてください。このリンクは保存されたオブジェクトを表示できる URL に誘導します。値は、真偽値か呼び出し可能オブジェクトで指定します。
\nTrue(デフォルトです) の場合、オブジェクトのget_absolute_url()メソッドが使われ、URLが生成されます。モデルが
\nget_absolute_url()メソッドを持っていても "サイトで見る" ボタンを表示したくない場合は、view_on_siteにFalseをセットしてください:\nfrom django.contrib import admin\n\n\nclass PersonAdmin(admin.ModelAdmin):\n view_on_site = False\n呼び出し可能オブジェクトの場合、引数にモデルのインスタンスを受け入れます。例えば:
\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
カスタムテンプレートのオプションLink to this heading#
\nadmin テンプレートをオーバーライドする セクションでは、デフォルトの admin テンプレートをオーバーライドないし拡張する方法を説明しています。ModelAdmin ビューで使用されるデフォルトのテンプレートをオーバーライドするには、以下のオプションを使用してください:
- \n
- \nModelAdmin.add_form_templateLink to this definition# \n
カスタムンテンプレートの絶対パスで、
\nadd_view()で使われます。
- \n
- \nModelAdmin.change_form_templateLink to this definition# \n
カスタムンテンプレートの絶対パスで、
\nchange_view()で使われます。
- \n
- \nModelAdmin.change_list_templateLink to this definition# \n
カスタムンテンプレートの絶対パスで、
\nchangelist_view()で使われます。
- \n
- \nModelAdmin.delete_confirmation_templateLink to this definition# \n
カスタムンテンプレートの絶対パスで、1 つ以上のオブジェクトを削除するときに確認ページを表示するために、
\ndelete_view()で使われます。
- \n
- \nModelAdmin.delete_selected_confirmation_templateLink to this definition# \n
カスタムンテンプレートの絶対パスで、1 つ以上のオブジェクトを削除するときに確認ページを表示するために、
\ndelete_selectedアクションメソッドで使われます。アクションのドキュメント を参照してください。
- \n
- \nModelAdmin.object_history_templateLink to this definition# \n
カスタムンテンプレートの絶対パスで、
\nhistory_view()で使われます。
- \n
- \nModelAdmin.popup_response_templateLink to this definition# \n
カスタムンテンプレートの絶対パスで、
\nresponse_add()、response_change()、response_delete()の 3 つで使われます。
ModelAdmin のメソッドLink to this heading#
\n\n- \n
- \nModelAdmin.save_model(request, obj, form, change)Link to this definition# \n
\nsave_modelメソッドには、HttpRequest、モデルのインスタンス、ModelFormのインスタンス、追加か変更かを表す真偽値が渡されます。このメソッドをオーバーライドすると、保存の前後に操作を追加できます。super().save_model()を呼び出して、Model.save()を使ってオブジェクトを保存してください。例えば、保存前にオブジェクトに
\nrequest.userを追加するには:\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
\ndelete_modelには、HttpRequestとモデルのインスタンスが渡されます。このメソッドをオーバーライドすると、削除の前後に操作を追加できます。super().delete_model()を呼び出して、Model.delete()を使ってオブジェクトを削除してください。
- \n
- \nModelAdmin.delete_queryset(request, queryset)Link to this definition# \n
\ndelete_queryset()には、HttpRequestと削除するオブジェクトのQuerySetが渡されます。このメソッドをオーバーライドすると、"選択したオブジェクトの削除" アクション に対する削除のプロセスをカスタムできます。
- \n
- \nModelAdmin.save_formset(request, form, formset, change)Link to this definition# \n
\nsave_formsetメソッドには、HttpRequest、親ModelFormのインスタンス、親オブジェクトの追加か変更かを表す真偽値が与えられます。たとえば、変更のあったフォームセットのモデルのインスタンスそれぞれに
\nrequest.userを追加するには、次のようにします。\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()\n関連項目: フォームセット内のオブジェクトを保存する
\n
- \n
- \nModelAdmin.get_ordering(request)Link to this definition# \n
\nget_orderingメソッドは引数にrequestを取り、orderingのときと同じようなlistかtupleを返すことが期待されます。次に例を示します。\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
\nget_search_resultsメソッドは、検索語と一致するオブジェクトを表示するための、オブジェクトのリストを修正します。リクエスト、現在のフィルタを適用するクエリセット、 ユーザーが入力した検索語を受け取ります。 検索を実行するために修正されたクエリセットと、結果に重複があるかどうかを表す真偽値を含むタプルを返します。デフォルトの実装では、
\nModelAdmin.search_fieldsに含まれるフィールドを検索します。このメソッドは、独自の検索方法でオーバーライドできます。例えば、数値のフィールドで検索したり、Solr や Haystack といった外部のツールを使うことができます。独自の検索方法によって実装されたクエリセットの変更が結果に重複を生じさせるかを確認し、返値の 2 番目の要素に
\nTrueを返す必要があります。たとえば、
\nnameとageで検索するには、以下のように使います。\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\nこの実装は、数値フィールドに対して文字列比較を行う
\nsearch_fields = ('name', '=age')に比べて、はるかに効率的です... たとえば PostgreSQL では... OR UPPER("polls_choice"."votes"::text) = UPPER('4')となります。
- \n\n
\nsave_relatedメソッドには、HttpRequest、親ModelFormのインスタンス、インラインフォームセットのリスト、親の追加か変更かを表す真偽値が与えられます。このメソッドで、保存の前後に親に対するリレーション先オブジェクトに対する操作を追加できます。この時点では親オブジェクトとそのフォームはすでに保存されていることに注意してください。
- \n
- \nModelAdmin.get_autocomplete_fields(request)Link to this definition# \n
\nget_autocomplete_fields()メソッドには、HttpRequestが渡され、上述のModelAdmin.autocomplete_fieldsセクションで説明した通りオートコンプリートウィジェットで表示するフィールドの名前のlistかtupleを返すことが期待されます。
- \n
- \nModelAdmin.get_readonly_fields(request, obj=None)Link to this definition# \n
\nget_readonly_fieldsメソッドには、HttpRequestと編集対象のobj(ないし新規追加用のNone) が渡され、上述のModelAdmin.readonly_fieldsセクションで説明した通り、読み取り専用で表示するフィールドの名前のlistかtupleを返すことが期待されます。
- \n
- \nModelAdmin.get_prepopulated_fields(request, obj=None)Link to this definition# \n
\nget_prepopulated_fieldsメソッドには、HttpRequestと編集対象のobj(ないし新規追加用のNone) が渡され、上述のModelAdmin.prepopulated_fieldsセクションで説明した通りdictionaryを返すことが期待されます。
- \n
- \nModelAdmin.get_list_display(request)Link to this definition# \n
\nget_list_displayメソッドには、HttpRequestが渡され、上述のModelAdmin.list_displayセクションで説明した通りチェンジリストビューで表示するフィールドの名前のlistかtupleを返すことが期待されます。
- \n
- \nModelAdmin.get_list_display_links(request, list_display)Link to this definition# \n
\nget_list_display_linksメソッドには、HttpRequestとModelAdmin.get_list_display()によって返されたlistないしtupleが渡されます。上述のModelAdmin.list_display_linksセクションで説明した通り、チェンジリストで変更ビューにリンクを貼りたいフィールドの名前のlistかtuple、もしくはNoneを返すことが期待されます。
- \n
- \nModelAdmin.get_exclude(request, obj=None)Link to this definition# \n
\nget_excludeメソッドには、HttpRequestと編集対象のobj(ないし新規追加用のNone) が渡され、上述のModelAdmin.excludeセクションで説明した通りフィールドのリストを返すことが期待されます。
- \n
- \nModelAdmin.get_fields(request, obj=None)Link to this definition# \n
\nget_fieldsメソッドには、HttpRequestと編集対象のobj(ないし新規追加用のNone) が渡され、上述のModelAdmin.fieldsセクションで説明した通りフィールドのリストを返すことが期待されます。
- \n
- \nModelAdmin.get_fieldsets(request, obj=None)Link to this definition# \n
\nget_fieldsetsメソッドには、HttpRequestと編集対象のobj(ないし新規追加用のNone) が渡され、2 値タプルのリストを返すことが期待されます。各 2 値タプルは、上述のModelAdmin.fieldsetsセクションで説明した通り admin のフォームページ上の<fieldset>を表します。
- \n
- \nModelAdmin.get_list_filter(request)Link to this definition# \n
\nget_list_filterメソッドには、HttpRequestが渡され、list_filter属性のときと同じ種類のシーケンス型を返すことが期待されます。
- \n\n
\nget_list_select_relatedメソッドには、HttpRequestが渡され、真偽値もしくはModelAdmin.list_select_relatedと同様のリストを返す必要があります。
- \n
- \nModelAdmin.get_search_fields(request)Link to this definition# \n
\nget_search_fieldsメソッドには、HttpRequestが渡され、search_fields属性のときと同じ種類のシーケンス型を返すことが期待されます。
- \n
- \nModelAdmin.get_sortable_by(request)Link to this definition# \n
\nget_list_displayメソッドはHttpRequestを受け取り、チェンジリストページでソート可能なフィールドの名のコレクション (例:list、tuple、set) を返すことが期待されます。デフォルトの実装では、セットされている場合は
\nsortable_byを返します。セットされていなければget_list_display()を参照します。たとえば、1 つ以上のカラムを並び替え不可にするには:
\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
\nget_inline_instancesメソッドは、編集中のHttpRequestとobj(追加フォームの場合はNone) を受け取り、以下のInlineModelAdminセクションで説明されているように、InlineModelAdminオブジェクトのlistまたはtupleを返すことが期待されます。例えば、以下は追加、変更、削除、閲覧の権限に基づくデフォルトのフィルタリングなしでインラインを返す方法です:\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]\nこのメソッドをオーバーライドする場合、返値となるインラインは
\ninlinesで定義したクラスのインスタンスにしてください。間違えると、リレーション先オブジェクトを追加する際に "Bad Request" が発生する可能性があります。
- \n
- \nModelAdmin.get_inlines(request, obj)Link to this definition# \n
\nget_inlinesメソッドは、編集対象のHttpRequestとobj(追加フォームの場合はNone) を受け取り、インラインのイテラブルを返すことが期待されます。ModelAdmin.inlinesで指定する代わりに、このメソッドをオーバーライドすることで、リクエストやモデルインスタンスに基づいて動的にインラインを追加できます。
- \n
- \nModelAdmin.get_urls()Link to this definition# \n
\nModelAdminのget_urlsメソッドは URLconf と同じようにその ModelAdmin で使用する URL を返します。 そのため、 URL ディスパッチャ で説明されているように、ビューのAdminSite.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)\nadmin のレイアウトを使用したい場合、
\nadmin/base_site.htmlを extend してください:\n\n\n{% extends "admin/base_site.html" %}\n{% block content %}\n...\n{% endblock %}\nページがキャッシュ可能で、それでもパーミッションチェックを行いたい場合は、
\nAdminSite.admin_view()にcacheable=True引数を渡します:\npath("my_view/", self.admin_site.admin_view(self.my_view, cacheable=True))\n
\nModelAdminビューはmodel_admin属性を持ちます。その他のAdminSiteビューはadmin_site属性を持ちます。
- \n
- \nModelAdmin.get_form(request, obj=None, **kwargs)Link to this definition# \n
admin の追加と変更のビューで使うための
\nModelFormクラスを返します。add_view()とchange_view()を参照してください。基本の実装は
\nmodelform_factory()を使用してformをサブクラス化し、fieldsやexcludeといった属性によって修正されます。なので、例えばスーパーユーザーに対して追加的なフィールドを与えたい場合は、以下のように基本のフォームを変更できます:\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)\n
\nModelFormクラスを直接返すこともできます。
- \n
- \nModelAdmin.get_formsets_with_inlines(request, obj=None)Link to this definition# \n
admin の追加や変更のビューで使用するための (
\nFormSet,InlineModelAdmin) ペアを生成します。たとえば、変更ビューのみで特定のインラインを表示したい場合、以下のように
\nget_formsets_with_inlinesをオーバーライドできます。\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
\nModelAdminのformfield_for_foreignkeyを使うと、ForignKey フィールドに対するデフォルトのフォームフィールドをオーバーライドできます。たとえば、ユーザーに基づいてこの ForeignKey フィールドに対するオブジェクトのサブセットを返すには:\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)\nこれは、
\nHttpRequestインスタンスを使ってCarForeignKey フィールドをフィルタし、特定のUserインスタンスが所有する car のみを表示します。より複雑なフィルタを行うには、
\nModelForm.__init__()メソッドを使用することで、モデルのinstanceに基づいたフィルタを行うことができます (リレーションシップを扱うフィールド を参照してください)。たとえば:\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
\nformfield_for_foreignkeyメソッドと同じように、formfield_for_manytomanyメソッドをオーバーライドすると ManyToMany に対するデフォルトのフォームフィールドを変更できます。たとえば、あるオーナーは複数の car を所有でき、また car は複数のオーナーに所有されるとすると（多対多の関係です）Carのフィールドをフィルタして特定のUserが所有する car だけを表示できます:\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
\nformfield_for_foreignkeyやformfield_for_manytomanyメソッドと同じように、formfield_for_choice_fieldメソッドをオーバーライドすると選択肢として宣言されたフィールドに対するデフォルトのフォームフィールドを変更できます。 たとえば、スーパーユーザーと通常のスタッフで表示する選択肢を違うものにしたい場合、以下のように記述できます:\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
リスト作成に使われる
\nChangelistを返します。デフォルトでは、django.contrib.admin.views.main.ChangeListが使われます。このクラスを継承することで、リスト作成の動作を変更できます。
- \n
- \nModelAdmin.get_changelist_form(request, **kwargs)Link to this definition# \n
チェンジリストページの
\nFormsetで使うためのModelFormクラスを返します。カスタムフォームを使うには、たとえば、次のようにします。\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
\nlist_editableを使っている場合、チェンジリストページで使用するための ModelFormSet クラスを返します。カスタムのフォームセットを使うには、たとえば、次のようにします。\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
チェンジリストページのオブジェクトは URL のクエリ文字列からルックアップしてフィルタすることができます。たとえば、
\nlist_filterはその仕組みで動作します。ルックアップはQuerySet.filter()(例user__email=user@example.com) で使われているものと似ています。クエリ文字列のルックアップはユーザによって操作される可能性があるため、無許可のデータ漏洩を防ぐためにサニタイズする必要があります。
\nlookup_allowed()メソッドには、クエリ文字列 ('user__email'など)、対応する値 ('user@example.com'など)、リクエストからのルックアップパスが渡され、パラメータを使用したチェンジリストのQuerySetのフィルタリングが許可されているかどうかを示す真偽値を返します。lookup_allowed()がFalseを返した場合、DisallowedModelAdminLookup(SuspiciousOperationのサブクラス) が発生します。デフォルトでは、
\nlookup_allowed()はモデルのローカルフィールド、list_filterで使用されるフィールドパス (ただし、get_list_filter()からのパスは使用できません)、limit_choices_toがraw_id_fieldsで正しく機能するために必要なルックアップへのアクセスを許可します。
\n\nModelAdminサブクラスで許可されるルックアップをカスタマイズするには、このメソッドをオーバーライドします。
- \n
- \nModelAdmin.has_view_permission(request, obj=None)Link to this definition# \n
\nobjの閲覧が許可されている場合はTrueを、そうでなければFalseを返します。obj がNoneの場合、この種類のオブジェクトの閲覧が一般的に許可されているかどうかを表すよう、TrueかFalseを指定します (たとえば、Falseは現在のユーザーがこの種類のすべてのオブジェクトを閲覧できないことを意味します)。デフォルトの実装では、ユーザーが "change" か "view" 権限を持っていれば
\nTrueを返します。
- \n
- \nModelAdmin.has_add_permission(request)Link to this definition# \n
オブジェクトの追加が許可されていれば
\nTrueを、そうでなければFalseを返します。
- \n
- \nModelAdmin.has_change_permission(request, obj=None)Link to this definition# \n
\nobjの編集が許可されている場合はTrueを、そうでなければFalseを返します。objがNoneの場合、この種類のオブジェクトの編集が一般的に許可されているかどうかを表すよう、TrueかFalseを指定します (たとえば、Falseは現在のユーザーがこの種類のすべてのオブジェクトを編集できないことを意味します)。
- \n
- \nModelAdmin.has_delete_permission(request, obj=None)Link to this definition# \n
\nobjの削除が許可されている場合はTrueを、そうでなければFalseを返します。objがNoneの場合、この種類のオブジェクトの削除が一般的に許可されているかどうかを表すよう、TrueかFalseを指定します (たとえば、Falseは現在のユーザーがこの種類のすべてのオブジェクトを削除できないことを意味します)。
- \n
- \nModelAdmin.has_module_permission(request)Link to this definition# \n
admin のインデックスページでモジュールを表示し、そのモジュールへのアクセスを許可する場合は
\nTrueを、そうでなければFalseを返します。デフォルトではUser.has_module_perms()を使用します。 オーバーライドしても閲覧、追加、変更、削除のアクセス権は制限しません。アクセス権の制限にはhas_view_permission()、has_add_permission()、has_change_permission()、has_delete_permission()を使用してください。
- \n
- \nModelAdmin.get_queryset(request)Link to this definition# \n
\nModelAdminのget_querysetメソッドは admin サイトで編集可能なモデルインスタンスのすべてのQuerySetを返します。このメソッドをオーバーライドする場面の 1 つは、ログイン中のユーザーが所有するオブジェクトを表示することです:\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
\ndjango.contrib.messagesバックエンドを使ってユーザーにメッセージを送ります。カスタムの ModelAdmin の例 を参照してください。キーワード引数を使うと、メッセージレベルを変更したり、余分な CSS タグを追加したり、
\ncontrib.messageフレームワークがインストールされていない場合にサイレントエラーにしたりすることができます。これらのキーワード引数はdjango.contrib.messages.add_message()の引数と同じです。詳しくはその関数のドキュメントを参照してください。違いの一つは、レベルを整数/定数の他に文字列ラベルとして渡せる点です。
- \n
- \nModelAdmin.get_paginator(request, queryset, per_page, orphans=0, allow_empty_first_page=True)Link to this definition# \n
このビューで使用する paginator のインスタンスを返します。デフォルトでは
\npaginatorのインスタンスを返します。
- \n
- \nModelAdmin.response_add(request, obj, post_url_continue=None)Link to this definition# \n
\nadd_view()ステージに対するHttpResponseを決定します。
\nresponse_addは、admin フォームが送信され、オブジェクトとすべての関係インスタンスが作成および保存された直後に呼び出されます。オーバーライドすることで、オブジェクトが作成された後のデフォルトの動作を変更できます。
- \n
- \nModelAdmin.response_change(request, obj)Link to this definition# \n
\nchange_view()ステージに対するHttpResponseを決定します。
\nresponse_changeは、admin フォームが送信され、オブジェクトとすべての関係インスタンスが保存された直後に呼び出されます。オーバーライドすることで、オブジェクトが変更された後のデフォルトの動作を変更できます。
- \n
- \nModelAdmin.response_delete(request, obj_display, obj_id)Link to this definition# \n
\ndelete_view()ステージに対するHttpResponseを決定します。
\nresponse_deleteは、オブジェクトが削除された後に呼び出されます。オーバーライドすることで、オブジェクトが削除された後のデフォルトの動作を変更できます。
\nobj_displayは削除されたオブジェクトの名前を表す文字列です。
\nobj_idは削除するオブジェクトを取得するために使用するシリアライズされた識別子です。
- \n
- \nModelAdmin.get_formset_kwargs(request, obj, inline, prefix)Link to this definition# \n
フォームセットのコンストラクタに渡されるキーワード引数をカスタマイズするためのフックです。たとえばフォームセットのフォームに
\nrequestを渡すには:\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 }\nまた、フォームセットのフォームに
\ninitialを指定するためにも使用できます。
- \n
- \nModelAdmin.get_changeform_initial_data(request)Link to this definition# \n
admin の変更フォームの初期データに対するフックです。デフォルトでは、フィールドには
\nGETパラメータで初期値が与えられます。たとえば、?name=initial_valueはnameフィールドの初期値をinitial_valueにセットします。このメソッドは、
\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
\ndelete_view()と "delete selected" アクション の削除処理をカスタマイズするフックです。引数
\nobjsは削除するオブジェクト (QuerySetまたはモデルインスタンスのリスト) の同型イテラブルで、requestはHttpRequestです。このメソッドは
\n(deleted_objects, model_count, perms_needed, protected)の4タプルを返さなければなりません。
\ndeleted_objectsは削除されるすべてのオブジェクトを表す文字列のリストです。削除されるオブジェクトにリレーション先オブジェクトがある場合、リストはネストされ、それらのリレーション先オブジェクトも含まれます。リストはテンプレート内でunordered_listフィルタを使ってフォーマットされます。
\nmodel_countは各モデルのverbose_name_pluralと削除されるオブジェクトの数をマッピングした辞書です。
\nperms_needはverbose_nameのセットで、ユーザが削除する権限を持っていないモデルです。
\nprotectedは削除できない保護されたリレーション先オブジェクトを表す文字列のリストです。このリストはテンプレートに表示されます。
その他のメソッドLink to this heading#
\n- \n
- \nModelAdmin.add_view(request, form_url='', extra_context=None)Link to this definition# \n
モデルインスタンスの追加ページに対する Django のビューです。以下のノートを参照してください。
\n
- \n
- \nModelAdmin.change_view(request, object_id, form_url='', extra_context=None)Link to this definition# \n
モデルインスタンスの編集ページに対する Django のビューです。以下のノートを参照してください。
\n
- \n
- \nModelAdmin.changelist_view(request, extra_context=None)Link to this definition# \n
モデルインスタンスの変更リスト（チェンジリスト）およびアクションページに対する Django のビューです。以下のノートを参照してください。
\n
- \n
- \nModelAdmin.delete_view(request, object_id, extra_context=None)Link to this definition# \n
モデルインスタンスの削除の確認ページに対する Django のビューです。以下のノートを参照してください。
\n
- \n
- \nModelAdmin.history_view(request, object_id, extra_context=None)Link to this definition# \n
与えられたモデルのインスタンスに対する修正履歴を表示するページに対する Django のビューです。
\n
前の節で詳しく説明したフック型の ModelAdmin メソッドとは異なり、これら 5 つのメソッドは、実際には admin アプリケーションの URL ディスパッチハンドラから Django ビューとして呼び出され、モデルインスタンスの CRUD 操作を扱うページをレンダリングするように設計されています。そのため、これらのメソッドを完全にオーバーライドすると、 admin アプリケーションの動作が大きく変わってしまいます。
これらのメソッドをオーバーライドする一般的な理由の 1 つは、ビューをレンダリングするテンプレートに提供されるコンテキスト・データを補強することです。以下の例では、change ビューがオーバーライドされ、レンダリングされるテンプレートに、他の方法では利用できないマッピング・データが提供されます:
\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 )\nこれらのビューは TemplateResponse インスタンスを返し、レンダリング前のレスポンスデータを簡単にカスタマイズできます。詳細は TemplateResponse のドキュメント を参照してください。
ModelAdmin アセットの定義Link to this heading#
\nビューを追加したり変更したりするために、CSS や JavaScript を追加したいことがあるかもしれません。そういうときには ModelAdmin の Media インナークラスを使用します:
class ArticleAdmin(admin.ModelAdmin):\n class Media:\n css = {\n "all": ["my_styles.css"],\n }\n js = ["my_code.js"]\nstaticfiles アプリ は、すべてのアセットのパスの前に STATIC_URL (STATIC_URL が None の場合は MEDIA_URL) を付与します。 フォーム上の通常のアセット定義 と同じルールが適用されます。
jQueryLink to this heading#
\nDjango admin の JavaScript は jQuery ライブラリを使用します。
\nユーザが提供するスクリプトやライブラリとの衝突を避けるため、 Django の jQuery (version 3.7.1) は django.jQuery という名前空間になっています。自分の admin JavaScript で jQuery を使いたい場合、別のコピーを入れなくても、 django.jQuery オブジェクトをチェンジリストやadd/edit ビューで使用できます。また、 django.jQuery に依存する独自の管理フォームやウィジェットは、 フォーム メディア アセットの宣言 の際に js=['admin/js/jquery.init.js', …] を指定しなければなりません。
ModelAdmin クラスはデフォルトで jQuery を要件とするので、特別なニーズがない限り jQuery をメディアリソースの ModelAdmin のリストに追加する必要はありません。たとえば、jQuery ライブラリがグローバルな名前空間を持つ必要がある場合 (たとえば、サードパーティの jQuery プラグインを使用する場合など)、もしくは jQuery の新しいバージョンを使いたい場合には、自分自身でコピーを用意する必要があります。
Django には、非圧縮と 'minified' のバージョンのjQuery があり、それぞれ jquery.js と jquery.min.js となっています。
ModelAdmin と InlineModelAdmin には、フォームやフォームセットのJavaScriptファイルへのパスを格納する Media オブジェクトのリストを返す media プロパティがあります。 DEBUG が True の場合、 jquery.js を含む様々な JavaScript ファイルの圧縮されていないバージョンを返します。そうでない場合は、 "minify" されたバージョンを返します。
カスタムのバリデーションを admin に追加するLink to this heading#
\nまた、管理画面でデータのカスタムバリデーションを追加することもできます。自動管理インターフェイスは django.forms を再利用し、 ModelAdmin クラスは独自のフォームを定義する機能を提供します:
class ArticleAdmin(admin.ModelAdmin):\n form = MyArticleAdminForm\nMyArticleAdminForm は必要な場所をインポートすればどこでも定義できます。これでフォームの中で任意のフィールドに対して独自のカスタムバリデーションを追加できます:
class MyArticleAdminForm(forms.ModelForm):\n def clean_name(self):\n # do something that validates your data\n return self.cleaned_data["name"]\nここで ModelForm を使用することは重要です。そうしないと問題が発生する可能性があります。 カスタムバリデーション に関する フォーム のドキュメント、そしてより具体的には モデルフォームのバリデーションに関する注意事項 を参照してください。