Ticket #14112: 14112.2.diff

docs/faq/admin.txt

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

docs/ref/contrib/admin/index.txt

@@ -5 +5 @@
 .. 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 +829 @@
 
 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 +1008 @@
 ``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::
 

docs/ref/contrib/contenttypes.txt

@@ -112 +112 @@
 
     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 +370 @@
 
     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

docs/ref/contrib/gis/testing.txt

@@ -133 +133 @@
 If ``init_spatialite-2.3.sql`` is in the same path as your project's ``manage.py``,
 then all you have to do is::
 
-    $ python manage.py test 
+    $ python manage.py test
 
 Settings
 --------
@@ -166 +166 @@
 
 .. note::
 
-    In order to create a spatial database, the :setting:`DATABASE_USER` setting
-    (or :setting:`TEST_DATABASE_USER`, if optionally defined on Oracle) requires
-    elevated privileges.  When using PostGIS or MySQL, the database user 
+    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.
 

docs/ref/contrib/index.txt

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

docs/ref/django-admin.txt

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

docs/ref/models/fields.txt

@@ -291 +291 @@
 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 +301 @@
 A list of validators to run for this field.See the :doc:`validators
 documentation </ref/validators>` for more information.
 
+.. _model-field-types:
 
 Field types
 ===========

docs/ref/models/querysets.txt

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

docs/ref/settings.txt

@@ -130 +130 @@
 
 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 +401 @@
 
 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 +580 @@
 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 +590 @@
 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 +1195 @@
 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

docs/ref/templates/api.txt

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

docs/topics/testing.txt

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