diff --git a/docs/faq/admin.txt b/docs/faq/admin.txt index 8ee6cc184bb..cd0e4f92b67 100644 --- a/docs/faq/admin.txt +++ b/docs/faq/admin.txt @@ -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 ` 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 ` 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. --------------------------------------------------------------------------------------------------------------------------- diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt index 86163c8401a..055057677c5 100644 --- a/docs/ref/contrib/admin/index.txt +++ b/docs/ref/contrib/admin/index.txt @@ -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:: diff --git a/docs/ref/contrib/contenttypes.txt b/docs/ref/contrib/contenttypes.txt index de56b0f0eec..b6956512ad5 100644 --- a/docs/ref/contrib/contenttypes.txt +++ b/docs/ref/contrib/contenttypes.txt @@ -112,7 +112,7 @@ Methods on ``ContentType`` instances Takes a set of valid :ref:`lookup arguments ` for the model the :class:`~django.contrib.contenttypes.models.ContentType` - represents, and does :ref:`a get() lookup ` on that model, + represents, and does :lookup:`a get() lookup ` 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 diff --git a/docs/ref/contrib/gis/testing.txt b/docs/ref/contrib/gis/testing.txt index 3401e4d7698..2e81510cd90 100644 --- a/docs/ref/contrib/gis/testing.txt +++ b/docs/ref/contrib/gis/testing.txt @@ -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``, then all you have to do is:: - $ python manage.py test + $ python manage.py test Settings -------- @@ -166,9 +166,9 @@ 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 - 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. diff --git a/docs/ref/contrib/index.txt b/docs/ref/contrib/index.txt index 89680150ff7..177da89eddb 100644 --- a/docs/ref/contrib/index.txt +++ b/docs/ref/contrib/index.txt @@ -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 diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt index 335c8b89991..67b1b6c9db5 100644 --- a/docs/ref/django-admin.txt +++ b/docs/ref/django-admin.txt @@ -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:: diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt index da0b24622a3..68208b3bfe9 100644 --- a/docs/ref/models/fields.txt +++ b/docs/ref/models/fields.txt @@ -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 `. -.. _model-field-types: - ``validators`` ------------------- @@ -303,6 +301,7 @@ underscores to spaces. See :ref:`Verbose field names `. A list of validators to run for this field.See the :doc:`validators documentation ` for more information. +.. _model-field-types: Field types =========== diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt index 02d105d3cb5..a42452d07d2 100644 --- a/docs/ref/models/querysets.txt +++ b/docs/ref/models/querysets.txt @@ -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)`` ~~~~~~~~~~~~~~~~~ diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt index 834f6112a99..cb0e1afbf5a 100644 --- a/docs/ref/settings.txt +++ b/docs/ref/settings.txt @@ -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 ` 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 `. 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 diff --git a/docs/ref/templates/api.txt b/docs/ref/templates/api.txt index 3c4e3b34e43..2ac4e653c49 100644 --- a/docs/ref/templates/api.txt +++ b/docs/ref/templates/api.txt @@ -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 diff --git a/docs/topics/testing.txt b/docs/topics/testing.txt index bfd1ef5e508..9c1d8b28fd2 100644 --- a/docs/topics/testing.txt +++ b/docs/topics/testing.txt @@ -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.