Changes between Version 6 and Version 7 of RowLevelPermissions


Ignore:
Timestamp:
May 30, 2006, 8:27:52 PM (18 years ago)
Author:
Chris Long <indirecthit@…>
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • RowLevelPermissions

    v6 v7  
    1313
    1414
     15== Planned Features ==
     16 
     17 * Negative permissions, e.g. "User A can not modify article 2 and 4 but can modify all other articles"
     18 * A modified admin page for editing objects that will allow admins to add users with specific (negative and positive) row level permissions to the object being edited
     19 * A method of adding row level permissions using an API
     20 * Allow custom permissions for row level permissions
     21 * Developer can enable or, by default, disable the row level permissions on an object
     22 * Generic functions to create row level permissions in certain scenarios, e.g. the above scenerio
     23
     24
    1525== Implementation ==
    1626
    17 The priority of permissions would work: User/Group Object Type Permissions -> User/Group Row Level Permission. Meaning it would check each of those permissions in order to determine if the user has the correct permissions to do the activity they wish to do.
     27The priority of permissions will be modified to follow this order: User Row Level -> Group Row Level -> User Object Type -> Group Object Type. The reason for this change is to allow negative permissions, the permissions code should check in this order, stopping at the first positive permission or negative permission. These modifications will have to be made after discussing them with Joseph Kocherhans who is implementing GenericAuthorization and other members of the development team.
    1828
    19 The method I am considering would use a seperate table to contain the row level permissions. Within that table would be the object id, user/group id, permissions (e.g. read, write, delete, etc.). There will most likely be a seperate table for each object type.
     29The actual database structure of the row level permissions system will use a single table and generic foreign keys. The generic foreign key will be modified slightly from the code written by Luke Plant in his tagging application (http://files.lukeplant.fastmail.fm/public/python/lp_tagging_app_0.1.zip). The changes will most likely consist of changing the primary keys to be integers rather then strings.
    2030
    21 A reason for doing it this way, is that it allows a many-to-many relationship between instances of objects and users/groups. Therefore, one or more users/groups can have different permissions on the same object. Another reason, is that it will not affect the current columns within the object's table.
     31== Timeline ==
    2232
    23 By default, these permissions will be disabled, but the developer will be able to enable the row level permissions using the meta attribute for each type of object.
    24 
    25 The row level permissions will allow custom permissions.
    26 
    27 The row level permissions can be modified using an API or by the administration interface.
    28 
    29 Another possible method of doing this would be a similiar method to the current unix permissions. This method is not as flexible as the above method, and will most likely modify the object's table directly which might cause problems.
     33||'''Task'''||'''Status'''||
     34||Row Level Permission object is implemented and tested||In progress||
     35||Developer can choose to enable row level permissions||Not started||
     36||API for modifying row level permissions is implemented and tested||Not started||
     37||Admin interface is modified to editing of row level permissions||Not started||
     38||Negative row level perms||Not started||
     39||Generic Functions to create row level perms||Not started||
    3040
    3141
    … …  
    4656== Suggestions ==
    4757
    48 From the ongoing discussion on django-developers group. I'm researching some of the suggestions to determine the best route, as I do this I'll make changes above.
     58From the discussion on Django-developers group. The italicized suggestions I have decided to use or not use, the other ones I am still considering/looking into.
    4959
    50  * Using GenericForeignKey and one table instead of having a table for each object. Suggested by Ian Holsman. As an example see: http://files.lukeplant.fastmail.fm/public/python/lp_tagging_app_0.1.zip
    51  * Implementing negativity. ie person X is NOT allowed to see row Y. Suggested by Ian Holsman. Suggested by Honza Král to allow something like "person X can read all articles except article Y". This would most likely require a rewrite of the order of permissions, therefore doing it from most specific (row level) to least specific (object type).
     60 * ''Using GenericForeignKey and one table instead of having a table for each object. Suggested by Ian Holsman. As an example see: http://files.lukeplant.fastmail.fm/public/python/lp_tagging_app_0.1.zip ''
     61 * ''Implementing negativity. ie person X is NOT allowed to see row Y. Suggested by Ian Holsman. Suggested by Honza Král to allow something like "person X can read all articles except article Y". This would most likely require a rewrite of the order of permissions, therefore doing it from most specific (row level) to least specific (object type).''
    5262 * From oggie rob:
    5363   * "An alternative approach for the group-level changes: a new permission type that allows you to assign a group that can  access that object. i.e. permissionA = access for every user in groupA. Then every user that belongs to groupA can access objects created by any user in groupA. You would then, obviously, add the permission to groupA only"
    5464   * "How do you deal with those permissions in the generic and admin list views? You may need to change the returned lists to show only those things that the user has created? I'm not sure. I know it would be an issue in the admin pages but the generic lists might be used in various ways (and perhaps the option to choose would be nice)."
    55  * From Ian Holsman: "while I use integer's as my keys (which is they  default django way), others override this and use strings and other weird things. I'm not sure how my previous suggestion would work when you take that kind of thing into account."
    56  * Generic mechanism for creating row level permissions when enabled, such as the example of the forum given above. E,g. the developer would enable this feature, and from that point on a user would have row level permissions (specified by the developer) for any object they create. Suggested by Andy Shaw.
    57  * From Andy Shaw: "would Luke's GenericForeignKey allow for inline editing, assuming it was to be adopted? Personally I'd much rather be able to alter a row's permissions on its own admin page than have to switch table."
    58 
    59 
    60 
    61 
    62 
     65 * ''From Ian Holsman: "while I use integer's as my keys (which is they  default Django way), others override this and use strings and other weird things. I'm not sure how my previous suggestion would work when you take that kind of thing into account."''
     66 * ''Generic mechanism for creating row level permissions when enabled, such as the example of the forum given above. E,g. the developer would enable this feature, and from that point on a user would have row level permissions (specified by the developer) for any object they create. Suggested by Andy Shaw.''
     67 * ''From Andy Shaw: "would Luke's GenericForeignKey allow for inline editing, assuming it was to be adopted? Personally I'd much rather be able to alter a row's permissions on its own admin page than have to switch table."''
Back to Top