Changes between Version 36 and Version 37 of RowLevelPermissions


Ignore:
Timestamp:
Nov 23, 2006, 10:01:49 PM (18 years ago)
Author:
Adrian Holovaty
Comment:

More edits

Legend:

Unmodified
Added
Removed
Modified

  • RowLevelPermissions

    v36 v37  
    2828 * Row-level permissions can be negative. This is determined by an attribute called "negative."
    2929 * Django checks permissions in the following order:
     30
    3031   * User row-level permission
    3132   * Group row-level permission
    3233   * User model-level permission
    3334   * Group model-level permission
    34    The checking stops either at the first positive or negative. If no permission is found, it will return a negative (or false).
     35
     36Permission checking stops either at the first positive or negative. If no permission is found, it will return a negative (or false).
    3537
    3638=== Enabling row-level permissions ===
    … …  
    106108==== Has row-level permission ====
    107109
    108 The method {{{contains_permission()}}} checks whether the user has the given permission on a model -- not an *instance* of a model but the model itself. This checks if there is exists the given row level permission on any of the instances of the model. It is used in the admin interface to determine if the change list should be shown to the user.
    109 
    110 E.g. If {{{some_user}}} has change permission on article 234, and you did:
    111 {{{
    112 #!python
    113 ...
     110The {{{User}}} method {{{contains_permission()}}} checks whether a user has the given permission on a model -- not an *instance* of a model but the model class itself. It returns {{{True}}} if *any* row-level permission exists for the given user for the given model. (This is used in the admin interface to determine if the change list should be displayed for a user.)
     111
     112For example, the following would return {{{True}}} if {{{some_user}}} had change permission on article 234:
     113{{{
     114#!python
    114115some_user.contains_permission("mine.change_mineral", Mineral)
    115 ...
    116116}}}
    117117It will return True.
    118118
    119 ''I am not a fan of contains_permission name, but for now it does work. If you have any ideas on how to change it, please let me know.''
    120 
    121 === Checking Permissions in a Template ===
    122 
    123 In a template, you can use the tag if_has_perm to check for permissions. The tag has the following syntax:
     119The name {{{contains_permission}}} is still up for debate, as it's not perfect. If you have any ideas, please leave them here by editing this page, or leave a message on the django-developers mailing list.
     120
     121=== Checking permissions in a template ===
     122
     123Use the template tag {{{if_has_perm}}} to check permission in a template. The tag has the following syntax:
     124
    124125{{{
    125126{% load auth %}
    … …  
    130131{% end_if_has_perm %}
    131132}}}
     133
    132134The parameters in square brackets are optional and the normal brackets are required. The else statement is optional. The permission codename should be in the format: app_label.codename.
    133135
     136For example:
     137
     138{{{
     139{% load auth %}
     140{% if_has_perm mine.change_mineral obj %}
     141...
     142{% else %}
     143...
     144{% end_if_has_perm %}
     145}}}
     146
    134147=== Administration ===
    135148
    136 You can set up row level permissions to be created automatically by the admin interface when a user creates an object by using the options: grant_change_row_level_perm and grant_delete_row_level_perm. By default these are turned off. An example:
    137 {{{
    138 #!python
    139 ...
     149You can configure row-level permissions to be created automatically by the admin interface when a user creates an object by using the {{{class Admin}}} options {{{grant_change_row_level_perm}}} and {{{grant_delete_row_level_perm}}}. These are {{{False}}} by default.
     150
     151For example:
     152
     153{{{
     154#!python
    140155class Mineral(models.Model):
    141 ...   
     156    # ...
    142157    class Admin:
    143         grant_change_row_level_perm=True
    144         grant_delete_row_level_perm=True
     158        grant_change_row_level_perm = True
     159        grant_delete_row_level_perm = True
    145160   
    146161    class Meta:
    147162        row_level_permissions = True
    148 ...
    149 }}}
    150 
    151 Row level permissions can be edited in the administration interface, on the change form for each object with row level permissions enabled is a link beside History to edit row level permissions. To edit row level permissions, you must have the change RLP permission and change permission on the object. To add row level permissions, you must have the add RLP permisison and change permission on the object.
     163}}}
     164
     165Row-level permissions can be edited in the admin interface, on the change form for each object with row-level permissions enabled is a link beside History to edit row level permissions. To edit row level permissions, you must have the change RLP permission and change permission on the object. To add row level permissions, you must have the add RLP permisison and change permission on the object.
    152166
    153167By default, all instances of a model are shown to a user when they access the change list for a model. To turn off this behaviour, you must set the ''show_all_rows'' admin option to false. Doing this will increase the number of database queries made to the server, which is why the default option is that all rows are shown. An example:
Back to Top