Fixed broken links, round 4. refs #19516

Configuration

=============

.. class:: django.contrib.auth.middleware.RemoteUserMiddleware

First, you must add the

:class:`django.contrib.auth.middleware.RemoteUserMiddleware` to the

:setting:`MIDDLEWARE_CLASSES` setting **after** the

Writing custom django-admin commands

====================================

.. module:: django.core.management

Applications can register their own actions with ``manage.py``. For example,

you might want to add a ``manage.py`` action for a Django app that you're

distributing. In this document, we will be building a custom ``closepoll``

    The actual logic of the command. Subclasses must implement this method.

.. method:: BaseCommand.validate(app=None, display_num_errors=False)

    Validates the given app, raising :class:`CommandError` for any errors.

    If ``app`` is None, then all installed apps are validated.

.. _ref-basecommand-subclasses:

BaseCommand subclasses

Initializing your new field is a matter of separating out any arguments that are

specific to your case from the common arguments and passing the latter to the

:meth:`~django.db.models.Field.__init__` method of

:class:`~django.db.models.Field` (or your parent class).

``__init__()`` method of :class:`~django.db.models.Field` (or your parent

class).

In our example, we'll call our field ``HandField``. (It's a good idea to call

your :class:`~django.db.models.Field` subclass ``<Something>Field``, so it's

This method is called by the :class:`~django.forms.ModelForm` helper.

All of the ``kwargs`` dictionary is passed directly to the form field's

:meth:`~django.forms.Field__init__` method. Normally, all you need to do is

set up a good default for the ``form_class`` argument and then delegate further

handling to the parent class. This might require you to write a custom form

field (and even a form widget). See the :doc:`forms documentation

</topics/forms/index>` for information about this, and take a look at the code in

``__init__()`` method. Normally, all you need to do is set up a good default

for the ``form_class`` argument and then delegate further handling to the

parent class. This might require you to write a custom form field (and even a

form widget). See the :doc:`forms documentation </topics/forms/index>` for

information about this, and take a look at the code in

:mod:`django.contrib.localflavor` for some examples of custom widgets.

Continuing our ongoing example, we can write the :meth:`.formfield` method as::

.. method:: Field.value_to_string(self, obj)

This method is used by the serializers to convert the field into a string for

output. Calling :meth:`Field._get_val_from_obj(obj)` is the best way to get the

output. Calling ``Field._get_val_from_obj(obj)`` is the best way to get the

value to serialize. For example, since our ``HandField`` uses strings for its

data storage anyway, we can reuse some existing conversion code::

   a field that's similar to what you want and extend it a little bit,

   instead of creating an entirely new field from scratch.

2. Put a :meth:`__str__` or :meth:`__unicode__` method on the class you're

2. Put a ``__str__()`` or ``__unicode__()`` method on the class you're

   wrapping up as a field. There are a lot of places where the default

   behavior of the field code is to call

   :func:`~django.utils.encoding.force_text` on the value. (In our

   examples in this document, ``value`` would be a ``Hand`` instance, not a

   ``HandField``). So if your :meth:`__unicode__` method automatically

   ``HandField``). So if your ``__unicode__()`` method automatically

   converts to the string form of your Python object, you can save yourself

   a lot of work.

* The old imports for CSRF functionality (``django.contrib.csrf.*``),

  which moved to core in 1.2, will be removed.

* The :mod:`django.contrib.gis.db.backend` module will be removed in favor

* The ``django.contrib.gis.db.backend`` module will be removed in favor

  of the specific backends.

* ``SMTPConnection`` will be removed in favor of a generic Email backend API.

  The :attr:`~django.test.client.Response.templates` attribute should be

  used instead.

* The :class:`~django.test.simple.DjangoTestRunner` will be removed.

* The ``django.test.simple.DjangoTestRunner`` will be removed.

  Instead use a unittest-native class.  The features of the

  :class:`django.test.simple.DjangoTestRunner` (including fail-fast and

  ``django.test.simple.DjangoTestRunner`` (including fail-fast and

  Ctrl-C test termination) can currently be provided by the unittest-native

  :class:`TextTestRunner`.

  :class:`~unittest.TextTestRunner`.

* The undocumented function

  :func:`django.contrib.formtools.utils.security_hash` will be removed,

  instead use :func:`django.contrib.formtools.utils.form_hmac`

  ``django.contrib.formtools.utils.security_hash`` will be removed,

  instead use ``django.contrib.formtools.utils.form_hmac``

* The function-based generic view modules will be removed in favor of their

  class-based equivalents, outlined :doc:`here

  </topics/class-based-views/index>`.

* The :class:`~django.core.servers.basehttp.AdminMediaHandler` will be

* The ``django.core.servers.basehttp.AdminMediaHandler`` will be

  removed.  In its place use

  :class:`~django.contrib.staticfiles.handlers.StaticFilesHandler`.

  ``django.contrib.staticfiles.handlers.StaticFilesHandler``.

* The template tags library ``adminmedia`` and the template tag ``{%

  admin_media_prefix %}`` will be removed in favor of the generic static files

  an implied string. In 1.4, this behavior is provided by a version of the tag

  in the ``future`` template tag library.

* The :djadmin:`reset` and :djadmin:`sqlreset` management commands

  will be removed.

* The ``reset`` and ``sqlreset`` management commands will be removed.

* Authentication backends will need to support an inactive user

  being passed to all methods dealing with permissions.

  a :class:`~django.contrib.gis.geos.GEOSException` when called

  on a geometry with no SRID value.

* :class:`~django.http.CompatCookie` will be removed in favor of

  :class:`~django.http.SimpleCookie`.

* ``django.http.CompatCookie`` will be removed in favor of

  ``django.http.SimpleCookie``.

* :class:`django.core.context_processors.PermWrapper` and

  :class:`django.core.context_processors.PermLookupDict` will be removed in

* ``django.core.context_processors.PermWrapper`` and

  ``django.core.context_processors.PermLookupDict`` will be removed in

  favor of the corresponding

  :class:`django.contrib.auth.context_processors.PermWrapper` and

  :class:`django.contrib.auth.context_processors.PermLookupDict`,

  ``django.utils.itercompat.all`` and ``django.utils.itercompat.any`` will

  be removed. The Python builtin versions should be used instead.

* The :func:`~django.views.decorators.csrf.csrf_response_exempt` and

  :func:`~django.views.decorators.csrf.csrf_view_exempt` decorators will

* The ``csrf_response_exempt`` and ``csrf_view_exempt`` decorators will

  be removed. Since 1.4 ``csrf_response_exempt`` has been a no-op (it

  returns the same function), and ``csrf_view_exempt`` has been a

  synonym for ``django.views.decorators.csrf.csrf_exempt``, which should

The auth framework uses two :doc:`signals </topics/signals>` that can be used

for notification when a user logs in or out.

.. function:: django.contrib.auth.signals.user_logged_in

.. function:: user_logged_in

    Sent when a user logs in successfully.

    ``user``

        The user instance that just logged in.

.. function:: django.contrib.auth.signals.user_logged_out

.. function:: user_logged_out

    Sent when the logout method is called.

        The user instance that just logged out or ``None`` if the

        user was not authenticated.

.. function:: django.contrib.auth.signals.user_login_failed

.. function:: user_login_failed

    .. versionadded:: 1.5