SoC Row Lvl Perms: Update
Chris L
An update on how the development of Row Level Permissions are going.
For this project, I am using the content-type contrib package to create
a generic table to store the row level permissions. Currently the model
for row level permission is:
class RowLevelPermission(models.Model):
type_id = models.IntegerField("'Type' ID")
type_ct = models.ForeignKey(ContentType, verbose_name="'Type'
content type", related_name="rowLvlType")
owner_id = models.IntegerField("'Owner' ID")
owner_ct = models.ForeignKey(ContentType, verbose_name="'Owner'
content type", related_name="rowLvlOwner")
permission = models.ForeignKey(Permission)
This works out to a really simple database table. This table should
allow a lot of flexibility, the object type can be anything and the
owner type can technically be anything. So if you have a model
replacing the standard user model then you should be able to utilize
row level permissions with very little work. You can also use this to
allow users to edit their own user profile (e.g. User 1 has read/write
access to user 1).
The largest problem I have right now is working out how to connect the
object or owner with the row level permission (e.g. user.row_lvl_perm
would return the row level perms related to that object). As Luke
mentioned earlier, his method of generic foreign keys doesn't' easily
allow this, so I am working on a method combining Luke's code, Ian's
code and my own work into allowing this. I'll be releasing it over the
next week or so for everyone to review, if they are interested.
If you don't know about generic tables, I suggest taking a look at
Ian's write-up on them:
http://feh.holsman.net/articles/2006/06/03/django-contenttype
The relation is going to work by specifying the relation within the
model that does not contain the content type, e.g.:
class User(models.Model):
....
row_lvl_perm = related.CTField(...)
...
That's my plan/update for now. Please let me know what you think.
Cheers,
Chris
João Marcus
>
> Cheers,
>
> Chris
Seems to be coming along nicely. I would have some suggestions:
1) Have a field "allow/deny" in model
2) Have a "group" field too, to let permissions setting for groups
3) Handle permissions hierarchically, checking:
3.1) Content-wide permissions
3.2) Group-level permissions
3.3) User-level permissions
e.g. the content-wide permissions for a "Ticket" is "deny". Only
the owner and users from group "Ticket Managers" can "Obliterate" the
ticket. Users from group "Ticket Viewers" can read the tickets.
This would probably need some kind of permissions caching system.
Forgive me if my ideas are stupid and/or way off your objectives right
now.
Cheers,
Joao Marcus