Re: AnonymousUser has_perm/has_module_perms function check authentication backends
@Noah, You could also look at it as what a AnonymousUser can't do on
some objects (while it's possible on others).
-- Gert
Mobile: +32 498725202
Web: http://gert.selentic.net
2010/1/19 Noah Silas :
> I'm not certain I understand - if anyone can perform some action, what's the
> point of protecting it with a permissions check?
> ~Noah Silas
>
>
> 2010/1/18 Łukasz Rekucki
>>
>> 2010/1/18 Alex Gaynor :
>> > On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel
>> > wrote:
>> >>
>> >> Am 18.01.2010 um 22:26 schrieb Luke Plant:
>> >>
>> >>> Hi Harro,
>> >>>
>> Hmm I guess I'll just have to keep on hacking django then..
>> because that 1% case is something I keep running into for every
>> project in one way or another.
>> And if it was designed for most apps, why was the row level
>> permission bits added? It's useless without simply always being
>> able to call request.user.has_perm('permission', obj)
>> >>>
>> >>> Despite a slight overstatement in that last paragraph, your argument
>> >>> seems pretty good to me. The whole point of these methods is to allow
>> >>> custom backends to implement their own logic, so obviously it is
>> >>> pointless to arbitrarily limit it.
>> >>>
>> >>> The only downside is that custom backends need to be able to cope with
>> >>> anonymous users being passed to the has_perm methods, but that is
>> >>> already well catered for with the is_anonymous() method. It is also
>> >>> better to make this change before 1.2 lands, otherwise we have a
>> >>> slight backwards incompatibility if we wanted to do it in the future
>> >>> (backends could break if they unexpectedly got an AnonymousUser
>> >>> instead of a User).
>> >>>
>> >>> Anyone got a good reason reason why this *shouldn't* go in? I'm +1 on
>> >>> committing.
>> >>
>> >> Hm, I don't see a good argument to allow anonymous users to have a
>> >> permissions, to be honest. Anonymous users are by definition not
>> >> authenticated. Giving them more meaning by being able to grant them
>> >> permissions doesn't make them anonymous anymore, right?
>> >>
>> >> Also, before adding those hooks to the ModelBackend, AnonymousUser
>> >> never returned True when asked if it has a permission or not. Why should
>> >> it
>> >> now?
>> >>
>> >> Jannis
>> >>
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups "Django developers" group.
>> >> To post to this group, send email to
>> >> django-develop...@googlegroups.com.
>> >> To unsubscribe from this group, send email to
>> >> django-developers+unsubscr...@googlegroups.com.
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/django-developers?hl=en.
>> >>
>> >
>> > I think the best argument in favor of it is using permissions with
>> > reusable applications. Say I have a wiki application I write, I don't
>> > know whether anonymous users should be able to edit pages, I could
>> > make it a setting, but that's ugly. Instead the natural thing to do
>> > is ask the auth backend and let the developer implement it however.
>>
>> This argument convinced me to like this idea :) My only concern is
>> that, a newly created user could have fewer permissions then an
>> anonymous one. I can't think of a situation where this would be
>> useful. So maybe all other users could actually inherit those
>> "anonymous permissions" ?
>>
>> >
>> > Alex
>> >
>> > --
>> > "I disapprove of what you say, but I will defend to the death your
>> > right to say it." -- Voltaire
>> > "The people's good is the highest law." -- Cicero
>> > "Code can always be simpler than you think, but never as simple as you
>> > want" -- Me
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Django developers" group.
>> > To post to this group, send email to django-develop...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > django-developers+unsubscr...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/django-developers?hl=en.
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> Łukasz Rekucki
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
You received this message because you are subscribed to the Goog
Master/slave replication in multi-db era
Russell Keith-Magee wrote: There are some cases where this shouldn't happen - for example, in a master/slave setup. I'm tinkering with some code at the moment to control this sort of database allocation. Russel, can you share your ideas on the matter? I'm about to port (soon-ish) my replication backend to new multi-db reality and if you already had some thoughts I'd very appreciate to hear it. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
Raffaele Salmaso wrote: > Joseph Kocherhans wrote: >> regressions? > http://code.djangoproject.com/ticket/12577 Hello, is anybody out there? Sorry if I seem rude, but there is a severe regression an no one care to say at least 'ok I see it', even when there is an *explicit* request for regressions... I've resolved with an horrible monkeypatch, but at least I've now a working copy of django -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
2010/1/18 Noah Silas :
> I'm not certain I understand - if anyone can perform some action, what's the
> point of protecting it with a permissions check?
> ~Noah Silas
>
>
> 2010/1/18 Łukasz Rekucki
>>
>> 2010/1/18 Alex Gaynor :
>> > On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel
>> > wrote:
>> >>
>> >> Am 18.01.2010 um 22:26 schrieb Luke Plant:
>> >>
>> >>> Hi Harro,
>> >>>
>> Hmm I guess I'll just have to keep on hacking django then..
>> because that 1% case is something I keep running into for every
>> project in one way or another.
>> And if it was designed for most apps, why was the row level
>> permission bits added? It's useless without simply always being
>> able to call request.user.has_perm('permission', obj)
>> >>>
>> >>> Despite a slight overstatement in that last paragraph, your argument
>> >>> seems pretty good to me. The whole point of these methods is to allow
>> >>> custom backends to implement their own logic, so obviously it is
>> >>> pointless to arbitrarily limit it.
>> >>>
>> >>> The only downside is that custom backends need to be able to cope with
>> >>> anonymous users being passed to the has_perm methods, but that is
>> >>> already well catered for with the is_anonymous() method. It is also
>> >>> better to make this change before 1.2 lands, otherwise we have a
>> >>> slight backwards incompatibility if we wanted to do it in the future
>> >>> (backends could break if they unexpectedly got an AnonymousUser
>> >>> instead of a User).
>> >>>
>> >>> Anyone got a good reason reason why this *shouldn't* go in? I'm +1 on
>> >>> committing.
>> >>
>> >> Hm, I don't see a good argument to allow anonymous users to have a
>> >> permissions, to be honest. Anonymous users are by definition not
>> >> authenticated. Giving them more meaning by being able to grant them
>> >> permissions doesn't make them anonymous anymore, right?
>> >>
>> >> Also, before adding those hooks to the ModelBackend, AnonymousUser
>> >> never returned True when asked if it has a permission or not. Why should
>> >> it
>> >> now?
>> >>
>> >> Jannis
>> >>
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups "Django developers" group.
>> >> To post to this group, send email to
>> >> django-develop...@googlegroups.com.
>> >> To unsubscribe from this group, send email to
>> >> django-developers+unsubscr...@googlegroups.com.
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/django-developers?hl=en.
>> >>
>> >
>> > I think the best argument in favor of it is using permissions with
>> > reusable applications. Say I have a wiki application I write, I don't
>> > know whether anonymous users should be able to edit pages, I could
>> > make it a setting, but that's ugly. Instead the natural thing to do
>> > is ask the auth backend and let the developer implement it however.
>>
>> This argument convinced me to like this idea :) My only concern is
>> that, a newly created user could have fewer permissions then an
>> anonymous one. I can't think of a situation where this would be
>> useful. So maybe all other users could actually inherit those
>> "anonymous permissions" ?
>>
>> >
>> > Alex
>> >
>> > --
>> > "I disapprove of what you say, but I will defend to the death your
>> > right to say it." -- Voltaire
>> > "The people's good is the highest law." -- Cicero
>> > "Code can always be simpler than you think, but never as simple as you
>> > want" -- Me
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Django developers" group.
>> > To post to this group, send email to django-develop...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > django-developers+unsubscr...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/django-developers?hl=en.
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> Łukasz Rekucki
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
The point is that as the developer of a reusable application you don't
know what *anyone* can do, and you should be able to abstract that by
querying the backend.
Alex
--
"I disapprove of what you say, but I will defend to the death your
right
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
I'm not certain I understand - if anyone can perform some action, what's the
point of protecting it with a permissions check?
~Noah Silas
2010/1/18 Łukasz Rekucki
> 2010/1/18 Alex Gaynor :
> > On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel
> wrote:
> >>
> >> Am 18.01.2010 um 22:26 schrieb Luke Plant:
> >>
> >>> Hi Harro,
> >>>
> Hmm I guess I'll just have to keep on hacking django then..
> because that 1% case is something I keep running into for every
> project in one way or another.
> And if it was designed for most apps, why was the row level
> permission bits added? It's useless without simply always being
> able to call request.user.has_perm('permission', obj)
> >>>
> >>> Despite a slight overstatement in that last paragraph, your argument
> >>> seems pretty good to me. The whole point of these methods is to allow
> >>> custom backends to implement their own logic, so obviously it is
> >>> pointless to arbitrarily limit it.
> >>>
> >>> The only downside is that custom backends need to be able to cope with
> >>> anonymous users being passed to the has_perm methods, but that is
> >>> already well catered for with the is_anonymous() method. It is also
> >>> better to make this change before 1.2 lands, otherwise we have a
> >>> slight backwards incompatibility if we wanted to do it in the future
> >>> (backends could break if they unexpectedly got an AnonymousUser
> >>> instead of a User).
> >>>
> >>> Anyone got a good reason reason why this *shouldn't* go in? I'm +1 on
> >>> committing.
> >>
> >> Hm, I don't see a good argument to allow anonymous users to have a
> permissions, to be honest. Anonymous users are by definition not
> authenticated. Giving them more meaning by being able to grant them
> permissions doesn't make them anonymous anymore, right?
> >>
> >> Also, before adding those hooks to the ModelBackend, AnonymousUser never
> returned True when asked if it has a permission or not. Why should it now?
> >>
> >> Jannis
> >>
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> >> To post to this group, send email to django-developers@googlegroups.com
> .
> >> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> >> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> >>
> >
> > I think the best argument in favor of it is using permissions with
> > reusable applications. Say I have a wiki application I write, I don't
> > know whether anonymous users should be able to edit pages, I could
> > make it a setting, but that's ugly. Instead the natural thing to do
> > is ask the auth backend and let the developer implement it however.
>
> This argument convinced me to like this idea :) My only concern is
> that, a newly created user could have fewer permissions then an
> anonymous one. I can't think of a situation where this would be
> useful. So maybe all other users could actually inherit those
> "anonymous permissions" ?
>
> >
> > Alex
> >
> > --
> > "I disapprove of what you say, but I will defend to the death your
> > right to say it." -- Voltaire
> > "The people's good is the highest law." -- Cicero
> > "Code can always be simpler than you think, but never as simple as you
> > want" -- Me
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> > For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> >
> >
> >
> >
>
>
>
> --
> Łukasz Rekucki
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>
>
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Call for comment: #12624 Class based test runners
On Tue, Jan 19, 2010 at 12:39 AM, Eric Holscher wrote: > Saw this go in, and it gets a huge +1 from me as well. However, I know that > in the past we have talked about adding other things to the test runner > (like coverage, etc), so it would seem like now would be a good time to > recommend accepting **kwargs in your custom test runners, so that when we > add in more abilities in the future, we don't blow up people's old test > runners that they have that don't support new options. True - thats worth a note in the docs. I've made the change in r12259. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
2010/1/18 Alex Gaynor :
> On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel wrote:
>>
>> Am 18.01.2010 um 22:26 schrieb Luke Plant:
>>
>>> Hi Harro,
>>>
Hmm I guess I'll just have to keep on hacking django then..
because that 1% case is something I keep running into for every
project in one way or another.
And if it was designed for most apps, why was the row level
permission bits added? It's useless without simply always being
able to call request.user.has_perm('permission', obj)
>>>
>>> Despite a slight overstatement in that last paragraph, your argument
>>> seems pretty good to me. The whole point of these methods is to allow
>>> custom backends to implement their own logic, so obviously it is
>>> pointless to arbitrarily limit it.
>>>
>>> The only downside is that custom backends need to be able to cope with
>>> anonymous users being passed to the has_perm methods, but that is
>>> already well catered for with the is_anonymous() method. It is also
>>> better to make this change before 1.2 lands, otherwise we have a
>>> slight backwards incompatibility if we wanted to do it in the future
>>> (backends could break if they unexpectedly got an AnonymousUser
>>> instead of a User).
>>>
>>> Anyone got a good reason reason why this *shouldn't* go in? I'm +1 on
>>> committing.
>>
>> Hm, I don't see a good argument to allow anonymous users to have a
>> permissions, to be honest. Anonymous users are by definition not
>> authenticated. Giving them more meaning by being able to grant them
>> permissions doesn't make them anonymous anymore, right?
>>
>> Also, before adding those hooks to the ModelBackend, AnonymousUser never
>> returned True when asked if it has a permission or not. Why should it now?
>>
>> Jannis
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
> I think the best argument in favor of it is using permissions with
> reusable applications. Say I have a wiki application I write, I don't
> know whether anonymous users should be able to edit pages, I could
> make it a setting, but that's ugly. Instead the natural thing to do
> is ask the auth backend and let the developer implement it however.
This argument convinced me to like this idea :) My only concern is
that, a newly created user could have fewer permissions then an
anonymous one. I can't think of a situation where this would be
useful. So maybe all other users could actually inherit those
"anonymous permissions" ?
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>
>
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
On Monday 18 January 2010 21:55:58 Jannis Leidel wrote: > > Anyone got a good reason reason why this *shouldn't* go in? I'm > > +1 on committing. > > Hm, I don't see a good argument to allow anonymous users to have a > permissions, to be honest. Anonymous users are by definition not > authenticated. Giving them more meaning by being able to grant > them permissions doesn't make them anonymous anymore, right? As you say - anonymous users are by definition not *authenticated*, but that does not be that they are not *authorised*. Permissions is about authorisation, not authentication, and Harro had some good examples where you want to control authorisation for non-authenticated users in a fine-grained way. In fact, most websites assume a certain level of authorisation for non-authenticated users (ability to browse certain parts of the site etc.), so this distinction is already real, not just academic, and the patch would just make it easier to control. Luke -- "Pessimism: Every dark cloud has a silver lining, but lightning kills hundreds of people each year trying to find it." (despair.com) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel wrote:
>
> Am 18.01.2010 um 22:26 schrieb Luke Plant:
>
>> Hi Harro,
>>
>>> Hmm I guess I'll just have to keep on hacking django then..
>>> because that 1% case is something I keep running into for every
>>> project in one way or another.
>>> And if it was designed for most apps, why was the row level
>>> permission bits added? It's useless without simply always being
>>> able to call request.user.has_perm('permission', obj)
>>
>> Despite a slight overstatement in that last paragraph, your argument
>> seems pretty good to me. The whole point of these methods is to allow
>> custom backends to implement their own logic, so obviously it is
>> pointless to arbitrarily limit it.
>>
>> The only downside is that custom backends need to be able to cope with
>> anonymous users being passed to the has_perm methods, but that is
>> already well catered for with the is_anonymous() method. It is also
>> better to make this change before 1.2 lands, otherwise we have a
>> slight backwards incompatibility if we wanted to do it in the future
>> (backends could break if they unexpectedly got an AnonymousUser
>> instead of a User).
>>
>> Anyone got a good reason reason why this *shouldn't* go in? I'm +1 on
>> committing.
>
> Hm, I don't see a good argument to allow anonymous users to have a
> permissions, to be honest. Anonymous users are by definition not
> authenticated. Giving them more meaning by being able to grant them
> permissions doesn't make them anonymous anymore, right?
>
> Also, before adding those hooks to the ModelBackend, AnonymousUser never
> returned True when asked if it has a permission or not. Why should it now?
>
> Jannis
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>
>
I think the best argument in favor of it is using permissions with
reusable applications. Say I have a wiki application I write, I don't
know whether anonymous users should be able to edit pages, I could
make it a setting, but that's ugly. Instead the natural thing to do
is ask the auth backend and let the developer implement it however.
Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
Am 18.01.2010 um 22:26 schrieb Luke Plant:
> Hi Harro,
>
>> Hmm I guess I'll just have to keep on hacking django then..
>> because that 1% case is something I keep running into for every
>> project in one way or another.
>> And if it was designed for most apps, why was the row level
>> permission bits added? It's useless without simply always being
>> able to call request.user.has_perm('permission', obj)
>
> Despite a slight overstatement in that last paragraph, your argument
> seems pretty good to me. The whole point of these methods is to allow
> custom backends to implement their own logic, so obviously it is
> pointless to arbitrarily limit it.
>
> The only downside is that custom backends need to be able to cope with
> anonymous users being passed to the has_perm methods, but that is
> already well catered for with the is_anonymous() method. It is also
> better to make this change before 1.2 lands, otherwise we have a
> slight backwards incompatibility if we wanted to do it in the future
> (backends could break if they unexpectedly got an AnonymousUser
> instead of a User).
>
> Anyone got a good reason reason why this *shouldn't* go in? I'm +1 on
> committing.
Hm, I don't see a good argument to allow anonymous users to have a permissions,
to be honest. Anonymous users are by definition not authenticated. Giving them
more meaning by being able to grant them permissions doesn't make them
anonymous anymore, right?
Also, before adding those hooks to the ModelBackend, AnonymousUser never
returned True when asked if it has a permission or not. Why should it now?
Jannis
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
Hi Harro,
> Hmm I guess I'll just have to keep on hacking django then..
> because that 1% case is something I keep running into for every
> project in one way or another.
> And if it was designed for most apps, why was the row level
> permission bits added? It's useless without simply always being
> able to call request.user.has_perm('permission', obj)
Despite a slight overstatement in that last paragraph, your argument
seems pretty good to me. The whole point of these methods is to allow
custom backends to implement their own logic, so obviously it is
pointless to arbitrarily limit it.
The only downside is that custom backends need to be able to cope with
anonymous users being passed to the has_perm methods, but that is
already well catered for with the is_anonymous() method. It is also
better to make this change before 1.2 lands, otherwise we have a
slight backwards incompatibility if we wanted to do it in the future
(backends could break if they unexpectedly got an AnonymousUser
instead of a User).
Anyone got a good reason reason why this *shouldn't* go in? I'm +1 on
committing.
Some small tweaks to the patch will help:
- 'set()' is nicer than 'set([])'
- in topics/auth.html, it would be nice to document that the backend
should be able to cope with anonymous users being passed to
has_perm().
Luke
--
"Pessimism: Every dark cloud has a silver lining, but lightning
kills hundreds of people each year trying to find it." (despair.com)
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: DictionaryField
Well, I think you're right. It would be a lot of code, but it would be
useful in just few cases.
> This seems like a lot of work and tweeks, just so you can save that 2
> lines to define a class.
>
> class DictModel(models.Model):
>class Meta:
>abstract = True
>ordering = ['value']
>unique_together = ('value',)
>
>def __unicode__(self):
>return unicode(self.value)
>
> # just 2 lines per dictionary and you have all the flexibility you'll ever
> need
> class School(DictModel):
>value = models.CharField(max_length=
> 64)
>
> class Suburb(DictModel):
>value = models.IntegerField()
>
>
There is no need in ENUM functionality since 'choices=' option exists.
Representing ENUM and SET as input fields even with autocompletion may be
confusing in multi-language applications.
On Mon, Jan 18, 2010 at 7:50 PM, veena wrote:
> Hi,
> for me it has a big WTF factor. Automatically created tables according
> to field.
>
> As DirectoryField I would suppose behaviour like SET or ENUM fields in
> MySQL. I hope there are equivalents in other DB storages.
> Implementation of this types I would appreciate in Django ORM. This
> doesn't need to be even new field. It will be sufficient to have
> implemented those use cases for present field types which gets default
> values as dictionary or tuple of tuples.
> - validating: no other values except set in defaults are valid
> - unique values in SETs
> - support for binary representation of values and binary matching in
> ORM queries
>
>
> Vaclav
>
>
regards,
Mihail
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Looking for full-time developer
This is not the right forum for job postings. This list is for discussion related to the development of Django itself. You might instead try the django-users list [1] or the Django Gigs web site [2]. In all honestly you will find a much larger number of actual Django developers at either of those two locations. -Tobias [1] http://groups.google.com/group/django-users [2] http://djangogigs.com/ On Mon, Jan 18, 2010 at 3:40 PM, gnoze5 wrote: > Hey there, > > I am looking for a full-time Django developer(preferably someone with > a solid python background) to work remotely or in Lisbon , Portugal. > We are currently developing several web applications in Django and > need someone to complete our team. > > I am sorry if this is inapropriate but it is not that easy to find a > good Django developer via normal HR means. > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Looking for full-time developer
Hey there, I am looking for a full-time Django developer(preferably someone with a solid python background) to work remotely or in Lisbon , Portugal. We are currently developing several web applications in Django and need someone to complete our team. I am sorry if this is inapropriate but it is not that easy to find a good Django developer via normal HR means. Email: david.nogue...@emerge.pt Phone: +351 913 185 158 Thanks, David N. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
Hmm I guess I'll just have to keep on hacking django then..
because that 1% case is something I keep running into for every
project in one way or another.
And if it was designed for most apps, why was the row level permission
bits added? It's useless without simply always being able to call
request.user.has_perm('permission', obj)
And adding my own class won't work because of the same reason.
On Jan 17, 9:32 pm, Yuri Baburov wrote:
> Hi Harro,
>
> Just create a special "AnonymousUser" as User with id=0, and set it up
> with backend/middleware.
> You'll have your permissions.
>
>
>
>
>
> On Sun, Jan 17, 2010 at 2:45 PM, Harro wrote:
> > Why wouldn't a AnonymousUser have permissions?
>
> > Imagine a site where can create photo albums.
>
> > User A creates two photo albums, one to share with a specific set of
> > users and one that's public.
> > So Album A has no guest permissions, Album B has viewing permissions.
> > Now let's say you can also comment on and rate a photo. Which are two
> > separate things. For some photo's you might want to disable rating and/
> > or commenting.
> > Now you could go an add can_comment, can_rate booleans on the photo,
> > but thats not needed with row level permissions.
>
> > I really don't care how or where to store the permissions for
> > AnonymousUsers, that's up to the person implementing a backend for it,
> > I do care however about that fact that the current implementation is
> > limiting the system.
>
> > On Jan 15, 5:27 pm, Anton Bessonov wrote:
> >> No. You need row based permissions if You will limit User(!) rights. For
> >> example user can edit entries with FK 2.
> >> Seehttp://code.djangoproject.com/wiki/RowLevelPermissions
>
> >> But AnonymousUser (Guest) don't have any permissions. It's a special and
> >> that the guest can - it's not a permission - it's a setting.
>
> >> Gert Van Gool schrieb:
>
> >> > Isn't the idea of row based permission that you don't need a special
> >> > model for that?
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: bu...@live.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: DictionaryField
Hi, for me it has a big WTF factor. Automatically created tables according to field. As DirectoryField I would suppose behaviour like SET or ENUM fields in MySQL. I hope there are equivalents in other DB storages. Implementation of this types I would appreciate in Django ORM. This doesn't need to be even new field. It will be sufficient to have implemented those use cases for present field types which gets default values as dictionary or tuple of tuples. - validating: no other values except set in defaults are valid - unique values in SETs - support for binary representation of values and binary matching in ORM queries Vaclav On 17 led, 00:02, Mihail Lukin wrote: > Hi, Community > > Sometimes an application model include a lot of fields which are just > dictionary values. Example: > > class HDD(models.Model): > form_factor = models.ForeignKey(HDDFF) > capacity = models.ForeignKey(HDDCap) > interface = models.ForeignKey(HDDIntf) > ... > > and so on, where HDDFF, HDDCap and HDDIntf are similar classes. > Abstract class with only one field "name" may be used, so that this > classes could be defined like this: > > class HDDFF(DictModel): pass > > but it is not as good as something like this: > > class HDD(models.Model): > form_factor = models.DictionaryField() > capacity = models.DictionaryField() > interface = models.DictionaryField() > > Database tables "hdd_form_factor_dict", "hdd_capacity_dict" and so on > could be created automatically, just like it is done by > ManyToManyField. > > What do you think about that? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: DictionaryField
Mihail's initial version doesn't have any data in each model. So
presumably he's just tracking primary keys. In which case a
PositiveIntegerField would work.
And some of the use cases look awfully like 'choices=...' would be the
best bet. Others would be fine if you queried the current set of
values and put them in a drop down on the form:
options = set(MyModel.objects.values_list('opt', flat=True))
But I have had the odd occassion where I've wanted a set of options (a
la choices) but that were editable from the admin. Because of the need
to edit them, however, they have to be top level manually created
models, otherwise I can't specify their admin interface and edit them.
Ian.
On Jan 18, 3:35 am, Yuri Baburov wrote:
> Hi Łukasz, Mikhail,
>
> You can go further and create DictionaryField.
>
> But I see the problems you will get with it:
> 1) You won't be able to refer to the model afterwards, since it's not
> defined in models.py as global.
> 2) I prefer to make DictionaryModel key the primary_key when
> appropriate, you'll need that option.
> 3) Additional fields or methods can appear at any time later, making
> such "economy" almost useless.
>
> So, my only wish is better builtin autocomplete widget for admin and
> regular usage.
> Current default one (for raw_id_fields) looks overcomplicated.
> Unfortunately, The Right autocomplete widget for django admin doesn't exist
> yet.
>
> 2010/1/18 Łukasz Rekucki :
>
>
>
> > 2010/1/17 Simon Meers :
> >> I had considered designing something like this last week. It does seem to
> >> be
> >> a common requirement -- any situation where a simple field would be almost
> >> suitable but for the fact you'd like to avoid duplicates and allow fast
> >> selection of existing values. A Field shortcut could be commonly used to
> >> avoid the creation of separate models. Another example:
>
> >> class Suburb(models.Model):
> >> name = models.CharField(max_length=64, unique=True)
>
> >> class Meta:
> >> ordering = ['name']
>
> >> def __unicode__(self):
> >> return u'%s' % self.name
>
> >> class School(models.Model):
> >> name = models.CharField(max_length=64, unique=True)
>
> >> class Meta:
> >> ordering = ['name']
>
> >> def __unicode__(self):
> >> return u'%s' % self.name
>
> >> class Student(models.Model):
> >> school = models.ForeignKey(School)
> >> suburb = models.ForeignKey(Suburb)
> >> # ...
>
> >> could be replaced with simply:
>
> >> class Student(models.Model):
> >> school = models.DictionaryField(max_length=64)
> >> suburb = models.DictionaryField(max_length=64)
> >> # ...
>
> >> I'm not 100% sold on the name, but I think it is on the right track. I'm
> >> also wondering whether it could be worth catering for types other than
> >> CharField as well. For example:
>
> >> team_number = models.DictionaryField(type=models.IntegerField)
>
> >> This makes me wonder whether perhaps this could be generically applied to
> >> all fields via a Field.__init__ kwarg instead:
>
> >> class Student(models.Model):
> >> school = models.CharField(max_length=64, lookup=True)
> >> suburb = models.CharField(max_length=64, lookup=True)
> >> team_number = models.IntegerField(lookup=True)
>
> >> Either way, these fields could then be stored in separate tables
> >> appname_modelname_fieldname, with a single field of the appropriate type
> >> (named 'value' or similar). It would be nice to also provide external
> >> access
> >> to these auto-generated models via something like Student.school.objects.
> >> Currently Student.school would be a ReverseSingleRelatedObjectDescriptor,
> >> and objects can be accessed via
> >> Student.school.field.related.parent_model.objects.all(), but a shortcut
> >> would be nice.
>
> >> The auto-generated models could provide ordering by value, a unique
> >> constraint on the field, and a simple __unicode__ method like the examples
> >> above.
>
> > This seems like a lot of work and tweeks, just so you can save that 2
> > lines to define a class.
>
> > class DictModel(models.Model):
> > class Meta:
> > abstract = True
> > ordering = ['value']
> > unique_together = ('value',)
>
> > def __unicode__(self):
> > return unicode(self.value)
>
> > # just 2 lines per dictionary and you have all the flexibility you'll ever
> > need
> > class School(DictModel):
> > value = models.CharField(max_length=64)
>
> > class Suburb(DictModel):
> > value = models.IntegerField()
>
> > Also, by giving your dictionaries an explicit name, they can be easily
> > reused. I would probably also make the "value" field a primary_key, so
> > that you won't have to make all those joins just to print out
> > student's info.
>
> >> Simon
>
> >> 2010/1/17 Михаил Лукин
>
> >>> Well, the simplest way is making DictionaryField more like CharField,
> >>> except that
Re: Call for comment: #12624 Class based test runners
Saw this go in, and it gets a huge +1 from me as well. However, I know that in the past we have talked about adding other things to the test runner (like coverage, etc), so it would seem like now would be a good time to recommend accepting **kwargs in your custom test runners, so that when we add in more abilities in the future, we don't blow up people's old test runners that they have that don't support new options. Otherwise this patch looks good, thanks for the work Russ. Cheers, Eric -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Per application default database?
On Mon, Jan 18, 2010 at 11:04 AM, Bill Hubauer wrote: > One of the use cases that may be common for multiple database support is > being able to combine multiple Django applications that require different > databases into a single site. This is exactly what I need to do for one > project. This can be done with the new multiple database support, but it > feels heavy handed to me to require the "integrator" go through all of the > application code and insert "using" specifiers. I also get nervous to > about missing some places where it would be required. > > I've reviewed the code related to the selection of the default database and > think that it wouldn't be too hard to make it possible to do application > specific defaults to database settings. It would mostly be refactoring the > django.db.DEFAULT_DB_ALIAS constant into a function, and then deciding the > best way to allow the user to specify a default database per application in > the settings file. > > Has there been any consideration or discussion of this type of > functionality? > There has been. See: http://groups.google.com/group/django-developers/browse_thread/thread/7904c7da7cb0085f/eb5a359e30307e89?lnk=gst&q=multidb+tobias#eb5a359e30307e89 If I recall correctly, the resolution was basically "not in this phase," i.e., this is something to be worked out in a future release of Django. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Per application default database?
Hi all, One of the use cases that may be common for multiple database support is being able to combine multiple Django applications that require different databases into a single site. This is exactly what I need to do for one project. This can be done with the new multiple database support, but it feels heavy handed to me to require the "integrator" go through all of the application code and insert "using" specifiers. I also get nervous to about missing some places where it would be required. I've reviewed the code related to the selection of the default database and think that it wouldn't be too hard to make it possible to do application specific defaults to database settings. It would mostly be refactoring the django.db.DEFAULT_DB_ALIAS constant into a function, and then deciding the best way to allow the user to specify a default database per application in the settings file. Has there been any consideration or discussion of this type of functionality? Regards, Bill-- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Call for comment: #12624 Class based test runners
On Sun, Jan 17, 2010 at 4:58 AM, Jeff Balogh wrote: > On Sat, Jan 16, 2010 at 6:26 AM, Russell Keith-Magee > wrote: >> Hi all, >> >> This is a quick call for comment on ticket #12624. >> >> This ticket proposes to make Django's test runner a class-based, >> rather than function based operation. > > One thing: > http://docs.djangoproject.com/en/dev/releases/1.2/#test-runner-exit-status-code > says that run_tests should return 0 for success or 1 for failure, but > your patch still returns the old `len(errors) + len(failures)`. That was intentional. I've opted to avoid data loss until the last possible moment. There is a distinction here between the "mange.py test" return value, and the return value from the internal test runner. At the ./manage.py level (and in runtests.py), the full integer status code is clipped to a 0/1 value to avoid operating systems complaining if there was a return code larger than 255. However, that doesn't mean that a programmatic invocation (such as by a continuous integration system) won't be able to use the full integer value of failed tests. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Reservations about "default" database in 1.2 alpha
On Jan 17, 2010, at 6:54 PM, Russell Keith-Magee wrote: > As far as I'm aware, that's exactly what should be happening. If you > retrieve an object from 'other', the object should retain an internal > state that indicates that it came from 'other', and subsequent > database operations (including save) should be directed to the 'other' > database. Ok.. I stand corrected. I just looked at the code for the save_base function and it does use the saved state if the user did not pass in a "using" value. I did look at the code some before I posted my original message, but not closely enough. I guess I was reacting to the release notes that seemed to imply that the only two options were the explicit using param, or the "default" database. Regards, Bill -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
