Author: russellm
Date: 2010-08-23 03:08:46 -0500 (Mon, 23 Aug 2010)
New Revision: 13629
Modified:
django/branches/releases/1.2.X/docs/faq/admin.txt
django/branches/releases/1.2.X/docs/ref/contrib/admin/index.txt
django/branches/releases/1.2.X/docs/ref/contrib/contenttypes.txt
django/branches/releases/1.2.X/docs/ref/contrib/gis/testing.txt
django/branches/releases/1.2.X/docs/ref/contrib/index.txt
django/branches/releases/1.2.X/docs/ref/django-admin.txt
django/branches/releases/1.2.X/docs/ref/models/fields.txt
django/branches/releases/1.2.X/docs/ref/models/querysets.txt
django/branches/releases/1.2.X/docs/ref/settings.txt
django/branches/releases/1.2.X/docs/ref/templates/api.txt
django/branches/releases/1.2.X/docs/topics/testing.txt
Log:
[1.2.X] Fixed #14112 -- Various Markup fixes for the docs. Thanks to ramiro for
the patch.
Backport of r13628 from trunk.
Modified: django/branches/releases/1.2.X/docs/faq/admin.txt
===================================================================
--- django/branches/releases/1.2.X/docs/faq/admin.txt 2010-08-23 08:07:35 UTC
(rev 13628)
+++ django/branches/releases/1.2.X/docs/faq/admin.txt 2010-08-23 08:08:46 UTC
(rev 13629)
@@ -35,19 +35,22 @@
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.
---------------------------------------------------------------------------------------------------------------------------
Modified: django/branches/releases/1.2.X/docs/ref/contrib/admin/index.txt
===================================================================
--- django/branches/releases/1.2.X/docs/ref/contrib/admin/index.txt
2010-08-23 08:07:35 UTC (rev 13628)
+++ django/branches/releases/1.2.X/docs/ref/contrib/admin/index.txt
2010-08-23 08:08:46 UTC (rev 13629)
@@ -5,8 +5,6 @@
.. 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 @@
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 @@
``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::
Modified: django/branches/releases/1.2.X/docs/ref/contrib/contenttypes.txt
===================================================================
--- django/branches/releases/1.2.X/docs/ref/contrib/contenttypes.txt
2010-08-23 08:07:35 UTC (rev 13628)
+++ django/branches/releases/1.2.X/docs/ref/contrib/contenttypes.txt
2010-08-23 08:08:46 UTC (rev 13629)
@@ -112,7 +112,7 @@
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 @@
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
Modified: django/branches/releases/1.2.X/docs/ref/contrib/gis/testing.txt
===================================================================
--- django/branches/releases/1.2.X/docs/ref/contrib/gis/testing.txt
2010-08-23 08:07:35 UTC (rev 13628)
+++ django/branches/releases/1.2.X/docs/ref/contrib/gis/testing.txt
2010-08-23 08:08:46 UTC (rev 13629)
@@ -133,7 +133,7 @@
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,9 +166,9 @@
.. 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.
Modified: django/branches/releases/1.2.X/docs/ref/contrib/index.txt
===================================================================
--- django/branches/releases/1.2.X/docs/ref/contrib/index.txt 2010-08-23
08:07:35 UTC (rev 13628)
+++ django/branches/releases/1.2.X/docs/ref/contrib/index.txt 2010-08-23
08:08:46 UTC (rev 13629)
@@ -166,8 +166,9 @@
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
Modified: django/branches/releases/1.2.X/docs/ref/django-admin.txt
===================================================================
--- django/branches/releases/1.2.X/docs/ref/django-admin.txt 2010-08-23
08:07:35 UTC (rev 13628)
+++ django/branches/releases/1.2.X/docs/ref/django-admin.txt 2010-08-23
08:08:46 UTC (rev 13629)
@@ -104,7 +104,7 @@
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::
Modified: django/branches/releases/1.2.X/docs/ref/models/fields.txt
===================================================================
--- django/branches/releases/1.2.X/docs/ref/models/fields.txt 2010-08-23
08:07:35 UTC (rev 13628)
+++ django/branches/releases/1.2.X/docs/ref/models/fields.txt 2010-08-23
08:08:46 UTC (rev 13629)
@@ -291,8 +291,6 @@
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 @@
A list of validators to run for this field.See the :doc:`validators
documentation </ref/validators>` for more information.
+.. _model-field-types:
Field types
===========
Modified: django/branches/releases/1.2.X/docs/ref/models/querysets.txt
===================================================================
--- django/branches/releases/1.2.X/docs/ref/models/querysets.txt
2010-08-23 08:07:35 UTC (rev 13628)
+++ django/branches/releases/1.2.X/docs/ref/models/querysets.txt
2010-08-23 08:08:46 UTC (rev 13629)
@@ -962,8 +962,6 @@
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)``
~~~~~~~~~~~~~~~~~
Modified: django/branches/releases/1.2.X/docs/ref/settings.txt
===================================================================
--- django/branches/releases/1.2.X/docs/ref/settings.txt 2010-08-23
08:07:35 UTC (rev 13628)
+++ django/branches/releases/1.2.X/docs/ref/settings.txt 2010-08-23
08:08:46 UTC (rev 13629)
@@ -130,6 +130,22 @@
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,7 +401,18 @@
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
DATABASE_ROUTERS
@@ -553,7 +580,7 @@
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 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 @@
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
Modified: django/branches/releases/1.2.X/docs/ref/templates/api.txt
===================================================================
--- django/branches/releases/1.2.X/docs/ref/templates/api.txt 2010-08-23
08:07:35 UTC (rev 13628)
+++ django/branches/releases/1.2.X/docs/ref/templates/api.txt 2010-08-23
08:08:46 UTC (rev 13629)
@@ -700,7 +700,7 @@
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
Modified: django/branches/releases/1.2.X/docs/topics/testing.txt
===================================================================
--- django/branches/releases/1.2.X/docs/topics/testing.txt 2010-08-23
08:07:35 UTC (rev 13628)
+++ django/branches/releases/1.2.X/docs/topics/testing.txt 2010-08-23
08:08:46 UTC (rev 13629)
@@ -310,7 +310,7 @@
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 @@
---------------------
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.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
