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:
Russell Keith-Magee 2010-08-23 08:07:35 +00:00
parent 5d4c37af7c
commit a323fd3c5e
11 changed files with 74 additions and 29 deletions

View File

@ -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.
---------------------------------------------------------------------------------------------------------------------------

View File

@ -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::

View File

@ -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

View File

@ -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.

View File

@ -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

View File

@ -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::

View File

@ -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
===========

View File

@ -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)``
~~~~~~~~~~~~~~~~~

View File

@ -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

View File

@ -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

View File

@ -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.