Re: [Django] #17121: New documentation version chooser doesn't work in Firefox

[Django]

#17121: New documentation version chooser doesn't work in Firefox
---+
 Reporter:  varikin|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by charettes):

 Might be related to https://bugzilla.mozilla.org/show_bug.cgi?id=641240

-- 
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] #17117: ADMIN_MEDIA_PREFIX should still be visible in docs

[Django]

#17117: ADMIN_MEDIA_PREFIX should still be visible in docs
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by ptone):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Ready for checkin


-- 
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] #17121: New documentation version chooser doesn't work in Firefox

[Django]

#17121: New documentation version chooser doesn't work in Firefox
---+
 Reporter:  varikin|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by varikin):

 I just checked it at home on FF 7.0. It is the find bar at the bottom
 (cmd-F/ctr-F) that does it. Closing that bar fixes the issue. Opening
 again introduces the issue again. Wow! I would love to know what is
 different that the bar does that.

-- 
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] #16250: Error with new pyscopg2 2.4.2 release and tests

[Django]

#16250: Error with new pyscopg2 2.4.2 release and tests
---+
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by anonymous):

 And anonymous, you can find 2.4.1 on pypi:

 pip install psycopg2==2.4.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] #16250: Error with new pyscopg2 2.4.2 release and tests

[Django]

#16250: Error with new pyscopg2 2.4.2 release and tests
---+
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by anonymous):

 Nonetheless, anonynmous's point stands that the fix should be included in
 the next Django 1.3

-- 
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] #17122: Admin inlines and forms do not support custom model fields that store non-unicode data in the database to be the primary key referenced by relation fields.

[Django]

#17122: Admin inlines and forms do not support custom model fields that store 
non-
unicode data in the database to be the primary key referenced by relation
fields.
-+--
 Reporter:  nickname123  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by nickname123):

 The patch I just uploaded adds support for ForeignKey and ManyToManyField
 relations.

 The OneToOneField is not in this patch.  I believe a design decision
 discussion would be required to implement OneToOneField support because it
 would have to pass its relation to the widget and currently does not do
 so.

-- 
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] #17122: Admin inlines and forms do not support custom model fields that store non-unicode data in the database to be the primary key referenced by relation fields.

[Django]

#17122: Admin inlines and forms do not support custom model fields that store 
non-
unicode data in the database to be the primary key referenced by relation
fields.
-+--
 Reporter:  nickname123  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by nickname123):

 * cc: nickname123 (added)
 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * 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.

[Django] #17122: Admin inlines and forms do not support custom model fields that store non-unicode data in the database to be the primary key referenced by relation fields.

[Django]

#17122: Admin inlines and forms do not support custom model fields that store 
non-
unicode data in the database to be the primary key referenced by relation
fields.
-+
 Reporter:  nickname123  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Forms|Version:  1.3
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Admin inlines and forms do not support custom model fields that store non-
 unicode data in the database to be the primary key referenced by relation
 fields because they call force_unicode() on raw database data when
 rendering widgets and determining if data has changed.

 A simple solution is to call the custom field's to_python method where
 this occurs because to_python supports the raw database data and will
 return an object that supports unicode transformation.

-- 
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] #5763: Queryset doesn't have a "not equal" filter operator

[Django]

#5763: Queryset doesn't have a "not equal" filter operator
-+-
 Reporter:  jdetaeye |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  qs-rf|  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by SmileyChris):

 * status:  reopened => closed
 * resolution:   => wontfix


Comment:

 Thanks for your thoughts, Adam, but reopening a ticket closed by a core
 developer is a no-no (as mentioned in the
 [https://docs.djangoproject.com/en/1.3/internals/contributing/#ticket-
 resolutions contributing documentation]).

 Try bringing this up in the django-developers mailing list.

-- 
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] #17120: FormSet max_num can be bypassed and any number of forms saved

[Django]

#17120: FormSet max_num can be bypassed and any number of forms saved
+
 Reporter:  mila|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.3
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by russellm):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


-- 
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] #17121: New documentation version chooser doesn't work in Firefox

[Django]

#17121: New documentation version chooser doesn't work in Firefox
---+
 Reporter:  varikin|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by carljm):

 * stage:  Unreviewed => Accepted


Comment:

 I've seen this issue, but it's transient, even on affected versions of
 Firefox (presuming there are not-affected versions). It has to do with
 Firefox's "link destination" popup trying to jump over to the right side
 of the screen, and causing Firefox to think you're no longer hovering over
 the documentation version links (or something along those lines). I can
 reproduce it much more reliably if I hit Ctrl-F so the Find bar is present
 at the bottom of the page. I'm running Firefox 7.0.1 on Ubuntu 10.10 x64,
 not a FF nightly or anything like that.

-- 
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] #17121: New documentation version chooser doesn't work in Firefox

[Django]

#17121: New documentation version chooser doesn't work in Firefox
---+--
 Reporter:  varikin|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by charettes):

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


Comment:

 I cannot reproduce using nightly 10.0a1 cc66accc8181 build (most up-to-
 date as of 10/26/2011) on ubuntu 11.10 x64.

 Do you have the most up-to-date version?

-- 
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] #17070: newly created templatetags module not loaded or recognized until server restart

[Django]

#17070: newly created templatetags module not loaded or recognized until server
restart
--+
 Reporter:  UltraAyla |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  Template system   |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:  templatetag tags  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by ptone):

 related: #12772

-- 
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] #17121: New documentation version chooser doesn't work in Firefox

[Django]

#17121: New documentation version chooser doesn't work in Firefox
---+
 Reporter:  varikin|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  SVN
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 In the new thing at that the bottom of the documentation page to switch
 between the doc version, the other versions that display when hovering
 disappear before being able to click them in Firefox.

 I tested this in chrome and they still show, but in Firefox (I am running
 Nightly which if FF10) on a Mac, the other options like 1.1, 1,2, 1.3, or
 Dev disappear shortly after moving the mouse away from the main box saying
 which version is displayed.

 I haven't tested in current stable Firefox though.

-- 
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] #16818: Regression introduced by r16739 -- `ManyRelatedManager.add()` doesn't commit to database

[Django]

#16818: Regression introduced by r16739 -- `ManyRelatedManager.add()` doesn't
commit to database
-+-
 Reporter:  pressureman  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by mrmachine):

 * cc: real.human@… (added)


-- 
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.

[Changeset] r17042 - in django/trunk: django/utils tests/regressiontests/cache

[noreply]

Author: aaugustin
Date: 2011-10-26 15:47:04 -0700 (Wed, 26 Oct 2011)
New Revision: 17042

Modified:
   django/trunk/django/utils/cache.py
   django/trunk/tests/regressiontests/cache/tests.py
Log:
Fixed several problems that hid one another in the cache tests and code.

1 - Used django.test.TestCase instead of unittest.TestCase so that the 
override_settings decorator works.
2 - Reverted parts of r17039 that caused failures (masked until 1).
3 - Isolated tests by clearing the cache in tear down (masked until 1). Refs 
#11505.
4 - Fixed a bug in cache key generation (revealed by 3).
5 - Fixed a test that relied on this bug -- hardcoding the generated cache keys 
in tests isn't a very good idea anyway.
6 - Uniformized some parts of the cache tests.



Modified: django/trunk/django/utils/cache.py
===
--- django/trunk/django/utils/cache.py  2011-10-26 21:07:12 UTC (rev 17041)
+++ django/trunk/django/utils/cache.py  2011-10-26 22:47:04 UTC (rev 17042)
@@ -174,7 +174,7 @@
 ctx.update(value)
 path = hashlib.md5(iri_to_uri(request.get_full_path()))
 cache_key = 'views.decorators.cache.cache_page.%s.%s.%s.%s' % (
-key_prefix, request.method, path.hexdigest(), ctx.hexdigest())
+key_prefix, method, path.hexdigest(), ctx.hexdigest())
 return _i18n_cache_key_suffix(request, cache_key)
 
 def _generate_cache_header_key(key_prefix, request):

Modified: django/trunk/tests/regressiontests/cache/tests.py
===
--- django/trunk/tests/regressiontests/cache/tests.py   2011-10-26 21:07:12 UTC 
(rev 17041)
+++ django/trunk/tests/regressiontests/cache/tests.py   2011-10-26 22:47:04 UTC 
(rev 17042)
@@ -941,12 +941,16 @@
 self.assertRaises(InvalidCacheBackendError, get_cache, 
'does_not_exist')
 
 
-class CacheUtils(unittest.TestCase):
+class CacheUtils(TestCase):
 """TestCase for django.utils.cache functions."""
 
 def setUp(self):
 self.path = '/cache/test/'
+self.cache = get_cache('default')
 
+def tearDown(self):
+self.cache.clear()
+
 def _get_request(self, path, method='GET'):
 request = HttpRequest()
 request.META = {
@@ -1006,7 +1010,7 @@
 response['Vary'] = 'Pony'
 # Make sure that the Vary header is added to the key hash
 learn_cache_key(request, response)
-self.assertEqual(get_cache_key(request), 
'views.decorators.cache.cache_page.settingsprefix.HEAD.a8c87a3d8c44853d7f79474f7ffe4ad5.d41d8cd98f00b204e9800998ecf8427e')
+self.assertEqual(get_cache_key(request), 
'views.decorators.cache.cache_page.settingsprefix.GET.a8c87a3d8c44853d7f79474f7ffe4ad5.d41d8cd98f00b204e9800998ecf8427e')
 
 def test_patch_cache_control(self):
 tests = (
@@ -1054,11 +1058,15 @@
 )(CacheUtils)
 
 
-class CacheHEADTest(unittest.TestCase):
+class CacheHEADTest(TestCase):
 
 def setUp(self):
 self.path = '/cache/test/'
+self.cache = get_cache('default')
 
+def tearDown(self):
+self.cache.clear()
+
 def _get_request(self, method):
 request = HttpRequest()
 request.META = {
@@ -1112,17 +1120,22 @@
 )(CacheHEADTest)
 
 
-class CacheI18nTest(unittest.TestCase):
+class CacheI18nTest(TestCase):
 
 def setUp(self):
 self.path = '/cache/test/'
+self.cache = get_cache('default')
 
-def _get_request(self):
+def tearDown(self):
+self.cache.clear()
+
+def _get_request(self, method='GET'):
 request = HttpRequest()
 request.META = {
 'SERVER_NAME': 'testserver',
 'SERVER_PORT': 80,
 }
+request.method = method
 request.path = request.path_info = self.path
 return request
 
@@ -1167,10 +1180,10 @@
 )
 def test_middleware(self):
 def set_cache(request, lang, msg):
-with translation.override(lang):
-response = HttpResponse()
-response.content= msg
-return UpdateCacheMiddleware().process_response(request, 
response)
+translation.activate(lang)
+response = HttpResponse()
+response.content = msg
+return UpdateCacheMiddleware().process_response(request, response)
 
 # cache with non empty request.GET
 request = self._get_request_cache(query_string='foo=bar=true')
@@ -1198,8 +1211,8 @@
 set_cache(request, 'en', en_message)
 get_cache_data = FetchFromCacheMiddleware().process_request(request)
 # Check that we can recover the cache
-self.assertNotEqual(get_cache_data.content, None)
-self.assertEqual(en_message, get_cache_data.content)
+self.assertNotEqual(get_cache_data, None)
+self.assertEqual(get_cache_data.content, en_message)
 # Check that we use etags
 self.assertTrue(get_cache_data.has_header('ETag'))
 # Check that 

Re: [Django] #11505: Django's TestCase should reset the cache

[Django]

#11505: Django's TestCase should reset the cache
-+-
 Reporter:  andrewfong   |Owner:
 Type:  New feature  |  andrewfong
Component:  Testing framework|   Status:  assigned
 Severity:  Normal   |  Version:  SVN
 Keywords:  cache testing flush  |   Resolution:
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  1
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by aaugustin):

 In [17042]:
 {{{
 #!CommitTicketReference repository="" revision="17042"
 Fixed several problems that hid one another in the cache tests and code.

 1 - Used django.test.TestCase instead of unittest.TestCase so that the
 override_settings decorator works.
 2 - Reverted parts of r17039 that caused failures (masked until 1).
 3 - Isolated tests by clearing the cache in tear down (masked until 1).
 Refs #11505.
 4 - Fixed a bug in cache key generation (revealed by 3).
 5 - Fixed a test that relied on this bug -- hardcoding the generated cache
 keys in tests isn't a very good idea anyway.
 6 - Uniformized some parts of the cache tests.
 }}}

-- 
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] #5763: Queryset doesn't have a "not equal" filter operator

[Django]

#5763: Queryset doesn't have a "not equal" filter operator
-+-
 Reporter:  jdetaeye |Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  qs-rf|  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by asmoore82):

 * status:  closed => reopened
 * resolution:  wontfix =>
 * easy:  0 => 1


Comment:

 Apologies for the re-open - but I wasn't sure what would be worse, a re-
 open or a new ticket for the same old discussion...

 I'm going to have to take the position that the absence of a `__ne`
 operator //still//
 represents a functional hole in the querying API, even with consideration
 of exclude()

 > it doesn't make sense to have `__ne` without any other negated queries,

 Ah but there are indeed other negated queries.

 `filter(__gte)` and `exclude(__lt)` are **almost** equivalent.

 Similarly, you can **almost** approximate `__ne` with a hokey `Q(__lt) |
 Q(__gt)` contraption.

 But the real issue lies within that "almost" -- this is what could be
 cause for a separate ticket, but a quick and dirty `__ne` would head the
 issue off altogether ;). Chaining multiple `filter()` and `exclude()`
 calls on multi-valued relationships yields not-so-surprising but
 nonetheless undesired results. To quote from the Django docs:

 > Django has a consistent way of processing `filter()` and `exclude()`
 calls. Everything inside a single `filter()` call is applied
 simultaneously to filter out items matching all those requirements.
 Successive `filter()` calls further restrict the set of objects, but for
 multi-valued relations, they apply to any object linked to the primary
 model, not necessarily those objects that were selected by an earlier
 `filter()` call.

 This consistency is a good thing but it combines with the lack of `__ne`
 to form a problem.

 Say you have blogs with entries with tags and author_counts

 If you want to get all entries that are tagged 'django' with more than 2
 co-authors:
  {{{ Entry.objects.filter(tag__name='django', author_count__gt=2) }}}

 It is similarly easy to get blogs with entries with the above criteria:
  {{{ Blog.objects.filter(entry__tag__name='django',
 entry__author_count__gt=2) }}}

 But what if you want entries tagged 'django' that are **not** co-authored
 by 2:
  {{{ Entry.objects.filter(tag__name='django').exclude(author_count=2) }}}

 But if you want the blogs with those entries, it can't easily be done:
  {{{
 Blog.objects.filter(entry__tag__name='django').exclude(entry__author_count=2)
 }}}
 is **not** the equivalent of the imaginary query:
  {{{ Blog.objects.filter(entry__tag__name='django',
 entry__author_count__ne=2) }}}
 which can currently be approximated with:
  {{{ Blog.objects.filter(Q(entry__author_count__lt=2) |
 Q(entry__author_count__gt=2), entry__tag__name='django') }}}

 You can also get the desired results with a `.extra()` call but let's not
 go there :P.

 This brings us to the most surprising aspect, using the negation operator
 `~` on `Q()` objects that select on multi-valued relations is technically
 possible but can yield the undesired results on the unsuspecting, which
 actually runs sort of contrary to the Documentation quote above.

 Bad Surprise!!:
  {{{ Blog.objects.filter(~Q(entry__author_count=2),
 entry__tag__name='django') }}}
 `^`The more I look at this, the more I think it is cause for a ticket in
 its own right. The fix for this would be to smarten up the `Q()` objects
 so that a NOT operator on `__gt` becomes `__lte`, a NOT on `__lt` becomes
 `__gte`, and so on. But you will ultimately be missing the `__ne` and
 other NOT primitives to fall back on.

 In other words, this ticket is a "could-go-either-way" blocker for `^`that
 more important ticket. I'll do some research on that and make a ticket if
 it hasn't already been addressed.

 Thanks to all who make Django awesome! I'm a database newbie and loving
 it!

 ~Adam sM

-- 
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 

[Changeset] r17041 - django/trunk/tests/regressiontests/wsgi

[noreply]

Author: carljm
Date: 2011-10-26 14:07:12 -0700 (Wed, 26 Oct 2011)
New Revision: 17041

Modified:
   django/trunk/tests/regressiontests/wsgi/tests.py
Log:
Fixed error message string assumptions in WSGI tests (were breaking tests on 
PyPy). Thanks to Alex Gaynor for the report.

Modified: django/trunk/tests/regressiontests/wsgi/tests.py
===
--- django/trunk/tests/regressiontests/wsgi/tests.py2011-10-26 21:03:18 UTC 
(rev 17040)
+++ django/trunk/tests/regressiontests/wsgi/tests.py2011-10-26 21:07:12 UTC 
(rev 17041)
@@ -83,20 +83,17 @@
 
 @override_settings(WSGI_APPLICATION="regressiontests.wsgi.noexist.app")
 def test_bad_module(self):
-with self.assertRaises(ImproperlyConfigured) as cm:
+with self.assertRaisesRegexp(
+ImproperlyConfigured,
+r"^WSGI application 'regressiontests.wsgi.noexist.app' could not 
be loaded; could not import module 'regressiontests.wsgi.noexist':"):
+
 get_internal_wsgi_application()
 
-self.assertEqual(
-str(cm.exception),
-"WSGI application 'regressiontests.wsgi.noexist.app' could not be 
loaded; could not import module 'regressiontests.wsgi.noexist': No module named 
noexist")
 
-
 @override_settings(WSGI_APPLICATION="regressiontests.wsgi.wsgi.noexist")
 def test_bad_name(self):
-with self.assertRaises(ImproperlyConfigured) as cm:
-get_internal_wsgi_application()
+with self.assertRaisesRegexp(
+ImproperlyConfigured,
+r"^WSGI application 'regressiontests.wsgi.wsgi.noexist' could not 
be loaded; can't find 'noexist' in module 'regressiontests.wsgi.wsgi':"):
 
-self.assertEqual(
-str(cm.exception),
-"WSGI application 'regressiontests.wsgi.wsgi.noexist' could not be 
loaded; can't find 'noexist' in module 'regressiontests.wsgi.wsgi': 'module' 
object has no attribute 'noexist'")
-
+get_internal_wsgi_application()

-- 
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.

[Changeset] r17040 - in django/trunk: django/contrib/markup tests/regressiontests/cache tests/regressiontests/db_typecasts tests/regressiontests/templates

[noreply]

Author: aaugustin
Date: 2011-10-26 14:03:18 -0700 (Wed, 26 Oct 2011)
New Revision: 17040

Modified:
   django/trunk/django/contrib/markup/tests.py
   django/trunk/tests/regressiontests/cache/tests.py
   django/trunk/tests/regressiontests/db_typecasts/tests.py
   django/trunk/tests/regressiontests/templates/loaders.py
   django/trunk/tests/regressiontests/templates/tests.py
Log:
Removed remains from times when tests could be run outside of runtests.py.


Modified: django/trunk/django/contrib/markup/tests.py
===
--- django/trunk/django/contrib/markup/tests.py 2011-10-26 20:55:36 UTC (rev 
17039)
+++ django/trunk/django/contrib/markup/tests.py 2011-10-26 21:03:18 UTC (rev 
17040)
@@ -83,7 +83,3 @@
 t = Template("{% load markup %}{{ rest_content|restructuredtext }}")
 rendered = 
t.render(Context({'rest_content':self.rest_content})).strip()
 self.assertEqual(rendered, self.rest_content)
-
-
-if __name__ == '__main__':
-unittest.main()

Modified: django/trunk/tests/regressiontests/cache/tests.py
===
--- django/trunk/tests/regressiontests/cache/tests.py   2011-10-26 20:55:36 UTC 
(rev 17039)
+++ django/trunk/tests/regressiontests/cache/tests.py   2011-10-26 21:03:18 UTC 
(rev 17040)
@@ -1581,8 +1581,3 @@
 response = self.client.get('/test_admin/admin/')
 self.assertEqual(response.status_code, 200)
 self.assertTrue(response.has_header('ETag'))
-
-
-if __name__ == '__main__':
-unittest.main()
-

Modified: django/trunk/tests/regressiontests/db_typecasts/tests.py
===
--- django/trunk/tests/regressiontests/db_typecasts/tests.py2011-10-26 
20:55:36 UTC (rev 17039)
+++ django/trunk/tests/regressiontests/db_typecasts/tests.py2011-10-26 
21:03:18 UTC (rev 17040)
@@ -53,6 +53,3 @@
 for inpt, expected in v:
 got = getattr(typecasts, k)(inpt)
 self.assertEqual(got, expected, "In %s: %r doesn't match %r. 
Got %r instead." % (k, inpt, expected, got))
-
-if __name__ == '__main__':
-unittest.main()

Modified: django/trunk/tests/regressiontests/templates/loaders.py
===
--- django/trunk/tests/regressiontests/templates/loaders.py 2011-10-26 
20:55:36 UTC (rev 17039)
+++ django/trunk/tests/regressiontests/templates/loaders.py 2011-10-26 
21:03:18 UTC (rev 17040)
@@ -153,6 +153,3 @@
 self.assertRaisesRegexp(TemplateDoesNotExist,
 'No template names provided$',
 loader.select_template, [])
-
-if __name__ == "__main__":
-unittest.main()

Modified: django/trunk/tests/regressiontests/templates/tests.py
===
--- django/trunk/tests/regressiontests/templates/tests.py   2011-10-26 
20:55:36 UTC (rev 17039)
+++ django/trunk/tests/regressiontests/templates/tests.py   2011-10-26 
21:03:18 UTC (rev 17040)
@@ -1711,7 +1711,3 @@
 template.Template('{% include "child" only %}').render(ctx),
 'none'
 )
-
-
-if __name__ == "__main__":
-unittest.main()

-- 
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] #17120: FormSet max_num can be bypassed and any number of forms saved

[Django]

#17120: FormSet max_num can be bypassed and any number of forms saved
+
 Reporter:  mila|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Forms   |Version:  1.3
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 I've reported this issue to secur...@djangoproject.com first. It is not
 considered to be security issue (see Russell's email bellow) so I open it
 here.

 Formsets accept its max_num from data submitted by the user and ignore a
 value set in the code. It means that user can bypass any formset max_num
 check and save any number of forms he like.

 For example: a user has paid for two persons so I will offer him formsets
 with max_num=2 in order to make an order. If he tampers the form data he
 can send orders for any number of persons. In case of model formsets it
 means that any number of orders will be saved to a database despite the
 max_num value.

 On Fri, Oct 21, 2011 at 2:14 AM, Russell Keith-Magee
  wrote:
 {{{

  We discussed this issue internally, and decided that it wasn't a
  security issue.

  I can certainly see why you raised this as an issue. It's certainly a
  reasonable assumption that max_num should be interpreted as a limit,
  and that it shouldn't be able to be tampered with by a user. To that
  end, it's definitely a bug; we should improve the documentation, and
  we should make whatever changes we need to make to ensure that max_num
  is handled server side, rather than relying on the client-provided
  value.

  An example that helps explain why this isn't a security issue.
  Consider the following case:

   * Page has a form with inlines, and max_num = 3. There is 1 existing
  inline object.
   * User 1 loads the edit page
   * User 2 loads the edit page
   * User 1 submits a POST containing 3 inlines (1 original plus 2 new
 entries)
   * User 2 submits a POST containing 3 inlines (1 original plus 2 new
  entries, different to those from User 1).

  In this case, both User1 and User2 have obeyed max_num in their forms,
  but User 2 will, in practice, violate the max_num rule. This situation
  exists even when max_num isn't being tampered with; so it highlights
  that max_num is really just a guidance for dynamic form layout, not a
  data validation control. If it were a validation condition, it would
  need to be handled at the model level, not the form level.

  Thank you very much for raising this as a security issue, and
  apologies again for the poor feedback on our part. If you raise this
  as a ticket, we can address the client-side modification issue as a
  normal bug.

  Yours,
  Russ Magee %-)

 }}}

-- 
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.

[Changeset] r17039 - django/trunk/tests/regressiontests/cache

[noreply]

Author: aaugustin
Date: 2011-10-26 13:55:36 -0700 (Wed, 26 Oct 2011)
New Revision: 17039

Modified:
   django/trunk/tests/regressiontests/cache/tests.py
Log:
Improved settings manipulation in the cache tests with the suitable decorators 
and context managers.


Modified: django/trunk/tests/regressiontests/cache/tests.py
===
--- django/trunk/tests/regressiontests/cache/tests.py   2011-10-26 15:17:43 UTC 
(rev 17038)
+++ django/trunk/tests/regressiontests/cache/tests.py   2011-10-26 20:55:36 UTC 
(rev 17039)
@@ -34,10 +34,12 @@
 # functions/classes for complex data type tests
 def f():
 return 42
+
 class C:
 def m(n):
 return 24
 
+
 class DummyCacheTests(unittest.TestCase):
 # The Dummy cache backend doesn't really behave like a test backend,
 # so it has different test requirements.
@@ -737,10 +739,12 @@
 self.assertEqual(self.custom_key_cache.get('answer2'), 42)
 self.assertEqual(self.custom_key_cache2.get('answer2'), 42)
 
+
 def custom_key_func(key, key_prefix, version):
 "A customized cache key function"
 return 'CUSTOM-' + '-'.join([key_prefix, str(version), key])
 
+
 class DBCacheTests(unittest.TestCase, BaseCacheTests):
 backend_name = 'django.core.cache.backends.db.DatabaseCache'
 
@@ -818,6 +822,7 @@
 self.assertEqual(mirror_cache.get('value1'), 42)
 self.assertEqual(other_cache.get('value1'), None)
 
+
 # memcached backend isn't guaranteed to be available.
 # To check the memcached backend, the test settings file will
 # need to contain a cache backend setting that points at
@@ -853,6 +858,7 @@
 
 MemcachedCacheTests = 
unittest.skipUnless(settings.CACHES[DEFAULT_CACHE_ALIAS]['BACKEND'].startswith('django.core.cache.backends.memcached.'),
 "memcached not available")(MemcachedCacheTests)
 
+
 class FileBasedCacheTests(unittest.TestCase, BaseCacheTests):
 """
 Specific test cases for the file-based cache.
@@ -900,6 +906,7 @@
 self.cache = get_cache('file://%s?max_entries=30' % self.dirname)
 self.perform_cull_test(50, 29)
 
+
 class CustomCacheKeyValidationTests(unittest.TestCase):
 """
 Tests for the ability to mixin a custom ``validate_key`` method to
@@ -933,23 +940,13 @@
 
 self.assertRaises(InvalidCacheBackendError, get_cache, 
'does_not_exist')
 
+
 class CacheUtils(unittest.TestCase):
 """TestCase for django.utils.cache functions."""
 
 def setUp(self):
 self.path = '/cache/test/'
-self.old_cache_middleware_key_prefix = 
settings.CACHE_MIDDLEWARE_KEY_PREFIX
-self.old_cache_middleware_seconds = settings.CACHE_MIDDLEWARE_SECONDS
-self.orig_use_i18n = settings.USE_I18N
-settings.CACHE_MIDDLEWARE_KEY_PREFIX = 'settingsprefix'
-settings.CACHE_MIDDLEWARE_SECONDS = 1
-settings.USE_I18N = False
 
-def tearDown(self):
-settings.CACHE_MIDDLEWARE_KEY_PREFIX = 
self.old_cache_middleware_key_prefix
-settings.CACHE_MIDDLEWARE_SECONDS = self.old_cache_middleware_seconds
-settings.USE_I18N = self.orig_use_i18n
-
 def _get_request(self, path, method='GET'):
 request = HttpRequest()
 request.META = {
@@ -1036,39 +1033,32 @@
 parts = set(cc_delim_re.split(response['Cache-Control']))
 self.assertEqual(parts, expected_cc)
 
-class PrefixedCacheUtils(CacheUtils):
-def setUp(self):
-super(PrefixedCacheUtils, self).setUp()
-self.old_cache_key_prefix = 
settings.CACHES['default'].get('KEY_PREFIX', None)
-settings.CACHES['default']['KEY_PREFIX'] = 'cacheprefix'
+CacheUtils = override_settings(
+CACHE_MIDDLEWARE_KEY_PREFIX='settingsprefix',
+CACHE_MIDDLEWARE_SECONDS=1,
+CACHES={
+'default': {
+'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
+},
+},
+USE_I18N=False,
+)(CacheUtils)
 
-def tearDown(self):
-super(PrefixedCacheUtils, self).tearDown()
-if self.old_cache_key_prefix is None:
-del settings.CACHES['default']['KEY_PREFIX']
-else:
-settings.CACHES['default']['KEY_PREFIX'] = 
self.old_cache_key_prefix
+PrefixedCacheUtils = override_settings(
+CACHES={
+'default': {
+'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
+'KEY_PREFIX': 'cacheprefix',
+},
+},
+)(CacheUtils)
 
+
 class CacheHEADTest(unittest.TestCase):
 
 def setUp(self):
-self.orig_cache_middleware_seconds = settings.CACHE_MIDDLEWARE_SECONDS
-self.orig_cache_middleware_key_prefix = 
settings.CACHE_MIDDLEWARE_KEY_PREFIX
-self.orig_caches = settings.CACHES
-settings.CACHE_MIDDLEWARE_SECONDS = 60
-settings.CACHE_MIDDLEWARE_KEY_PREFIX = 'test'
-settings.CACHES = {
-'default': {
-'BACKEND': 

Re: [Django] #17097: Permission to delete a comment should be based on a user's given permissions

[Django]

#17097: Permission to delete a comment should be based on a user's given
permissions
--+
 Reporter:  george@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.comments  |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by George Hickman ):

 I've added a patch using !ModelAdmin.has_delete_permission() in
 contrib.comments.admin.py and a couple of pretty basic tests for user's
 permissions when set on a group. They'll need expanding though, as the
 patch isn't tested yet (bit short on time right now) but hopefully that's
 a start anyway.

-- 
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] #17040: In utils.crypto.constant_time_compare only call ord on non ints.

[Django]

#17040: In utils.crypto.constant_time_compare only call ord on non ints.
--+
 Reporter:  adsworth  |Owner:  adsworth
 Type:  Bug   |   Status:  new
Component:  Python 3  |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by adsworth):

 I am by no crypto expert, but since constant_time_compare in the django
 and the contrib apps is only used to compare hashes or some sort of tokens
 I'd think it save to assume byte strings is the "right thing". Since a
 unicode string can use one or two bytes per char depending on the contents
 I think you are right about a constant time compare not being possible.

 also calling ord() on a unicode char that is 2 bytes long results in a
 TypeError.
 {{{#!python
 >>> ord('ழ்')
 Traceback (most recent call last):
   File "", line 1, in 
 TypeError: ord() expected a character, but string of length 2 found
 >>>
 }}}

-- 
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] #5704: Admin popup windows won't close when using application/xhtml as default content type

[Django]

#5704: Admin popup windows won't close when using application/xhtml as default
content type
-+-
 Reporter:  Rob van der Linde|Owner:  dArignac
   |   Status:  assigned
 Type:  Bug  |  Version:  SVN
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * stage:  Accepted => Ready for checkin


-- 
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] #4978: Admin DateTimeShortcuts.js ISODate

[Django]

#4978: Admin DateTimeShortcuts.js ISODate
-+-
 Reporter:  fero |Owner:  xian
     |   Status:  closed
 Type:  Bug  |  Version:  SVN
Component:  contrib.admin|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  datetime calendar|  Needs documentation:  0
  isodate date   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by claudep):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => fixed
 * easy:   => 0


Comment:

 It seems this is fixed for some time now. Please reopen if you can
 reproduce it in up-to-date code.

-- 
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] #17119: Cache Framework: wrong per-site cache behavior documentation

[Django]

#17119: Cache Framework: wrong per-site cache behavior documentation
---+--
 Reporter:  Vanni  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by vanni.totaro@…):

 * easy:  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] #17119: Cache Framework: wrong per-site cache behavior documentation

[Django]

#17119: Cache Framework: wrong per-site cache behavior documentation
---+--
 Reporter:  Vanni  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by vanni.totaro@…):

 * type:  Uncategorized => Bug


-- 
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] #17119: Cache Framework: wrong per-site cache behavior documentation

[Django]

#17119: Cache Framework: wrong per-site cache behavior documentation
---+--
 Reporter:  Vanni  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by vanni.totaro@…):

 * needs_better_patch:   => 0
 * 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.

[Django] #17119: Cache Framework: wrong per-site cache behavior documentation

[Django]

#17119: Cache Framework: wrong per-site cache behavior documentation
---+
 Reporter:  Vanni  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 From https://docs.djangoproject.com/en/dev/topics/cache/#the-per-site-
 cache documentation page: "The cache middleware caches every page that
 doesn't have GET or POST parameters".\\
 AFAIK it is not true. URLs with GET parameters (like
 http://www.example.com/?this_is_a_get_param=value) get (IMHO correctly)
 cached and POST parameters are simply ignored.

-- 
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] #17079: "extra" parameter does not add any extra lines in inline formset with initial data

[Django]

#17079: "extra" parameter does not add any extra lines in inline formset with
initial data
---+--
 Reporter:  mardy@…|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:  invalid
 Keywords:  formset extra  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by claudep):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 When you create the formset in the POST section, the extra form is created
 but is then filled with the POST data. You should then recreate a new
 formset or, better, redirect to the same view (POST should always
 redirect, see http://en.wikipedia.org/wiki/Post/Redirect/Get).

-- 
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] #17100: Possible bad regex for email validator

[Django]

#17100: Possible bad regex for email validator
---+
 Reporter:  reames@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Core (Other)   |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by claudep):

 I think the fix should also be backported to stable branch.

-- 
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] #17100: Possible bad regex for email validator

[Django]

#17100: Possible bad regex for email validator
---+
 Reporter:  reames@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Core (Other)   |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by claudep):

 * has_patch:  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] #16507: Tests that alter ROOT_URLCONF should set DEBUG_PROPAGATE_EXCEPTION

[Django]

#16507: Tests that alter ROOT_URLCONF should set DEBUG_PROPAGATE_EXCEPTION
--+
 Reporter:  andymckay |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  contrib.messages  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by carljm):

 Based on #17113, I think that my comment above was bogus, just a
 misunderstanding of what was happening here based on looking at the
 failing-handler case. Thanks for confirming that, Claude - sorry for the
 misdirection.

 Andy, if you can write a test case demonstrating a situation where the
 wrong handler is actually used, please upload to #17113 and re-open.

 It seems to me that Claude is right that this bug is a simple case where
 both urlconfs use the default 500 handler and template, but that template
 tries to reverse a URL that doesn't exist in the temporary URLconf. It's
 tempting to say we should set DEBUG_PROPAGATE_EXCEPTIONS to True in the
 base `TestCase` class whenever a custom URLconf is used (or just set it
 for all test runs, as Andy suggests), but I think this is overly implicit
 and non-obvious behavior, and not backwards-compatible; it could cause
 changes in the behavior of existing tests. (And is there any other
 precedent where we force the default value of a setting implicitly, just
 for running tests? Other than DATABASES, I guess).

 Really this is not a general issue in the test suite, only in the contrib
 tests which might be run from someone's project that has a custom 500
 template. And if someone triggers it in their own tests with their own
 custom 500 template, they can deal with that. So in the end I think
 Claude's latest approach of fixing the specific test is probably the best
 option?

-- 
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] #16818: Regression introduced by r16739 -- `ManyRelatedManager.add()` doesn't commit to database (was: Regression introduced by r16739)

[Django]

#16818: Regression introduced by r16739 -- `ManyRelatedManager.add()` doesn't
commit to database
-+-
 Reporter:  pressureman  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  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] #16818: Regression introduced by r16739

[Django]

#16818: Regression introduced by r16739
-+-
 Reporter:  pressureman  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by ramiro):

 #17112 was a duplicate and has some additional notes. Among them this one:

 ''I'm not sure how to create an automated test for this, because the
 problem only exhibits when reading from the database from a different
 process or transaction. ''

-- 
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] #17112: `ManyRelatedManager.add()` doesn't commit to database

[Django]

#17112: `ManyRelatedManager.add()` doesn't commit to database
-+-
 Reporter:  mrmachine|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  add reverse m2m  |  Needs documentation:  0
  relation not committed |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by ramiro):

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


Comment:

 #16818 also reported this. I'm going to close this one as a duplicate
 adding as a comment there a copy of the note by ''mrmachine'' about why
 this isn't easily reproducible with our test suite (I wasn't able by
 simply adding a test case).

-- 
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] #17113: Test that error handlers of custom urls.py are called

[Django]

#17113: Test that error handlers of custom urls.py are called
---+--
 Reporter:  claudep|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  SVN
 Severity:  Normal |   Resolution:  worksforme
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by carljm):

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


Comment:

 My comment on #16507 was bogus, it was purely a misunderstanding of what
 was happening in that ticket. Thanks claudep for demonstrating that this
 works just fine, sorry for the misdirection.

-- 
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] #17100: Possible bad regex for email validator

[Django]

#17100: Possible bad regex for email validator
---+
 Reporter:  reames@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Core (Other)   |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by claudep):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


-- 
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] #17116: Changing the default encoding breaks test_broken_unicode (regressiontests.model_regress.tests.ModelTests)

[Django]

#17116: Changing the default encoding breaks test_broken_unicode
(regressiontests.model_regress.tests.ModelTests)
-+-
 Reporter:  Raphaël Hertzog  |Owner:  nobody
  |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:  Testing framework|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted
 * 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.

[Changeset] r17038 - django/trunk/django/contrib/humanize

[noreply]

Author: carljm
Date: 2011-10-26 08:17:43 -0700 (Wed, 26 Oct 2011)
New Revision: 17038

Modified:
   django/trunk/django/contrib/humanize/tests.py
Log:
Avoid spurious failures in naturaltime tests.

Previous fix didn't cover timesince module, which naturaltime delegates to
under certain conditions. Extended mock of datetime to timesince module, and
switched to a fixed datetime rather than now() for testing, for more
reproducible tests (failures in mock will fail fast, rather than sporadically).

Modified: django/trunk/django/contrib/humanize/tests.py
===
--- django/trunk/django/contrib/humanize/tests.py   2011-10-26 12:19:18 UTC 
(rev 17037)
+++ django/trunk/django/contrib/humanize/tests.py   2011-10-26 15:17:43 UTC 
(rev 17038)
@@ -118,7 +118,8 @@
 self.assertNotEqual(naturalday_one, naturalday_two)
 
 def test_naturaltime(self):
-now = datetime.now()
+# we're going to mock datetime.datetime, so use a fixed datetime
+now = datetime(2011, 8, 15)
 test_list = [
 now,
 now - timedelta(seconds=1),
@@ -160,18 +161,21 @@
 
 # mock out datetime so these tests don't fail occasionally when the
 # test runs too slow
-class MockDateTime(object):
+class MockDateTime(datetime):
+@classmethod
 def now(self):
 return now
 
-def __call__(self, *args, **kwargs):
-return datetime(*args, **kwargs)
-
+# naturaltime also calls timesince/timeuntil
 from django.contrib.humanize.templatetags import humanize
-orig_datetime = humanize.datetime
-humanize.datetime = MockDateTime()
+from django.utils import timesince
+orig_humanize_datetime = humanize.datetime
+orig_timesince_datetime = timesince.datetime.datetime
+humanize.datetime = MockDateTime
+timesince.datetime.datetime = MockDateTime
 
 try:
 self.humanize_tester(test_list, result_list, 'naturaltime')
 finally:
-humanize.datetime = orig_datetime
+humanize.datetime = orig_humanize_datetime
+timesince.datetime.datetime = orig_timesince_datetime

-- 
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] #17118: list_editable will update wrong rows on a multiuser system if pagination is enabled

[Django]

#17118: list_editable will update wrong rows on a multiuser system if 
pagination is
enabled
+--
 Reporter:  |  Owner:  nobody
  emilianodelvalle@…| Status:  new
 Type:  Bug |Version:  1.3
Component:  contrib.admin   |   Keywords:  list_editable list multiuser
 Severity:  Normal  |  Has patch:  0
 Triage Stage:  Unreviewed  |  UI/UX:  0
Easy pickings:  0   |
+--
 If there is a model with fields which are "list editable" and the number
 of rows for that model enables pagination, an update on those fields could
 not work as expected (other rows are updated).

 1. Lets say that the user updates fields on the first page on the change
 list view.
 2. While saving those changes, the information on the database changes
 (another user or another process added rows that should be shown before
 the rows updated by the user, shifting the rows modified by the user to a
 second page).
 3. Django will update the editable fields on the newest rows with the data
 entered for other rows.

 I debugged the code and I think that the bug is on the BaseModelFormSet.
 For some reason, if it can't retrieve a instance model using the pk, it
 will use the index to retrieve it. However, the queryset that it's using
 has been limited by pagination. Therefore if the row updated has been
 moved to another page, it won't be found.

 This belongs to BaseModelFormSet, take a look at the final if on the
 _construct_form method.
 {{{
 def _existing_object(self, pk):
 if not hasattr(self, '_object_dict'):
 self._object_dict = dict([(o.pk, o) for o in
 self.get_queryset()])
 return self._object_dict.get(pk)

 def _construct_form(self, i, **kwargs):
 if self.is_bound and i < self.initial_form_count():
 # Import goes here instead of module-level because importing
 # django.db has side effects.
 from django.db import connections
 pk_key = "%s-%s" % (self.add_prefix(i),
 self.model._meta.pk.name)
 pk = self.data[pk_key]
 pk_field = self.model._meta.pk
 pk = pk_field.get_db_prep_lookup('exact', pk,
 connection=connections[self.get_queryset().db])
 if isinstance(pk, list):
 pk = pk[0]
 kwargs['instance'] = self._existing_object(pk)
 if i < self.initial_form_count() and not kwargs.get('instance'):
 kwargs['instance'] = self.get_queryset()[i]
 return super(BaseModelFormSet, self)._construct_form(i, **kwargs)
 }}}

-- 
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] #17117: ADMIN_MEDIA_PREFIX should still be visible in docs

[Django]

#17117: ADMIN_MEDIA_PREFIX should still be visible in docs
---+
 Reporter:  claudep|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  SVN
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 ADMIN_MEDIA_PREFIX is now a deprecated setting. However, the commit
 [16487] simply deleted the setting from the docs, instead of moving it to
 the deprecated section.

-- 
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] #17116: Changing the default encoding breaks test_broken_unicode (regressiontests.model_regress.tests.ModelTests)

[Django]

#17116: Changing the default encoding breaks test_broken_unicode
(regressiontests.model_regress.tests.ModelTests)
-+
 Reporter:  Raphaël Hertzog   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Testing framework|Version:  1.3
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 This bug has been reported in the Debian bug tracking system:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646634

 If you add the lines below to /etc/python2.7/sitecustomize.py:
 {{{
 import sys
 sys.setdefaultencoding('utf8')
 }}}

 Then you get this test failure:

 {{{
 FAIL: test_broken_unicode (regressiontests.model_regress.tests.ModelTests)
 --
 Traceback (most recent call last):
   File "/root/python-
 django-1.3.1/tests/regressiontests/model_regress/tests.py", line 146, in
 test_broken_unicode
 self.assertEqual(repr(b), "")
 AssertionError: '' !=
 ''

 }}}

 I know it's not a good idea to change the default encoding but maybe this
 test could be skipped if sys.getdefaultencoding() doesn't return ascii.

-- 
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] #17115: Problem loading fixtures sql files when models are in models/ directory and not in the models.py

[Django]

#17115: Problem loading fixtures sql files when models are in models/ directory 
and
not in the models.py
+-
 Reporter:  shomodj@…   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Core (Management commands)  |Version:  1.3
 Severity:  Normal  |   Keywords:  models fixtures
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+-
 If I put model files into models/ directory and add Meta: app_label, sql
 create works, but now fixtures don't work as django now looks in the
 app/models/sql path and not in the app/sql path as stated in the
 documentation.

 bug is in the django/core/management/sql.py line 130

 Now I'm not sure if this is a documentation bug or django bug...

-- 
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.

[Changeset] r17037 - in django/trunk: django/contrib/admin docs/ref/contrib/admin docs/releases tests/regressiontests/admin_changelist

[noreply]

Author: julien
Date: 2011-10-26 05:19:18 -0700 (Wed, 26 Oct 2011)
New Revision: 17037

Modified:
   django/trunk/django/contrib/admin/options.py
   django/trunk/docs/ref/contrib/admin/index.txt
   django/trunk/docs/releases/1.4.txt
   django/trunk/tests/regressiontests/admin_changelist/admin.py
   django/trunk/tests/regressiontests/admin_changelist/models.py
   django/trunk/tests/regressiontests/admin_changelist/tests.py
Log:
Fixed #16257 -- Added new `ModelAdmin.get_list_display_links()` method to allow 
for the dynamic display of links on the admin changelist. Thanks to graveyboat 
for the suggestion and initial patch.

Modified: django/trunk/django/contrib/admin/options.py
===
--- django/trunk/django/contrib/admin/options.py2011-10-26 10:38:12 UTC 
(rev 17036)
+++ django/trunk/django/contrib/admin/options.py2011-10-26 12:19:18 UTC 
(rev 17037)
@@ -650,6 +650,18 @@
 """
 return self.list_display
 
+def get_list_display_links(self, request, list_display):
+"""
+Return a sequence containing the fields to be displayed as links
+on the changelist. The list_display parameter is the list of fields
+returned by get_list_display().
+"""
+if self.list_display_links or not list_display:
+return self.list_display_links
+else:
+# Use only the first item in list_display as link
+return list(list_display)[:1]
+
 def construct_change_message(self, request, form, formsets):
 """
 Construct a change message from a changed object.
@@ -1087,22 +1099,20 @@
 
 @csrf_protect_m
 def changelist_view(self, request, extra_context=None):
-"The 'change list' admin view for this model."
+"""
+The 'change list' admin view for this model.
+"""
 from django.contrib.admin.views.main import ERROR_FLAG
 opts = self.model._meta
 app_label = opts.app_label
 if not self.has_change_permission(request, None):
 raise PermissionDenied
 
+list_display = self.get_list_display(request)
+list_display_links = self.get_list_display_links(request, list_display)
+
 # Check actions to see if any are available on this changelist
 actions = self.get_actions(request)
-
-list_display = self.get_list_display(request)
-
-list_display_links = self.list_display_links
-if not self.list_display_links and list_display:
-list_display_links = list(list_display)[:1]
-
 if actions:
 # Add the action checkboxes if there are any actions available.
 list_display = ['action_checkbox'] +  list(list_display)

Modified: django/trunk/docs/ref/contrib/admin/index.txt
===
--- django/trunk/docs/ref/contrib/admin/index.txt   2011-10-26 10:38:12 UTC 
(rev 17036)
+++ django/trunk/docs/ref/contrib/admin/index.txt   2011-10-26 12:19:18 UTC 
(rev 17037)
@@ -1044,6 +1044,16 @@
 displayed on the changelist view as described above in the
 :attr:`ModelAdmin.list_display` section.
 
+.. method:: ModelAdmin.get_list_display_links(self, request, list_display)
+
+.. versionadded:: 1.4
+
+The ``get_list_display_links`` method is given the ``HttpRequest`` and
+the ``list`` or ``tuple`` returned by :meth:`ModelAdmin.get_list_display`.
+It is expected to return a ``list`` or ``tuple`` of field names on the
+changelist that will be linked to the change view, as described in the
+:attr:`ModelAdmin.list_display_links` section.
+
 .. method:: ModelAdmin.get_urls(self)
 
 The ``get_urls`` method on a ``ModelAdmin`` returns the URLs to be used for

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2011-10-26 10:38:12 UTC (rev 17036)
+++ django/trunk/docs/releases/1.4.txt  2011-10-26 12:19:18 UTC (rev 17037)
@@ -124,13 +124,20 @@
 :meth:`~django.contrib.admin.ModelAdmin.get_ordering` for specifying the
 ordering dynamically (e.g. depending on the request) has also been added.
 
-``ModelAdmin.save_related()``
-~
+New ``ModelAdmin`` methods
+~~
 
-A new :meth:`~django.contrib.admin.ModelAdmin.save_related` hook was added to
+A new :meth:`~django.contrib.admin.ModelAdmin.save_related` method was added to
 :mod:`~django.contrib.admin.ModelAdmin` to ease the customization of how
 related objects are saved in the admin.
 
+Two other new methods,
+:meth:`~django.contrib.admin.ModelAdmin.get_list_display` and
+:meth:`~django.contrib.admin.ModelAdmin.get_list_display_links`
+were added to :class:`~django.contrib.admin.ModelAdmin` to enable the dynamic
+customization of fields and links to display on the admin
+change list.
+
 Admin inlines respect user permissions
 

Re: [Django] #16257: contrib:admin dynamic list_display_links support

[Django]

#16257: contrib:admin dynamic list_display_links support
-+-
 Reporter:  graveyboat   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  list_display | Triage Stage:  Accepted
  override dynamic admin |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by julien):

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


Comment:

 In [17037]:
 {{{
 #!CommitTicketReference repository="" revision="17037"
 Fixed #16257 -- Added new `ModelAdmin.get_list_display_links()` method to
 allow for the dynamic display of links on the admin changelist. Thanks to
 graveyboat for the suggestion and initial patch.
 }}}

-- 
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] #17114: Passing a value of int(1) to CheckBox.render doesn't include the value

[Django]

#17114: Passing a value of int(1) to CheckBox.render doesn't include the value
---+
 Reporter:  george@…   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Specifically the check here:
 
https://github.com/django/django/blob/438c41b4faf99435ca28eaa0ccac3ff40a79600c/django/forms/widgets.py#L481

 It's the True part of the list that causes the issue so the equivalent `if
 1 in not (True,): print 'error'` will yield the same result. The effect of
 this is no `value="1"` if you pass that into the CheckBox.render() method.

-- 
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.

[Changeset] r17036 - django/trunk/docs/topics/i18n

[noreply]

Author: aaugustin
Date: 2011-10-26 03:38:12 -0700 (Wed, 26 Oct 2011)
New Revision: 17036

Modified:
   django/trunk/docs/topics/i18n/formatting.txt
Log:
Fixed a reference that was broken at r17026.


Modified: django/trunk/docs/topics/i18n/formatting.txt
===
--- django/trunk/docs/topics/i18n/formatting.txt2011-10-26 09:37:07 UTC 
(rev 17035)
+++ django/trunk/docs/topics/i18n/formatting.txt2011-10-26 10:38:12 UTC 
(rev 17036)
@@ -1,3 +1,5 @@
+.. _format-localization:
+
 ===
 Format localization
 ===
@@ -2,4 +4,2 @@
 
-.. _format-localization:
-
 .. versionadded:: 1.2

-- 
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] #15852: Exception when http.parse_cookie recieves bad cookie

[Django]

#15852: Exception when http.parse_cookie recieves bad cookie
-+-
 Reporter:  Fredrik Stålnacke|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  parse_cookie | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 Until a few months ago, all bugfixes were backported to the stable branch.
 This policy was recently changed in order to reduce the risk of
 regressions and the work load for the core team.

 The new policy is documented here:
 https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions

-- 
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] #15852: Exception when http.parse_cookie recieves bad cookie

[Django]

#15852: Exception when http.parse_cookie recieves bad cookie
-+-
 Reporter:  Fredrik Stålnacke|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  HTTP handling|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  parse_cookie | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by joonas.kuorilehto@…):

 * cc: joonas.kuorilehto@… (added)
 * status:  closed => reopened
 * ui_ux:   => 0
 * resolution:  fixed =>


Comment:

 I believe this bug has not been fixed in 1.3.X branch. As I have
 understood bug fixes like this should land into 1.3.X.

 I was testing with Codenomicon HTTP Test Suite fuzzer and noticed a very
 similar traceback in my server logs. I can reproduce this by sending the
 following minimized HTTP request:

 {{{
 POST / HTTP/1.1
 Host: 10.10.3.83
 Cookie: = = = = =

 {}
 }}}

 This causes a 'NoneType' 'AttributeError' on both Django test server and
 Apache mod_wsgi.

 Traceback with Django 1.3.1:
 {{{
 Traceback (most recent call last):
   File "/var/env/local/lib/python2.7/site-
 packages/django/core/servers/basehttp.py", line 283, in run
 self.result = application(self.environ, self.start_response)
   File "/var/env/local/lib/python2.7/site-
 packages/django/contrib/staticfiles/handlers.py", line 68, in __call__
 return self.application(environ, start_response)
   File "/var/env/local/lib/python2.7/site-
 packages/django/core/handlers/wsgi.py", line 272, in __call__
 response = self.get_response(request)
   File "/var/env/local/lib/python2.7/site-
 packages/django/core/handlers/base.py", line 169, in get_response
 response = self.handle_uncaught_exception(request, resolver,
 sys.exc_info())
   File "/var/env/local/lib/python2.7/site-
 packages/django/core/handlers/base.py", line 218, in
 handle_uncaught_exception
 return callback(request, **param_dict)
   File "/var/env/local/lib/python2.7/site-
 packages/django/utils/decorators.py", line 89, in _wrapped_view
 result = middleware.process_view(request, view_func, args, kwargs)
   File "/var/env/local/lib/python2.7/site-
 packages/django/middleware/csrf.py", line 116, in process_view
 request.META["CSRF_COOKIE"] =
 _sanitize_token(request.COOKIES[settings.CSRF_COOKIE_NAME])
   File "/var/env/local/lib/python2.7/site-
 packages/django/core/handlers/wsgi.py", line 218, in _get_cookies
 self._cookies = http.parse_cookie(self.environ.get('HTTP_COOKIE', ''))
   File "/var/env/local/lib/python2.7/site-
 packages/django/http/__init__.py", line 468, in parse_cookie
 c.load(cookie, ignore_parse_errors=True)
   File "/var/env/local/lib/python2.7/site-
 packages/django/http/__init__.py", line 97, in load
 super(SimpleCookie, self).load(rawdata)
   File "/usr/lib/python2.7/Cookie.py", line 632, in load
 self.__ParseString(rawdata)
   File "/usr/lib/python2.7/Cookie.py", line 665, in __ParseString
 self.__set(K, rval, cval)
   File "/var/env/local/lib/python2.7/site-
 packages/django/http/__init__.py", line 107, in _loose_set
 self._strict_set(key, real_value, coded_value)
   File "/usr/lib/python2.7/Cookie.py", line 585, in __set
 M.set(key, real_value, coded_value)
 AttributeError: 'NoneType' object has no attribute 'set'
 }}}

 I think this problem is related to this ticket. Either the fix is not
 included in the 1.3.X branch or the fix is incomplete.

-- 
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] #17090: Problems with ModelAdmin.get_list_display()

[Django]

#17090: Problems with ModelAdmin.get_list_display()
-+-
 Reporter:  julien   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by julien):

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


Comment:

 In [17035]:
 {{{
 #!CommitTicketReference repository="" revision="17035"
 Fixed #17090 -- Made the API specification for
 `ModelAdmin.get_list_display()` more consistent with that of
 `ModelAdmin.list_display` by separating out the admin action check boxes
 business. This is backwards-incompatible for those who have been using the
 still-unreleased `get_list_display()` method. Thanks to Ramiro Morales for
 the review.
 }}}

-- 
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.

[Changeset] r17035 - in django/trunk: django/contrib/admin tests/regressiontests/admin_changelist tests/regressiontests/admin_registration

[noreply]

Author: julien
Date: 2011-10-26 02:37:07 -0700 (Wed, 26 Oct 2011)
New Revision: 17035

Modified:
   django/trunk/django/contrib/admin/options.py
   django/trunk/tests/regressiontests/admin_changelist/tests.py
   django/trunk/tests/regressiontests/admin_registration/tests.py
Log:
Fixed #17090 -- Made the API specification for `ModelAdmin.get_list_display()` 
more consistent with that of `ModelAdmin.list_display` by separating out the 
admin action check boxes business. This is backwards-incompatible for those who 
have been using the still-unreleased `get_list_display()` method. Thanks to 
Ramiro Morales for the review.

Modified: django/trunk/django/contrib/admin/options.py
===
--- django/trunk/django/contrib/admin/options.py2011-10-26 06:33:13 UTC 
(rev 17034)
+++ django/trunk/django/contrib/admin/options.py2011-10-26 09:37:07 UTC 
(rev 17035)
@@ -342,13 +342,6 @@
 self.model = model
 self.opts = model._meta
 self.admin_site = admin_site
-if 'action_checkbox' not in self.list_display and self.actions is not 
None:
-self.list_display = ['action_checkbox'] +  list(self.list_display)
-if not self.list_display_links:
-for name in self.list_display:
-if name != 'action_checkbox':
-self.list_display_links = [name]
-break
 super(ModelAdmin, self).__init__()
 
 def get_inline_instances(self, request):
@@ -1104,19 +1097,23 @@
 # Check actions to see if any are available on this changelist
 actions = self.get_actions(request)
 
-# Remove action checkboxes if there aren't any actions available.
-list_display = list(self.get_list_display(request))
-if not actions:
-try:
-list_display.remove('action_checkbox')
-except ValueError:
-pass
+list_display = self.get_list_display(request)
 
+list_display_links = self.list_display_links
+if not self.list_display_links and list_display:
+list_display_links = list(list_display)[:1]
+
+if actions:
+# Add the action checkboxes if there are any actions available.
+list_display = ['action_checkbox'] +  list(list_display)
+
 ChangeList = self.get_changelist(request)
 try:
-cl = ChangeList(request, self.model, list_display, 
self.list_display_links,
-self.list_filter, self.date_hierarchy, self.search_fields,
-self.list_select_related, self.list_per_page, 
self.list_max_show_all, self.list_editable, self)
+cl = ChangeList(request, self.model, list_display,
+list_display_links, self.list_filter, self.date_hierarchy,
+self.search_fields, self.list_select_related,
+self.list_per_page, self.list_max_show_all, self.list_editable,
+self)
 except IncorrectLookupParameters:
 # Wacky lookup parameters were given, so redirect to the main
 # changelist page, without parameters, and pass an 'invalid=1'

Modified: django/trunk/tests/regressiontests/admin_changelist/tests.py
===
--- django/trunk/tests/regressiontests/admin_changelist/tests.py
2011-10-26 06:33:13 UTC (rev 17034)
+++ django/trunk/tests/regressiontests/admin_changelist/tests.py
2011-10-26 09:37:07 UTC (rev 17035)
@@ -48,7 +48,7 @@
 template = Template('{% load admin_list %}{% spaceless %}{% 
result_list cl %}{% endspaceless %}')
 context = Context({'cl': cl})
 table_output = template.render(context)
-row_html = 'name(None)' % (new_child.id, new_child.id)
+row_html = 'name(None)' % new_child.id
 self.assertFalse(table_output.find(row_html) == -1,
 'Failed to find expected row element: %s' % table_output)
 
@@ -68,7 +68,7 @@
 template = Template('{% load admin_list %}{% spaceless %}{% 
result_list cl %}{% endspaceless %}')
 context = Context({'cl': cl})
 table_output = template.render(context)
-row_html = 'nameParent 
object' % (new_child.id, new_child.id)
+row_html = 'nameParent object' % new_child.id
 self.assertFalse(table_output.find(row_html) == -1,
 'Failed to find expected row element: %s' % table_output)
 

Modified: django/trunk/tests/regressiontests/admin_registration/tests.py
===
--- django/trunk/tests/regressiontests/admin_registration/tests.py  
2011-10-26 06:33:13 UTC (rev 17034)
+++ django/trunk/tests/regressiontests/admin_registration/tests.py  
2011-10-26 09:37:07 UTC (rev 17035)
@@ -42,7 +42,7 @@
search_fields=["name"], list_display=['__str__'])
 

Re: [Django] #16507: Tests that alter ROOT_URLCONF should set DEBUG_PROPAGATE_EXCEPTION

[Django]

#16507: Tests that alter ROOT_URLCONF should set DEBUG_PROPAGATE_EXCEPTION
--+
 Reporter:  andymckay |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  contrib.messages  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * needs_better_patch:  1 => 0


Comment:

 I found that to reproduce this error, just create
 django/contrib/contenttype/templates/500.html containing {% url foo %} (or
 in any other installed app). I'm not sure I follow all content of Andy's
 latest comment. Anyway, I'm uploading a new patch which should fix the
 500.html template issue.

-- 
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] #17090: Problems with ModelAdmin.get_list_display()

[Django]

#17090: Problems with ModelAdmin.get_list_display()
-+-
 Reporter:  julien   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by ramiro):

 * version:  1.3 => SVN
 * stage:  Unreviewed => Ready for checkin


-- 
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] #16507: Tests that alter ROOT_URLCONF should set DEBUG_PROPAGATE_EXCEPTION

[Django]

#16507: Tests that alter ROOT_URLCONF should set DEBUG_PROPAGATE_EXCEPTION
--+
 Reporter:  andymckay |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  contrib.messages  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 Replying to [comment:15 andymckay]:
 (...)
 > * The wrong handler is called, I was trying to boil this down to a one
 file test case. You can move the assignment to handler500 around it
 doesn't matter. The problem as Carl said is that we don't have a complete
 isolation in the test, we are altering some parts (the urls) but not
 others (the handlers). If you need a more comprehensive example I can
 point you at code in my projects that trigger this.

 I've separated the issue about wrong handler being called in ticket
 #17113. (The test I uploaded in this ticket is currently passing)

-- 
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] #17113: Test that error handlers of custom urls.py are called

[Django]

#17113: Test that error handlers of custom urls.py are called
---+--
 Reporter:  claudep|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by claudep):

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


Comment:

 Added passing test.

-- 
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] #17113: Test that error handlers of custom urls.py are called

[Django]

#17113: Test that error handlers of custom urls.py are called
---+
 Reporter:  claudep|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  SVN
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 In #16507, some comments talk about custom error handlers on custom
 urls.py for tests not being used. This ticket should be used to
 demonstrate this is true/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] #17112: `ManyRelatedManager.add()` doesn't commit to database

[Django]

#17112: `ManyRelatedManager.add()` doesn't commit to database
-+-
 Reporter:  mrmachine|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  add reverse m2m  |  Needs documentation:  0
  relation not committed |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by ptone):

 The changeset that introduces the problem is r16739 (git
 bef16bd6825d05fe48b0feb9b0e933686cc7099b)

-- 
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] #11670: Model fields named 'year', 'month', 'gt', 'lt' etc. get mistaken for lookup types in lookups across relations

[Django]

#11670: Model fields named 'year', 'month', 'gt', 'lt' etc. get mistaken for 
lookup
types in lookups across relations
-+-
 Reporter:  andy@…   |Owner:
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * cc: akaariai (added)


Comment:

 I have an idea, but maybe it is not workable. So, my first idea is to get
 the patch in as is, and revisit this issue later on.

 The maybe-unworkable idea is that the code for traveling the lookups
 translates to this logic (at least I think it does):
 {{{
 while lookup_leads_to_field:
 fields.append(found_field)
 if found_field is related_field:
 related_field = found_field.related_field
 else:
 goto marker1

 if lookups_left:
 if not allow_explicit_fk:
 raise FieldError
 marker1:
 ...
 }}}

 Now, if you get a lookup like `rel_field__non_existing_field` you are
 going to raise `FieldError`. But if you instead do
 `nonrel_field__non_existing_field` you are going to say that nonrel_field
 was found and non_existing_field part wasn't looked. This is because
 nonrel_field will "goto marker1" (via NotRelatedField exception) and skip
 the if lookups_left part.

 So, the only idea I have is to return the rel_field in the
 `rel_field__non_existing_field` lookup case. So, something like this:
 {{{
 # pseudoish...
 for counter, field_name in enumerate(parts):
 try:
 if field_name == 'pk':
 field_name = opts.pk.name
 field_info = opts.get_field_by_name(field_name)
 fields += (field_info,)
 if (counter + 1) < num_parts:
 # If we haven't reached the end of the list of
 # lookups yet, then let's attempt to continue
 # traversing relations.
 related_model = get_model_from_relation(field_info[0])
 opts = related_model._meta
 except FieldDoesNotExist, NotRelatedField:
 break
 if fields:
 # We found at least one field, lets return that
 last_field = fields[-1]
 else:
 # The lookup was totally bogus - it didn't resolve any field from
 # the base model
 raise FieldError
 return parts, fields, last_field
 }}}

 The caller is then responsible to raising `FieldError` if that is the
 appropriate action, doing the explicit_fk logic and checking for existing
 aggregates, etc. I haven't tried this at all, so it is possible this idea
 is bogus, or will make the caller's job more complicate than it needs to
 be.

 As said before: getting the patch in as is could be the thing to do.
 Polish it later on when we know how custom lookups are going to be
 handled. I have a tendency to over-complicate things, and I have a feeling
 I am in over-complicating mode right now... :)

-- 
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] #17112: `ManyRelatedManager.add()` doesn't commit to database

[Django]

#17112: `ManyRelatedManager.add()` doesn't commit to database
-+-
 Reporter:  mrmachine|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  add reverse m2m  |  Needs documentation:  0
  relation not committed |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by julien):

 * severity:  Normal => Release blocker


Comment:

 Marking as blocker since it's a regression.

-- 
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.

[Changeset] r17034 - in django/trunk: django/views/generic tests/regressiontests/views tests/regressiontests/views/tests/generic

[noreply]

Author: julien
Date: 2011-10-25 23:33:13 -0700 (Tue, 25 Oct 2011)
New Revision: 17034

Modified:
   django/trunk/django/views/generic/simple.py
   django/trunk/tests/regressiontests/views/generic_urls.py
   django/trunk/tests/regressiontests/views/tests/generic/simple.py
Log:
Fixed #17111 -- Made the `redirect_to` generic view properly handle query 
strings with percent symbols. Thanks, Chris Adams.

Modified: django/trunk/django/views/generic/simple.py
===
--- django/trunk/django/views/generic/simple.py 2011-10-26 05:33:17 UTC (rev 
17033)
+++ django/trunk/django/views/generic/simple.py 2011-10-26 06:33:13 UTC (rev 
17034)
@@ -49,12 +49,16 @@
 
 """
 args = request.META.get('QUERY_STRING', '')
-if args and query_string and url is not None:
-url = "%s?%s" % (url, args)
 
 if url is not None:
+if kwargs:
+url = url % kwargs
+
+if args and query_string:
+url = "%s?%s" % (url, args)
+
 klass = permanent and HttpResponsePermanentRedirect or 
HttpResponseRedirect
-return klass(url % kwargs)
+return klass(url)
 else:
 logger.warning('Gone: %s' % request.path,
 extra={

Modified: django/trunk/tests/regressiontests/views/generic_urls.py
===
--- django/trunk/tests/regressiontests/views/generic_urls.py2011-10-26 
05:33:17 UTC (rev 17033)
+++ django/trunk/tests/regressiontests/views/generic_urls.py2011-10-26 
06:33:13 UTC (rev 17034)
@@ -115,4 +115,5 @@
 (r'^simple/redirect_to_none/$', 'redirect_to', dict(url=None)),
 (r'^simple/redirect_to_arg/(?P\d+)/$', 'redirect_to', 
dict(url='/simple/target_arg/%(id)s/')),
 (r'^simple/redirect_to_query/$', 'redirect_to', 
dict(url='/simple/target/', query_string=True)),
+(r'^simple/redirect_to_arg_and_query/(?P\d+)/$', 'redirect_to', 
dict(url='/simple/target_arg/%(id)s/', query_string=True)),
 )

Modified: django/trunk/tests/regressiontests/views/tests/generic/simple.py
===
--- django/trunk/tests/regressiontests/views/tests/generic/simple.py
2011-10-26 05:33:17 UTC (rev 17033)
+++ django/trunk/tests/regressiontests/views/tests/generic/simple.py
2011-10-26 06:33:13 UTC (rev 17034)
@@ -48,9 +48,17 @@
 self.assertEqual(response.status_code, 301)
 
self.assertEqual('http://testserver/simple/target/?param1=foo=bar', 
response['Location'])
 
+# Confirm that the contents of the query string are not subject to
+# string interpolation (Refs #17111):
+response = 
self.client.get('/simple/redirect_to_query/?param1=foo=hist%C3%B3ria')
+self.assertEqual(response.status_code, 301)
+
self.assertEqual('http://testserver/simple/target/?param1=foo=hist%C3%B3ria',
 response['Location'])
+response = 
self.client.get('/simple/redirect_to_arg_and_query/99/?param1=foo=hist%C3%B3ria')
+self.assertEqual(response.status_code, 301)
+
self.assertEqual('http://testserver/simple/target_arg/99/?param1=foo=hist%C3%B3ria',
 response['Location'])
+
 def test_redirect_to_when_meta_contains_no_query_string(self):
 "regression for #16705"
 # we can't use self.client.get because it always sets QUERY_STRING
 response = self.client.request(PATH_INFO='/simple/redirect_to/')
 self.assertEqual(response.status_code, 301)
-

-- 
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] #17111: simple redirect_to: handle query strings with percent symbols

[Django]

#17111: simple redirect_to: handle query strings with percent symbols
-+-
 Reporter:  acdha|Owner:  cadams
 Type:  Bug  |   Status:  closed
Component:  Generic views|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  i18n | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by julien):

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


Comment:

 In [17034]:
 {{{
 #!CommitTicketReference repository="" revision="17034"
 Fixed #17111 -- Made the `redirect_to` generic view properly handle query
 strings with percent symbols. Thanks, Chris Adams.
 }}}

-- 
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] #17111: simple redirect_to: handle query strings with percent symbols

[Django]

#17111: simple redirect_to: handle query strings with percent symbols
-+-
 Reporter:  acdha|Owner:  cadams
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  i18n | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by julien):

 * stage:  Unreviewed => Ready for checkin


Comment:

 Good catch, thanks!

-- 
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] #17112: `ManyRelatedManager.add()` doesn't commit to database

[Django]

#17112: `ManyRelatedManager.add()` doesn't commit to database
-+-
 Reporter:  mrmachine|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  add reverse m2m  |  Needs documentation:  0
  relation not committed |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by ptone):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I can confirm that this works across processes in 1.3, but not in trunk

-- 
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] #17112: `ManyRelatedManager.add()` doesn't commit to database

[Django]

#17112: `ManyRelatedManager.add()` doesn't commit to database
-+-
 Reporter:  mrmachine|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Database layer   |Version:  SVN
  (models, ORM)  |   Keywords:  add reverse m2m
 Severity:  Normal   |  relation not committed
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Execute the following in order in two different interactive shells (two
 processes) to trigger the bug. The problem is that the call to `.add()` is
 not committed to the database until a second call to `.create()`. If the
 first process happens to be a management command (for example) and there
 are no subsequent database writes, the relations are never committed. You
 can also confirm this by inspecting the database after executing each
 command.

 {{{
 # shell 1
 >>> from django.contrib.auth.models import *
 >>> u = User.objects.create(username='test')
 >>> u.groups.add(Group.objects.latest('pk'))
 >>> User.objects.get(username='test').groups.all()
 []

 # shell 2
 >>> from django.contrib.auth.models import *
 >>> User.objects.get(username='test').groups.all()
 []

 # shell 1
 >>> u2 = User.objects.create(username='test2')

 # shell 2
 >>> User.objects.get(username='test').groups.all()
 []

 # sql command to check if group has been linked to user
 select * from auth_user_groups where user_id = (select id from auth_user
 where username = 'test');
 }}}

 I've tested this against trunk, and it was confirmed by ptone who also
 confirmed that it is a regression from 1.3. I tested on PostgreSQL and
 SQLite.

 I'm not sure how to create an automated test for this, because the problem
 only exhibits when reading from the database from a different process or
 transaction.

-- 
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.