Fixed #29683 -- Added view permission to docs.

This commit is contained in:
Stephen James 2018-09-26 15:06:43 -04:00 committed by Tim Graham
parent fb2964a410
commit e40e7026ca
4 changed files with 11 additions and 12 deletions

View File

@ -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(

View File

@ -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:

View File

@ -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

View File

@ -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