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 myproject.myapp.models import Author\n\nclass AuthorAdmin(admin.ModelAdmin):\n pass\nadmin.site.register(Author, AuthorAdmin)\n
register デコレータLink to this heading#
\n- \n
- \nregister(*models, site=django.admin.sites.site)Link to this definition# \n
\nModelAdminを登録するために、デレコータも用意されています:\nfrom django.contrib import admin\nfrom .models import Author\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@admin.register(Author, Reader, Editor, site=custom_admin_site)\nclass PersonAdmin(admin.ModelAdmin):\n pass\nYou can't use this decorator if you have to reference your model admin\nclass in its
\n__init__()method, e.g.\nsuper(PersonAdmin, self).__init__(*args, **kwargs). You can use\nsuper().__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
- \n
これはデフォルトの admin サイトのクラスやサイトインスタンスを返す呼び出し可能オブジェクトへのドット区切りのインポートパスです。デフォルトは
\n'django.contrib.admin.sites.AdminSite'です。使い方は Overriding the default admin site を参照してください。
- \n
- \nautodiscover()Link to this definition# \n
この関数は、インストールされた各アプリケーション内で
\nadminモジュールをインポートするよう試みます。これらのモジュールは admin にモデルが登録されているものと想定されます。通常、この機能を手動で呼び出す必要はありません。Django が開始するとき
\nAdminConfigが呼び出してくれます。
If you are using a custom AdminSite, it is common to import all of the\nModelAdmin subclasses into your code and register them to the custom\nAdminSite. In that case, in order to disable auto-discovery, you should\nput 'django.contrib.admin.apps.SimpleAdminConfig' instead of\n'django.contrib.admin' in your INSTALLED_APPS setting.
ModelAdmin のオプションLink to this heading#
\nModelAdmin は非常に柔軟にできています。インターフェイスをカスタマイズするために、様々なオプションが用意されています。すべてのプションは ModelAdmin サブクラスで定義します:
from django.contrib import admin\n\nclass AuthorAdmin(admin.ModelAdmin):\n date_hierarchy = 'pub_date'\n- \n
- \nModelAdmin.actionsLink to this definition# \n
チェンジリストページで有効化するアクションのリストです。詳細は Admin actions を参照してください。
\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\nclass AuthorAdmin(admin.ModelAdmin):\n empty_value_display = '-empty-'\n
\nAdminSite.empty_value_displayですべての admin ページもしくは特定のフィールドに対してempty_value_displayをオーバーライドすることもできます:\nfrom django.contrib import admin\n\nclass AuthorAdmin(admin.ModelAdmin):\n fields = ('name', 'title', 'view_birth_date')\n\n def view_birth_date(self, obj):\n return obj.birth_date\n\n view_birth_date.empty_value_display = '???'\n
- \n
- \nModelAdmin.excludeLink to this definition# \n
この属性を使用する場合、フォームから除外するフィールドの名称をリストで指定します。
\nたとえば、以下のモデルを考えてみましょう:
\n\nfrom django.db import models\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\nclass AuthorAdmin(admin.ModelAdmin):\n fields = ('name', 'title')\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で定義される値を持つことができ、読み込み専用で表示されます。より複雑なレイアウトを作るには、the
\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\nclass FlatPageAdmin(admin.ModelAdmin):\n fieldsets = (\n (None, {\n 'fields': ('url', 'title', 'content', 'sites')\n }),\n ('Advanced options', {\n 'classes': ('collapse',),\n 'fields': ('registration_required', 'template_name'),\n }),\n )\nこれにより、admin ページは以下のような見た目となります:
\n![\"/ja/2.2/_images/fieldsets.png\"](\"/ja/2.2/_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
descriptionA string of optional extra text to be displayed at the top of each\nfieldset, under the heading of the fieldset. This string is not\nrendered for
\nTabularInlinedue to its\nlayout.Note that this value is not HTML-escaped when it's displayed in\nthe admin interface. This lets you include HTML if you so desire.\nAlternatively you can use plain text and\n
\ndjango.utils.html.escape()to escape any HTML special\ncharacters. \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\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 つの種類があります:- \n
モデルフィールドの名前。たとえば:
\n\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ('first_name', 'last_name')\n\n1 つの引数 (モデルのインスタンス) を受け入れるカラブルです。たとえば:
\n\ndef upper_case_name(obj):\n return ("%s %s" % (obj.first_name, obj.last_name)).upper()\nupper_case_name.short_description = 'Name'\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 def upper_case_name(self, obj):\n return ("%s %s" % (obj.first_name, obj.last_name)).upper()\n upper_case_name.short_description = 'Name'\n\nモデルの属性や (必須の引数を持たない) メソッドを表す文字列です。たとえば:
\n\nfrom django.contrib import admin\nfrom django.db import models\n\nclass Person(models.Model):\n name = models.CharField(max_length=50)\n birthday = models.DateField()\n\n def decade_born_in(self):\n return self.birthday.strftime('%Y')[:3] + "0's"\n decade_born_in.short_description = 'Birth decade'\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の代わりにかわいい "on" か "off" のアイコンを表示します。 \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\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 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\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ('first_name', 'last_name', 'colored_name')\n\nこれまでの例で見てきたように、カラブル、モデルメソッド、
ModelAdminのいずれかを使っているとき、カラブルにshort_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 def birth_date_view(self, obj):\n return obj.birth_date\n\n birth_date_view.empty_value_display = 'unknown'\n\n与えられた文字列が、モデルのメソッド、True か False を返す
\nModelAdmin、カラブルのどれかの場合、メソッドに値がTrueのboolean属性を与えれば、Django は かわいい "on" か "off" のアイコンを表示します。以下は、モデルの例です:
\n\nfrom django.contrib import admin\nfrom django.db import models\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n birthday = models.DateField()\n\n def born_in_fifties(self):\n return self.birthday.strftime('%Y')[:3] == '195'\n born_in_fifties.boolean = True\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の要素が特定のデータベースフィールドを表す場合、アイテムのadmin_order_field属性をセットすることでこの事実を伝えることができます。例:
\n\nfrom django.contrib import admin\nfrom django.db import models\nfrom django.utils.html import format_html\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n color_code = models.CharField(max_length=6)\n\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 colored_first_name.admin_order_field = 'first_name'\n\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ('first_name', 'colored_first_name')\n上記のコードは、admin 内で
\ncolored_first_nameで ソートしようとするとき、first_nameフィールドで並べ替えるよう Django に伝えます。
\nadmin_order_fieldを降順で並べ替えるには、フィールド名にハイフンのプレフィクスが使えます。上の例を書き換えると、以下のようになります:\ncolored_first_name.admin_order_field = '-first_name'\n
\nadmin_order_fieldは関係モデルの値でソートするため、クエリ検索をサポートしています。以下の例は list display に "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\nclass BlogAdmin(admin.ModelAdmin):\n list_display = ('title', 'author', 'author_first_name')\n\n def author_first_name(self, obj):\n return obj.author.first_name\n\n author_first_name.admin_order_field = 'author__first_name'\n
\nadmin_order_field内では Query 表現 を使うことができます。たとえば:\n\nfrom django.db.models import Value\nfrom django.db.models.functions import Concat\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n last_name = models.CharField(max_length=50)\n\n def full_name(self):\n return self.first_name + ' ' + self.last_name\n full_name.admin_order_field = Concat('first_name', Value(' '), 'last_name')\n\nElements of
\nlist_displaycan also be properties. Please note however,\nthat due to the way properties work in Python, setting\nshort_descriptionon a property is only possible when using the\nproperty()function and not with the@propertydecorator.例:
\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n last_name = models.CharField(max_length=50)\n\n def my_property(self):\n return self.first_name + ' ' + self.last_name\n my_property.short_description = "Full name of the person"\n\n full_name = property(my_property)\n\nclass PersonAdmin(admin.ModelAdmin):\n list_display = ('full_name',)\n\nThe field names in
list_displaywill also appear as CSS classes in\nthe HTML output, in the form ofcolumn-<field_name>on each<th>\nelement. This can be used to set column widths in a CSS file for example. \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をセットしてください。:![\"/ja/2.2/_images/list_filter.png\"](\"/ja/2.2/_images/list_filter.png\")
\n
\nlist_filterは要素のリストかタプルで、各要素は以下のいずれかの種類となります:- \n
フィールドの名称で、フィールドには
\nBooleanField、CharField、DateField、DateTimeField、IntegerField、ForeignKey、ManyToManyFieldのどれかを指定します。たとえば:\nclass PersonAdmin(admin.ModelAdmin):\n list_filter = ('is_staff', 'company')\n
\nlist_filter内のフィールド名は``__`` ルックアップを使って関係先を参照できます。たとえば:\nclass PersonAdmin(admin.UserAdmin):\n list_filter = ('company__name',)\n\n
\ndjango.contrib.admin.SimpleListFilterを継承したクラスで、title` とparameter_name属性を指定し、またlookupsとquerysetメソッドをオーバーライドする必要があります。たとえば:\n\nfrom datetime import date\n\nfrom django.contrib import admin\nfrom django.utils.translation import gettext_lazy as _\n\nclass DecadeBornListFilter(admin.SimpleListFilter):\n # Human-readable title which will be displayed in the\n # right admin sidebar just above the filter options.\n title = _('decade born')\n\n # Parameter for the filter that will be used in the URL query.\n parameter_name = 'decade'\n\n def lookups(self, request, model_admin):\n """\n Returns a list of tuples. The first element in each\n tuple is the coded value for the option that will\n appear in the URL query. The second element is the\n human-readable name for the option that will appear\n in the right sidebar.\n """\n return (\n ('80s', _('in the eighties')),\n ('90s', _('in the nineties')),\n )\n\n def queryset(self, request, queryset):\n """\n Returns the filtered queryset based on the value\n provided in the query string and retrievable via\n `self.value()`.\n """\n # Compare the requested value (either '80s' or '90s')\n # to decide how to filter the queryset.\n if self.value() == '80s':\n return queryset.filter(birthday__gte=date(1980, 1, 1),\n birthday__lte=date(1989, 12, 31))\n if self.value() == '90s':\n return queryset.filter(birthday__gte=date(1990, 1, 1),\n birthday__lte=date(1999, 12, 31))\n\nclass PersonAdmin(admin.ModelAdmin):\n list_filter = (DecadeBornListFilter,)\n\nタプルで、最初の要素がフィールド名で、2 番目の要素が
\ndjango.contrib.admin.FieldListFilterを継承したクラスです。たとえば:\nclass PersonAdmin(admin.ModelAdmin):\n list_filter = (\n ('is_staff', admin.BooleanFieldListFilter),\n )\n
\nRelatedOnlyFieldListFilterを使って、関係内に含まれたオブジェクトへの関係モデルの選択肢を制限することができます:\nclass BookAdmin(admin.ModelAdmin):\n list_filter = (\n ('author', admin.RelatedOnlyFieldListFilter),\n )\n
\n\nauthorがUserモデルへのForeignKeyと仮定すると、list_filterの選択肢が全ユーザーではなく book を書いたことがあるユーザーだけに絞られます。 \n
List filter's typically appear only if the filter has more than one choice.\nA filter's
\nhas_output()method controls whether or not it appears.It is possible to specify a custom template for rendering a list filter:
\n\nclass FilterWithCustomTemplate(admin.SimpleListFilter):\n template = "custom_template.html"\n具体的な例については、Django により提供されるデフォルトのテンプレート (
\nadmin/filter.html) を参照してください。
- \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
Set
\nprepopulated_fieldsto a dictionary mapping field names to the\nfields it should prepopulate from:\nclass ArticleAdmin(admin.ModelAdmin):\n prepopulated_fields = {"slug": ("title",)}\nWhen set, the given fields will use a bit of JavaScript to populate from\nthe fields assigned. The main use for this functionality is to\nautomatically generate the value for
\nSlugFieldfields from one or more\nother fields. The generated value is produced by concatenating the values\nof the source fields, and then by transforming that result into a valid\nslug (e.g. substituting dashes for spaces; lowercasing ASCII letters; and\nremoving various English stop words such as 'a', 'an', 'as', and similar).Prepopulated fields aren't modified by JavaScript after a value has been\nsaved. It's usually undesired that slugs change (which would cause an\nobject's URL to change if the slug is used in it).
\n
\nprepopulated_fieldsはDateTimeField、ForeignKey、OneToOneField、ManyToManyFieldフィールドを受け入れません。
- \n
- \nModelAdmin.preserve_filtersLink to this definition# \n
admin は現在、オブジェクトの作成、編集、削除を行った後もリストビューのフィルタを維持します。この属性を
\nFalseにセットすると、フィルタをクリアする以前の挙動に戻すことができます。
- \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\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/2.2/_images/raw_id_fields.png\"](\"/ja/2.2/_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 のフィールドはモデルのフィールドからデータを表示するだけではなく、モデルや``ModelAdmin`` クラス自身のメソッドの出力を表示させることもできます。これは
\nModelAdmin.list_displayの挙動に似ています。これにより、編集中のオブジェクトのステータスのフィードバックを admin インターフェースに与えることが簡単にできるようになります。例えば:\nfrom django.contrib import admin\nfrom django.utils.html import format_html_join\nfrom django.utils.safestring import mark_safe\n\nclass PersonAdmin(admin.ModelAdmin):\n readonly_fields = ('address_report',)\n\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 # short_description functions like a model field's verbose_name\n address_report.short_description = "Address"\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例えば、著者の情報を持つブログエントリーの場合、以下の定義により、著者の E メールアドレスによるブログエントリーの検索が可能となります:
\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検索に
\nicontainsを使いたくない場合、フィールドに検索方法を追加することで、好きな方法を使うことができます。例えば、search_fieldsに['first_name__exact']をセットすればexactを使えます。前述の通り、クエリ条件は分割されて AND で再構成されるので、
\n\nexactを使った検索は単一の単語の検索でしか機能しません。これは、すべての単語がまったく同じ場合以外、2 語以上が完全一致することはないからです。いくつかの (古い) ショートカットを使って、フィールドの検索方法を指定することもできます。以下の文字で
\nsearch_fields内のフィールドにプレフィックスを追加できます。これはフィールドに__<lookup>を追加するのと同等です:\n\n\n
\nプレフィックス
検索方法
^
\n =
\n @
\n None
\n 検索方法をカスタムする必要がある場合は、
\nModelAdmin.get_search_results()を使って追加的もしくは代替の検索方法を提供することができます。
- \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
- \n
デフォルトでは、チェンジリストページでは
\nlist_displayで指定したすべてのモデルフィールド (とadmin_order_fieldプロパティを持つカラブル) で並び替えが可能です。特定のカラムでの並び替えを無効化したい場合、
\nsortable_by``に :attr:`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\nclass PersonAdmin(admin.ModelAdmin):\n view_on_site = False\nカラブルの場合、引数にモデルのインスタンスを受け入れます。例えば:
\n\nfrom django.contrib import admin\nfrom django.urls import reverse\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#
\nOverriding admin templates セクションでは、デフォルトの 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アクションメソッドで使われます。actions documentation を参照してください。
- \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\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
- \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()\nSaving objects in the formset もご覧ください。
\n
- \n
- \nModelAdmin.get_ordering(request)Link to this definition# \n
\nget_orderingメソッドは引数にrequestを取り、orderingのときと同じようなlistかtupleを返すことが期待されます。例えば:\nclass PersonAdmin(admin.ModelAdmin):\n\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, use_distinct = super().get_search_results(request, queryset, search_term)\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, use_distinct\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
- \n
\nget_list_displayメソッドには、HttpRequestが渡され、チェンジリストページ並び替え可能にするフィールドの名前の コレクション (例:list、tuple、set) を返すことが期待されます。デフォルトの実装では、セットされている場合は
\nsortable_byを返します。セットされていなければget_list_display()を参照します。例えば、1 つ以上のカラムを並び替え不可にするには:
\n\nclass PersonAdmin(admin.ModelAdmin):\n\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
The
\nget_inline_instancesmethod is given theHttpRequestand the\nobjbeing edited (orNoneon an add form) and is expected to return\nalistortupleofInlineModelAdmin\nobjects, as described below in theInlineModelAdmin\nsection. For example, the following would return inlines without the default\nfiltering based on add, change, delete, and view permissions:\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_urls()Link to this definition# \n
\nModelAdminのget_urlsメソッドは、URLconf と同じ方法で、その ModelAdmin に対して使用される URL を返します。したがって、URL ディスパッチャ と同じように拡張することができます:\nfrom django.contrib import admin\nfrom django.template.response import TemplateResponse\nfrom django.urls import path\n\nclass MyModelAdmin(admin.ModelAdmin):\n def get_urls(self):\n urls = super().get_urls()\n my_urls = [\n path('my_view/', self.my_view),\n ]\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{% extends "admin/base_site.html" %}\n{% block content %}\n...\n{% endblock %}\nHowever, the
\nself.my_viewfunction registered above suffers from two\nproblems:- \n
It will not perform any permission checks, so it will be accessible\nto the general public.
\nIt will not provide any header details to prevent caching. This means\nif the page retrieves data from the database, and caching middleware is\nactive, the page could show outdated information.
\n
Since this is usually not what you want, Django provides a convenience\nwrapper to check permissions and mark the view as non-cacheable. This\nwrapper is
\nAdminSite.admin_view()(i.e.self.admin_site.admin_view\ninside aModelAdmininstance); use it like so:\nclass MyModelAdmin(admin.ModelAdmin):\n def get_urls(self):\n urls = super().get_urls()\n my_urls = [\n path('my_view/', self.admin_site.admin_view(self.my_view))\n ]\n return my_urls + urls\nNotice the wrapped view in the fifth line above:
\n\npath('my_view/', self.admin_site.admin_view(self.my_view))\nThis wrapping will protect
\nself.my_viewfrom unauthorized access and\nwill apply thedjango.views.decorators.cache.never_cache()decorator to\nmake sure it is not cached if the cache middleware is active.If the page is cacheable, but you still want the permission check to be\nperformed, you can pass a
\ncacheable=Trueargument to\nAdminSite.admin_view():\npath('my_view/', self.admin_site.admin_view(self.my_view, cacheable=True))\n
\nModelAdminviews havemodel_adminattributes. Other\nAdminSiteviews haveadmin_siteattributes.
- \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 のみを表示します。
- \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'] += (('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\nclass MyForm(forms.ModelForm):\n pass\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\nclass MyAdminFormSet(BaseModelFormSet):\n pass\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)Link to this definition# \n
The objects in the changelist page can be filtered with lookups from the\nURL's query string. This is how
\nlist_filterworks, for example. The\nlookups are similar to what's used inQuerySet.filter()(e.g.\nuser__email=user@example.com). Since the lookups in the query string\ncan be manipulated by the user, they must be sanitized to prevent\nunauthorized data exposure.The
\nlookup_allowed()method is given a lookup path from the query string\n(e.g.'user__email') and the corresponding value\n(e.g.'user@example.com'), and returns a boolean indicating whether\nfiltering the changelist'sQuerySetusing the parameters is permitted.\nIflookup_allowed()returnsFalse,DisallowedModelAdminLookup\n(subclass ofSuspiciousOperation) is raised.By default,
\nlookup_allowed()allows access to a model's local fields,\nfield paths used inlist_filter(but not paths from\nget_list_filter()), and lookups required for\nlimit_choices_toto function\ncorrectly inraw_id_fields.Override this method to customize the lookups permitted for your\n
\nModelAdminsubclass.
- \n
- \nModelAdmin.has_view_permission(request, obj=None)Link to this definition# \n
- \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バックエンドを使ってユーザーにメッセージを送ります。custom ModelAdmin example を参照してください。Keyword arguments allow you to change the message level, add extra CSS\ntags, or fail silently if the
\ncontrib.messagesframework is not\ninstalled. These keyword arguments match those for\ndjango.contrib.messages.add_message(), see that function's\ndocumentation for more details. One difference is that the level may be\npassed as a string label in addition to integer/constant.
- \n
- \nModelAdmin.get_paginator(request, queryset, per_page, orphans=0, allow_empty_first_page=True)Link to this definition# \n
ビューに対して使う paginator to のインスタンスを返します。デフォルトでは、
\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は、オブジェクトが削除された後に呼び出されます。オーバーライドすることで、オブジェクトが削除された後のデフォルトの挙動を変更することができます。``obj_display``は削除されたオブジェクトの名前を表す文字列です。
\n
\nobj_idis the serialized identifier used to retrieve the object to be\ndeleted.
- \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
- \n
A hook for customizing the deletion process of the
\ndelete_view()and\nthe "delete selected" action.The
\nobjsargument is a homogeneous iterable of objects (aQuerySet\nor a list of model instances) to be deleted, andrequestis the\nHttpRequest.This method must return a 4-tuple of\n
\n(deleted_objects, model_count, perms_needed, protected).
\ndeleted_objectsis a list of strings representing all the objects that\nwill be deleted. If there are any related objects to be deleted, the list\nis nested and includes those related objects. The list is formatted in the\ntemplate using theunordered_listfilter.
\nmodel_countis a dictionary mapping each model's\nverbose_name_pluralto the number of\nobjects that will be deleted.
\nperms_neededis a set ofverbose_names\nof the models that the user doesn't have permission to delete.
\nprotectedis a list of strings representing of all the protected\nrelated objects that can't be deleted. The list is displayed in the\ntemplate.
その他のメソッド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
Unlike the hook-type ModelAdmin methods detailed in the previous section,\nthese five methods are in reality designed to be invoked as Django views from\nthe admin application URL dispatching handler to render the pages that deal\nwith model instances CRUD operations. As a result, completely overriding these\nmethods will significantly change the behavior of the admin application.
One common reason for overriding these methods is to augment the context data\nthat is provided to the template that renders the view. In the following\nexample, the change view is overridden so that the rendered template is\nprovided some extra mapping data that would not otherwise be available:
\nclass MyModelAdmin(admin.ModelAdmin):\n\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, object_id, form_url, extra_context=extra_context,\n )\nThese views return TemplateResponse\ninstances which allow you to easily customize the response data before\nrendering. For more details, see the TemplateResponse documentation.
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 app は、すべてのアセットのパスに STATIC_URL (STATIC_URL が None の場合は MEDIA_URL) を prepend します。regular asset definitions on forms と同じルールが適用されます。
jQueryLink to this heading#
\nDjango admin の JavaScript は jQuery ライブラリを使用します。
\nユーザーのスクリプトやライブラリとの競合を避けるため、Django の jQuery (version 3.3.1) は django.jQuery という名前空間にあります。jQuery を自身の admin の JavaScript で使うとき、別途ライブラリを準備しないで、チェンジリストや追加、編集ビュー上で django.jQuery オブジェクトを使うことができます。
ModelAdmin クラスはデフォルトで jQuery を要件とするので、特別なニーズがない限り jQuery をメディアリソースの ModelAdmin のリストに追加する必要はありません。例えば、jQuery ライブラリがグローバルな名前空間を持つ必要がある場合 (例えばサードパーティの jQuery プラグインを使用する場合など)、もしくは jQuery の新しいバージョンを使いたい場合には、自分自身でコピーを用意する必要があります。
Django には、非圧縮と 'minified' のバージョンのjQuery があり、それぞれ jquery.js と``jquery.min.js`` となっています。
ModelAdmin and InlineModelAdmin have a media property\nthat returns a list of Media objects which store paths to the JavaScript\nfiles for the forms and/or formsets. If DEBUG is True it will\nreturn the uncompressed versions of the various JavaScript files, including\njquery.js; if not, it will return the 'minified' versions.
カスタムのバリデーションを admin に追加するLink to this heading#
\nAdding custom validation of data in the admin is quite easy. The automatic\nadmin interface reuses django.forms, and the ModelAdmin class gives\nyou the ability define your own form:
class ArticleAdmin(admin.ModelAdmin):\n form = MyArticleAdminForm\nMyArticleAdminForm can be defined anywhere as long as you import where\nneeded. Now within your form you can add your own custom validation for\nany field:
class MyArticleAdminForm(forms.ModelForm):\n def clean_name(self):\n # do something that validates your data\n return self.cleaned_data["name"]\nIt is important you use a ModelForm here otherwise things can break. See\nthe forms documentation on custom validation and, more specifically, the\nmodel form validation notes for more\ninformation.