[2.1.x] Fixed #29683 -- Added view permission to docs.

Backport of e40e7026ca from master.

django/contrib/auth/models.py

@@ -43,6 +43,7 @@ class Permission(models.Model):
         - The "change" permission limits a user's ability to view the change
           list, view the "change" form and change an object.
         - The "delete" permission limits the ability to delete an object.
+        - The "view" permission limits the ability to view an object.
 
     Permissions are set globally per type of object, not per specific object
     instance. It is possible to say "Mary may change news stories," but it's
@@ -50,8 +51,7 @@ class Permission(models.Model):
     ones she created herself" or "Mary may only change news stories that have a
     certain status or publication date."
 
-    Three basic permissions -- add, change and delete -- are automatically
-    created for each Django model.
+    The permissions listed above are automatically created for each model.
     """
     name = models.CharField(_('name'), max_length=255)
     content_type = models.ForeignKey(

docs/topics/auth/customizing.txt

@@ -273,14 +273,13 @@ Custom permissions
 To create custom permissions for a given model object, use the ``permissions``
 :ref:`model Meta attribute <meta-options>`.
 
-This example Task model creates three custom permissions, i.e., actions users
-can or cannot do with Task instances, specific to your application::
+This example ``Task`` model creates two custom permissions, i.e., actions users
+can or cannot do with ``Task`` instances, specific to your application::
 
     class Task(models.Model):
         ...
         class Meta:
             permissions = (
-                ("view_task", "Can see available tasks"),
                 ("change_task_status", "Can change the status of tasks"),
                 ("close_task", "Can remove a task by setting its status as closed"),
             )
@@ -289,11 +288,11 @@ The only thing this does is create those extra permissions when you run
 :djadmin:`manage.py migrate <migrate>` (the function that creates permissions
 is connected to the :data:`~django.db.models.signals.post_migrate` signal).
 Your code is in charge of checking the value of these permissions when a user
-is trying to access the functionality provided by the application (viewing
-tasks, changing the status of tasks, closing tasks.) Continuing the above
-example, the following checks if a user may view tasks::
+is trying to access the functionality provided by the application (changing the
+status of tasks or closing tasks.) Continuing the above example, the following
+checks if a user may close tasks::
 
-    user.has_perm('app.view_task')
+    user.has_perm('app.close_task')
 
 .. _extending-user:
 

docs/topics/auth/default.txt

@@ -196,8 +196,8 @@ Default permissions
 -------------------
 
 When ``django.contrib.auth`` is listed in your :setting:`INSTALLED_APPS`
-setting, it will ensure that three default permissions -- add, change and
-delete -- are created for each Django model defined in one of your installed
+setting, it will ensure that four default permissions -- add, change, delete,
+and view -- are created for each Django model defined in one of your installed
 applications.
 
 These permissions will be created when you run :djadmin:`manage.py migrate

docs/topics/testing/advanced.txt

@@ -249,7 +249,7 @@ Advanced features of ``TransactionTestCase``
     By default, ``available_apps`` is set to ``None``. After each test, Django
     calls :djadmin:`flush` to reset the database state. This empties all tables
     and emits the :data:`~django.db.models.signals.post_migrate` signal, which
-    re-creates one content type and three permissions for each model. This
+    recreates one content type and four permissions for each model. This
     operation gets expensive proportionally to the number of models.
 
     Setting ``available_apps`` to a list of applications instructs Django to