1
0
mirror of https://github.com/django/django.git synced 2024-12-27 19:46:22 +00:00

[1.8.x] Fixed #25166 -- Clarified how auth permissions are created.

Thanks Baptiste Mispelon for report and review.

Backport of 217f173be0 from master
This commit is contained in:
Tim Graham 2015-07-25 09:30:54 -04:00
parent 65885f265a
commit 19ac8b2fe1
2 changed files with 8 additions and 6 deletions

View File

@ -281,11 +281,12 @@ can or cannot do with Task instances, specific to your application::
)
The only thing this does is create those extra permissions when you run
:djadmin:`manage.py migrate <migrate>`. 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::
: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::
user.has_perm('app.view_task')

View File

@ -207,7 +207,8 @@ These permissions will be created when you run :djadmin:`manage.py migrate
will be created for all previously-installed models, as well as for any new
models being installed at that time. Afterward, it will create default
permissions for new models each time you run :djadmin:`manage.py migrate
<migrate>`.
<migrate>` (the function that creates permissions is connected to the
:data:`~django.db.models.signals.post_migrate` signal).
Assuming you have an application with an
:attr:`~django.db.models.Options.app_label` ``foo`` and a model named ``Bar``,