| | 46 | == Suggestions == |
| | 47 | |
| | 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. |
| | 49 | |
| | 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). |
| | 52 | * From oggie rob: |
| | 53 | * "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" |
| | 54 | * "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." |