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?
|
||||
-----------------------------------------------------------------------------------------------
|
||||
|
||||
The :class:`ModelAdmin` class provides customization hooks that allow you to transform
|
||||
an object as it saved, using details from the request. By extracting the current user
|
||||
from the request, and customizing the :meth:`ModelAdmin.save_model` hook, you can update
|
||||
an object to reflect the user that edited it. See :ref:`the documentation on ModelAdmin
|
||||
methods <model-admin-methods>` for an example.
|
||||
The :class:`~django.contrib.admin.ModelAdmin` class provides customization hooks
|
||||
that allow you to transform an object as it saved, using details from the
|
||||
request. By extracting the current user from the request, and customizing the
|
||||
:meth:`~django.contrib.admin.ModelAdmin.save_model` hook, you can update an
|
||||
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?
|
||||
---------------------------------------------------------------------------------------------
|
||||
|
||||
The :class:`ModelAdmin` class also provides customization hooks that allow you to control the
|
||||
visibility and editability of objects in the admin. Using the same trick of extracting the
|
||||
user from the request, the :meth:`ModelAdmin.queryset` and :meth:`ModelAdmin.has_change_permission`
|
||||
can be used to control the visibility and editability of objects in the admin.
|
||||
The :class:`~django.contrib.admin.ModelAdmin` class also provides customization
|
||||
hooks that allow you to control the visibility and editability of objects in the
|
||||
admin. Using the same trick of extracting the user from the request, the
|
||||
: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.
|
||||
---------------------------------------------------------------------------------------------------------------------------
|
||||
|
|
|
@ -5,8 +5,6 @@ The Django admin site
|
|||
.. module:: django.contrib.admin
|
||||
:synopsis: Django's admin site.
|
||||
|
||||
.. currentmodule:: django.contrib.admin
|
||||
|
||||
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
|
||||
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
|
||||
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::
|
||||
|
||||
class MyModelAdmin(admin.ModelAdmin):
|
||||
|
@ -1010,6 +1008,8 @@ information.
|
|||
``InlineModelAdmin`` objects
|
||||
============================
|
||||
|
||||
.. class:: InlineModelAdmin
|
||||
|
||||
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::
|
||||
|
||||
|
|
|
@ -112,7 +112,7 @@ Methods on ``ContentType`` instances
|
|||
|
||||
Takes a set of valid :ref:`lookup arguments <field-lookups-intro>` for the
|
||||
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.
|
||||
|
||||
.. 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`
|
||||
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:
|
||||
|
||||
.. attribute:: generic.GenericInlineModelAdmin.ct_field
|
||||
|
|
|
@ -166,8 +166,8 @@ must be used. To use this runner, configure :setting:`TEST_RUNNER` as follows::
|
|||
|
||||
.. note::
|
||||
|
||||
In order to create a spatial database, the :setting:`DATABASE_USER` setting
|
||||
(or :setting:`TEST_DATABASE_USER`, if optionally defined on Oracle) requires
|
||||
In order to create a spatial database, the :setting:`USER` setting
|
||||
(or :setting:`TEST_USER`, if optionally defined on Oracle) requires
|
||||
elevated privileges. When using PostGIS or MySQL, the database user
|
||||
must have at least the ability to create databases. When testing on Oracle,
|
||||
the user should be a superuser.
|
||||
|
|
|
@ -166,8 +166,9 @@ For more documentation, read the source code in
|
|||
ReStructured Text
|
||||
-----------------
|
||||
|
||||
When using the `restructuredtext` markup filter you can define a :setting:`RESTRUCTUREDTEXT_FORMAT_SETTINGS`
|
||||
in your django settings to override the default writer settings. See the `restructuredtext writer settings`_ for
|
||||
When using the ``restructuredtext`` markup filter you can define a
|
||||
: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.
|
||||
|
||||
.. _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
|
||||
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.
|
||||
|
||||
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
|
||||
underscores to spaces. See :ref:`Verbose field names <verbose-field-names>`.
|
||||
|
||||
.. _model-field-types:
|
||||
|
||||
``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
|
||||
documentation </ref/validators>` for more information.
|
||||
|
||||
.. _model-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,
|
||||
they query the database each time they're called.
|
||||
|
||||
.. _get-kwargs:
|
||||
|
||||
``get(**kwargs)``
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
|
@ -130,6 +130,22 @@ Default: ``'locmem://'``
|
|||
|
||||
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
|
||||
|
||||
CACHE_MIDDLEWARE_KEY_PREFIX
|
||||
|
@ -385,6 +401,17 @@ test database will use the name ``'test_' + DATABASE_NAME``.
|
|||
|
||||
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
|
||||
|
||||
|
@ -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
|
||||
``Content-Type`` header.
|
||||
|
||||
.. setting:: DEFAULT_FROM_EMAIL
|
||||
.. setting:: 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
|
||||
specify a particular storage system. See :doc:`/topics/files`.
|
||||
|
||||
.. setting:: 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`_.
|
||||
|
||||
.. _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
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
|
|
|
@ -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.
|
||||
|
||||
Running tests outside the test runner
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
-------------------------------------
|
||||
|
||||
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
|
||||
|
@ -417,7 +417,7 @@ Other test conditions
|
|||
---------------------
|
||||
|
||||
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
|
||||
setting.
|
||||
|
||||
|
|
Loading…
Reference in New Issue