Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

[1.6.x] Fixed grammar/typos in auth customization docs

Backport of 1b9c72f from master.
  • Loading branch information...
commit 7a58fde7a60d93b118bcaeb2d18c95e7ec512b8a 1 parent 1bf9580
@claudep claudep authored
Showing with 14 additions and 14 deletions.
  1. +14 −14 docs/topics/auth/customizing.txt
View
28 docs/topics/auth/customizing.txt
@@ -539,13 +539,13 @@ password resets. You must then provide some key implementation details:
"active". This attribute is provided as an attribute on
``AbstractBaseUser`` defaulting to ``True``. How you choose to
implement it will depend on the details of your chosen auth backends.
- See the documentation of the :attr:`attribute on the builtin user model
- <django.contrib.auth.models.User.is_active>` for details.
+ See the documentation of the :attr:`is_active attribute on the built-in
+ user model <django.contrib.auth.models.User.is_active>` for details.
.. method:: get_full_name()
A longer formal identifier for the user. A common interpretation
- would be the full name name of the user, but it can be any string that
+ would be the full name of the user, but it can be any string that
identifies the user.
.. method:: get_short_name()
@@ -640,7 +640,7 @@ additional methods:
The prototype of ``create_user()`` should accept the username field,
plus all required fields as arguments. For example, if your user model
uses ``email`` as the username field, and has ``date_of_birth`` as a
- required fields, then ``create_user`` should be defined as::
+ required field, then ``create_user`` should be defined as::
def create_user(self, email, date_of_birth, password=None):
# create user here
@@ -651,14 +651,14 @@ additional methods:
The prototype of ``create_superuser()`` should accept the username
field, plus all required fields as arguments. For example, if your user
model uses ``email`` as the username field, and has ``date_of_birth``
- as a required fields, then ``create_superuser`` should be defined as::
+ as a required field, then ``create_superuser`` should be defined as::
def create_superuser(self, email, date_of_birth, password):
# create superuser here
...
Unlike ``create_user()``, ``create_superuser()`` *must* require the
- caller to provider a password.
+ caller to provide a password.
:class:`~django.contrib.auth.models.BaseUserManager` provides the following
utility methods:
@@ -667,7 +667,7 @@ utility methods:
.. method:: models.BaseUserManager.normalize_email(email)
- A classmethod that normalizes email addresses by lowercasing
+ A ``classmethod`` that normalizes email addresses by lowercasing
the domain portion of the email address.
.. method:: models.BaseUserManager.get_by_natural_key(username)
@@ -678,12 +678,12 @@ utility methods:
.. method:: models.BaseUserManager.make_random_password(length=10, allowed_chars='abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789')
Returns a random password with the given length and given string of
- allowed characters. (Note that the default value of ``allowed_chars``
+ allowed characters. Note that the default value of ``allowed_chars``
doesn't contain letters that can cause user confusion, including:
* ``i``, ``l``, ``I``, and ``1`` (lowercase letter i, lowercase
letter L, uppercase letter i, and the number one)
- * ``o``, ``O``, and ``0`` (uppercase letter o, lowercase letter o,
+ * ``o``, ``O``, and ``0`` (lowercase letter o, uppercase letter o,
and zero)
Extending Django's default User
@@ -776,7 +776,7 @@ your custom User model extends ``django.contrib.auth.models.AbstractUser``,
you can use Django's existing ``django.contrib.auth.admin.UserAdmin``
class. However, if your User model extends
:class:`~django.contrib.auth.models.AbstractBaseUser`, you'll need to define
-a custom ModelAdmin class. It may be possible to subclass the default
+a custom ``ModelAdmin`` class. It may be possible to subclass the default
``django.contrib.auth.admin.UserAdmin``; however, you'll need to
override any of the definitions that refer to fields on
``django.contrib.auth.models.AbstractUser`` that aren't on your
@@ -819,8 +819,8 @@ methods and attributes:
.. method:: models.PermissionsMixin.has_perm(perm, obj=None)
- Returns ``True`` if the user has the specified permission, where perm is
- in the format ``"<app label>.<permission codename>"`` (see
+ Returns ``True`` if the user has the specified permission, where
+ ``perm`` is in the format ``"<app label>.<permission codename>"`` (see
:ref:`permissions <topic-authorization>`). If the user is inactive, this method will
always return ``False``.
@@ -870,7 +870,7 @@ Custom users and signals
Another limitation of custom User models is that you can't use
:func:`django.contrib.auth.get_user_model()` as the sender or target of a signal
handler. Instead, you must register the handler with the resulting User model.
-See :doc:`/topics/signals` for more information on registering an sending
+See :doc:`/topics/signals` for more information on registering and sending
signals.
Custom users and testing/fixtures
@@ -1116,7 +1116,7 @@ code would be required in the app's ``admin.py`` file::
# Now register the new UserAdmin...
admin.site.register(MyUser, MyUserAdmin)
- # ... and, since we're not using Django's builtin permissions,
+ # ... and, since we're not using Django's built-in permissions,
# unregister the Group model from admin.
admin.site.unregister(Group)
Please sign in to comment.
Something went wrong with that request. Please try again.