理由はよくわかりませんが、個人的には、ModelAdminにモンキーパッチを適用する代わりに、特定のモデルの変更リストテンプレートを上書き(または拡張)する傾向があります。
編集:
ありがとうございますが、テンプレートをオーバーライドするだけでは実行できないカスタマイズが必要です。たとえば、別のクエリセットを表示するなど。
別のクエリセットを表示するために、ModelAdmin.queryset()をオーバーライドできます。
また、リストされているアイテムを編集できないようにする必要があります。テンプレートを上書きすると、編集フォームへのリンクは表示されませんが、フォームへのURLを推測できる場合は、フォームにアクセスしてURLを入力することで編集できます。これはセキュリティホールになります。
問題のユーザーから編集権限を削除してみませんか?「追加」ビューと「変更」ビューをオーバーライドすることもできます。
class SomeModelAdmin(admin.ModelAdmin):
...
def change_view(self, request, object_id, extra_context=None):
return render_to_response('forbiden_operation.html', dict(op='edit'))
def ModelAdmin.add_view(self, request, form_url='', extra_context=None):
return render_to_response('forbiden_operation.html', dict(op='add'))
これらは「公式」フックであり、将来破損する可能性は低くなります。
「管理者の禅」も覚えておいてください。
基本的に、Djangoの管理インターフェースは単一のアクティビティ用に設計されています。
構造化コンテンツを編集する信頼できるユーザー。
はい、それは非常に単純です—しかし、その単純さは多くの仮定に基づいています。Djangoの管理インターフェースの全体的な哲学は、これらの仮定に直接従っているので、次のセクションでこのフレーズのサブテキストを掘り下げてみましょう。「信頼できるユーザー…」</p>
管理インターフェースは、開発者であるあなたが信頼する人々が使用するように設計されています。これは単に「認証された人」を意味するのではありません。これは、Djangoが、コンテンツエディターが正しいことを実行することを信頼できると想定していることを意味します。
つまり、コンテンツを編集するための承認プロセスはありません。ユーザーを信頼している場合は、誰も編集を承認する必要はありません。もう1つの意味は、パーミッションシステムは強力ですが、この記事の執筆時点では、オブジェクトごとにアクセスを制限することをサポートしていないということです。誰かが自分のストーリーを編集することを信頼する場合、そのユーザーが他人のストーリーを許可なく編集しないことを信頼します。
「…編集中…」</p>
Djangoの管理インターフェースの主な目的は、人々がデータを編集できるようにすることです。これは最初は明白に思えますが、やはり微妙で強力な影響があります。
たとえば、管理インターフェースは(今説明したように)データを確認するのに非常に便利ですが、その目的を念頭に置いて設計されていません。たとえば、「表示可能」権限がないことに注意してください(第12章を参照)。Djangoは、ユーザーが管理インターフェースでコンテンツを表示することを許可されている場合、それを編集することも許可されていると想定しています。
注意すべきもう1つの重要な点は、「ワークフロー」にリモートでアプローチすることすらできないことです。特定のタスクに一連のステップが必要な場合、それらのステップを特定の順序で実行するように強制することはサポートされていません。Djangoの管理インターフェースは、編集を取り巻く活動ではなく、編集に焦点を合わせています。このワークフローの回避は、信頼の原則からも生じています。管理インターフェースの哲学は、ワークフローは人事上の問題であり、コードに実装されるものではないということです。
最後に、管理インターフェースに集約がないことに注意してください。つまり、合計や平均などを表示することはサポートされていません。繰り返しになりますが、管理インターフェースは編集用です—残りすべてのカスタムビューを作成することが期待されます。
「…構造化コンテンツ」</p>
他のDjangoと同様に、管理インターフェースでは構造化データを操作する必要があります。したがって、Djangoモデルに保存されているデータの編集のみをサポートします。ファイルシステムに保存されているデータなど、その他の場合は、カスタムビューが必要になります。
終止符
Djangoの管理インターフェースがすべての人にとってすべてのものになろうとしているわけではないことは、今では明らかです。代わりに、私たちは1つのことにしっかりと焦点を合わせ、そのことを非常にうまく行うことを選択します。
Djangoの管理インターフェースを拡張することになると、同じ哲学の多くが当てはまります(「拡張性」は私たちの目標のどこにも現れないことに注意してください)。カスタムDjangoビューは何でも実行でき、管理インターフェイスに視覚的に簡単に統合できるため(次のセクションで説明)、管理インターフェイスをカスタマイズするための組み込みの機会は設計によって多少制限されます。
非常に複雑なものではありますが、管理インターフェースは「単なるアプリ」であることに注意してください。十分な時間のあるDjango開発者が再現できなかったことは何もしません。将来、誰かが異なる一連の仮定に基づいて異なる動作をする異なる管理インターフェースを開発する可能性は十分にあります。
最後に、この記事の執筆時点で、Django開発者は、カスタマイズの柔軟性を大幅に向上させる新しいバージョンの管理インターフェースに取り組んでいることを指摘しておく必要があります。これを読むまでに、これらの新機能は正真正銘のDjangoディストリビューションに組み込まれている可能性があります。調べるには、「newforms-admin」ブランチが統合されているかどうかをDjangoコミュニティの誰かに尋ねてください。
管理アプリは、カスタマイズの柔軟性を高めるために多くの改善が見られましたが、私見では「管理者の禅」の多くが依然として当てはまります。