Re: newforms-admin and django.contrib.auth
On Dec 17, 2007 1:34 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I'm either confused or scared. Presumably the admin application still > relies on authentication, right? Without making me rustle through all > the code, can you explain how it is enforcing access restrictions > without the authentication app? It still relies on knowing whether someone has permission to do something, just not on the specific implementation in django.contrib.auth. At the moment, for example, access to the admin interface is determined by AdminSite.has_permission(), which receives the HttpRequest and returns a boolean. Similarly, ModelAdmin has methods -- has_add_permission(), has_change_permission() and has_delete_permission() -- which receive the HttpRequest (and the model object, in the change/delete cases) and return booleans. This means the default implementation can happily use django.contrib.auth and the existing is_staff flag and permission system, but that using something else is as easy as subclassing and overriding the right methods. And with a little refactoring to remove the direct reliance on the LogEntry and Message models, it would be easy to run the Django admin without django.contrib.auth, simply by plugging in whatever auth/permissions system you like in the appropriate places. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Hi to ALL. I just join this group.
Greetings to all http://rtymarya.tripod.com/naruto-music-melody.html naruto music melody http://rtymarya.tripod.com/naruto-battle-music.html naruto battle music http://rtymarya.tripod.com/naruto-shippuden-music-download.html naruto shippuden music download http://rtymarya.tripod.com/naruto-music-video.html naruto music video http://rtymarya.tripod.com/naruto-musicyu-gi-oh-music.html naruto musicyu gi oh music --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms-admin and django.contrib.auth
On 17 Dec 2007, at 08:08, James Bennett wrote: > This means the default implementation can happily use > django.contrib.auth and the existing is_staff flag and permission > system, but that using something else is as easy as subclassing and > overriding the right methods. And with a little refactoring to remove > the direct reliance on the LogEntry and Message models, it would be > easy to run the Django admin without django.contrib.auth, simply by > plugging in whatever auth/permissions system you like in the > appropriate places. I love it. This would make it much cleaner to integrate the Django admin with existing authentication schemes (LDAP, Active Directory, whatever custom SSO mechanism Oracle sell to big companies) without having to create a new Django user for every existing SSO user and keep the two in sync somehow. Sounds like it wouldn't be an enormous change either. Cheers, Simon --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms-admin and django.contrib.auth
Tell me if I'm crazy here, but what if LogEntry objects were created upon emission of some signal? That way, other apps could hook in and log their own actions as well, along with removing the admin's dependency on auth. It could go into django.contrib.logging or something. What do you guys think of that? On Dec 16, 10:04 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > While playing around a bit with newforms-admin, I noticed that it's > ever-so-close to being able to handle one cool use case which came up > during the design discussion at PyCon: running django.contrib.admin > without django.contrib.auth. > > The implemention of has_permission() on AdminSite, and > has_(add|change|delete)_permission() on ModelAdmin, gets it almost all > the way there, but leaves two stumbling blocks: > > 1. Creating instances of LogEntry, which FK to > django.contrib.auth.models.User, and > 2. Creating instances of Message, which also FK to > django.contrib.auth.models.User. > > Right now, you *can* work around this by overriding/duplicating a lot > of code in ModelAdmin, but factoring out log entries and messages into > methods -- similar to what's already been done with permission checks > -- would make that unnecessary. > > I'm not particularly attached to these method names, but adding > methods on ModelAdmin, say, log_action() and send_user_message(), and > having the object-saving code call those methods instead of directly > handling logging and messages, would solve this pretty cleanly (and > also add a little bit more useful functionality for someone who wants > to roll their own implementation of these features). > > Anyone have strong feelings one way or another? > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms-admin and django.contrib.auth
On Dec 17, 2007 3:39 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Tell me if I'm crazy here, but what if LogEntry objects were created > upon emission of some signal? That way, other apps could hook in and > log their own actions as well, along with removing the admin's > dependency on auth. It could go into django.contrib.logging or > something. > > What do you guys think of that? I think it's a bad idea. Signal dispatch involves much, much, much, much, *much* more overhead than a simple method call, so using a signal where there's no clearly-defined need for it always gets a -1 from me (despite the popularity of "define a signal for X" requests on this list). Also, I don't think that the admin's LogEntry model needs to be, or should be, exposed in this fashion. It's logically part of the administrative interface, and trying to force it into a "generic logging" hole is probably a bad idea. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms-admin and django.contrib.auth
Doh! I just had a read through the dispatcher code and there's a lot more going on there than I previously thought (possibly due to the frequency of signal requests, like you mentioned). On Dec 17, 3:52 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > On Dec 17, 2007 3:39 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Tell me if I'm crazy here, but what if LogEntry objects were created > > upon emission of some signal? That way, other apps could hook in and > > log their own actions as well, along with removing the admin's > > dependency on auth. It could go into django.contrib.logging or > > something. > > > What do you guys think of that? > > I think it's a bad idea. Signal dispatch involves much, much, much, > much, *much* more overhead than a simple method call, so using a > signal where there's no clearly-defined need for it always gets a -1 > from me (despite the popularity of "define a signal for X" requests on > this list). > > Also, I don't think that the admin's LogEntry model needs to be, or > should be, exposed in this fashion. It's logically part of the > administrative interface, and trying to force it into a "generic > logging" hole is probably a bad idea. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
select_related will be fixed?
I found bug in Django ORM. In function select_realted is a parameter 'depth' which works wrong. If I set depth=1, Django getting related tables with depth=2. The bug is in file db/models/query.py in function fill_table_cache, where is: if max_depth and cur_depth > max_depth: return None and should be: if max_depth and cur_depth >= max_depth: return None --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related will be fixed?
On Mon, 2007-12-17 at 03:25 -0800, [EMAIL PROTECTED] wrote: > I found bug in Django ORM. In function select_realted is a parameter > 'depth' which works wrong. If I set depth=1, Django getting related > tables with depth=2. Always worth having a quick search in Trac for things like this. This is ticket #6018. Malcolm -- Always try to be modest and be proud of it! http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related will be fixed?
Yes, right. But here is patch from 8 months ago: http://code.djangoproject.com/attachment/ticket/3275/fix_depth_bug.diff and why it isn't in branch head? On 17 Gru, 12:28, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Mon, 2007-12-17 at 03:25 -0800, [EMAIL PROTECTED] wrote: > > I found bug in Django ORM. In function select_realted is a parameter > > 'depth' which works wrong. If I set depth=1, Django getting related > > tables with depth=2. > > Always worth having a quick search in Trac for things like this. This is > ticket #6018. > > Malcolm > > -- > Always try to be modest and be proud of it!http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related will be fixed?
On Mon, 2007-12-17 at 03:36 -0800, [EMAIL PROTECTED] wrote: > Yes, right. But here is patch from 8 months ago: > http://code.djangoproject.com/attachment/ticket/3275/fix_depth_bug.diff > and why it isn't in branch head? All those bugs are being fixed on the queryset-refactor branch. I hadn't realise #3275 existed, but I've now marked it as a dupe of #6018, since the latter ticket has history attached to it (the commit that fixed the problem on the branch, which will eventually be merged back into trunk). Regards, Malcolm -- Quantum mechanics: the dreams stuff is made of. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related will be fixed?
On Dec 17, 2007 5:36 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Yes, right. But here is patch from 8 months ago: > http://code.djangoproject.com/attachment/ticket/3275/fix_depth_bug.diff > and why it isn't in branch head? Perhaps you didn't read the information on that ticket, which answers your question? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms-admin and django.contrib.auth
James Bennett wrote:
> This means the default implementation can happily use
> django.contrib.auth and the existing is_staff flag and permission
> system, but that using something else is as easy as subclassing and
> overriding the right methods. And with a little refactoring to remove
> the direct reliance on the LogEntry and Message models, it would be
> easy to run the Django admin without django.contrib.auth
When you say 'without django.contrib.auth' does it mean that one can
ditch User model but still use django.contrib.auth to call custom
AUTHENTICATION_BACKENDs, use it's context processor to populate {{ user }}?
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: newforms-admin and django.contrib.auth
On 12/17/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> James Bennett wrote:
> > This means the default implementation can happily use
> > django.contrib.auth and the existing is_staff flag and permission
> > system, but that using something else is as easy as subclassing and
> > overriding the right methods. And with a little refactoring to remove
> > the direct reliance on the LogEntry and Message models, it would be
> > easy to run the Django admin without django.contrib.auth
> When you say 'without django.contrib.auth' does it mean that one can
> ditch User model but still use django.contrib.auth to call custom
> AUTHENTICATION_BACKENDs, use it's context processor to populate {{ user }}?
I don't want to speak for James, but that's how I see it.
Joseph
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: newforms-admin and django.contrib.auth
On 12/16/07, James Bennett <[EMAIL PROTECTED]> wrote: > > While playing around a bit with newforms-admin, I noticed that it's > ever-so-close to being able to handle one cool use case which came up > during the design discussion at PyCon: running django.contrib.admin > without django.contrib.auth. > > The implemention of has_permission() on AdminSite, and > has_(add|change|delete)_permission() on ModelAdmin, gets it almost all > the way there, but leaves two stumbling blocks: > > 1. Creating instances of LogEntry, which FK to > django.contrib.auth.models.User, and > 2. Creating instances of Message, which also FK to > django.contrib.auth.models.User. > > Right now, you *can* work around this by overriding/duplicating a lot > of code in ModelAdmin, but factoring out log entries and messages into > methods -- similar to what's already been done with permission checks > -- would make that unnecessary. > > I'm not particularly attached to these method names, but adding > methods on ModelAdmin, say, log_action() and send_user_message(), and > having the object-saving code call those methods instead of directly > handling logging and messages, would solve this pretty cleanly (and > also add a little bit more useful functionality for someone who wants > to roll their own implementation of these features). > > Anyone have strong feelings one way or another? +1 on the concept. There are details to figure out, for instance, which method is in charge of generating the actual content of the message, but it shouldn't be that difficult. I've been wanting this for well, nearly as long as Django has existed. I'd lost sight of that and didn't realize we were so close. Joseph --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms-admin and django.contrib.auth
On 2007-12-16 21:04:10 -0700, "James Bennett" <[EMAIL PROTECTED]> said: > > While playing around a bit with newforms-admin, I noticed that it's > ever-so-close to being able to handle one cool use case which came up > during the design discussion at PyCon: running django.contrib.admin > without django.contrib.auth. > > The implemention of has_permission() on AdminSite, and > has_(add|change|delete)_permission() on ModelAdmin, gets it almost all > the way there, but leaves two stumbling blocks: > > 1. Creating instances of LogEntry, which FK to > django.contrib.auth.models.User, and > 2. Creating instances of Message, which also FK to > django.contrib.auth.models.User. > > Right now, you *can* work around this by overriding/duplicating a lot > of code in ModelAdmin, but factoring out log entries and messages into > methods -- similar to what's already been done with permission checks > -- would make that unnecessary. > > I'm not particularly attached to these method names, but adding > methods on ModelAdmin, say, log_action() and send_user_message(), and > having the object-saving code call those methods instead of directly > handling logging and messages, would solve this pretty cleanly (and > also add a little bit more useful functionality for someone who wants > to roll their own implementation of these features). > > Anyone have strong feelings one way or another? +1. There are a few other places in ModelAdmin that should be split out into its own method, but unrelated to this. This would definitely solve this problem cleanly for those looking for this feature. -- Brian Rosner http://oebfare.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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms-admin and django.contrib.auth
Joseph Kocherhans wrote: > I don't want to speak for James, but that's how I see it. Then this is great! --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: lazy (in utils.functional) is broken
On Dec 17, 6:52 pm, "Gary Wilson Jr." <[EMAIL PROTECTED]> wrote: > SmileyChris wrote: > > I've been working on a new version of the session messages ticket and > > was looking at making the "messages" context variable lazy - it seems > > silly how it currently wipes messages, even if you didn't check for > > them. > > What ticket number is this btw? http://code.djangoproject.com/ticket/4604 PS: I didn't want to continue this debate on lazy() and didn't want it to hold up the ticket, so I just wrote a custom lazy object. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Splitting django.newforms.models
I would like to propose splitting django.newforms.models. The reasoning behind this stems from the work going on in newforms-admin. django.newforms.models now consists of ModelForm, the model choice fields and the model related formset code. I am working on a patch that adds declarative style formsets which increases the code related to model formsets. Its just becoming a bare to work with sometimes. I wanted to see how everyone felt if it were to be split up like so: django | - newforms | - models | - __init__.py - fields.py - forms.py That would be how it would layout in trunk so then newforms-admin would add a formsets.py to the mix and nicely cleaning everything up. I am more than happy to open a ticket and write up a patch if everyone is in favor of this small clean up. -- Brian Rosner http://oebfare.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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms-admin and django.contrib.auth
On Dec 17, 2007 1:04 PM, James Bennett <[EMAIL PROTECTED]> wrote: > > While playing around a bit with newforms-admin, I noticed that it's > ever-so-close to being able to handle one cool use case which came up > during the design discussion at PyCon: running django.contrib.admin > without django.contrib.auth. ... > Anyone have strong feelings one way or another? +1 from me. I don't have a particular use case for this myself, but I agree that being able to swap out contrib.auth with an alternate admin scheme is a cool use case that we should support if it is possible to do so. 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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
