Re: Permissions: is something wrong with them?

2009-01-06 Thread Artem Skvira

Hi Russ,

Thanks for your reply. There was no particulary strong reason why I
addressed the question to you,
I guess the only reason I can think of is that I know of your
existence :)

On the question of assigning permissions to the model: as far as I
understand, the described in [1] syntax is only
for saying that object of type 'USCitizen' _may_ have those
permissions associated with it.
But the actual association (grant of a certain permission) must happen
separately, via admin or in user's code.

The code snippet I listed was doing the latter - associating a certain
permission with an instance of the object.Please correct me if I'm
wrong here.

Depending on the application logic certain instances may or may not
get certain permissions assigned to them, so assignment process
becomes rather routine task, and that's why I suggested it could be
implemented as a helper function.

On the second point - it just seemed not elegant enough and a bit
ambiguous, that's why I raised that.
The whole permissions thing just didn't feel quite right in comparison
to the elegant, light and structured model/view/template part.

Thanks for your time anyway :)

On Jan 6, 10:05 pm, "Russell Keith-Magee" 
wrote:
> On Tue, Jan 6, 2009 at 4:26 AM, Artem Skvira  wrote:
> > On Jan 2, 6:26 pm, Artem Skvira  wrote:
> >> Would anyone be able to comment on the issues raised?
> > Can I get Russell's comment on that?
>
> I'm not entirely sure why I've been flagged personally on this. In
> addition, it's hard to comment, because it isn't entirely clear why
> you think "the issues raised" are such a big problem. As best as I can
> make out, you have two complaints:
>
> 1) Defining permissions is too hard
> 2) Permissions should formally require the
>
> For the first point, the method you describe for defining new
> permissions is one approach. Another approach using model metadata is
> also described in the documentation [1]. Between the two, I'm not sure
> why you see the need for helper, especially since permission creation
> is a once-off activity.
>
> As for the second point; the model name isn't required in the
> permission name, but it isn't prohibited either. This is a matter of
> convention - including the model name is often a good idea (e.g., the
> default 'add_X', 'change_X' permissions), but it's easy to think of
> examples where requiring the model name would be cumbersome (e.g, a
> 'can_vote' permission on a Citizen model).
>
> You are correct that this does open a potential window for an
> ambiguity where you have two models in the same app with a permission
> of the same name. I'm not certain about the design decision here (the
> auth module was written before I joined Django as a core contributor),
> but I can see how this could be used to allow shared permissions e.g.,
> anyone given permission to open the house gets automatic permission to
> open the car, and vice versa.
>
> Even if this wasn't the design intent, I can't say the problem
> particularly concerns me. Having a free-form permissions string guided
> by convention is easy to use, and it has been in use for over 3 years
> without (to the best of my knowledge) any significant reports of
> difficulty stemming from the problem you describe. In addition, there
> is plenty of legacy code using the existing permissions framework that
> would be onerous to change, and besides - a simple workaround exists:
> "don't use ambiguous permission names", which is hardly an onerous
> suggestion.
>
> [1]http://docs.djangoproject.com/en/dev/topics/auth/#id1
>
> Yours,
> Russ Magee %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: Permissions: is something wrong with them?

2009-01-06 Thread Russell Keith-Magee

On Tue, Jan 6, 2009 at 4:26 AM, Artem Skvira  wrote:
> On Jan 2, 6:26 pm, Artem Skvira  wrote:
>> Would anyone be able to comment on the issues raised?
> Can I get Russell's comment on that?

I'm not entirely sure why I've been flagged personally on this. In
addition, it's hard to comment, because it isn't entirely clear why
you think "the issues raised" are such a big problem. As best as I can
make out, you have two complaints:

1) Defining permissions is too hard
2) Permissions should formally require the

For the first point, the method you describe for defining new
permissions is one approach. Another approach using model metadata is
also described in the documentation [1]. Between the two, I'm not sure
why you see the need for helper, especially since permission creation
is a once-off activity.

As for the second point; the model name isn't required in the
permission name, but it isn't prohibited either. This is a matter of
convention - including the model name is often a good idea (e.g., the
default 'add_X', 'change_X' permissions), but it's easy to think of
examples where requiring the model name would be cumbersome (e.g, a
'can_vote' permission on a Citizen model).

You are correct that this does open a potential window for an
ambiguity where you have two models in the same app with a permission
of the same name. I'm not certain about the design decision here (the
auth module was written before I joined Django as a core contributor),
but I can see how this could be used to allow shared permissions e.g.,
anyone given permission to open the house gets automatic permission to
open the car, and vice versa.

Even if this wasn't the design intent, I can't say the problem
particularly concerns me. Having a free-form permissions string guided
by convention is easy to use, and it has been in use for over 3 years
without (to the best of my knowledge) any significant reports of
difficulty stemming from the problem you describe. In addition, there
is plenty of legacy code using the existing permissions framework that
would be onerous to change, and besides - a simple workaround exists:
"don't use ambiguous permission names", which is hardly an onerous
suggestion.

[1] http://docs.djangoproject.com/en/dev/topics/auth/#id1

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: Permissions: is something wrong with them?

2009-01-05 Thread Artem Skvira

Can I get Russell's comment on that?

On Jan 2, 6:26 pm, Artem Skvira  wrote:
> Well,
>
> it's not the usage I'm not clear on but rather architecture.
> Would anyone be able to comment on the issues raised?
>
> Thanks
>
> On Jan 2, 2:20 pm, Jeff Anderson  wrote:
>
> >ArtemSkvira wrote:
> > > Is it worth asking this question is dev group?
>
> > No. Your usage question does not belong on the dev group. It belongs
> > here, on the user group.
>
> >  signature.asc
> > < 1KViewDownload
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: Permissions: is something wrong with them?

2009-01-01 Thread Artem Skvira

Well,

it's not the usage I'm not clear on but rather architecture.
Would anyone be able to comment on the issues raised?

Thanks

On Jan 2, 2:20 pm, Jeff Anderson  wrote:
> Artem Skvira wrote:
> > Is it worth asking this question is dev group?
>
> No. Your usage question does not belong on the dev group. It belongs
> here, on the user group.
>
>  signature.asc
> < 1KViewDownload
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: Permissions: is something wrong with them?

2009-01-01 Thread Jeff Anderson
Artem Skvira wrote:
> Is it worth asking this question is dev group?
>   
No. Your usage question does not belong on the dev group. It belongs
here, on the user group.



signature.asc
Description: OpenPGP digital signature


Re: Permissions: is something wrong with them?

2009-01-01 Thread Artem Skvira

Is it worth asking this question is dev group?

On Dec 31 2008, 1:56 am, Artem Skvira  wrote:
> Hi all,
>
> I have some issues with djangopermissionsmodel. Please bear in mind
> that I have just started learning django so feel free to correct me if
> I'm wrong :)
>
> First of all it was hard to find how one can add a custom permission
> to list ofpermissionsof a model instance.
> I ended up with a code like this:
>
>         from ... import model
>         ...
>         c_type = ContentType.objects.get_for_model(model)
>         p = Permission.objects.get(codename=name, content_type=c_type)
>         user.user_permissions.add(p)
>
> It does look like rather generic task to me, and If that is the right
> way of doing that, it could be implemented as a helper function in
> django, alongside with has_perm(), get_all_permissions() and others.
> Or is there something like that already?
>
> Second thing which I have problems understanding is a naming
> convention for .has_perm() function parameter. Why for god's sake it
> omits model name, including only package name and permission name?
>
> Here is the quote from documentation:
>
>         has_perm(perm)
>                 Returns True if the user has the specified permission, where 
> perm is
> in the format "package.codename"
>
> It's easy to imagine a situation when one has got several 
> custompermissionswith same name for different models within same package.
> Is this going to cause some sort of conflict or wrong name resolution
> when using has_perm()?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: Permissions: is something wrong with them?

2009-01-01 Thread Artem Skvira

Is it worth asking this question is dev group?

On Dec 31 2008, 1:56 am, Artem Skvira  wrote:
> Hi all,
>
> I have some issues with djangopermissionsmodel. Please bear in mind
> that I have just started learning django so feel free to correct me if
> I'm wrong :)
>
> First of all it was hard to find how one can add a custom permission
> to list ofpermissionsof a model instance.
> I ended up with a code like this:
>
>         from ... import model
>         ...
>         c_type = ContentType.objects.get_for_model(model)
>         p = Permission.objects.get(codename=name, content_type=c_type)
>         user.user_permissions.add(p)
>
> It does look like rather generic task to me, and If that is the right
> way of doing that, it could be implemented as a helper function in
> django, alongside with has_perm(), get_all_permissions() and others.
> Or is there something like that already?
>
> Second thing which I have problems understanding is a naming
> convention for .has_perm() function parameter. Why for god's sake it
> omits model name, including only package name and permission name?
>
> Here is the quote from documentation:
>
>         has_perm(perm)
>                 Returns True if the user has the specified permission, where 
> perm is
> in the format "package.codename"
>
> It's easy to imagine a situation when one has got several 
> custompermissionswith same name for different models within same package.
> Is this going to cause some sort of conflict or wrong name resolution
> when using has_perm()?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Permissions: is something wrong with them?

2008-12-30 Thread Artem Skvira

Hi all,

I have some issues with django permissions model. Please bear in mind
that I have just started learning django so feel free to correct me if
I'm wrong :)

First of all it was hard to find how one can add a custom permission
to list of permissions of a model instance.
I ended up with a code like this:

from ... import model
...
c_type = ContentType.objects.get_for_model(model)
p = Permission.objects.get(codename=name, content_type=c_type)
user.user_permissions.add(p)

It does look like rather generic task to me, and If that is the right
way of doing that, it could be implemented as a helper function in
django, alongside with has_perm(), get_all_permissions() and others.
Or is there something like that already?

Second thing which I have problems understanding is a naming
convention for .has_perm() function parameter. Why for god's sake it
omits model name, including only package name and permission name?

Here is the quote from documentation:

has_perm(perm)
Returns True if the user has the specified permission, where 
perm is
in the format "package.codename"

It's easy to imagine a situation when one has got several custom
permissions with same name for different models within same package.
Is this going to cause some sort of conflict or wrong name resolution
when using has_perm()?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---