From e689873a6961ca80760abc2f7742af8912b81207 Mon Sep 17 00:00:00 2001 From: Tim Graham Date: Tue, 21 Jul 2015 08:11:28 -0400 Subject: [PATCH] [1.8.x] Normalized indentation and line lengths in docs/topics/auth/default.txt. Backport of 5fd83db255500507484c5fedbd98763460a59656 from master --- docs/topics/auth/default.txt | 73 ++++++++++++++++++------------------ 1 file changed, 37 insertions(+), 36 deletions(-) diff --git a/docs/topics/auth/default.txt b/docs/topics/auth/default.txt index 31460db03aa..51b4cf35dba 100644 --- a/docs/topics/auth/default.txt +++ b/docs/topics/auth/default.txt @@ -881,16 +881,16 @@ implementation details see :ref:`using-the-views`. {% endblock %} If you have customized authentication (see - :doc:`Customizing Authentication `) you can pass a custom authentication form - to the login view via the ``authentication_form`` parameter. This form must - accept a ``request`` keyword argument in its ``__init__`` method, and - provide a ``get_user`` method which returns the authenticated user object - (this method is only ever called after successful form validation). + :doc:`Customizing Authentication `) you can pass + a custom authentication form to the login view via the + ``authentication_form`` parameter. This form must accept a ``request`` + keyword argument in its ``__init__`` method, and provide a ``get_user()`` + method which returns the authenticated user object (this method is only + ever called after successful form validation). .. _forms documentation: ../forms/ .. _site framework docs: ../sites/ - .. function:: logout(request, [next_page, template_name, redirect_field_name, current_app, extra_context]) Logs a user out. @@ -1020,7 +1020,6 @@ implementation details see :ref:`using-the-views`. :class:`~django.contrib.auth.forms.PasswordResetForm` and use the ``password_reset_form`` argument. - Users flagged with an unusable password (see :meth:`~django.contrib.auth.models.User.set_unusable_password()` aren't allowed to request a password reset to prevent misuse when using an @@ -1126,8 +1125,9 @@ implementation details see :ref:`using-the-views`. .. note:: - If the email address provided does not exist in the system, the user is inactive, or has an unusable password, - the user will still be redirected to this view but no email will be sent. + If the email address provided does not exist in the system, the user is + inactive, or has an unusable password, the user will still be + redirected to this view but no email will be sent. **Optional arguments:** @@ -1185,22 +1185,22 @@ implementation details see :ref:`using-the-views`. .. function:: password_reset_complete(request[,template_name, current_app, extra_context]) - Presents a view which informs the user that the password has been - successfully changed. + Presents a view which informs the user that the password has been + successfully changed. - **URL name:** ``password_reset_complete`` + **URL name:** ``password_reset_complete`` - **Optional arguments:** + **Optional arguments:** - * ``template_name``: The full name of a template to display the view. - Defaults to :file:`registration/password_reset_complete.html`. + * ``template_name``: The full name of a template to display the view. + Defaults to :file:`registration/password_reset_complete.html`. - * ``current_app``: A hint indicating which application contains the current - view. See the :ref:`namespaced URL resolution strategy - ` for more information. + * ``current_app``: A hint indicating which application contains the current + view. See the :ref:`namespaced URL resolution strategy + ` for more information. - * ``extra_context``: A dictionary of context data that will be added to the - default context data passed to the template. + * ``extra_context``: A dictionary of context data that will be added to the + default context data passed to the template. Helper functions ---------------- @@ -1225,7 +1225,6 @@ Helper functions URL to redirect to after log out. Overrides ``next`` if the given ``GET`` parameter is passed. - .. _built-in-auth-forms: Built-in forms @@ -1262,14 +1261,16 @@ provides several built-in forms located in :mod:`django.contrib.auth.forms`: .. versionadded:: 1.7 - By default, ``AuthenticationForm`` rejects users whose ``is_active`` flag - is set to ``False``. You may override this behavior with a custom policy to - determine which users can log in. Do this with a custom form that subclasses - ``AuthenticationForm`` and overrides the ``confirm_login_allowed`` method. - This method should raise a :exc:`~django.core.exceptions.ValidationError` - if the given user may not log in. + By default, ``AuthenticationForm`` rejects users whose ``is_active`` + flag is set to ``False``. You may override this behavior with a custom + policy to determine which users can log in. Do this with a custom form + that subclasses ``AuthenticationForm`` and overrides the + ``confirm_login_allowed()`` method. This method should raise a + :exc:`~django.core.exceptions.ValidationError` if the given user may + not log in. - For example, to allow all users to log in, regardless of "active" status:: + For example, to allow all users to log in regardless of "active" + status:: from django.contrib.auth.forms import AuthenticationForm @@ -1310,8 +1311,9 @@ provides several built-in forms located in :mod:`django.contrib.auth.forms`: :param subject_template_name: the template for the subject. :param email_template_name: the template for the email body. - :param context: context passed to the ``subject_template``, ``email_template``, - and ``html_email_template`` (if it is not ``None``). + :param context: context passed to the ``subject_template``, + ``email_template``, and ``html_email_template`` (if it is not + ``None``). :param from_email: the sender's email. :param to_email: the email of the requester. :param html_email_template_name: the template for the HTML body; @@ -1337,7 +1339,6 @@ provides several built-in forms located in :mod:`django.contrib.auth.forms`: .. currentmodule:: django.contrib.auth - Authentication data in templates -------------------------------- @@ -1347,11 +1348,11 @@ The currently logged-in user and their permissions are made available in the .. admonition:: Technicality - Technically, these variables are only made available in the template - context if you use :class:`~django.template.RequestContext` and the - ``'django.contrib.auth.context_processors.auth'`` context processor is - enabled. It is in the default generated settings file. For more, see the - :ref:`RequestContext docs `. + Technically, these variables are only made available in the template + context if you use :class:`~django.template.RequestContext` and the + ``'django.contrib.auth.context_processors.auth'`` context processor is + enabled. It is in the default generated settings file. For more, see the + :ref:`RequestContext docs `. Users ~~~~~