On Sat, 2006-07-08 at 16:54 +0000, Chris L wrote:
> Hi,
>
> I've currently set up enabling row level permissions using the meta
> class, e.g. to enable row level permissions for the Mineral model you
> would have:
>
> class Mineral(models.Model):
> name = models.CharField(maxlength=150)
> hardness = models.PositiveSmallIntegerField()
>
> class Admin:
> pass
>
> class Meta:
> unique_together = (('name', 'hardness'),)
> row_lvl_perms = True
The word "level" has more "e"s in it. :-)
Or do you want to be a PPC developer ([1])? There are counter-measures
we can take for that (see [2]).
Seriously, there seems to be a (good) trend in Django attributes to
spell the word out fully (I'm going to duck the question of whether
"perms" should be expanded, but I wouldn't fight it if it was).
[1] http://lkml.org/lkml/2001/10/12/91
[2] http://lkml.org/lkml/2004/1/21/8
> >From then on, you can access all row level permissions related to an
> instance of Mineral by using the attribute row_lvl_perms (e.g.
> mineral.row_lvl_perms.all() ).
>
> The way I am adding the row_lvl_perms attribute is using the following
> code in ModelBase (located in django.db.models.base):
>
> if getattr(new_class._meta, 'row_lvl_perms', None):
> from django.contrib.auth.models import RowLevelPermission
> gen_rel =
> django.db.models.GenericRelation(RowLevelPermission,
> object_id_field="type_id", content_type_field="type_ct")
> new_class.add_to_class("row_lvl_perms", gen_rel)
>
> Wanted to get an opinion from the other developers, do you think this
> is the best way of enabling row level permissions?
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.
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.
> I thought about enabling them by default and having to specify if you
> want them disabled, but I'm not sure if that would be the best route,
> especially since general permissions have to be enabled to work. Any
> thoughts?
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.
Looks like progress here. Nice. :-)
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
