Changes between Version 22 and Version 23 of RowLevelPermissions


Ignore:
Timestamp:
Aug 15, 2006, 11:09:45 AM (18 years ago)
Author:
Chris Long
Comment:

Updated status

Legend:

Unmodified
Added
Removed
Modified
  • RowLevelPermissions

    v22 v23  
    1313== Current Status ==
    1414
    15 At this current point of time, you can create row level permissions and modify them using the API. Checking of row level permissions are currently not implemented.
     15Row level permissions is now working, it should still be considered beta but it can be used. Please see below for more details on how to utilize row levle permissions.
    1616
    1717== Todo ==
    1818
    1919 * More unit tests
    20  * Tidy up the admin interface and finish the AJAX interface
     20 * Tidy up the admin interface
    2121 * Caching the row level permissions when checking
    2222
     
    8080...
    8181}}}
    82 ''Developer's note: This will most likely change as I'm not too sure "model" accurately describes what it represents. I will update this page when I make the change.''
    8382
    8483=== Creating a Row Level Permission ===
     
    9291   ...
    9392}}}
    94 The permission param can either be the codename of the permission or a permission instance. The negative param is optional and will default to false. You must pass an instance of the object and owner to this method.
    95 ''Developer's Note: I will probably add in another option to allow the permission to be an id as well.''
     93The permission parameter can either be the codename of the permission or a permission instance. The negative param is optional and will default to false. You must pass an instance of the object and owner to this method.
    9694
    9795The second is create_default_row_permissions:
     
    10199   ...
    102100}}}
    103 This will set up a row level permission with the default permissions set up for an object. The default permissions are: add, change and delete. An example of it's use is:
     101This will set up a row level permission with the default permissions set up for an object. The default permissions are: add, change and delete.
     102
     103An example of it's use is, this creates a change row level permission on the quartz object:
    104104{{{
    105105#!python
     
    113113In the next week, GenericAuthorization and row level permissions will be merged. Therefore, I have shown two different methods of checking for permissions, one using the generic authorization and the currently implemented technique.
    114114
    115 The current method uses the has_perm method in the User model. Note: The object parameter is optional, this is to allow backwards compatibility.
     115The current method uses the has_perm method in the User model. Note: The object parameter is optional, this is to allow backwards compatibility, so if you do not want to check for row level permissions do not include the object parameter.
    116116
    117117Example:
     
    127127This will also check group row level permissions. If the user is in two groups, the first having a positive row level permission and the second having a negative row level permission, it will take the positive row level permission over the negative.
    128128
    129 '''Second method using GenericAuthorization will be written after the merger'''
     129'''Second method using GenericAuthorization will be written after the merge. It will follow the documentation written on GenericAuthorization'''
    130130
    131131
     
    134134Please see RowLevelPermissionsDeveloper for more information on how row level permissions are implemented.
    135135
    136 
    137 == Proposal for Integrating into Administration Interface ==
    138 
    139 === Inline Editing ===
    140 
    141 Using the admin interface a user can edit Row Level Permissions (RLP) within the edit screen of a specific instance of a model. It will only be shown if RLPs are enabled for the model.
    142 
    143 The RLPs will be organized in a tabular form and using AJAX the user can add, delete or change RLPs related to the instance of the model. The page will also be set up to be backwards compatible incase the user is not able to use JavaScript.
    144 
    145 I am undecided as to whether the RLP form should be shown on the add form or not. The first priority is integrating it into the change form and then determine if it is needed in the add form.
    146 
    147 === Editing ===
    148 
    149 There will probably be no capability for editing RLPs like a normal object with an add, change, and list view in the administration interface. There are a few reasons:
    150  * The number of RLPs could be quite high as there could possibly be one for every instance of a model. Editing this through the classic admin interface would be cumbersome.
    151  * Adding/Editing RLPs requires selecting the model, the instance of the model, the owner model and the instance of the owner model and the permissions related to the model. The form needed to do this would be quite elaborate and not very useful.
    152 
    153136== Download ==
    154137
Back to Top