Fixed #14112 -- Various Markup fixes for the docs. Thanks to ramiro for the patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@13628 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
5d4c37af7c
commit
a323fd3c5e
|
@ -35,19 +35,22 @@ Set the :setting:`CACHE_MIDDLEWARE_ANONYMOUS_ONLY` setting to ``True``. See the
|
||||||
How do I automatically set a field's value to the user who last edited the object in the admin?
|
How do I automatically set a field's value to the user who last edited the object in the admin?
|
||||||
-----------------------------------------------------------------------------------------------
|
-----------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
The :class:`ModelAdmin` class provides customization hooks that allow you to transform
|
The :class:`~django.contrib.admin.ModelAdmin` class provides customization hooks
|
||||||
an object as it saved, using details from the request. By extracting the current user
|
that allow you to transform an object as it saved, using details from the
|
||||||
from the request, and customizing the :meth:`ModelAdmin.save_model` hook, you can update
|
request. By extracting the current user from the request, and customizing the
|
||||||
an object to reflect the user that edited it. See :ref:`the documentation on ModelAdmin
|
:meth:`~django.contrib.admin.ModelAdmin.save_model` hook, you can update an
|
||||||
methods <model-admin-methods>` for an example.
|
object to reflect the user that edited it. See :ref:`the documentation on
|
||||||
|
ModelAdmin methods <model-admin-methods>` for an example.
|
||||||
|
|
||||||
How do I limit admin access so that objects can only be edited by the users who created them?
|
How do I limit admin access so that objects can only be edited by the users who created them?
|
||||||
---------------------------------------------------------------------------------------------
|
---------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
The :class:`ModelAdmin` class also provides customization hooks that allow you to control the
|
The :class:`~django.contrib.admin.ModelAdmin` class also provides customization
|
||||||
visibility and editability of objects in the admin. Using the same trick of extracting the
|
hooks that allow you to control the visibility and editability of objects in the
|
||||||
user from the request, the :meth:`ModelAdmin.queryset` and :meth:`ModelAdmin.has_change_permission`
|
admin. Using the same trick of extracting the user from the request, the
|
||||||
can be used to control the visibility and editability of objects in the admin.
|
:meth:`~django.contrib.admin.ModelAdmin.queryset` and
|
||||||
|
:meth:`~django.contrib.admin.ModelAdmin.has_change_permission` can be used to
|
||||||
|
control the visibility and editability of objects in the admin.
|
||||||
|
|
||||||
My admin-site CSS and images showed up fine using the development server, but they're not displaying when using mod_python.
|
My admin-site CSS and images showed up fine using the development server, but they're not displaying when using mod_python.
|
||||||
---------------------------------------------------------------------------------------------------------------------------
|
---------------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
|
@ -5,8 +5,6 @@ The Django admin site
|
||||||
.. module:: django.contrib.admin
|
.. module:: django.contrib.admin
|
||||||
:synopsis: Django's admin site.
|
:synopsis: Django's admin site.
|
||||||
|
|
||||||
.. currentmodule:: django.contrib.admin
|
|
||||||
|
|
||||||
One of the most powerful parts of Django is the automatic admin interface. It
|
One of the most powerful parts of Django is the automatic admin interface. It
|
||||||
reads metadata in your model to provide a powerful and production-ready
|
reads metadata in your model to provide a powerful and production-ready
|
||||||
interface that content producers can immediately use to start adding content to
|
interface that content producers can immediately use to start adding content to
|
||||||
|
@ -831,7 +829,7 @@ problems:
|
||||||
|
|
||||||
Since this is usually not what you want, Django provides a convenience wrapper
|
Since this is usually not what you want, Django provides a convenience wrapper
|
||||||
to check permissions and mark the view as non-cacheable. This wrapper is
|
to check permissions and mark the view as non-cacheable. This wrapper is
|
||||||
:meth:`AdminSite.admin_view` (i.e. ``self.admin_site.admin_view`` inside a
|
:meth:`AdminSite.admin_view` (i.e. ``self.admin_site.admin_view`` inside a
|
||||||
``ModelAdmin`` instance); use it like so::
|
``ModelAdmin`` instance); use it like so::
|
||||||
|
|
||||||
class MyModelAdmin(admin.ModelAdmin):
|
class MyModelAdmin(admin.ModelAdmin):
|
||||||
|
@ -1010,6 +1008,8 @@ information.
|
||||||
``InlineModelAdmin`` objects
|
``InlineModelAdmin`` objects
|
||||||
============================
|
============================
|
||||||
|
|
||||||
|
.. class:: InlineModelAdmin
|
||||||
|
|
||||||
The admin interface has the ability to edit models on the same page as a
|
The admin interface has the ability to edit models on the same page as a
|
||||||
parent model. These are called inlines. Suppose you have these two models::
|
parent model. These are called inlines. Suppose you have these two models::
|
||||||
|
|
||||||
|
|
|
@ -112,7 +112,7 @@ Methods on ``ContentType`` instances
|
||||||
|
|
||||||
Takes a set of valid :ref:`lookup arguments <field-lookups-intro>` for the
|
Takes a set of valid :ref:`lookup arguments <field-lookups-intro>` for the
|
||||||
model the :class:`~django.contrib.contenttypes.models.ContentType`
|
model the :class:`~django.contrib.contenttypes.models.ContentType`
|
||||||
represents, and does :ref:`a get() lookup <get-kwargs>` on that model,
|
represents, and does :lookup:`a get() lookup <get>` on that model,
|
||||||
returning the corresponding object.
|
returning the corresponding object.
|
||||||
|
|
||||||
.. method:: models.ContentType.model_class()
|
.. method:: models.ContentType.model_class()
|
||||||
|
@ -370,7 +370,7 @@ This enables the use of generic relations in forms and the admin. See the
|
||||||
|
|
||||||
The :class:`~django.contrib.contenttypes.generic.GenericInlineModelAdmin`
|
The :class:`~django.contrib.contenttypes.generic.GenericInlineModelAdmin`
|
||||||
class inherits all properties from an
|
class inherits all properties from an
|
||||||
:class:`~django.contrib.admin.options.InlineModelAdmin` class. However,
|
:class:`~django.contrib.admin.InlineModelAdmin` class. However,
|
||||||
it adds a couple of its own for working with the generic relation:
|
it adds a couple of its own for working with the generic relation:
|
||||||
|
|
||||||
.. attribute:: generic.GenericInlineModelAdmin.ct_field
|
.. attribute:: generic.GenericInlineModelAdmin.ct_field
|
||||||
|
|
|
@ -133,7 +133,7 @@ You will need to download the `initialization SQL`__ script for SpatiaLite::
|
||||||
If ``init_spatialite-2.3.sql`` is in the same path as your project's ``manage.py``,
|
If ``init_spatialite-2.3.sql`` is in the same path as your project's ``manage.py``,
|
||||||
then all you have to do is::
|
then all you have to do is::
|
||||||
|
|
||||||
$ python manage.py test
|
$ python manage.py test
|
||||||
|
|
||||||
Settings
|
Settings
|
||||||
--------
|
--------
|
||||||
|
@ -166,9 +166,9 @@ must be used. To use this runner, configure :setting:`TEST_RUNNER` as follows::
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
In order to create a spatial database, the :setting:`DATABASE_USER` setting
|
In order to create a spatial database, the :setting:`USER` setting
|
||||||
(or :setting:`TEST_DATABASE_USER`, if optionally defined on Oracle) requires
|
(or :setting:`TEST_USER`, if optionally defined on Oracle) requires
|
||||||
elevated privileges. When using PostGIS or MySQL, the database user
|
elevated privileges. When using PostGIS or MySQL, the database user
|
||||||
must have at least the ability to create databases. When testing on Oracle,
|
must have at least the ability to create databases. When testing on Oracle,
|
||||||
the user should be a superuser.
|
the user should be a superuser.
|
||||||
|
|
||||||
|
|
|
@ -166,8 +166,9 @@ For more documentation, read the source code in
|
||||||
ReStructured Text
|
ReStructured Text
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
When using the `restructuredtext` markup filter you can define a :setting:`RESTRUCTUREDTEXT_FORMAT_SETTINGS`
|
When using the ``restructuredtext`` markup filter you can define a
|
||||||
in your django settings to override the default writer settings. See the `restructuredtext writer settings`_ for
|
:setting:`RESTRUCTUREDTEXT_FILTER_SETTINGS` in your django settings to override
|
||||||
|
the default writer settings. See the `restructuredtext writer settings`_ for
|
||||||
details on what these settings are.
|
details on what these settings are.
|
||||||
|
|
||||||
.. _restructuredtext writer settings: http://docutils.sourceforge.net/docs/user/config.html#html4css1-writer
|
.. _restructuredtext writer settings: http://docutils.sourceforge.net/docs/user/config.html#html4css1-writer
|
||||||
|
|
|
@ -104,7 +104,7 @@ compilemessages
|
||||||
Compiles .po files created with ``makemessages`` to .mo files for use with
|
Compiles .po files created with ``makemessages`` to .mo files for use with
|
||||||
the builtin gettext support. See :doc:`/topics/i18n/index`.
|
the builtin gettext support. See :doc:`/topics/i18n/index`.
|
||||||
|
|
||||||
Use the :djadminopt:`--locale`` option to specify the locale to process.
|
Use the :djadminopt:`--locale` option to specify the locale to process.
|
||||||
If not provided, all locales are processed.
|
If not provided, all locales are processed.
|
||||||
|
|
||||||
Example usage::
|
Example usage::
|
||||||
|
|
|
@ -291,8 +291,6 @@ A human-readable name for the field. If the verbose name isn't given, Django
|
||||||
will automatically create it using the field's attribute name, converting
|
will automatically create it using the field's attribute name, converting
|
||||||
underscores to spaces. See :ref:`Verbose field names <verbose-field-names>`.
|
underscores to spaces. See :ref:`Verbose field names <verbose-field-names>`.
|
||||||
|
|
||||||
.. _model-field-types:
|
|
||||||
|
|
||||||
``validators``
|
``validators``
|
||||||
-------------------
|
-------------------
|
||||||
|
|
||||||
|
@ -303,6 +301,7 @@ underscores to spaces. See :ref:`Verbose field names <verbose-field-names>`.
|
||||||
A list of validators to run for this field.See the :doc:`validators
|
A list of validators to run for this field.See the :doc:`validators
|
||||||
documentation </ref/validators>` for more information.
|
documentation </ref/validators>` for more information.
|
||||||
|
|
||||||
|
.. _model-field-types:
|
||||||
|
|
||||||
Field types
|
Field types
|
||||||
===========
|
===========
|
||||||
|
|
|
@ -962,8 +962,6 @@ something *other than* a ``QuerySet``.
|
||||||
These methods do not use a cache (see :ref:`caching-and-querysets`). Rather,
|
These methods do not use a cache (see :ref:`caching-and-querysets`). Rather,
|
||||||
they query the database each time they're called.
|
they query the database each time they're called.
|
||||||
|
|
||||||
.. _get-kwargs:
|
|
||||||
|
|
||||||
``get(**kwargs)``
|
``get(**kwargs)``
|
||||||
~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
|
|
@ -130,6 +130,22 @@ Default: ``'locmem://'``
|
||||||
|
|
||||||
The cache backend to use. See :doc:`/topics/cache`.
|
The cache backend to use. See :doc:`/topics/cache`.
|
||||||
|
|
||||||
|
.. setting:: CACHE_MIDDLEWARE_ANONYMOUS_ONLY
|
||||||
|
|
||||||
|
CACHE_MIDDLEWARE_ANONYMOUS_ONLY
|
||||||
|
-------------------------------
|
||||||
|
|
||||||
|
Default: ``False``
|
||||||
|
|
||||||
|
If the value of this setting is ``True``, only anonymous requests (i.e., not
|
||||||
|
those made by a logged-in user) will be cached. Otherwise, the middleware
|
||||||
|
caches every page that doesn't have GET or POST parameters.
|
||||||
|
|
||||||
|
If you set the value of this setting to ``True``, you should make sure you've
|
||||||
|
activated ``AuthenticationMiddleware``.
|
||||||
|
|
||||||
|
See the :doc:`cache documentation </topics/cache>` for more information.
|
||||||
|
|
||||||
.. setting:: CACHE_MIDDLEWARE_KEY_PREFIX
|
.. setting:: CACHE_MIDDLEWARE_KEY_PREFIX
|
||||||
|
|
||||||
CACHE_MIDDLEWARE_KEY_PREFIX
|
CACHE_MIDDLEWARE_KEY_PREFIX
|
||||||
|
@ -385,6 +401,17 @@ test database will use the name ``'test_' + DATABASE_NAME``.
|
||||||
|
|
||||||
See :doc:`/topics/testing`.
|
See :doc:`/topics/testing`.
|
||||||
|
|
||||||
|
.. setting:: TEST_USER
|
||||||
|
|
||||||
|
TEST_USER
|
||||||
|
~~~~~~~~~
|
||||||
|
|
||||||
|
Default: ``None``
|
||||||
|
|
||||||
|
This is an Oracle-specific setting.
|
||||||
|
|
||||||
|
The username to use when connecting to the Oracle database that will be used
|
||||||
|
when running tests.
|
||||||
|
|
||||||
.. setting:: DATABASE_ROUTERS
|
.. setting:: DATABASE_ROUTERS
|
||||||
|
|
||||||
|
@ -553,7 +580,7 @@ Default content type to use for all ``HttpResponse`` objects, if a MIME type
|
||||||
isn't manually specified. Used with ``DEFAULT_CHARSET`` to construct the
|
isn't manually specified. Used with ``DEFAULT_CHARSET`` to construct the
|
||||||
``Content-Type`` header.
|
``Content-Type`` header.
|
||||||
|
|
||||||
.. setting:: DEFAULT_FROM_EMAIL
|
.. setting:: DEFAULT_FILE_STORAGE
|
||||||
|
|
||||||
DEFAULT_FILE_STORAGE
|
DEFAULT_FILE_STORAGE
|
||||||
--------------------
|
--------------------
|
||||||
|
@ -563,6 +590,8 @@ Default: ``'django.core.files.storage.FileSystemStorage'``
|
||||||
Default file storage class to be used for any file-related operations that don't
|
Default file storage class to be used for any file-related operations that don't
|
||||||
specify a particular storage system. See :doc:`/topics/files`.
|
specify a particular storage system. See :doc:`/topics/files`.
|
||||||
|
|
||||||
|
.. setting:: DEFAULT_FROM_EMAIL
|
||||||
|
|
||||||
DEFAULT_FROM_EMAIL
|
DEFAULT_FROM_EMAIL
|
||||||
------------------
|
------------------
|
||||||
|
|
||||||
|
@ -1166,6 +1195,21 @@ We don't list the default values here, because that would be profane. To see
|
||||||
the default values, see the file `django/conf/global_settings.py`_.
|
the default values, see the file `django/conf/global_settings.py`_.
|
||||||
|
|
||||||
.. _django/conf/global_settings.py: http://code.djangoproject.com/browser/django/trunk/django/conf/global_settings.py
|
.. _django/conf/global_settings.py: http://code.djangoproject.com/browser/django/trunk/django/conf/global_settings.py
|
||||||
|
|
||||||
|
.. setting:: RESTRUCTUREDTEXT_FILTER_SETTINGS
|
||||||
|
|
||||||
|
RESTRUCTUREDTEXT_FILTER_SETTINGS
|
||||||
|
--------------------------------
|
||||||
|
|
||||||
|
Default: ``{}``
|
||||||
|
|
||||||
|
A dictionary containing settings for the ``restructuredtext`` markup filter from
|
||||||
|
the :doc:`django.contrib.markup application </ref/contrib/markup>`. They override
|
||||||
|
the default writer settings. See the Docutils restructuredtext `writer settings
|
||||||
|
docs`_ for details.
|
||||||
|
|
||||||
|
.. _writer settings docs: http://docutils.sourceforge.net/docs/user/config.html#html4css1-writer
|
||||||
|
|
||||||
.. setting:: ROOT_URLCONF
|
.. setting:: ROOT_URLCONF
|
||||||
|
|
||||||
ROOT_URLCONF
|
ROOT_URLCONF
|
||||||
|
|
|
@ -700,7 +700,7 @@ Configuring the template system in standalone mode
|
||||||
|
|
||||||
Normally, Django will load all the configuration information it needs from its
|
Normally, Django will load all the configuration information it needs from its
|
||||||
own default configuration file, combined with the settings in the module given
|
own default configuration file, combined with the settings in the module given
|
||||||
in the :setting:`DJANGO_SETTINGS_MODULE` environment variable. But if you're
|
in the :envvar:`DJANGO_SETTINGS_MODULE` environment variable. But if you're
|
||||||
using the template system independently of the rest of Django, the environment
|
using the template system independently of the rest of Django, the environment
|
||||||
variable approach isn't very convenient, because you probably want to configure
|
variable approach isn't very convenient, because you probably want to configure
|
||||||
the template system in line with the rest of your application rather than
|
the template system in line with the rest of your application rather than
|
||||||
|
|
|
@ -310,7 +310,7 @@ but not gracefully. No details of the tests run before the interruption will
|
||||||
be reported, and any test databases created by the run will not be destroyed.
|
be reported, and any test databases created by the run will not be destroyed.
|
||||||
|
|
||||||
Running tests outside the test runner
|
Running tests outside the test runner
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
-------------------------------------
|
||||||
|
|
||||||
If you want to run tests outside of ``./manage.py test`` -- for example,
|
If you want to run tests outside of ``./manage.py test`` -- for example,
|
||||||
from a shell prompt -- you will need to set up the test
|
from a shell prompt -- you will need to set up the test
|
||||||
|
@ -417,7 +417,7 @@ Other test conditions
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
Regardless of the value of the :setting:`DEBUG` setting in your configuration
|
Regardless of the value of the :setting:`DEBUG` setting in your configuration
|
||||||
file, all Django tests run with :setting:`DEBUG=False`. This is to ensure that
|
file, all Django tests run with :setting:`DEBUG`\=False. This is to ensure that
|
||||||
the observed output of your code matches what will be seen in a production
|
the observed output of your code matches what will be seen in a production
|
||||||
setting.
|
setting.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue