Code

Changes between Version 36 and Version 37 of RowLevelPermissions


Ignore:
Timestamp:
11/23/06 20:01:49 (7 years ago)
Author:
adrian
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: