Re: [Django] #11009: Auth PasswordResestTest fails since changeset 10599 - Ticket #8752

[Django]

#11009: Auth PasswordResestTest fails since changeset 10599 - Ticket #8752
-+--
  Reporter:  laureline.gue...@makina-corpus.org  | Owner:  
nobody
Status:  new | Milestone:   
 
 Component:  Contrib apps|   Version:  SVN  
 
Resolution:  |  Keywords:   
 
 Stage:  Ready for checkin   | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by SmileyChris):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Ready for checkin
  * summary:  Auth PasswordResestTest fails since sur changeset 10599 -
  Ticket #8752 => Auth PasswordResestTest fails
  since changeset 10599 - Ticket #8752
  * needs_tests:  => 0
  * needs_docs:  => 0

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

Re: [Django] #11036: QueryDict has_key() calls __getitem__ instead of __contains__

[Django]

#11036: QueryDict has_key() calls __getitem__ instead of __contains__
+---
  Reporter:  bensmith   | Owner:  nobody   
Status:  closed | Milestone:   
 Component:  HTTP handling  |   Version:  1.0  
Resolution:  worksforme |  Keywords:  QueryDict
 Stage:  Unreviewed | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by SmileyChris):

  * status:  new => closed
  * resolution:  => worksforme

Comment:

 {{{
 In [1]: from django.http import QueryDict

 In [2]: q = QueryDict('')

 In [3]: q.has_key('fish')
 Out[3]: False
 }}}

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

Re: [Django] #11020: models.permalink() does not pass through the url prefix

[Django]

#11020: models.permalink() does not pass through the url prefix
---+
  Reporter:  hjust | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  1 
Needs_docs:  1 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Changes (by SmileyChris):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Design decision needed
  * needs_tests:  => 1
  * needs_docs:  => 1

Comment:

 You don't have to use the permalink decorator. It feels like this is an
 edge case that could just use a `reverse()` call, but I'll push to a
 design decision rather than close outright.

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

Re: [Django] #11013: Named imports in urls

[Django]

#11013: Named imports in urls
-+--
  Reporter:  gruszczy| Owner:  nobody
Status:  closed  | Milestone:
 Component:  Core framework  |   Version:  1.1-beta-1
Resolution:  invalid |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  1 
Needs_better_patch:  0   |  
-+--
Changes (by SmileyChris):

  * status:  reopened => closed
  * resolution:  => invalid
  * stage:  Unreviewed => Design decision needed

Comment:

 I agree that the current urlconf method relies on an overly implicit
 import. The original ticket here is for a different issue, which was
 indeed invalid.

 Feel free to open a new ticket with a suggestion on how to avoid this
 reliance on implicit imports (and/or bring up the issue in the django dev
 google group)

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

Re: [Django] #11694: lighttpd fastcgi documentation not working

[Django]

#11694: lighttpd fastcgi documentation not working
--+-
  Reporter:  bugger...@gmail.com  | Owner:  nobody
Status:  new  | Milestone:
 Component:  Documentation|   Version:  1.1   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by aszlig):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Hm, this whole FORCE_SCRIPT_NAME thingy was always required before and
 '''is''' documented at the bottom of the deployment documentation.

 Maybe it's a good idea to avoid FORCE_SCRIPT_NAME by changing the
 documentation example to something like:


 {{{
 server.modules += (
 "mod_alias",
 "mod_fastcgi",
 )

 server.document-root = "/home/user/public_html"

 fastcgi.server = (
 "/" => ((
 "socket" => "/home/user/mysite.sock",
 "check-local" => "disable",
 "fix-root-scriptname" => "enable",
 )),
 )

 $HTTP["url"] =~ "/(?:media(?:$|/)|favicon\.ico$|... whatever you want to
 serve directly ...)" {
 fastcgi.server = ()
 alias.url = (
 "/media"  => "/home/user/django/contrib/admin/media/",
 )
 }
 }}}

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

Re: [Django] #11603: Add an assertFormSetError function to django.test.TestCase

[Django]

#11603: Add an assertFormSetError function to django.test.TestCase
+---
  Reporter:  martin_speleo  | Owner:  martin_speleo
Status:  new| Milestone:   
 Component:  Testing framework  |   Version:  SVN  
Resolution: |  Keywords:  formset  
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by martin_speleo):

  * needs_docs:  1 => 0
  * has_patch:  0 => 1
  * version:  => SVN
  * needs_tests:  1 => 0

Comment:

 My first attempt at contibuting to Django, I think the patch should be
 ready to be checked in.

 It could possibly do with some unittesting on checking for more than one
 error at once.  assertFormError also does not have unittests for dealing
 with multiple errors, along with a few other little bits and pieces.  But
 if I understand correctly, exceptions are normally used to raise errors in
 forms/formsets so mulitple errors will be uncommon.

 I have not tested that my changes to the documentation do not break
 everything, as I am running Vista and the make file for the documentation
 used a -p command on mkdir which did not appear to be understood.  If this
 is a problem let me know and I will try to make the documenetation again.

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

Re: [Django] #10650: Clarify use of MEDIA_ROOT in default settings.py

[Django]

#10650: Clarify use of MEDIA_ROOT in default settings.py
-+--
  Reporter:  tvon| Owner:  nobody
Status:  new | Milestone:  1.2   
 Component:  File uploads/storage|   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by thiggins):

 Brian, thanks for tuning in. Your latest point is well taken. After all,
 MEDIA_ROOT is just a root. It could easily have two folders under it, one
 for incoming and one for outgoing media. I also see that the ongoing
 process of software/documentation design has created the ''appearance'' of
 a conceptual disparity between the very terse official documentation and
 your blog post. I think what is desired first by the uninitiated, like
 myself and perhaps vak and Muhammad Alkarouri above, is a clear path to
 getting pages served, while still in the development phase, with CSS and
 images intact. Your blog attempts to assist with this, and I promise to
 study it again with improved insight.

 I had been having a several-days-long email conversation with my CS
 graduate son on the correct setup of MEDIA_ROOT. I took the point of view
 that it is for all static files. He insisted that it is for uploads only,
 pointing to this ticket, and saying:

 "Read this ticket. Someone even mentions the blog post you linked.
 http://code.djangoproject.com/ticket/10650

 Notice in the blog post he makes use of MEDIA_ROOT and MEDIA_URL himself,
 passing it along to static.serve. He could have called these settings
 anything. He's confusing people by using settings that Django uses for
 something else.

 Unfortunately, Django is also at fault for being far too vague in its docs
 about what MEDIA_ROOT and MEDIA_URL are used for. Searching through
 Django's code confirms that MEDIA_ROOT & MEDIA_URL are used for file
 upload, and that MEDIA_URL is provided as a convenience to templates via
 the default context processors (available when using RequestContext?)."

 Thus persuaded, I agreed with him, but now see that what we have is merely
 a conceptual misunderstanding; if we users wire everything right we will
 get good results even if we put MEDIA_ROOT to the additional use of
 housing our served static media. STATIC_DOC_ROOT is a suggestion, and
 could be under MEDIA_ROOT anyway, and perhaps that would typically be
 sensible. Tidying up the ideas presented in the official documentation
 would have helped speed my process along, however.

 By the way, I would not personally say "Django is at fault." This is a
 wonderful product in the throes of a major creative upheaval and I am very
 excited about the extraordinary results I am seeing. Keep up the good
 work, please!

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

Re: [Django] #2713: Sitemap Index with Cache gives a NoReverseMatch exception

[Django]

#2713: Sitemap Index with Cache gives a NoReverseMatch exception
---+
  Reporter:  JayKlehr  | Owner:  stavros
Status:  new   | Milestone: 
 Component:  Contrib apps  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  1  
Needs_better_patch:  0 |  
---+
Comment (by stavros):

 That is indeed much better, for some reason I didn't think of it, even
 though I didn't like my solution myself.

 My patch might have been off because I made it by hand (I've actually
 never tried to make one before).

 Sure, I'll try to write some when I have some time (it should be soon).
 Thanks for the patch, I hope it gets implemented soon!

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

Re: [Django] #2713: Sitemap Index with Cache gives a NoReverseMatch exception

[Django]

#2713: Sitemap Index with Cache gives a NoReverseMatch exception
---+
  Reporter:  JayKlehr  | Owner:  stavros
Status:  new   | Milestone: 
 Component:  Contrib apps  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  1  
Needs_better_patch:  0 |  
---+
Changes (by SmileyChris):

  * owner:  adrian => stavros
  * status:  reopened => new
  * needs_tests:  0 => 1
  * stage:  Design decision needed => Accepted

Comment:

 Yes, named urls didn't directly fix this ticket.

 Stavros: hard coding an alternate url name isn't the best way to do it -
 here's a better patch (with docs). [side note: your patch also seemed to
 be back-the-front]

 Even though contrib.sitemaps currently has no tests, some regression tests
 should probably be added showing this works. Want to have a go at these?

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

Re: [Django] #11603: Add an assertFormSetError function to django.test.TestCase

[Django]

#11603: Add an assertFormSetError function to django.test.TestCase
+---
  Reporter:  martin_speleo  | Owner:  martin_speleo
Status:  new| Milestone:   
 Component:  Testing framework  |   Version:   
Resolution: |  Keywords:  formset  
 Stage:  Accepted   | Has_patch:  0
Needs_docs:  1  |   Needs_tests:  1
Needs_better_patch:  0  |  
+---
Changes (by martin_speleo):

 * cc: sethtr...@gmail.com (removed)
  * needs_docs:  0 => 1
  * owner:  nobody => martin_speleo
  * needs_tests:  0 => 1

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

Re: [Django] #11775: ABSOLUTE_URL_OVERRIDES doesn't work for the majority of contrib models

[Django]

#11775: ABSOLUTE_URL_OVERRIDES doesn't work for the majority of contrib models
---+
  Reporter:  jukvalim  | Owner:  jukvalim
Status:  assigned  | Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:|  Keywords:  
 Stage:  Unreviewed| Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by jukvalim):

  * status:  new => assigned

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

[Django] #11775: ABSOLUTE_URL_OVERRIDES doesn't work for the majority of contrib models

[Django]

#11775: ABSOLUTE_URL_OVERRIDES doesn't work for the majority of contrib models
+---
   Reporter:  jukvalim  |Owner:  jukvalim  
 Status:  new   |Milestone:
  Component:  Database layer (models, ORM)  |  Version:  SVN   
   Keywords:|Stage:  Unreviewed
  Has_patch:  1 |   Needs_docs:  0 
Needs_tests:  0 |   Needs_better_patch:  0 
+---
 At the moment, ABSOLUTE_URL_OVERRIDES is used to override get_absolute_url
 methods. However, most models in django.contrib don't have the
 get_absolute_url method in the first place, and so ABSOLUTE_URL_OVERRIDES
 does nothing to them. This means that you can't have links from unmodified
 admin pages of these model objects to the page that represents the model
 object in the application. If there is code that relies on getting the url
 to object by get_absolute_url, there needs to be separate code to handle
 these model objects.

 The reporter of this ticket came across both of these problems when
 wanting to link to the application page of a group
 (contrib.auth.models.Group) from admin, and from a general search.

 Proposed solution: Make it possible for ABSOLUTE_URL_OVERRIDES to insert a
 function as get_absolute_url method of a model class, rather than only
 overriding existing methods. (Design decision needed on this one, I think)

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

Re: [Django] #5176: Bug in django.utils.cache._generate_cache_key(request, headerlist, key_prefix)

[Django]

#5176: Bug in django.utils.cache._generate_cache_key(request, headerlist,
key_prefix)
---+
  Reporter:  Eratothene| Owner:  nobody  
Status:  reopened  | Milestone:  
 Component:  Cache system  |   Version:  SVN 
Resolution:|  Keywords:  cache session testclient
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  1 |  
---+
Changes (by tclineks):

  * needs_tests:  1 => 0

Comment:

 attached updated patch (against r11475)

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

Re: [Django] #1946: [patch] to allow overriding of default sequence name

[Django]

#1946: [patch] to allow overriding of default sequence name
---+
  Reporter:  ab...@cabal.org.uk| Owner:  shmengie
Status:  assigned  | Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  1 |   Needs_tests:  1   
Needs_better_patch:  1 |  
---+
Changes (by shmengie):

  * owner:  nobody => shmengie
  * status:  new => assigned

Comment:

 HM I like the elegance of your solution, but the potential performance
 repercussion will likely keep it out of the codebase.

 The Meta.sequence_name = 'my_cust_seq' has minimal performance impact (one
 python if statement) per InsertQuery.  Legacy integrators will not be
 concerned with table creation, but will appreciate being able to integrate
 their schema into django.  The Meta.sequence_name would need to be
 documented.

 Pros:
   Eases legacy integration
   Adds feature custom sequence_name ability

 Cons:
   Does not address sequence creation issues
   minimal performance impact (more a pro than con)
   minimal additional code in base

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

Re: [Django] #11772: ModelAdmin - added a model_modified hook for full CRUD support

[Django]

#11772: ModelAdmin - added a model_modified hook for full CRUD support
---+
  Reporter:  Rupe  | Owner:  nobody 

Status:  new   | Milestone: 

 Component:  django.contrib.admin  |   Version:  SVN

Resolution:|  Keywords:  modeladmin hook 
modified save add change delete
 Stage:  Unreviewed| Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Comment (by Rupe):

 The has_changed hook doesn't look like it triggers on the delete of a
 record.

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

[Django] #11774: add __range lookup parameter in django.contrib.admin.views.main.get_query_set

[Django]

#11774: add __range lookup parameter in
django.contrib.admin.views.main.get_query_set
--+-
 Reporter:  anonymous |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.1   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I think it will be good to add __range lookup here too
 >> django.contrib.admin.views.main.get_query_set
 Just like this ..
 {{{
 # if key ends with __in or __range, split parameter into separate values
 if key.endswith('__in'):
 lookup_params[key] = value.split(',')
 if key.endswith('__range'):
 lookup_params[key] = value.split(',')
 }}}

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

Re: [Django] #11772: ModelAdmin - added a model_modified hook for full CRUD support

[Django]

#11772: ModelAdmin - added a model_modified hook for full CRUD support
---+
  Reporter:  Rupe  | Owner:  nobody 

Status:  new   | Milestone: 

 Component:  django.contrib.admin  |   Version:  SVN

Resolution:|  Keywords:  modeladmin hook 
modified save add change delete
 Stage:  Unreviewed| Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by Mnewman):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Can you clear up for me why you need a hook here? You have access to
 model.form.has_changed() in any other hook on the modeladmin, and this
 looks like overkill for me. Maybe I am missing something.

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

Re: [Django] #11773: Porxy Model registered in Model Admin are only visible to Super User

[Django]

#11773: Porxy Model registered in Model Admin are only visible to Super User
--+-
  Reporter:  coulix   | Owner:  nobody
Status:  closed   | Milestone:
 Component:  django-admin.py  |   Version:
Resolution:  duplicate|  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by russellm):

  * status:  new => closed
  * resolution:  => duplicate

Comment:

 This is effectively a duplicate of #11154. Your user may have "all"
 permissions, but Django doesn't explicitly create permissions for Proxy
 classes. As a result, your non-superuser doesn't have permission to view,
 change or delete the proxy User.

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

[Django] #11773: Porxy Model registered in Model Admin are only visible to Super User

[Django]

#11773: Porxy Model registered in Model Admin are only visible to Super User
---+
   Reporter:  coulix   |Owner:  nobody
 Status:  new  |Milestone:
  Component:  django-admin.py  |  Version:
   Keywords:   |Stage:  Unreviewed
  Has_patch:  0|   Needs_docs:  0 
Needs_tests:  0|   Needs_better_patch:  0 
---+
 - MyUser model proxy User.
 - Register an admin for MyUser

 Only super user can see it, even giving all permissions to an admin does
 not make him see the interface.
 It has to be a superadmin.

 Is that wanted ?

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

[Django] #11772: ModelAdmin - added a model_modified hook for full CRUD support

[Django]

#11772: ModelAdmin - added a model_modified hook for full CRUD support
-+--
 Reporter:  Rupe |   Owner:  
nobody
   Status:  new  |   Milestone: 
   
Component:  django.contrib.admin | Version:  
SVN   
 Keywords:  modeladmin hook modified save add change delete  |   Stage:  
Unreviewed
Has_patch:  1|  
-+--
 I added a simple hook called model_modified that is called after each
 insert, update, and delete via the ModelAdmin class. There are times when
 it's useful to know when a model changes in any way by the user (via the
 admin app), including delete. The current methodology of overriding the
 save_model hook does not include delete. The usefulness of this hook over
 using the model signals for model changes is that you have access to the
 response object. I used this hook to clear certain session variables that
 were dependent on the correlating models.

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

Re: [Django] #11765: models.DateField(null=True, blank=True) accepts None, but not the empty string ''

[Django]

#11765: models.DateField(null=True, blank=True)  accepts None, but not the empty
string ''
---+
  Reporter:  shmengie  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Changes (by mrts):

  * version:  1.1 => SVN
  * component:  Uncategorized => Database layer (models, ORM)
  * needs_tests:  0 => 1

Comment:

 The problem is that `DateField.to_python()` (or `DateTimeField`) doesn't
 treat `''` specially, see
 source:/django/trunk/django/db/models/fields/__init__...@10545#l464

 {{{
 class DateTest(models.Model):
 foo = models.DateField(null=True, blank=True)
 }}}

 {{{
 >>> d = DateTest(foo='')
 >>> d.save()
 Traceback (most recent call last):
   ...
   File "/usr/lib/python2.6/dist-
 packages/django/db/models/fields/__init__.py", line 474, in to_python
 _('Enter a valid date in -MM-DD format.'))
 ValidationError: Enter a valid date in -MM-DD format.
 }}}

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

Re: [Django] #5833: Custom FilterSpecs

[Django]

#5833: Custom FilterSpecs
---+
  Reporter:  Honza_Kral| Owner:  jkocherhans
 
Status:  assigned  | Milestone:  1.2
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  nfa-someday 
list_filter filterspec nfa-changelist ep2008
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  1  
 
Needs_better_patch:  0 |  
---+
Comment (by marcob):

 When you delete a record, querystring looses return_to_ parameter.

 (BTW last patch seems not working for me)

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

Re: [Django] #11765: models.DateField(null=True, blank=True) accepts None, but not the empty string ''

[Django]

#11765: models.DateField(null=True, blank=True)  accepts None, but not the empty
string ''
+---
  Reporter:  shmengie   | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by mrts):

  * needs_better_patch:  => 0
  * summary:  models.DateField(null=True, blank=True)  accepts None, but
  not null string '' =>
  models.DateField(null=True, blank=True)
  accepts None, but not the empty string ''
  * needs_tests:  => 0
  * needs_docs:  => 0

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