Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

[1.2.X] Fixed #14835 -- Corrected a lack of indentation in the reST m…

…arkup for docs/ref/contrib/admin/index.txt and reflowed the text accordingly.

Thanks to cogat for the report.

Backport of [14830] from trunk - approximate, because other changes have
made it very hard to do exactly.

git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.2.X@15620 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit 25c217bc170d275a2db65fd9c9faa064797d4b2f 1 parent 58c4aca
Luke Plant authored February 21, 2011

Showing 1 changed file with 623 additions and 601 deletions. Show diff stats Hide diff stats

  1. 1,224  docs/ref/contrib/admin/index.txt
1,224  docs/ref/contrib/admin/index.txt
@@ -61,30 +61,31 @@ Other topics
61 61
 
62 62
 .. class:: ModelAdmin
63 63
 
64  
-The ``ModelAdmin`` class is the representation of a model in the admin
65  
-interface. These are stored in a file named ``admin.py`` in your application.
66  
-Let's take a look at a very simple example of the ``ModelAdmin``::
  64
+    The ``ModelAdmin`` class is the representation of a model in the admin
  65
+    interface. These are stored in a file named ``admin.py`` in your
  66
+    application. Let's take a look at a very simple example of
  67
+    the ``ModelAdmin``::
67 68
 
68  
-    from django.contrib import admin
69  
-    from myproject.myapp.models import Author
  69
+        from django.contrib import admin
  70
+        from myproject.myapp.models import Author
70 71
 
71  
-    class AuthorAdmin(admin.ModelAdmin):
72  
-        pass
73  
-    admin.site.register(Author, AuthorAdmin)
  72
+        class AuthorAdmin(admin.ModelAdmin):
  73
+            pass
  74
+        admin.site.register(Author, AuthorAdmin)
74 75
 
75  
-.. admonition:: Do you need a ``ModelAdmin`` object at all?
  76
+    .. admonition:: Do you need a ``ModelAdmin`` object at all?
76 77
 
77  
-    In the preceding example, the ``ModelAdmin`` class doesn't define any
78  
-    custom values (yet). As a result, the default admin interface will be
79  
-    provided. If you are happy with the default admin interface, you don't
80  
-    need to define a ``ModelAdmin`` object at all -- you can register the
81  
-    model class without providing a ``ModelAdmin`` description. The
82  
-    preceding example could be simplified to::
  78
+        In the preceding example, the ``ModelAdmin`` class doesn't define any
  79
+        custom values (yet). As a result, the default admin interface will be
  80
+        provided. If you are happy with the default admin interface, you don't
  81
+        need to define a ``ModelAdmin`` object at all -- you can register the
  82
+        model class without providing a ``ModelAdmin`` description. The
  83
+        preceding example could be simplified to::
83 84
 
84  
-        from django.contrib import admin
85  
-        from myproject.myapp.models import Author
  85
+            from django.contrib import admin
  86
+            from myproject.myapp.models import Author
86 87
 
87  
-        admin.site.register(Author)
  88
+            admin.site.register(Author)
88 89
 
89 90
 ``ModelAdmin`` Options
90 91
 ----------------------
@@ -98,619 +99,629 @@ subclass::
98 99
 
99 100
 .. attribute:: ModelAdmin.date_hierarchy
100 101
 
101  
-Set ``date_hierarchy`` to the name of a ``DateField`` or ``DateTimeField`` in
102  
-your model, and the change list page will include a date-based drilldown
103  
-navigation by that field.
  102
+    Set ``date_hierarchy`` to the name of a ``DateField`` or ``DateTimeField``
  103
+    in your model, and the change list page will include a date-based drilldown
  104
+    navigation by that field.
104 105
 
105  
-Example::
  106
+    Example::
106 107
 
107  
-    date_hierarchy = 'pub_date'
  108
+        date_hierarchy = 'pub_date'
108 109
 
109 110
 .. attribute:: ModelAdmin.form
110 111
 
111  
-By default a ``ModelForm`` is dynamically created for your model. It is used
112  
-to create the form presented on both the add/change pages. You can easily
113  
-provide your own ``ModelForm`` to override any default form behavior on the
114  
-add/change pages.
  112
+    By default a ``ModelForm`` is dynamically created for your model. It is
  113
+    used to create the form presented on both the add/change pages. You can
  114
+    easily provide your own ``ModelForm`` to override any default form behavior
  115
+    on the add/change pages.
115 116
 
116  
-For an example see the section `Adding custom validation to the admin`_.
  117
+    For an example see the section `Adding custom validation to the admin`_.
117 118
 
118 119
 .. attribute:: ModelAdmin.fieldsets
119 120
 
120  
-Set ``fieldsets`` to control the layout of admin "add" and "change" pages.
121  
-
122  
-``fieldsets`` is a list of two-tuples, in which each two-tuple represents a
123  
-``<fieldset>`` on the admin form page. (A ``<fieldset>`` is a "section" of the
124  
-form.)
125  
-
126  
-The two-tuples are in the format ``(name, field_options)``, where ``name`` is a
127  
-string representing the title of the fieldset and ``field_options`` is a
128  
-dictionary of information about the fieldset, including a list of fields to be
129  
-displayed in it.
130  
-
131  
-A full example, taken from the ``django.contrib.flatpages.FlatPage`` model::
132  
-
133  
-    class FlatPageAdmin(admin.ModelAdmin):
134  
-        fieldsets = (
135  
-            (None, {
136  
-                'fields': ('url', 'title', 'content', 'sites')
137  
-            }),
138  
-            ('Advanced options', {
139  
-                'classes': ('collapse',),
140  
-                'fields': ('enable_comments', 'registration_required', 'template_name')
141  
-            }),
142  
-        )
  121
+    Set ``fieldsets`` to control the layout of admin "add" and "change" pages.
  122
+
  123
+    ``fieldsets`` is a list of two-tuples, in which each two-tuple represents a
  124
+    ``<fieldset>`` on the admin form page. (A ``<fieldset>`` is a "section" of
  125
+    the form.)
  126
+
  127
+    The two-tuples are in the format ``(name, field_options)``, where ``name``
  128
+    is a string representing the title of the fieldset and ``field_options`` is
  129
+    a dictionary of information about the fieldset, including a list of fields
  130
+    to be displayed in it.
  131
+
  132
+    A full example, taken from the ``django.contrib.flatpages.FlatPage``
  133
+    model::
  134
+
  135
+        class FlatPageAdmin(admin.ModelAdmin):
  136
+            fieldsets = (
  137
+                (None, {
  138
+                    'fields': ('url', 'title', 'content', 'sites')
  139
+                }),
  140
+                ('Advanced options', {
  141
+                    'classes': ('collapse',),
  142
+                    'fields': ('enable_comments', 'registration_required', 'template_name')
  143
+                }),
  144
+            )
143 145
 
144  
-This results in an admin page that looks like:
  146
+    This results in an admin page that looks like:
145 147
 
146  
-    .. image:: _images/flatfiles_admin.png
  148
+        .. image:: _images/flatfiles_admin.png
147 149
 
148  
-If ``fieldsets`` isn't given, Django will default to displaying each field
149  
-that isn't an ``AutoField`` and has ``editable=True``, in a single fieldset,
150  
-in the same order as the fields are defined in the model.
  150
+    If ``fieldsets`` isn't given, Django will default to displaying each field
  151
+    that isn't an ``AutoField`` and has ``editable=True``, in a single
  152
+    fieldset, in the same order as the fields are defined in the model.
151 153
 
152  
-The ``field_options`` dictionary can have the following keys:
  154
+    The ``field_options`` dictionary can have the following keys:
153 155
 
154  
-    * ``fields``
155  
-        A tuple of field names to display in this fieldset. This key is
156  
-        required.
  156
+        * ``fields``
  157
+            A tuple of field names to display in this fieldset. This key is
  158
+            required.
157 159
 
158  
-        Example::
  160
+            Example::
159 161
 
160  
-            {
161  
-            'fields': ('first_name', 'last_name', 'address', 'city', 'state'),
162  
-            }
  162
+                {
  163
+                'fields': ('first_name', 'last_name', 'address', 'city', 'state'),
  164
+                }
163 165
 
164  
-        To display multiple fields on the same line, wrap those fields in
165  
-        their own tuple. In this example, the ``first_name`` and ``last_name``
166  
-        fields will display on the same line::
  166
+            To display multiple fields on the same line, wrap those fields in
  167
+            their own tuple. In this example, the ``first_name`` and
  168
+            ``last_name`` fields will display on the same line::
167 169
 
168  
-            {
169  
-            'fields': (('first_name', 'last_name'), 'address', 'city', 'state'),
170  
-            }
  170
+                {
  171
+                'fields': (('first_name', 'last_name'), 'address', 'city', 'state'),
  172
+                }
171 173
 
172  
-        .. versionadded:: 1.2
  174
+            .. versionadded:: 1.2
173 175
 
174  
-        ``fields`` can contain values defined in
175  
-        :attr:`~ModelAdmin.readonly_fields` to be displayed as read-only.
  176
+            ``fields`` can contain values defined in
  177
+            :attr:`~ModelAdmin.readonly_fields` to be displayed as read-only.
176 178
 
177  
-    * ``classes``
178  
-        A list containing extra CSS classes to apply to the fieldset.
  179
+        * ``classes``
  180
+            A list containing extra CSS classes to apply to the fieldset.
179 181
 
180  
-        Example::
  182
+            Example::
181 183
 
182  
-            {
183  
-            'classes': ['wide', 'extrapretty'],
184  
-            }
  184
+                {
  185
+                'classes': ['wide', 'extrapretty'],
  186
+                }
185 187
 
186  
-        Two useful classes defined by the default admin site stylesheet are
187  
-        ``collapse`` and ``wide``. Fieldsets with the ``collapse`` style will
188  
-        be initially collapsed in the admin and replaced with a small
189  
-        "click to expand" link. Fieldsets with the ``wide`` style will be
190  
-        given extra horizontal space.
  188
+            Two useful classes defined by the default admin site stylesheet are
  189
+            ``collapse`` and ``wide``. Fieldsets with the ``collapse`` style
  190
+            will be initially collapsed in the admin and replaced with a small
  191
+            "click to expand" link. Fieldsets with the ``wide`` style will be
  192
+            given extra horizontal space.
191 193
 
192  
-    * ``description``
193  
-        A string of optional extra text to be displayed at the top of each
194  
-        fieldset, under the heading of the fieldset.
  194
+        * ``description``
  195
+            A string of optional extra text to be displayed at the top of each
  196
+            fieldset, under the heading of the fieldset.
195 197
 
196  
-        Note that this value is *not* HTML-escaped when it's displayed in
197  
-        the admin interface. This lets you include HTML if you so desire.
198  
-        Alternatively you can use plain text and
199  
-        ``django.utils.html.escape()`` to escape any HTML special
200  
-        characters.
  198
+            Note that this value is *not* HTML-escaped when it's displayed in
  199
+            the admin interface. This lets you include HTML if you so desire.
  200
+            Alternatively you can use plain text and
  201
+            ``django.utils.html.escape()`` to escape any HTML special
  202
+            characters.
201 203
 
202 204
 .. attribute:: ModelAdmin.fields
203 205
 
204  
-Use this option as an alternative to ``fieldsets`` if the layout does not
205  
-matter and if you want to only show a subset of the available fields in the
206  
-form. For example, you could define a simpler version of the admin form for
207  
-the ``django.contrib.flatpages.FlatPage`` model as follows::
  206
+    Use this option as an alternative to ``fieldsets`` if the layout does not
  207
+    matter and if you want to only show a subset of the available fields in the
  208
+    form. For example, you could define a simpler version of the admin form for
  209
+    the ``django.contrib.flatpages.FlatPage`` model as follows::
208 210
 
209  
-    class FlatPageAdmin(admin.ModelAdmin):
210  
-        fields = ('url', 'title', 'content')
  211
+        class FlatPageAdmin(admin.ModelAdmin):
  212
+            fields = ('url', 'title', 'content')
211 213
 
212  
-In the above example, only the fields 'url', 'title' and 'content' will be
213  
-displayed, sequentially, in the form.
  214
+    In the above example, only the fields 'url', 'title' and 'content' will be
  215
+    displayed, sequentially, in the form.
214 216
 
215  
-.. versionadded:: 1.2
  217
+    .. versionadded:: 1.2
216 218
 
217  
-``fields`` can contain values defined in :attr:`ModelAdmin.readonly_fields`
218  
-to be displayed as read-only.
  219
+    ``fields`` can contain values defined in :attr:`ModelAdmin.readonly_fields`
  220
+    to be displayed as read-only.
219 221
 
220  
-.. admonition:: Note
  222
+    .. admonition:: Note
221 223
 
222  
-    This ``fields`` option should not be confused with the ``fields``
223  
-    dictionary key that is within the ``fieldsets`` option, as described in
224  
-    the previous section.
  224
+        This ``fields`` option should not be confused with the ``fields``
  225
+        dictionary key that is within the ``fieldsets`` option, as described in
  226
+        the previous section.
225 227
 
226  
-.. attribute:: ModelAdmin.exclude
  228
+    .. attribute:: ModelAdmin.exclude
227 229
 
228  
-This attribute, if given, should be a list of field names to exclude from the
229  
-form.
  230
+    This attribute, if given, should be a list of field names to exclude from
  231
+    the form.
230 232
 
231  
-For example, let's consider the following model::
  233
+    For example, let's consider the following model::
232 234
 
233  
-    class Author(models.Model):
234  
-        name = models.CharField(max_length=100)
235  
-        title = models.CharField(max_length=3)
236  
-        birth_date = models.DateField(blank=True, null=True)
  235
+        class Author(models.Model):
  236
+            name = models.CharField(max_length=100)
  237
+            title = models.CharField(max_length=3)
  238
+            birth_date = models.DateField(blank=True, null=True)
237 239
 
238  
-If you want a form for the ``Author`` model that includes only the ``name``
239  
-and ``title`` fields, you would specify ``fields`` or ``exclude`` like this::
  240
+    If you want a form for the ``Author`` model that includes only the ``name``
  241
+    and ``title`` fields, you would specify ``fields`` or ``exclude`` like
  242
+    this::
240 243
 
241  
-    class AuthorAdmin(admin.ModelAdmin):
242  
-        fields = ('name', 'title')
  244
+        class AuthorAdmin(admin.ModelAdmin):
  245
+            fields = ('name', 'title')
243 246
 
244  
-    class AuthorAdmin(admin.ModelAdmin):
245  
-        exclude = ('birth_date',)
  247
+        class AuthorAdmin(admin.ModelAdmin):
  248
+            exclude = ('birth_date',)
246 249
 
247  
-Since the Author model only has three fields, ``name``, ``title``, and
248  
-``birth_date``, the forms resulting from the above declarations will contain
249  
-exactly the same fields.
  250
+    Since the Author model only has three fields, ``name``, ``title``, and
  251
+    ``birth_date``, the forms resulting from the above declarations will
  252
+    contain exactly the same fields.
250 253
 
251  
-.. attribute:: ModelAdmin.filter_horizontal
  254
+    .. attribute:: ModelAdmin.filter_horizontal
252 255
 
253  
-Use a nifty unobtrusive JavaScript "filter" interface instead of the
254  
-usability-challenged ``<select multiple>`` in the admin form. The value is a
255  
-list of fields that should be displayed as a horizontal filter interface. See
256  
-``filter_vertical`` to use a vertical interface.
  256
+    Use a nifty unobtrusive JavaScript "filter" interface instead of the
  257
+    usability-challenged ``<select multiple>`` in the admin form. The value is
  258
+    a list of fields that should be displayed as a horizontal filter interface.
  259
+    See ``filter_vertical`` to use a vertical interface.
257 260
 
258  
-.. attribute:: ModelAdmin.filter_vertical
  261
+    .. attribute:: ModelAdmin.filter_vertical
259 262
 
260  
-Same as ``filter_horizontal``, but is a vertical display of the filter
261  
-interface.
  263
+    Same as ``filter_horizontal``, but is a vertical display of the filter
  264
+    interface.
262 265
 
263 266
 .. attribute:: ModelAdmin.list_display
264 267
 
265  
-Set ``list_display`` to control which fields are displayed on the change list
266  
-page of the admin.
  268
+    Set ``list_display`` to control which fields are displayed on the change
  269
+    list page of the admin.
267 270
 
268  
-Example::
  271
+    Example::
269 272
 
270  
-    list_display = ('first_name', 'last_name')
  273
+        list_display = ('first_name', 'last_name')
271 274
 
272  
-If you don't set ``list_display``, the admin site will display a single column
273  
-that displays the ``__unicode__()`` representation of each object.
  275
+    If you don't set ``list_display``, the admin site will display a single
  276
+    column that displays the ``__unicode__()`` representation of each object.
274 277
 
275  
-You have four possible values that can be used in ``list_display``:
  278
+    You have four possible values that can be used in ``list_display``:
276 279
 
277  
-    * A field of the model. For example::
  280
+        * A field of the model. For example::
278 281
 
279  
-          class PersonAdmin(admin.ModelAdmin):
280  
-              list_display = ('first_name', 'last_name')
  282
+              class PersonAdmin(admin.ModelAdmin):
  283
+                  list_display = ('first_name', 'last_name')
281 284
 
282  
-    * A callable that accepts one parameter for the model instance. For
283  
-      example::
  285
+        * A callable that accepts one parameter for the model instance. For
  286
+          example::
284 287
 
285  
-          def upper_case_name(obj):
286  
-              return ("%s %s" % (obj.first_name, obj.last_name)).upper()
287  
-          upper_case_name.short_description = 'Name'
  288
+              def upper_case_name(obj):
  289
+                  return ("%s %s" % (obj.first_name, obj.last_name)).upper()
  290
+              upper_case_name.short_description = 'Name'
288 291
 
289  
-          class PersonAdmin(admin.ModelAdmin):
290  
-              list_display = (upper_case_name,)
  292
+              class PersonAdmin(admin.ModelAdmin):
  293
+                  list_display = (upper_case_name,)
291 294
 
292  
-    * A string representing an attribute on the ``ModelAdmin``. This behaves
293  
-      same as the callable. For example::
  295
+        * A string representing an attribute on the ``ModelAdmin``. This
  296
+          behaves same as the callable. For example::
294 297
 
295  
-          class PersonAdmin(admin.ModelAdmin):
296  
-              list_display = ('upper_case_name',)
  298
+              class PersonAdmin(admin.ModelAdmin):
  299
+                  list_display = ('upper_case_name',)
297 300
 
298  
-              def upper_case_name(self, obj):
299  
-                return ("%s %s" % (obj.first_name, obj.last_name)).upper()
300  
-              upper_case_name.short_description = 'Name'
  301
+                  def upper_case_name(self, obj):
  302
+                    return ("%s %s" % (obj.first_name, obj.last_name)).upper()
  303
+                  upper_case_name.short_description = 'Name'
301 304
 
302  
-    * A string representing an attribute on the model. This behaves almost
303  
-      the same as the callable, but ``self`` in this context is the model
304  
-      instance. Here's a full model example::
  305
+        * A string representing an attribute on the model. This behaves almost
  306
+          the same as the callable, but ``self`` in this context is the model
  307
+          instance. Here's a full model example::
305 308
 
306  
-          class Person(models.Model):
307  
-              name = models.CharField(max_length=50)
308  
-              birthday = models.DateField()
  309
+              class Person(models.Model):
  310
+                  name = models.CharField(max_length=50)
  311
+                  birthday = models.DateField()
309 312
 
310  
-              def decade_born_in(self):
311  
-                  return self.birthday.strftime('%Y')[:3] + "0's"
312  
-              decade_born_in.short_description = 'Birth decade'
  313
+                  def decade_born_in(self):
  314
+                      return self.birthday.strftime('%Y')[:3] + "0's"
  315
+                  decade_born_in.short_description = 'Birth decade'
313 316
 
314  
-          class PersonAdmin(admin.ModelAdmin):
315  
-              list_display = ('name', 'decade_born_in')
  317
+              class PersonAdmin(admin.ModelAdmin):
  318
+                  list_display = ('name', 'decade_born_in')
316 319
 
317  
-A few special cases to note about ``list_display``:
  320
+    A few special cases to note about ``list_display``:
318 321
 
319  
-    * If the field is a ``ForeignKey``, Django will display the
320  
-      ``__unicode__()`` of the related object.
  322
+        * If the field is a ``ForeignKey``, Django will display the
  323
+          ``__unicode__()`` of the related object.
321 324
 
322  
-    * ``ManyToManyField`` fields aren't supported, because that would entail
323  
-      executing a separate SQL statement for each row in the table. If you
324  
-      want to do this nonetheless, give your model a custom method, and add
325  
-      that method's name to ``list_display``. (See below for more on custom
326  
-      methods in ``list_display``.)
  325
+        * ``ManyToManyField`` fields aren't supported, because that would
  326
+          entail executing a separate SQL statement for each row in the table.
  327
+          If you want to do this nonetheless, give your model a custom method,
  328
+          and add that method's name to ``list_display``. (See below for more
  329
+          on custom methods in ``list_display``.)
327 330
 
328  
-    * If the field is a ``BooleanField`` or ``NullBooleanField``, Django will
329  
-      display a pretty "on" or "off" icon instead of ``True`` or ``False``.
  331
+        * If the field is a ``BooleanField`` or ``NullBooleanField``, Django
  332
+          will display a pretty "on" or "off" icon instead of ``True`` or
  333
+          ``False``.
330 334
 
331  
-    * If the string given is a method of the model, ``ModelAdmin`` or a
332  
-      callable, Django will HTML-escape the output by default. If you'd rather
333  
-      not escape the output of the method, give the method an ``allow_tags``
334  
-      attribute whose value is ``True``.
  335
+        * If the string given is a method of the model, ``ModelAdmin`` or a
  336
+          callable, Django will HTML-escape the output by default. If you'd
  337
+          rather not escape the output of the method, give the method an
  338
+          ``allow_tags`` attribute whose value is ``True``.
335 339
 
336  
-      Here's a full example model::
  340
+          Here's a full example model::
337 341
 
338  
-          class Person(models.Model):
339  
-              first_name = models.CharField(max_length=50)
340  
-              last_name = models.CharField(max_length=50)
341  
-              color_code = models.CharField(max_length=6)
  342
+              class Person(models.Model):
  343
+                  first_name = models.CharField(max_length=50)
  344
+                  last_name = models.CharField(max_length=50)
  345
+                  color_code = models.CharField(max_length=6)
342 346
 
343  
-              def colored_name(self):
344  
-                  return '<span style="color: #%s;">%s %s</span>' % (self.color_code, self.first_name, self.last_name)
345  
-              colored_name.allow_tags = True
  347
+                  def colored_name(self):
  348
+                      return '<span style="color: #%s;">%s %s</span>' % (self.color_code, self.first_name, self.last_name)
  349
+                  colored_name.allow_tags = True
346 350
 
347  
-          class PersonAdmin(admin.ModelAdmin):
348  
-              list_display = ('first_name', 'last_name', 'colored_name')
  351
+              class PersonAdmin(admin.ModelAdmin):
  352
+                  list_display = ('first_name', 'last_name', 'colored_name')
349 353
 
350  
-    * If the string given is a method of the model, ``ModelAdmin`` or a
351  
-      callable that returns True or False Django will display a pretty "on" or
352  
-      "off" icon if you give the method a ``boolean`` attribute whose value is
353  
-      ``True``.
  354
+        * If the string given is a method of the model, ``ModelAdmin`` or a
  355
+          callable that returns True or False Django will display a pretty
  356
+          "on" or "off" icon if you give the method a ``boolean`` attribute
  357
+          whose value is ``True``.
354 358
 
355  
-      Here's a full example model::
  359
+          Here's a full example model::
356 360
 
357  
-          class Person(models.Model):
358  
-              first_name = models.CharField(max_length=50)
359  
-              birthday = models.DateField()
  361
+              class Person(models.Model):
  362
+                  first_name = models.CharField(max_length=50)
  363
+                  birthday = models.DateField()
360 364
 
361  
-              def born_in_fifties(self):
362  
-                  return self.birthday.strftime('%Y')[:3] == '195'
363  
-              born_in_fifties.boolean = True
  365
+                  def born_in_fifties(self):
  366
+                      return self.birthday.strftime('%Y')[:3] == '195'
  367
+                  born_in_fifties.boolean = True
364 368
 
365  
-          class PersonAdmin(admin.ModelAdmin):
366  
-              list_display = ('name', 'born_in_fifties')
  369
+              class PersonAdmin(admin.ModelAdmin):
  370
+                  list_display = ('name', 'born_in_fifties')
367 371
 
368 372
 
369  
-    * The ``__str__()`` and ``__unicode__()`` methods are just as valid in
370  
-      ``list_display`` as any other model method, so it's perfectly OK to do
371  
-      this::
  373
+        * The ``__str__()`` and ``__unicode__()`` methods are just as valid in
  374
+          ``list_display`` as any other model method, so it's perfectly OK to
  375
+          do this::
372 376
 
373  
-          list_display = ('__unicode__', 'some_other_field')
  377
+              list_display = ('__unicode__', 'some_other_field')
374 378
 
375  
-    * Usually, elements of ``list_display`` that aren't actual database fields
376  
-      can't be used in sorting (because Django does all the sorting at the
377  
-      database level).
  379
+        * Usually, elements of ``list_display`` that aren't actual database
  380
+          fields can't be used in sorting (because Django does all the sorting
  381
+          at the database level).
378 382
 
379  
-      However, if an element of ``list_display`` represents a certain database
380  
-      field, you can indicate this fact by setting the ``admin_order_field``
381  
-      attribute of the item.
  383
+          However, if an element of ``list_display`` represents a certain
  384
+          database field, you can indicate this fact by setting the
  385
+          ``admin_order_field`` attribute of the item.
382 386
 
383  
-      For example::
  387
+          For example::
384 388
 
385  
-        class Person(models.Model):
386  
-            first_name = models.CharField(max_length=50)
387  
-            color_code = models.CharField(max_length=6)
  389
+            class Person(models.Model):
  390
+                first_name = models.CharField(max_length=50)
  391
+                color_code = models.CharField(max_length=6)
388 392
 
389  
-            def colored_first_name(self):
390  
-                return '<span style="color: #%s;">%s</span>' % (self.color_code, self.first_name)
391  
-            colored_first_name.allow_tags = True
392  
-            colored_first_name.admin_order_field = 'first_name'
  393
+                def colored_first_name(self):
  394
+                    return '<span style="color: #%s;">%s</span>' % (self.color_code, self.first_name)
  395
+                colored_first_name.allow_tags = True
  396
+                colored_first_name.admin_order_field = 'first_name'
393 397
 
394  
-        class PersonAdmin(admin.ModelAdmin):
395  
-            list_display = ('first_name', 'colored_first_name')
  398
+            class PersonAdmin(admin.ModelAdmin):
  399
+                list_display = ('first_name', 'colored_first_name')
396 400
 
397  
-      The above will tell Django to order by the ``first_name`` field when
398  
-      trying to sort by ``colored_first_name`` in the admin.
  401
+          The above will tell Django to order by the ``first_name`` field when
  402
+          trying to sort by ``colored_first_name`` in the admin.
399 403
 
400 404
 .. attribute:: ModelAdmin.list_display_links
401 405
 
402  
-Set ``list_display_links`` to control which fields in ``list_display`` should
403  
-be linked to the "change" page for an object.
  406
+    Set ``list_display_links`` to control which fields in ``list_display``
  407
+    should be linked to the "change" page for an object.
404 408
 
405  
-By default, the change list page will link the first column -- the first field
406  
-specified in ``list_display`` -- to the change page for each item. But
407  
-``list_display_links`` lets you change which columns are linked. Set
408  
-``list_display_links`` to a list or tuple of field names (in the same format as
409  
-``list_display``) to link.
  409
+    By default, the change list page will link the first column -- the first
  410
+    field specified in ``list_display`` -- to the change page for each item.
  411
+    But``list_display_links`` lets you change which columns are linked. Set
  412
+    ``list_display_links`` to a list or tuple of field names (in the same
  413
+    format as ``list_display``) to link.
410 414
 
411  
-``list_display_links`` can specify one or many field names. As long as the
412  
-field names appear in ``list_display``, Django doesn't care how many (or how
413  
-few) fields are linked. The only requirement is: If you want to use
414  
-``list_display_links``, you must define ``list_display``.
  415
+    ``list_display_links`` can specify one or many field names. As long as the
  416
+    field names appear in ``list_display``, Django doesn't care how many (or
  417
+    how few) fields are linked. The only requirement is: If you want to use
  418
+    ``list_display_links``, you must define ``list_display``.
415 419
 
416  
-In this example, the ``first_name`` and ``last_name`` fields will be linked on
417  
-the change list page::
  420
+    In this example, the ``first_name`` and ``last_name`` fields will be
  421
+    linked on the change list page::
418 422
 
419  
-    class PersonAdmin(admin.ModelAdmin):
420  
-        list_display = ('first_name', 'last_name', 'birthday')
421  
-        list_display_links = ('first_name', 'last_name')
  423
+        class PersonAdmin(admin.ModelAdmin):
  424
+            list_display = ('first_name', 'last_name', 'birthday')
  425
+            list_display_links = ('first_name', 'last_name')
422 426
 
423  
-.. _admin-list-editable:
  427
+    .. _admin-list-editable:
424 428
 
425 429
 .. attribute:: ModelAdmin.list_editable
426 430
 
427  
-.. versionadded:: 1.1
  431
+    .. versionadded:: 1.1
428 432
 
429  
-Set ``list_editable`` to a list of field names on the model which will allow
430  
-editing on the change list page. That is, fields listed in ``list_editable``
431  
-will be displayed as form widgets on the change list page, allowing users to
432  
-edit and save multiple rows at once.
  433
+    Set ``list_editable`` to a list of field names on the model which will
  434
+    allow editing on the change list page. That is, fields listed in
  435
+    ``list_editable`` will be displayed as form widgets on the change list
  436
+    page, allowing users to edit and save multiple rows at once.
433 437
 
434  
-.. note::
  438
+    .. note::
435 439
 
436  
-    ``list_editable`` interacts with a couple of other options in particular
437  
-    ways; you should note the following rules:
  440
+        ``list_editable`` interacts with a couple of other options in
  441
+        particular ways; you should note the following rules:
438 442
 
439  
-        * Any field in ``list_editable`` must also be in ``list_display``. You
440  
-          can't edit a field that's not displayed!
  443
+            * Any field in ``list_editable`` must also be in ``list_display``.
  444
+              You can't edit a field that's not displayed!
441 445
 
442  
-        * The same field can't be listed in both ``list_editable`` and
443  
-          ``list_display_links`` -- a field can't be both a form and a link.
  446
+            * The same field can't be listed in both ``list_editable`` and
  447
+              ``list_display_links`` -- a field can't be both a form and
  448
+              a link.
444 449
 
445  
-    You'll get a validation error if either of these rules are broken.
  450
+        You'll get a validation error if either of these rules are broken.
446 451
 
447 452
 .. attribute:: ModelAdmin.list_filter
448 453
 
449  
-Set ``list_filter`` to activate filters in the right sidebar of the change list
450  
-page of the admin. This should be a list of field names, and each specified
451  
-field should be either a ``BooleanField``, ``CharField``, ``DateField``,
452  
-``DateTimeField``, ``IntegerField`` or ``ForeignKey``.
  454
+    Set ``list_filter`` to activate filters in the right sidebar of the change
  455
+    list page of the admin. This should be a list of field names, and each
  456
+    specified field should be either a ``BooleanField``, ``CharField``,
  457
+    ``DateField``, ``DateTimeField``, ``IntegerField`` or ``ForeignKey``.
453 458
 
454  
-This example, taken from the ``django.contrib.auth.models.User`` model, shows
455  
-how both ``list_display`` and ``list_filter`` work::
  459
+    This example, taken from the ``django.contrib.auth.models.User`` model,
  460
+    shows how both ``list_display`` and ``list_filter`` work::
456 461
 
457  
-    class UserAdmin(admin.ModelAdmin):
458  
-        list_display = ('username', 'email', 'first_name', 'last_name', 'is_staff')
459  
-        list_filter = ('is_staff', 'is_superuser')
  462
+        class UserAdmin(admin.ModelAdmin):
  463
+            list_display = ('username', 'email', 'first_name', 'last_name', 'is_staff')
  464
+            list_filter = ('is_staff', 'is_superuser')
460 465
 
461  
-The above code results in an admin change list page that looks like this:
  466
+    The above code results in an admin change list page that looks like this:
462 467
 
463  
-    .. image:: _images/users_changelist.png
  468
+        .. image:: _images/users_changelist.png
464 469
 
465  
-(This example also has ``search_fields`` defined. See below.)
  470
+    (This example also has ``search_fields`` defined. See below.)
466 471
 
467 472
 .. attribute:: ModelAdmin.list_per_page
468 473
 
469  
-Set ``list_per_page`` to control how many items appear on each paginated admin
470  
-change list page. By default, this is set to ``100``.
  474
+    Set ``list_per_page`` to control how many items appear on each paginated
  475
+    admin change list page. By default, this is set to ``100``.
471 476
 
472 477
 .. attribute:: ModelAdmin.list_select_related
473 478
 
474  
-Set ``list_select_related`` to tell Django to use
475  
-:meth:`~django.db.models.QuerySet.select_related` in retrieving the list of
476  
-objects on the admin change list page. This can save you a bunch of database
477  
-queries.
  479
+    Set ``list_select_related`` to tell Django to use
  480
+    :meth:`~django.db.models.QuerySet.select_related` in retrieving the list of
  481
+    objects on the admin change list page. This can save you a bunch of
  482
+    database queries.
478 483
 
479  
-The value should be either ``True`` or ``False``. Default is ``False``.
  484
+    The value should be either ``True`` or ``False``. Default is ``False``.
480 485
 
481  
-Note that Django will use :meth:`~django.db.models.QuerySet.select_related`,
482  
-regardless of this setting, if one of the ``list_display`` fields is a
483  
-``ForeignKey``.
  486
+    Note that Django will use :meth:`~django.db.models.QuerySet.select_related`,
  487
+    regardless of this setting, if one of the ``list_display`` fields is a
  488
+    ``ForeignKey``.
484 489
 
485 490
 .. attribute:: ModelAdmin.inlines
486 491
 
487  
-See ``InlineModelAdmin`` objects below.
  492
+    See ``InlineModelAdmin`` objects below.
488 493
 
489 494
 .. attribute:: ModelAdmin.ordering
490 495
 
491  
-Set ``ordering`` to specify how lists of objects should be ordered in the
492  
-Django admin views. This should be a list or tuple in the same format as a
493  
-model's ``ordering`` parameter.
  496
+    Set ``ordering`` to specify how lists of objects should be ordered in the
  497
+    Django admin views. This should be a list or tuple in the same format as a
  498
+    model's ``ordering`` parameter.
494 499
 
495  
-If this isn't provided, the Django admin will use the model's default ordering.
  500
+    If this isn't provided, the Django admin will use the model's default
  501
+    ordering.
496 502
 
497  
-.. admonition:: Note
  503
+    .. admonition:: Note
498 504
 
499  
-    Django will only honor the first element in the list/tuple; any others
500  
-    will be ignored.
  505
+        Django will only honor the first element in the list/tuple; any others
  506
+        will be ignored.
501 507
 
502 508
 .. attribute:: ModelAdmin.prepopulated_fields
503 509
 
504  
-Set ``prepopulated_fields`` to a dictionary mapping field names to the fields
505  
-it should prepopulate from::
  510
+    Set ``prepopulated_fields`` to a dictionary mapping field names to the
  511
+    fields it should prepopulate from::
506 512
 
507  
-    class ArticleAdmin(admin.ModelAdmin):
508  
-        prepopulated_fields = {"slug": ("title",)}
  513
+        class ArticleAdmin(admin.ModelAdmin):
  514
+            prepopulated_fields = {"slug": ("title",)}
509 515
 
510  
-When set, the given fields will use a bit of JavaScript to populate from the
511  
-fields assigned. The main use for this functionality is to automatically
512  
-generate the value for ``SlugField`` fields from one or more other fields. The
513  
-generated value is produced by concatenating the values of the source fields,
514  
-and then by transforming that result into a valid slug (e.g. substituting
515  
-dashes for spaces).
  516
+    When set, the given fields will use a bit of JavaScript to populate from
  517
+    the fields assigned. The main use for this functionality is to
  518
+    automatically generate the value for ``SlugField`` fields from one or more
  519
+    other fields. The generated value is produced by concatenating the values
  520
+    of the source fields, and then by transforming that result into a valid
  521
+    slug (e.g. substituting dashes for spaces).
516 522
 
517  
-``prepopulated_fields`` doesn't accept ``DateTimeField``, ``ForeignKey``, nor
518  
-``ManyToManyField`` fields.
  523
+    ``prepopulated_fields`` doesn't accept ``DateTimeField``, ``ForeignKey``,
  524
+    nor ``ManyToManyField`` fields.
519 525
 
520 526
 .. attribute:: ModelAdmin.radio_fields
521 527
 
522  
-By default, Django's admin uses a select-box interface (<select>) for
523  
-fields that are ``ForeignKey`` or have ``choices`` set. If a field is present
524  
-in ``radio_fields``, Django will use a radio-button interface instead.
525  
-Assuming ``group`` is a ``ForeignKey`` on the ``Person`` model::
  528
+    By default, Django's admin uses a select-box interface (<select>) for
  529
+    fields that are ``ForeignKey`` or have ``choices`` set. If a field is
  530
+    present in ``radio_fields``, Django will use a radio-button interface
  531
+    instead.  Assuming ``group`` is a ``ForeignKey`` on the ``Person`` model::
526 532
 
527  
-    class PersonAdmin(admin.ModelAdmin):
528  
-        radio_fields = {"group": admin.VERTICAL}
  533
+        class PersonAdmin(admin.ModelAdmin):
  534
+            radio_fields = {"group": admin.VERTICAL}
529 535
 
530  
-You have the choice of using ``HORIZONTAL`` or ``VERTICAL`` from the
531  
-``django.contrib.admin`` module.
  536
+    You have the choice of using ``HORIZONTAL`` or ``VERTICAL`` from the
  537
+    ``django.contrib.admin`` module.
532 538
 
533  
-Don't include a field in ``radio_fields`` unless it's a ``ForeignKey`` or has
534  
-``choices`` set.
  539
+    Don't include a field in ``radio_fields`` unless it's a ``ForeignKey`` or has
  540
+    ``choices`` set.
535 541
 
536 542
 .. attribute:: ModelAdmin.raw_id_fields
537 543
 
538  
-By default, Django's admin uses a select-box interface (<select>) for
539  
-fields that are ``ForeignKey``. Sometimes you don't want to incur the
540  
-overhead of having to select all the related instances to display in the
541  
-drop-down.
  544
+    By default, Django's admin uses a select-box interface (<select>) for
  545
+    fields that are ``ForeignKey``. Sometimes you don't want to incur the
  546
+    overhead of having to select all the related instances to display in the
  547
+    drop-down.
542 548
 
543  
-``raw_id_fields`` is a list of fields you would like to change
544  
-into a ``Input`` widget for either a ``ForeignKey`` or ``ManyToManyField``::
  549
+    ``raw_id_fields`` is a list of fields you would like to change
  550
+    into a ``Input`` widget for either a ``ForeignKey`` or
  551
+    ``ManyToManyField``::
545 552
 
546  
-    class ArticleAdmin(admin.ModelAdmin):
547  
-        raw_id_fields = ("newspaper",)
  553
+        class ArticleAdmin(admin.ModelAdmin):
  554
+            raw_id_fields = ("newspaper",)
548 555
 
549 556
 .. attribute:: ModelAdmin.readonly_fields
550 557
 
551  
-.. versionadded:: 1.2
  558
+    .. versionadded:: 1.2
552 559
 
553  
-By default the admin shows all fields as editable. Any fields in this option
554  
-(which should be a ``list`` or ``tuple``) will display its data as-is and
555  
-non-editable. This option behaves nearly identical to :attr:`ModelAdmin.list_display`.
556  
-Usage is the same, however, when you specify :attr:`ModelAdmin.fields` or
557  
-:attr:`ModelAdmin.fieldsets` the read-only fields must be present to be shown
558  
-(they are ignored otherwise).
  560
+    By default the admin shows all fields as editable. Any fields in this
  561
+    option (which should be a ``list`` or ``tuple``) will display its data
  562
+    as-is and non-editable. This option behaves nearly identical to
  563
+    :attr:`ModelAdmin.list_display`.  Usage is the same, however, when you
  564
+    specify :attr:`ModelAdmin.fields` or :attr:`ModelAdmin.fieldsets` the
  565
+    read-only fields must be present to be shown (they are ignored otherwise).
559 566
 
560  
-If ``readonly_fields`` is used without defining explicit ordering through
561  
-:attr:`ModelAdmin.fields` or :attr:`ModelAdmin.fieldsets` they will be added
562  
-last after all editable fields.
  567
+    If ``readonly_fields`` is used without defining explicit ordering through
  568
+    :attr:`ModelAdmin.fields` or :attr:`ModelAdmin.fieldsets` they will be
  569
+    added last after all editable fields.
563 570
 
564 571
 .. attribute:: ModelAdmin.save_as
565 572
 
566  
-Set ``save_as`` to enable a "save as" feature on admin change forms.
  573
+    Set ``save_as`` to enable a "save as" feature on admin change forms.
567 574
 
568  
-Normally, objects have three save options: "Save", "Save and continue editing"
569  
-and "Save and add another". If ``save_as`` is ``True``, "Save and add another"
570  
-will be replaced by a "Save as" button.
  575
+    Normally, objects have three save options: "Save", "Save and continue
  576
+    editing" and "Save and add another". If ``save_as`` is ``True``, "Save
  577
+    and add another" will be replaced by a "Save as" button.
571 578
 
572  
-"Save as" means the object will be saved as a new object (with a new ID),
573  
-rather than the old object.
  579
+    "Save as" means the object will be saved as a new object (with a new ID),
  580
+    rather than the old object.
574 581
 
575  
-By default, ``save_as`` is set to ``False``.
  582
+    By default, ``save_as`` is set to ``False``.
576 583
 
577 584
 .. attribute:: ModelAdmin.save_on_top
578 585
 
579  
-Set ``save_on_top`` to add save buttons across the top of your admin change
580  
-forms.
  586
+    Set ``save_on_top`` to add save buttons across the top of your adminchange
  587
+    forms.
581 588
 
582  
-Normally, the save buttons appear only at the bottom of the forms. If you set
583  
-``save_on_top``, the buttons will appear both on the top and the bottom.
  589
+    Normally, the save buttons appear only at the bottom of the forms. If you
  590
+    set ``save_on_top``, the buttons will appear both on the top and the
  591
+    bottom.
584 592
 
585 593
 By default, ``save_on_top`` is set to ``False``.
586 594
 
587 595
 .. attribute:: ModelAdmin.search_fields
588 596
 
589  
-Set ``search_fields`` to enable a search box on the admin change list page.
590  
-This should be set to a list of field names that will be searched whenever
591  
-somebody submits a search query in that text box.
  597
+    Set ``search_fields`` to enable a search box on the admin change list page.
  598
+    This should be set to a list of field names that will be searched whenever
  599
+    somebody submits a search query in that text box.
592 600
 
593  
-These fields should be some kind of text field, such as ``CharField`` or
594  
-``TextField``. You can also perform a related lookup on a ``ForeignKey`` or
595  
-``ManyToManyField`` with the lookup API "follow" notation::
  601
+    These fields should be some kind of text field, such as ``CharField`` or
  602
+    ``TextField``. You can also perform a related lookup on a ``ForeignKey`` or
  603
+    ``ManyToManyField`` with the lookup API "follow" notation::
596 604
 
597  
-    search_fields = ['foreign_key__related_fieldname']
  605
+        search_fields = ['foreign_key__related_fieldname']
598 606
 
599  
-For example, if you have a blog entry with an author, the following definition
600  
-would enable search blog entries by the email address of the author::
  607
+    For example, if you have a blog entry with an author, the following
  608
+    definition would enable search blog entries by the email address of the
  609
+    author::
601 610
 
602  
-    search_fields = ['user__email']
  611
+        search_fields = ['user__email']
603 612
 
604  
-When somebody does a search in the admin search box, Django splits the search
605  
-query into words and returns all objects that contain each of the words, case
606  
-insensitive, where each word must be in at least one of ``search_fields``. For
607  
-example, if ``search_fields`` is set to ``['first_name', 'last_name']`` and a
608  
-user searches for ``john lennon``, Django will do the equivalent of this SQL
609  
-``WHERE`` clause::
  613
+    When somebody does a search in the admin search box, Django splits the
  614
+    search query into words and returns all objects that contain each of the
  615
+    words, case insensitive, where each word must be in at least one of
  616
+    ``search_fields``. For example, if ``search_fields`` is set to
  617
+    ``['first_name', 'last_name']`` and a user searches for ``john lennon``,
  618
+    Django will do the equivalent of this SQL ``WHERE`` clause::
610 619
 
611  
-    WHERE (first_name ILIKE '%john%' OR last_name ILIKE '%john%')
612  
-    AND (first_name ILIKE '%lennon%' OR last_name ILIKE '%lennon%')
  620
+        WHERE (first_name ILIKE '%john%' OR last_name ILIKE '%john%')
  621
+        AND (first_name ILIKE '%lennon%' OR last_name ILIKE '%lennon%')
613 622
 
614  
-For faster and/or more restrictive searches, prefix the field name
615  
-with an operator:
  623
+    For faster and/or more restrictive searches, prefix the field name
  624
+    with an operator:
616 625
 
617  
-``^``
618  
-    Matches the beginning of the field. For example, if ``search_fields`` is
619  
-    set to ``['^first_name', '^last_name']`` and a user searches for
620  
-    ``john lennon``, Django will do the equivalent of this SQL ``WHERE``
621  
-    clause::
  626
+    ``^``
  627
+        Matches the beginning of the field. For example, if ``search_fields``
  628
+        is set to ``['^first_name', '^last_name']`` and a user searches for
  629
+        ``john lennon``, Django will do the equivalent of this SQL ``WHERE``
  630
+        clause::
622 631
 
623  
-        WHERE (first_name ILIKE 'john%' OR last_name ILIKE 'john%')
624  
-        AND (first_name ILIKE 'lennon%' OR last_name ILIKE 'lennon%')
  632
+            WHERE (first_name ILIKE 'john%' OR last_name ILIKE 'john%')
  633
+            AND (first_name ILIKE 'lennon%' OR last_name ILIKE 'lennon%')
625 634
 
626  
-    This query is more efficient than the normal ``'%john%'`` query, because
627  
-    the database only needs to check the beginning of a column's data, rather
628  
-    than seeking through the entire column's data. Plus, if the column has an
629  
-    index on it, some databases may be able to use the index for this query,
630  
-    even though it's a ``LIKE`` query.
  635
+        This query is more efficient than the normal ``'%john%'`` query,
  636
+        because the database only needs to check the beginning of a column's
  637
+        data, rather than seeking through the entire column's data. Plus, if
  638
+        the column has an index on it, some databases may be able to use the
  639
+        index for this query, even though it's a ``LIKE`` query.
631 640
 
632  
-``=``
633  
-    Matches exactly, case-insensitive. For example, if
634  
-    ``search_fields`` is set to ``['=first_name', '=last_name']`` and
635  
-    a user searches for ``john lennon``, Django will do the equivalent
636  
-    of this SQL ``WHERE`` clause::
  641
+    ``=``
  642
+        Matches exactly, case-insensitive. For example, if
  643
+        ``search_fields`` is set to ``['=first_name', '=last_name']`` and
  644
+        a user searches for ``john lennon``, Django will do the equivalent
  645
+        of this SQL ``WHERE`` clause::
637 646
 
638  
-        WHERE (first_name ILIKE 'john' OR last_name ILIKE 'john')
639  
-        AND (first_name ILIKE 'lennon' OR last_name ILIKE 'lennon')
  647
+            WHERE (first_name ILIKE 'john' OR last_name ILIKE 'john')
  648
+            AND (first_name ILIKE 'lennon' OR last_name ILIKE 'lennon')
640 649
 
641  
-    Note that the query input is split by spaces, so, following this example,
642  
-    it's currently not possible to search for all records in which
643  
-    ``first_name`` is exactly ``'john winston'`` (containing a space).
  650
+        Note that the query input is split by spaces, so, following this
  651
+        example, it's currently not possible to search for all records in which
  652
+        ``first_name`` is exactly ``'john winston'`` (containing a space).
644 653
 
645  
-``@``
646  
-    Performs a full-text match. This is like the default search method but uses
647  
-    an index. Currently this is only available for MySQL.
  654
+    ``@``
  655
+        Performs a full-text match. This is like the default search method but
  656
+        uses an index. Currently this is only available for MySQL.
648 657
 
649 658
 .. attribute:: ModelAdmin.formfield_overrides
650 659
 
651  
-.. versionadded:: 1.1
  660
+    .. versionadded:: 1.1
652 661
 
653  
-This provides a quick-and-dirty way to override some of the
654  
-:class:`~django.forms.Field` options for use in the admin.
655  
-``formfield_overrides`` is a dictionary mapping a field class to a dict of
656  
-arguments to pass to the field at construction time.
  662
+    This provides a quick-and-dirty way to override some of the
  663
+    :class:`~django.forms.Field` options for use in the admin.
  664
+    ``formfield_overrides`` is a dictionary mapping a field class to a dict of
  665
+    arguments to pass to the field at construction time.
657 666
 
658  
-Since that's a bit abstract, let's look at a concrete example. The most common
659  
-use of ``formfield_overrides`` is to add a custom widget for a certain type of
660  
-field. So, imagine we've written a ``RichTextEditorWidget`` that we'd like to
661  
-use for large text fields instead of the default ``<textarea>``. Here's how we'd
662  
-do that::
  667
+    Since that's a bit abstract, let's look at a concrete example. The most
  668
+    common use of ``formfield_overrides`` is to add a custom widget for a
  669
+    certain type of field. So, imagine we've written a ``RichTextEditorWidget``
  670
+    that we'd like to use for large text fields instead of the default
  671
+    ``<textarea>``. Here's how we'd do that::
663 672
 
664  
-    from django.db import models
665  
-    from django.contrib import admin
  673
+        from django.db import models
  674
+        from django.contrib import admin
666 675
 
667  
-    # Import our custom widget and our model from where they're defined
668  
-    from myapp.widgets import RichTextEditorWidget
669  
-    from myapp.models import MyModel
  676
+        # Import our custom widget and our model from where they're defined
  677
+        from myapp.widgets import RichTextEditorWidget
  678
+        from myapp.models import MyModel
670 679
 
671  
-    class MyModelAdmin(admin.ModelAdmin):
672  
-        formfield_overrides = {
673  
-            models.TextField: {'widget': RichTextEditorWidget},
674  
-        }
  680
+        class MyModelAdmin(admin.ModelAdmin):
  681
+            formfield_overrides = {
  682
+                models.TextField: {'widget': RichTextEditorWidget},
  683
+            }
675 684
 
676  
-Note that the key in the dictionary is the actual field class, *not* a string.
677  
-The value is another dictionary; these arguments will be passed to
678  
-:meth:`~django.forms.Field.__init__`. See :doc:`/ref/forms/api` for details.
  685
+    Note that the key in the dictionary is the actual field class, *not* a
  686
+    string. The value is another dictionary; these arguments will be passed to
  687
+    :meth:`~django.forms.Field.__init__`. See :doc:`/ref/forms/api` for
  688
+    details.
679 689
 
680  
-.. warning::
  690
+    .. warning::
681 691
 
682  
-    If you want to use a custom widget with a relation field (i.e.
683  
-    :class:`~django.db.models.ForeignKey` or
684  
-    :class:`~django.db.models.ManyToManyField`), make sure you haven't included
685  
-    that field's name in ``raw_id_fields`` or ``radio_fields``.
  692
+        If you want to use a custom widget with a relation field (i.e.
  693
+        :class:`~django.db.models.ForeignKey` or
  694
+        :class:`~django.db.models.ManyToManyField`), make sure you haven't included
  695
+        that field's name in ``raw_id_fields`` or ``radio_fields``.
686 696
 
687  
-    ``formfield_overrides`` won't let you change the widget on relation fields
688  
-    that have ``raw_id_fields`` or ``radio_fields`` set. That's because
689  
-    ``raw_id_fields`` and ``radio_fields`` imply custom widgets of their own.
  697
+        ``formfield_overrides`` won't let you change the widget on relation
  698
+        fields that have ``raw_id_fields`` or ``radio_fields`` set. That's
  699
+        because ``raw_id_fields`` and ``radio_fields`` imply custom widgets of
  700
+        their own.
690 701
 
691 702
 .. attribute:: ModelAdmin.actions
692 703
 
693  
-.. versionadded:: 1.1
  704
+    .. versionadded:: 1.1
694 705
 
695  
-A list of actions to make available on the change list page. See
696  
-:doc:`/ref/contrib/admin/actions` for details.
  706
+    A list of actions to make available on the change list page. See
  707
+    :doc:`/ref/contrib/admin/actions` for details.
697 708
 
698 709
 .. attribute:: ModelAdmin.actions_on_top
699 710
 .. attribute:: ModelAdmin.actions_on_bottom
700 711
 
701  
-.. versionadded:: 1.1
  712
+    .. versionadded:: 1.1
702 713
 
703  
-Controls where on the page the actions bar appears. By default, the admin
704  
-changelist displays actions at the top of the page (``actions_on_top = True;
705  
-actions_on_bottom = False``).
  714
+    Controls where on the page the actions bar appears. By default, the admin
  715
+    changelist displays actions at the top of the page (``actions_on_top = True;
  716
+    actions_on_bottom = False``).
706 717
 
707 718
 .. attribute:: ModelAdmin.actions_selection_counter
708 719
 
709  
-.. versionadded:: 1.2
  720
+    .. versionadded:: 1.2
710 721
 
711  
-Controls whether a selection counter is display next to the action dropdown.
712  
-By default, the admin changelist will display it
713  
-(``actions_selection_counter = True``).
  722
+    Controls whether a selection counter is display next to the action dropdown.
  723
+    By default, the admin changelist will display it
  724
+    (``actions_selection_counter = True``).
714 725
 
715 726
 Custom template options
716 727
 ~~~~~~~~~~~~~~~~~~~~~~~
@@ -759,133 +770,136 @@ templates used by the :class:`ModelAdmin` views:
759 770
 
760 771
 .. method:: ModelAdmin.save_model(self, request, obj, form, change)
761 772
 
762  
-The ``save_model`` method is given the ``HttpRequest``, a model instance,
763  
-a ``ModelForm`` instance and a boolean value based on whether it is adding or
764  
-changing the object. Here you can do any pre- or post-save operations.
  773
+    The ``save_model`` method is given the ``HttpRequest``, a model instance,
  774
+    a ``ModelForm`` instance and a boolean value based on whether it is adding
  775
+    or changing the object. Here you can do any pre- or post-save operations.
765 776
 
766  
-For example to attach ``request.user`` to the object prior to saving::
  777
+    For example to attach ``request.user`` to the object prior to saving::
767 778
 
768  
-    class ArticleAdmin(admin.ModelAdmin):
769  
-        def save_model(self, request, obj, form, change):
770  
-            obj.user = request.user
771  
-            obj.save()
  779
+        class ArticleAdmin(admin.ModelAdmin):
  780
+            def save_model(self, request, obj, form, change):
  781
+                obj.user = request.user
  782
+                obj.save()
772 783
 
773 784
 .. method:: ModelAdmin.save_formset(self, request, form, formset, change)
774 785
 
775  
-The ``save_formset`` method is given the ``HttpRequest``, the parent
776  
-``ModelForm`` instance and a boolean value based on whether it is adding or
777  
-changing the parent object.
  786
+    The ``save_formset`` method is given the ``HttpRequest``, the parent
  787
+    ``ModelForm`` instance and a boolean value based on whether it is adding or