No particular wish to be a PPC developer, it's more years of habit of
trying to copy down what the prof is saying without falling too far
behind. You end up losing some vowels and other unneeded letters at
points. :-) I'll change it around.
> So the idea here is that the each row in the RowLevelPermission's
> database table holds the content type of the model it refers to and thus
> you don't have to change the "permissioned" model's table at all? Is
> that right? Sorry if this a dumb question; just trying to get the
> ordering right in my head.
Not a dumb question. :-)
Each row in the RLP(Row Level Permission) table contains:
- The RLP id
- The content type for the "owner" (e.g. user, group)
- The id of the owner
- The content type of the object
- The id of the object
- The permission id
- If the RLP is negative or positive (e.g. user A can edit article 2 or
user A can NOT edit article 2)
No modifications of the permissions table at all. Trying to keep the
current permission system the way it is, so if you don't want to use
RLP, no need to make any changes.
> In case you were wondering (or it occurs to you later), one thing you
> can't do here is call loading.get_model('auth', 'rowlevelpersmission')
> -- which is what we do in some places. Because there is no guarantee
> that the model cache is fully initialised at that point and it is wrong
> (trust me!) to initialise the model cache inside get_model(). And you
> can't import RowLevelPermissions at the head of base.py because, I
> suspect, it will cause problems when trying to run ModelBase.__new__()
> on itself.
This could explain some problems I've been running into. Do you think
my current location for importing the RLP ok?
> What I'm not sure I understand is how does the checking process work: if
> I am trying to extract a particular instance from the database, does it
> look up the row table for that content type, see if there's a matching
> value for the primary key from my main model and then do the check?
>
> If so, that's at least one extra database query per extraction (I think
> it might be two extras at the moment, but we can cache the content-type
> with something like ticket #1717, although that will have to wait until
> Adrian's finished playing inside django.db.models now). So, personally,
> I would prefer it to be something that isn't on by default.
It would have to look up the content type and use the content type and
object id to determine the row level permissions that exist, or from
another angle, the owner content type and the owner id. Never even
thought about the extra database queries required. I think that's
another good argument to have it disabled by default.
> Looks like progress here. Nice. :-)
Thanks. :-)
Cheers,
Chris
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
