Normalized casing of "custom user model".

docs/howto/deployment/wsgi/apache-auth.txt

@@ -15,7 +15,7 @@ version >= 2.2 and mod_wsgi >= 2.0. For example, you could:
 * Allow certain users to connect to a WebDAV share created with mod_dav_.
 
 .. note::
-    If you have installed a :ref:`custom User model <auth-custom-user>` and
+    If you have installed a :ref:`custom user model <auth-custom-user>` and
     want to use this default auth handler, it must support an ``is_active``
     attribute. If you want to use group based authorization, your custom user
     must have a relation named 'groups', referring to a related object that has

docs/ref/contrib/auth.txt

@@ -183,9 +183,9 @@ Methods
 
     .. method:: get_username()
 
-        Returns the username for the user. Since the User model can be swapped
-        out, you should use this method instead of referencing the username
-        attribute directly.
+        Returns the username for the user. Since the ``User`` model can be
+        swapped out, you should use this method instead of referencing the
+        username attribute directly.
 
     .. method:: get_full_name()
 
@@ -305,7 +305,7 @@ Manager methods
 
         The ``extra_fields`` keyword arguments are passed through to the
         :class:`~django.contrib.auth.models.User`’s ``__init__`` method to
-        allow setting arbitrary fields on a :ref:`custom User model
+        allow setting arbitrary fields on a :ref:`custom user model
         <auth-custom-user>`.
 
         See :ref:`Creating users <topics-auth-creating-users>` for example usage.
@@ -615,16 +615,14 @@ The following backends are available in :mod:`django.contrib.auth.backends`:
 
 .. attribute:: RemoteUserBackend.create_unknown_user
 
-    ``True`` or ``False``.  Determines whether or not a
-    :class:`~django.contrib.auth.models.User` object is created if not already
-    in the database.  Defaults to ``True``.
+    ``True`` or ``False``. Determines whether or not a user object is created
+    if not already in the database  Defaults to ``True``.
 
 .. method:: RemoteUserBackend.authenticate(request, remote_user)
 
     The username passed as ``remote_user`` is considered trusted. This method
-    simply returns the ``User`` object with the given username, creating a new
-    ``User`` object if :attr:`~RemoteUserBackend.create_unknown_user` is
-    ``True``.
+    simply returns the user object with the given username, creating a new
+    user object if :attr:`~RemoteUserBackend.create_unknown_user` is ``True``.
 
     Returns ``None`` if :attr:`~RemoteUserBackend.create_unknown_user` is
     ``False`` and a ``User`` object with the given username is not found in the
@@ -637,9 +635,8 @@ The following backends are available in :mod:`django.contrib.auth.backends`:
 .. method:: RemoteUserBackend.clean_username(username)
 
    Performs any cleaning on the ``username`` (e.g. stripping LDAP DN
-   information) prior to using it to get or create a
-   :class:`~django.contrib.auth.models.User` object.  Returns the cleaned
-   username.
+   information) prior to using it to get or create a user object. Returns the
+   cleaned username.
 
 .. method:: RemoteUserBackend.configure_user(user)
 

docs/releases/1.5.txt

@@ -133,7 +133,7 @@ you may need to make some changes to the way you reference User instances. You
 should also document any specific features of the User model that your
 application relies upon.
 
-See the :ref:`documentation on custom User models <auth-custom-user>` for
+See the :ref:`documentation on custom user models <auth-custom-user>` for
 more details.
 
 Support for saving a subset of model's fields
@@ -560,7 +560,7 @@ Prior to Django 1.5, if you attempted to log into the admin interface and
 mistakenly used your email address instead of your username, the admin
 interface would provide a warning advising that your email address was
 not your username. In Django 1.5, the introduction of
-:ref:`custom User models <auth-custom-user>` has required the removal of this
+:ref:`custom user models <auth-custom-user>` has required the removal of this
 warning. This doesn't change the login behavior of the admin site; it only
 affects the warning message that is displayed under one particular mode of
 login failure.
@@ -741,7 +741,7 @@ framework.
 ``AUTH_PROFILE_MODULE``
 -----------------------
 
-With the introduction of :ref:`custom User models <auth-custom-user>`, there is
+With the introduction of :ref:`custom user models <auth-custom-user>`, there is
 no longer any need for a built-in mechanism to store user profile data.
 
 You can still define user profiles models that have a one-to-one relation with

docs/releases/1.6.txt

@@ -448,7 +448,7 @@ removed and the standalone GeoDjango tests execution setup it implemented isn't
 supported anymore. To run the GeoDjango tests simply use the new
 ``DiscoverRunner`` and specify the ``django.contrib.gis`` app.
 
-Custom User models in tests
+Custom user models in tests
 ---------------------------
 
 The introduction of the new test runner has also slightly changed the way that

docs/topics/auth/default.txt

@@ -86,7 +86,7 @@ function is used when creating a user.
 To change a user's password, you have several options:
 
 :djadmin:`manage.py changepassword *username* <changepassword>` offers a method
-of changing a User's password from the command line. It prompts you to
+of changing a user's password from the command line. It prompts you to
 change the password of a given user which you must enter twice. If
 they both match, the new password will be changed immediately. If you
 do not supply a user, the command will attempt to change the password
@@ -267,12 +267,12 @@ Permission caching
 ------------------
 
 The :class:`~django.contrib.auth.backends.ModelBackend` caches permissions on
-the ``User`` object after the first time they need to be fetched for a
-permissions check. This is typically fine for the request-response cycle since
-permissions are not typically checked immediately after they are added (in the
-admin, for example). If you are adding permissions and checking them immediately
+the user object after the first time they need to be fetched for a permissions
+check. This is typically fine for the request-response cycle since permissions
+aren't typically checked immediately after they are added (in the admin, for
+example). If you are adding permissions and checking them immediately
 afterward, in a test or view for example, the easiest solution is to re-fetch
-the ``User`` from the database. For example::
+the user from the database. For example::
 
     from django.contrib.auth.models import Permission, User
     from django.shortcuts import get_object_or_404
@@ -380,7 +380,7 @@ is selected as follows:
    pairing :func:`~django.contrib.auth.authenticate()` and
    :func:`~django.contrib.auth.login()`:
    :func:`~django.contrib.auth.authenticate()`
-   sets the ``user.backend`` attribute on the ``User`` object it returns.
+   sets the ``user.backend`` attribute on the user object it returns.
 #. Use the ``backend`` in :setting:`AUTHENTICATION_BACKENDS`, if there is only
    one.
 #. Otherwise, raise an exception.
@@ -1602,7 +1602,7 @@ provides several built-in forms located in :mod:`django.contrib.auth.forms`:
 
 .. note::
     The built-in authentication forms make certain assumptions about the user
-    model that they are working with. If you're using a :ref:`custom User model
+    model that they are working with. If you're using a :ref:`custom user model
     <auth-custom-user>`, it may be necessary to define your own forms for the
     authentication system. For more information, refer to the documentation
     about :ref:`using the built-in authentication forms with custom user models

tests/auth_tests/models/custom_user.py

@@ -6,7 +6,7 @@ from django.db import models
 from django.utils.encoding import python_2_unicode_compatible
 
 
-# The custom User uses email as the unique identifier, and requires
+# The custom user uses email as the unique identifier, and requires
 # that every user provide a date of birth. This lets us test
 # changes in username datatype, and non-text required fields.
 class CustomUserManager(BaseUserManager):

tests/auth_tests/test_management.py

@@ -263,7 +263,7 @@ class CreatesuperuserManagementCommandTestCase(TestCase):
 
     @override_settings(AUTH_USER_MODEL='auth_tests.CustomUser')
     def test_swappable_user(self):
-        "A superuser can be created when a custom User model is in use"
+        "A superuser can be created when a custom user model is in use"
         # We can use the management command to create a superuser
         # We skip validation because the temporary substitution of the
         # swappable User model messes with validation.