Re: [Django] #17834: ETag generated from empty content can break http caching

[Django]

#17834: ETag generated from empty content can break http caching
---+
 Reporter:  paulegan   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  1.3
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by paulegan):

 The problem is that the responses are not necessarily identical.  The
 response headers are often as important as the content itself.  The http
 spec is clear about this -
 http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html - and goes on to say
 "in order to be legal, a strong entity tag MUST change whenever the
 associated entity value changes in any way".

 Ideally Django ought to compute the ETag from the entity body and entity
 headers but in practice the body alone is usually sufficient for uniquely
 identifying the entity.  Of course that's not the case when the body is
 empty.  If explicitly coding an ETag for such a response, the values from
 the appropriate entity headers would be included when generating the tag.
 For a function like patch_response_headers, where the addition of the ETag
 header is implicit, I think it is simpler & safer to not compute a tag
 when the body is empty (and the headers dominate).


 I should note that this ticket isn't simple nit-picking but based on a
 real-world issue found in a production environment.

-- 
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] #17842: Typo in uWsgi Docs

[Django]

#17842: Typo in uWsgi Docs
-+-
 Reporter:  mitnk|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   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):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * needs_docs:   => 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] #16433: Missing 'help_text' in admin form when showing the back reference for a OneToOne field.

[Django]

#16433: Missing 'help_text' in admin form when showing the back reference for a
OneToOne field.
---+
 Reporter:  chris@…|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  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 admackin):

 * needs_tests:  1 => 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] #16433: Missing 'help_text' in admin form when showing the back reference for a OneToOne field.

[Django]

#16433: Missing 'help_text' in admin form when showing the back reference for a
OneToOne field.
---+
 Reporter:  chris@…|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by admackin):

 The test case I've supplied here covers the ManyToMany case.

 However, I'm not sure if my fix is treating the symptom instead of the
 cause.

-- 
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] #16433: Missing 'help_text' in admin form when showing the back reference for a OneToOne field.

[Django]

#16433: Missing 'help_text' in admin form when showing the back reference for a
OneToOne field.
---+
 Reporter:  chris@…|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by admackin):

 * cc: admackin+django@… (added)


Comment:

 The same problem occurs for ManyToMany fields (for the backwards
 reference), but only if the `related_name` attribute is used.

-- 
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] #17843: new contrib.admin userstyle template block in base.html

[Django]

#17843: new contrib.admin userstyle template block in base.html
---+--
 Reporter:  miked@…|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.admin  |Version:  SVN
 Severity:  Normal |   Keywords:  user css
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  1
---+--
 It is necessary to add user css styles '''after''' all the admin styles if
 a Django programmer wishes to override admin styles ''without'' editing
 Django css files.

 For example, it is necessary to darken help text to make it readable by
 older users. However, you cannot negotiate with young web designers.
 Hence, if you want to change what the Django designers did or you have
 employed an equally rabid designer of your own with a different opinion,
 there must be a non-violent way forward.

 Trying to use {% block extrastyle %}{% endblock %} with or without {{
 block.super }} in a local base_site.html fails because (it appears) that
 block is used to insert forms.css at a later stage.

 The solution is a new {% block userstyle %}{% endblock %} line positioned
 immediately after {% block extrastyle %}{% endblock %} and ahead of the
 hard-coded 

Re: [Django] #12753: Fixture loading can fails on second syncdb when auto_now_add field is ommitted

[Django]

#12753: Fixture loading can fails on second syncdb when auto_now_add field is
ommitted
-+-
 Reporter:  russellm |Owner:
 Type:  Bug  |  dmedvinsky
Component:  Core |   Status:  new
  (Serialization)|  Version:
 Severity:  Release blocker  |  1.4-beta-1
 Keywords:   |   Resolution:
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by vsafronovich):

 * severity:  Normal => Release blocker


Comment:

 still doesn`t work

-- 
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] #15566: .update queries should affect Date*Field's with auto_now

[Django]

#15566: .update queries should affect Date*Field's with auto_now
---+
 Reporter:  jdunck |Owner:  bberes
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by anonymous):

 > To point out the underlying problem - consider another type of field
 with a pre-save trigger; say, a CharField whose value is a computed
 checksum based on other fields and the timestamp. There's no way this
 could be expressed as a single update statement for multi-row updates.

 Oops, I see now, that points to a far worse inconsistency than what I
 perceived as a consequence of not patching {{{Queryset.update}}}. While I
 can think of at least one terribly Byzantinian way of performing at least
 general pre-save updates, I realize that it's impossible to perform
 something like a computed checksum or anything that would require a Python
 library on an update. Therefore, {{{Queryset.update}}} stands acquitted :(
 but I much appreciate the explanation, Russell.

-- 
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] #17842: Typo in uWsgi Docs

[Django]

#17842: Typo in uWsgi Docs
--+
 Reporter:  mitnk |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 See the patch for detail.

-- 
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] #17841: Clarify authentication backend documentation

[Django]

#17841: Clarify authentication backend documentation
---+--
 Reporter:  auzigog|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  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 auzigog):

 * easy:  0 => 1


Comment:

 Marking as easy pickings

-- 
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] #17841: Clarify authentication backend documentation

[Django]

#17841: Clarify authentication backend documentation
---+--
 Reporter:  auzigog|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  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 auzigog):

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


Comment:

 After getting clarification from SmileyChris and reading the cord code, I
 would propose this as a change:

 NOTE: Once a user has authenticated, Django stores which backend was used
 to authenticate the user in the user's session, and re-uses the same
 backend for the duration of that session whenever access to the currently
 authenticated user is needed. This effectively means that authentication
 sources are cached, [[continue with previous text that was there]]

-- 
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] #17841: Clarify authentication backend documentation

[Django]

#17841: Clarify authentication backend documentation
---+
 Reporter:  auzigog|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The current text for the "NOTE" in
 [https://docs.djangoproject.com/en/dev/topics/auth/#specifying-
 authentication-backends this section of the documentation] reads:

 Once a user has authenticated, Django stores which backend was used to
 authenticate the user in the user's session, and re-uses the same backend
 for subsequent authentication attempts for that user. This effectively
 means that authentication sources are cached, so if you change
 AUTHENTICATION_BACKENDS, you'll need to clear out session data if you need
 to force users to re-authenticate using different methods. A simple way to
 do that is simply to execute Session.objects.all().delete().

 It is pretty awkwardly worded in my opinion. It should be improved.

-- 
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] #15566: .update queries should affect Date*Field's with auto_now

[Django]

#15566: .update queries should affect Date*Field's with auto_now
---+
 Reporter:  jdunck |Owner:  bberes
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by russellm):

 Replying to [comment:15 anonymous]:
 > If {{{Queryset.update}}} is a lower-level SQL construct, then why do we
 have {{{cursor.execute}}} which could achieve the same thing in almost the
 same amount of SLOC and still remain perfectly
 [https://docs.djangoproject.com/en/dev/topics/db/sql/#passing-parameters-
 into-raw injection-proof]?

 Because .update() is database agnostic; raw SQL isn't necessarily cross-
 database compatible. I'd also argue that the syntax for something like a
 simple field value increment is cleaner in the ORM than in raw SQL,
 especially for a codebase that is principally written in ORM syntax.

 > {{{Queryset.update}}} is used widely in most of the apps I've worked on,
 and I'm pretty certain the developers who've added it didn't think of it
 as a low-level tool, but rather just an ORM method for updating multiple
 rows at the same time without having to select each and save each
 separately (ie, a simply efficiency tool in the ORM).

 I can't speak to how the method is perceived in the wild -- that's a
 documentation issue -- but a quick inspection of the implementation of the
 parts involved points pretty quickly to the fact that it can't be
 interpreted as anything *but* a low level method.

 auto_now_add is implemented as a pre-save, per-field modification. The
 fact that the value for this modification is easily evaluated, and the
 value for the field will be the same for all rows in the update is
 convenient, but doesn't solve the underlying issue -- that what we're
 dealing with is a field value that is computed on a per-row basis.

 To point out the underlying problem - consider another type of field with
 a pre-save trigger; say, a CharField whose value is a computed checksum
 based on other fields and the timestamp. There's no way this could be
 expressed as a single update statement for multi-row updates.

 The only way you could reconcile this with auto_now_add being fired on
 .update() is to consider the handling of auto_now_add to be a special case
 because it is a timestamp. I'm not convinced that special case is special
 enough to warrant breaking the rules.

 > To show I'm not just ranting, I'll be willing to write the necessary
 patch and corresponding tests with some guidance on how to handle both the
 aforementioned cases.

 If you can provide a patch that works for pre-save updates *in the general
 case*, then I'm interested. Otherwise, what you're proposing is to make a
 special case of date and time fields, and that's not something I'm
 comfortable with.

 I concur with Luke and Anssi; this is a documentation issue regarding the
 limitations and expectations of a call to .update().

-- 
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] #16220: Add introspection for multicolumn indexes

[Django]

#16220: Add introspection for multicolumn indexes
-+-
 Reporter:  jgelens  |Owner:  jgelens
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:  dceu2011 inspectdb   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by charettes):

 * cc: charette.s@… (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.

Re: [Django] #5805: Specify multicolumn indexes.

[Django]

#5805: Specify multicolumn indexes.
-+-
 Reporter:  Stavros  |Owner:  jgelens
  Korokithakis    |   Status:  assigned
 Type:  New feature  |  Version:  SVN
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  index multicolumn|  Patch needs improvement:  0
  indexes database dceu2011  |UI/UX:  0
Has patch:  1|
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by charettes):

 * cc: charette.s@… (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.

Re: [Django] #17813: Implement an opposite method for Entry.objects.latest

[Django]

#17813: Implement an opposite method for Entry.objects.latest
-+-
 Reporter:  tonnzor  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by russellm):

 * needs_docs:  0 => 1
 * easy:  0 => 1
 * needs_tests:  0 => 1
 * stage:  Design decision needed => Accepted


Comment:

 Consider the case of an event log. Retrieving the most recent event has an
 easy shortcut:
 {{{
 >>> Event.objects.latest('timestamp')
 }}}
 but getting the first event doesn't, so you need to do it the long way:
 {{{
 >>> Event.object.order_by('timestamp')[0]
 }}}
 Retrieving the first event by itself isn't an obvious query, but something
 like "Get me the first event this week" would be.

 For me, this is a fairly obvious piece of symmetry in the ORM API; I've
 wanted it to exist a few times in recent history.

-- 
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] #11150: ImageField validation depend on cStringIO

[Django]

#11150: ImageField validation depend on cStringIO
+-
 Reporter:  vvd |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  SVN
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Ready for checkin
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
Changes (by aaugustin):

 * 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] #11334: Django fails to show non-latin exception messages from PostgreSQL running on FastCGI

[Django]

#11334: Django fails to show non-latin exception messages from PostgreSQL 
running
on FastCGI
--+--
 Reporter:  Loststylus|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.1-beta-1
 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 claudep):

 For better readability, here is the traceback contained in the attached
 html error page:
 {{{
 Traceback (most recent call last):
   File "/var/lib/python-
 support/python2.6/flup/server/fcgi_base.py", line 558, in run
 protocolStatus, appStatus = self.server.handler(self)
   File "/var/lib/python-
 support/python2.6/flup/server/fcgi_base.py", line 1116, in handler
 result = self.application(environ, start_response)
   File "/usr/local/lib/python2.6/dist-
 packages/django/core/handlers/wsgi.py", line 239, in __call__
 response = self.get_response(request)
   File "/usr/local/lib/python2.6/dist-
 packages/django/core/handlers/base.py", line 128, in get_response
 return self.handle_uncaught_exception(request, resolver,
 exc_info)
   File "/usr/local/lib/python2.6/dist-
 packages/django/core/handlers/base.py", line 148, in
 handle_uncaught_exception
 return debug.technical_500_response(request, *exc_info)
   File "/usr/local/lib/python2.6/dist-
 packages/django/views/debug.py", line 39, in technical_500_response
 html = reporter.get_traceback_html()
   File "/usr/local/lib/python2.6/dist-
 packages/django/views/debug.py", line 97, in get_traceback_html
 'exception_value': smart_unicode(self.exc_value,
 errors='replace'),
   File "/usr/local/lib/python2.6/dist-
 packages/django/utils/encoding.py", line 35, in smart_unicode
 return force_unicode(s, encoding, strings_only, errors)
   File "/usr/local/lib/python2.6/dist-
 packages/django/utils/encoding.py", line 70, in force_unicode
 raise DjangoUnicodeDecodeError(s, *e.args)
 DjangoUnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in
 position 0: ordinal not in range(128).
 You passed in
 
ProgrammingError('\xd0\x92\xd1\x8b\xd1\x80\xd0\xb0\xd0\xb6\xd0\xb5\xd0\xbd\xd0\xb8\xd1\x8f
 SELECT DISTINCT ON \xd0\xb4\xd0\xbe\xd0\xbb\xd0\xb6\xd0\xbd\xd1\x8b
 \xd1\x81\xd0\xbe\xd0\xb2\xd0\xbf\xd0\xb0\xd0\xb4\xd0\xb0\xd1\x82\xd1\x8c
 \xd1\x81
 
\xd0\xb8\xd0\xb7\xd0\xbd\xd0\xb0\xd1\x87\xd0\xb0\xd0\xbb\xd1\x8c\xd0\xbd\xd1\x8b\xd0\xbc\xd0\xb8
 
\xd0\xb2\xd1\x8b\xd1\x80\xd0\xb0\xd0\xb6\xd0\xb5\xd0\xbd\xd0\xb8\xd1\x8f\xd0\xbc\xd0\xb8
 ORDER BY\n',) ()
 }}}

-- 
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] #17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled

[Django]

#17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | 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 akaariai):

 OK, another POC patch which has some support for AT TIME ZONE when using
 PostgreSQL.

 As far as I can see SQLite is somewhat easy to fix, PostgreSQL and Oracle
 are fixable if we can translate the Python time zone names to something
 the database understands. It seems the best fix for MySQL is adding the
 offset which has the DST problem.

 I am now done with tinkering with this ticket. I hope the POCs have some
 value for solving this properly after 1.4 has been released. At this point
 my only worry is that the option of requiring that all time zone names
 used must be usable as-is in the database will be lost after 1.4 is
 released.

 Lesson of the day: In POSIX syntax GMT+3 is GMT-3. Of course. As if the
 timezone handling wasn't confusing enough already...

-- 
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] #17840: Overriding form field error messages without argument causes string formatting error.

[Django]

#17840: Overriding form field error messages without argument causes string
formatting error.
+
 Reporter:  klein4  |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 claudep):

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


Comment:

 Now that the 1.4 branch is string-frozen, this will have to wait for 1.5.

-- 
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] #17834: ETag generated from empty content can break http caching

[Django]

#17834: ETag generated from empty content can break http caching
---+
 Reporter:  paulegan   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  1.3
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by claudep):

 Yes, but being empty or not, two identical responses get the same ETag. Is
 it a problem for you?

-- 
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] #17836: Can't assign values for models.DateTimeField(blank=True, null=True)

[Django]

#17836: Can't assign values for models.DateTimeField(blank=True, null=True)
-+-
 Reporter:  cmsimike@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by anonymous):

 ah crap, im sorry.

-- 
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] #17837: Markdown filter "safe" mode is vulnerable to e.g. 'onclick' attributes

[Django]

#17837: Markdown filter "safe" mode is vulnerable to e.g. 'onclick' attributes
-+-
 Reporter:  nomulous |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.markup   |  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:  javascript,  | Triage Stage:  Accepted
  injection, xss, markdown   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by nomulous):

 Sorry, that was stupid of me. I should have done so, but it slipped my
 mind because this vulnerability is already public for the Python-Markdown
 library itself.

-- 
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] #17837: Markdown filter "safe" mode is vulnerable to e.g. 'onclick' attributes

[Django]

#17837: Markdown filter "safe" mode is vulnerable to e.g. 'onclick' attributes
-+-
 Reporter:  nomulous |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.markup   |  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:  javascript,  | Triage Stage:  Accepted
  injection, xss, markdown   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

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


Comment:

 Thanks for the report. In future, please send security-related bugs to
 secur...@djangoproject.com rather than filing them in Trac (the Trac new-
 ticket form makes this same request right above the form.)

-- 
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] #17840: Overriding form field error messages without argument causes string formatting error.

[Django]

#17840: Overriding form field error messages without argument causes string
formatting error.
+
 Reporter:  klein4  |  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
+
 Something like this in a form's __init__ method

 {{{
 self.fields['my_choice_field'].error_messages['invalid_choice'] =
 u'Constant string'
 }}}

 will throw an error because of the following line in
 django/forms/models.py (line 1015):

 {{{
 raise ValidationError(self.error_messages['invalid_choice'] % val)
 }}}

 This method of string formatting forces the user's custom error message to
 contain a '%s' argument, like the default error message does. A
 dictionary-based string formatting operation like

 {{{
 self.error_messages['invalid_choice'] % {'foo': bar}
 }}}

 would fix this problem.

-- 
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] #17839: Ordering by an expression containing annotations

[Django]

#17839: Ordering by an expression containing annotations
--+
 Reporter:  joseph.helfer@…   |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I have found a query use case which seems not to be covered by query() and
 extra().[[BR]]
 I have two annotations: `.annotate(x=Count('foo'))` and
 `.annotate(y=Count('bar'))` and I want to do something like
 `.order_by(F('x')+F('y'))`.[[BR]]
 This (as written) doesn't work, however, because `order_by` only takes
 strings.[[BR]]
 Another solution would be to use `.extra(select={z: 'x + y'})` and then
 `.extra(order_by=['z'])`, but that doesn't work either, because `extra`
 can't refer to annotations.

-- 
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] #17838: prefetch_related fails for GenericForeignKeys when related object id is not a CharField/TextField

[Django]

#17838: prefetch_related fails for GenericForeignKeys when related object id is 
not
a CharField/TextField
--+--
 Reporter:  mkai  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.contenttypes  |Version:  SVN
 Severity:  Release blocker   |   Keywords:  prefetch_related
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+--
 After a ton of debugging, I finally found the reason why my prefetching
 wasn't working. Here's a simple test case with the comments framework:

 {{{
 from django.contrib.comments.models import Comment
 for c in Comment.objects.all().prefetch_related('content_object'):
 ... print c.content_object
 ...

 SELECT * FROM "django_comments" ORDER BY "django_comments"."submit_date"
 ASC  [3.67ms]
 SELECT * FROM "django_content_type" WHERE "django_content_type"."id" = 15
 [1.42ms]
 SELECT * FROM "items_item" WHERE "items_item"."id" IN (709, 79) ORDER BY
 "items_item"."created" DESC  [2.48ms]
 SELECT * FROM "items_item" WHERE "items_item"."id" = 79  [0.79ms]
 SELECT * FROM "items_item" WHERE "items_item"."id" = 709  [1.00ms]
 }}}

 As you can see, it's doing the IN query, but then issues another query for
 each item. The ```object_pk``` field on ```Comment``` is a TextField, but
 the id field on ```Item``` is an IntegerField. This has the effect that
 the cache lookup no longer works. It looks up a tuple like ```(79, )```, but the cache has a tuple like ```(u'79', )``` set.

 A quick fix is to simply convert the value to an int in
 contrib.contenttypes.generic.py:

 {{{
 def gfk_key(obj):
 ct_id = getattr(obj, ct_attname)
 if ct_id is None:
 return None
 else:
 # QUICK FIX: convert to int to fix cache lookups
 # return (getattr(obj, self.fk_field),
 return (int(getattr(obj, self.fk_field)),
 self.get_content_type(id=ct_id,
   using=obj._state.db).model_class())
 }}}

 That is probably a very naive solution. Maybe one should check the type of
 the related object's field and then (safely) convert the value based on
 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] #17836: Can't assign values for models.DateTimeField(blank=True, null=True)

[Django]

#17836: Can't assign values for models.DateTimeField(blank=True, null=True)
-+-
 Reporter:  cmsimike@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by carljm):

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


Comment:

 Closing as needsinfo pending reproduction code sans typo that still
 displays the problem.

-- 
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] #17836: Can't assign values for models.DateTimeField(blank=True, null=True)

[Django]

#17836: Can't assign values for models.DateTimeField(blank=True, null=True)
-+-
 Reporter:  cmsimike@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by carljm):

 Is the ``answrerd_on`` typo copied from your actual code? Because that
 would fully explain the behavior you are seeing.

-- 
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] #17836: Can't assign values for models.DateTimeField(blank=True, null=True)

[Django]

#17836: Can't assign values for models.DateTimeField(blank=True, null=True)
-+-
 Reporter:  cmsimike@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by anonymous):

 Using MySQL. I know that mysql doesn't support timezone aware datetimes
 but does it make sense for the model to not accept values?

 {{{#!python
 class MyModel(models.Model):
 #various other fields
 answered_on = models.DateTimeField(blank=True, null=True)

 modelToChange = MyModel.objects.get(pk=PK)
 form = MyModelForm(request.POST)
  if form.is_valid():
  value = form.cleaned_data['value']
  modelToChange.answer = answer
  modelToChange.answrerd_on = timezone.now() # or using datetime.now(),
 same problem
  print modelToChange.answered_on # this prints None regardless of
 previous method
  modelToChange.save() # generates a answered_on = NULL in the sql

 }}}

-- 
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] #17836: Can't assign values for models.DateTimeField(blank=True, null=True)

[Django]

#17836: Can't assign values for models.DateTimeField(blank=True, null=True)
-+-
 Reporter:  cmsimike@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by apollo13):

 I can't reproduce this on Django 1.4 RC 1 using sqlite and pg. Please tell
 us which database you use and provide some code we can use to reproduce.

-- 
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] #17837: Markdown filter "safe" mode is vulnerable to e.g. 'onclick' attributes

[Django]

#17837: Markdown filter "safe" mode is vulnerable to e.g. 'onclick' attributes
-+-
 Reporter:   |  Owner:  nobody
  nomulous   | Status:  new
 Type:  Bug  |Version:  SVN
Component:   |   Keywords:  javascript, injection, xss,
  contrib.markup |  markdown
 Severity:  Release  |  Has patch:  0
  blocker|  UI/UX:  0
 Triage Stage:   |
  Unreviewed |
Easy pickings:  0|
-+-
 The Python markdown library used by Django has syntax like this, which is
 obviously a JS injection vulnerability:


 {{{
 {@onclick=alert(1)}paragraph
 }}}

 Somehow, Python-markdown's safe mode still allows this, and thus, Django
 does too. Since this "safe"  mode is what developers are expected to use
 to render user input, this is a pretty significant security issue.

 I have opened a ticket for Python-markdown here: https://github.com/waylan
 /Python-Markdown/issues/82

 Newer versions of Python-markdown have an "enable_attributes" argument
 that you can pass, while older versions have a constant
 "ENABLE_ATTRIBUTES" that is declared at the module level. I'm not sure
 what the best way to fix this in Django directly would be.

-- 
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] #17834: ETag generated from empty content can break http caching

[Django]

#17834: ETag generated from empty content can break http caching
---+
 Reporter:  paulegan   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  1.3
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by paulegan):

 True, internally it's currently used only in UpdateCacheMiddleware, but
 even there a response with status 200 can still have an empty body.

-- 
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] #15566: .update queries should affect Date*Field's with auto_now

[Django]

#15566: .update queries should affect Date*Field's with auto_now
---+
 Reporter:  jdunck |Owner:  bberes
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by anonymous):

 If {{{Queryset.update}}} is a lower-level SQL construct, then why do we
 have {{{cursor.execute}}} which could achieve the same thing in almost the
 same amount of SLOC and still remain perfectly
 [https://docs.djangoproject.com/en/dev/topics/db/sql/#passing-parameters-
 into-raw injection-proof]?

 {{{Queryset.update}}} is used widely in most of the apps I've worked on,
 and I'm pretty certain the developers who've added it didn't think of it
 as a low-level tool, but rather just an ORM method for updating multiple
 rows at the same time without having to select each and save each
 separately (ie, a simply efficiency tool in the ORM).

 Allowing {{{Queryset.update}}} to cause database {{{max_length}}} errors
 and break the {{{auto_now}}} docs is a bug and serves no helpful purpose,
 because '''A)''' If I want to demonstrate a Postgres error, there is
 {{{cursor.execute}}}, and '''B)''' If a user wants to override the
 documented {{{auto_now}}} functionality during a {{{Queryset.update}}},
 they can simply provide an override value, and '''C)''' If a user wants to
 update specific rows while not leaving any evidence behind, they can
 simply use {{{cursor.execute}}} to update only the rows they want to
 update. The use-case that Luke suggested is simply an exploit of the bug
 and is probably a rarity in most code-bases because since {{{auto_now}}}
 also implies {{{editable=False}}}, it sort-of also implies that
 {{{auto_now}}} is more of a back-end feature.

 We don't have a documented {{{Queryset.insert}}} method for performing raw
 {{{INSERT}}} queries, or, for that matter, any documented {{{Queryset}}}
 methods which are data-altering, low-level SQL constructs. In fact, the
 only documented methods that are low-level seem to provide all the
 functionality necessary. {{{Queryset.raw}}} and {{{cursor.execute}}}
 provide the ability to perform low level SQL queries against the database
 to both retrieve and modify data.

 I think that creating an inconsistency in {{{Queryset.update}}} with
 support predicated only on the potential for previous exploitation of an
 undocumented bug seems like a really bad idea.

 To show I'm not just ranting, I'll be willing to write the necessary patch
 and corresponding tests with some guidance on how to handle both the
 aforementioned cases.

-- 
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] #17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled

[Django]

#17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | 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 akaariai):

 One more possibility: just require that every time zone used is usable as
 database time zone as is. Current time zones follow this rule (I mean the
 configured settings' time zone). It might be hard to require this one
 after 1.4 is released, and it might be also hard for those who do not use
 pytz.

-- 
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] #17834: ETag generated from empty content can break http caching

[Django]

#17834: ETag generated from empty content can break http caching
---+
 Reporter:  paulegan   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  1.3
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by claudep):

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


Comment:

 I digged a little more in the code. In Django code, patch_response_headers
 is never called for responses which code is not in the 200 range. If you
 want to call this function from your own code, I think it's your
 responsability to not call it on redirect responses.

-- 
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] #17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled

[Django]

#17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | 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 akaariai):

 * cc: anssi.kaariainen@… (added)


Comment:

 I have a "POC" version ready. It just adds some timedeltas to the values
 where needed. In the database everything is still done at time zone UTC,
 we just add the offsets as Python reports them.

 The biggest problem with this approach is DST handling. We use the offset
 as it is _now_, however the database date might have a different offset
 (offset now is 3 hours, in the summer 2 hours). So, we have an error of
 one hour for summer dates.

 This means that this issue is really hard to fix: if we use current
 offsets, we will make an error of one hour across DST (not to mention
 actual time zone changes in South America...). That is not correct enough
 to call this fixed. We could use "AT TIME ZONE 'tz name'" where available,
 but that has just one little problem: we don't know the time zone name.

 So, I really can't see an easy fix for this. We could invent a mapping
 mechanism for the Python time zone name -> DB time zone name. That isn't
 easy either, I believe PostgreSQL can have different time zone names on
 Windows and Linux. So, the user should actually define his converter
 dictionary in the settings.py, for each database. Or we could have our own
 mappings: time zone name -> list of time zones to try. On first connect
 inspect what time zones are available. Endless source of bugs, but on the
 other hand that isn't much different from supporting the different
 locales. This is the best approach available.

 After all this MySQL would still be broken. I don't believe there is
 anything Django can do to make time zones work correctly together with
 dates queries on that database. I really wonder if it is a good idea to
 encourage people to use USE_TZ with MySQL. The setup is broken, and as far
 as I see, will be broken.

 The attached patch is, as said, just a proof of concept, or more correctly
 a poor of the concept not working.

-- 
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] #17836: Can't assign values for models.DateTimeField(blank=True, null=True) (was: i should have previewed how the code would look)

[Django]

#17836: Can't assign values for models.DateTimeField(blank=True, null=True)
-+-
 Reporter:  cmsimike@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  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] #8408: add a new meta option: don't do count(*) in admin

[Django]

#8408: add a new meta option: don't do count(*) in admin
---+
 Reporter:  lidaobing  |Owner:  nobody
 Type:  New feature|   Status:  reopened
Component:  contrib.admin  |  Version:  SVN
 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
---+
Changes (by adamnelson):

 * stage:  Design decision needed => Accepted


Comment:

 Switching back to 'accepted' - I think the switch to DDN was in error and
 simply sent this back into the icebox even though it was previously
 accepted by a core dev and has a draft 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.

Re: [Django] #17836: i should have previewed how the code would look (was: Can't assign values for models.DateTimeField(blank=True, null=True))

[Django]

#17836: i should have previewed how the code would look
-+-
 Reporter:  cmsimike@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by cmsimike@…):

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


Comment:

 Sorry, I should have previewed i guess.

 model.asked_on = datetime.now() (or timezone.now()) [[BR]]
 print model.asked_on # None is printed to the console [[BR]]
 model.save() #sql logs show a null value being put into the update
 query.[[BR]]

-- 
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] #17836: Can't assign values for models.DateTimeField(blank=True, null=True)

[Django]

#17836: Can't assign values for models.DateTimeField(blank=True, null=True)
--+
 Reporter:  cmsimike@…|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4-beta-1
 Severity:  Release blocker   |   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Using Django 1.4b1 with timezone aware datetime objects

 It seems to be the case that I cannot assign a value to a model's field
 and persist it to the database. The field is defined as
 asked_on = models.DateTimeField(blank=True, null=True)
 and I've tried datetime.now and timezone.now()

 What happens is this:
 model.asked_on = datetime.now() (or timezone.now())
 print model.asked_on  # None is printed to the console
 model.save()  #sql logs show a null value being put into the update query.

-- 
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] #17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled

[Django]

#17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | 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 kmike):

 * cc: kmike84@… (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] r17672 - django/trunk

[noreply]

Author: ubernostrum
Date: 2012-03-05 09:30:27 -0800 (Mon, 05 Mar 2012)
New Revision: 17672

Modified:
   django/trunk/setup.py
Log:
Correct the download URL.

Modified: django/trunk/setup.py
===
--- django/trunk/setup.py   2012-03-05 17:22:23 UTC (rev 17671)
+++ django/trunk/setup.py   2012-03-05 17:30:27 UTC (rev 17672)
@@ -75,7 +75,7 @@
 author = 'Django Software Foundation',
 author_email = 'foundat...@djangoproject.com',
 description = 'A high-level Python Web framework that encourages rapid 
development and clean, pragmatic design.',
-download_url = 
'https://www.djangoproject.com/m/releases/1.4/Django-1.4rc1.tar.gz',
+download_url = 
'https://www.djangoproject.com/m/releases/1.4/Django-1.4c1.tar.gz',
 packages = packages,
 cmdclass = cmdclasses,
 data_files = data_files,

-- 
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] r17671 - in django/trunk: . django docs

[noreply]

Author: ubernostrum
Date: 2012-03-05 09:22:23 -0800 (Mon, 05 Mar 2012)
New Revision: 17671

Modified:
   django/trunk/django/__init__.py
   django/trunk/docs/conf.py
   django/trunk/setup.py
Log:
Bump for 1.4 RC 1.

Modified: django/trunk/django/__init__.py
===
--- django/trunk/django/__init__.py 2012-03-05 12:27:19 UTC (rev 17670)
+++ django/trunk/django/__init__.py 2012-03-05 17:22:23 UTC (rev 17671)
@@ -1,4 +1,4 @@
-VERSION = (1, 4, 0, 'beta', 1)
+VERSION = (1, 4, 0, 'rc', 1)
 
 def get_version(version=None):
 """Derives a PEP386-compliant version number from VERSION."""

Modified: django/trunk/docs/conf.py
===
--- django/trunk/docs/conf.py   2012-03-05 12:27:19 UTC (rev 17670)
+++ django/trunk/docs/conf.py   2012-03-05 17:22:23 UTC (rev 17671)
@@ -52,7 +52,7 @@
 # The short X.Y version.
 version = '1.4'
 # The full version, including alpha/beta/rc tags.
-release = '1.4 beta 1'
+release = '1.4 rc 1'
 # The next version to be released
 django_next_version = '1.4'
 

Modified: django/trunk/setup.py
===
--- django/trunk/setup.py   2012-03-05 12:27:19 UTC (rev 17670)
+++ django/trunk/setup.py   2012-03-05 17:22:23 UTC (rev 17671)
@@ -75,7 +75,7 @@
 author = 'Django Software Foundation',
 author_email = 'foundat...@djangoproject.com',
 description = 'A high-level Python Web framework that encourages rapid 
development and clean, pragmatic design.',
-download_url = 
'https://www.djangoproject.com/m/releases/1.4/Django-1.4b1.tar.gz',
+download_url = 
'https://www.djangoproject.com/m/releases/1.4/Django-1.4rc1.tar.gz',
 packages = packages,
 cmdclass = cmdclasses,
 data_files = data_files,

-- 
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] #17835: Refactor the release notes before 1.4 final

[Django]

#17835: Refactor the release notes before 1.4 final
-+-
   Reporter:  aaugustin  |  Owner:  jacobkm
   Type: | Status:  new
  Cleanup/optimization   |Version:  1.4-beta-1
  Component: |   Keywords:
  Documentation  |  Has patch:  0
   Severity:  Release|Needs tests:  0
  blocker|  Easy pickings:  0
   Triage Stage:  Accepted   |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 {{{
  Help me remember I want to refactor the release notes before the
 final.
  (We should mention timezones first since that's the one that is
 going to be the biggest change for most people.)
 }}}

-- 
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] #17834: ETag generated from empty content can break http caching

[Django]

#17834: ETag generated from empty content can break http caching
---+
 Reporter:  paulegan   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by claudep):

 * needs_docs:   => 0
 * has_patch:  0 => 1
 * needs_better_patch:   => 0
 * needs_tests:   => 1
 * 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] #17737: collectstatic copies wrong files to STATIC_ROOT

[Django]

#17737: collectstatic copies wrong files to STATIC_ROOT
-+
 Reporter:  pigletto |Owner:  jezdez
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.3
 Severity:  Normal   |   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 slinkp):

 Works for my variant, thanks. Jezdez, will this get backported to the
 standalone django-staticfiles? 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.

[Django] #17834: ETag generated from empty content can break http caching

[Django]

#17834: ETag generated from empty content can break http caching
---+
 Reporter:  paulegan   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  HTTP handling  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The [source:/django/trunk/django/utils/cache.py?rev=17286#L100
 patch_response_headers] function will set an ETag header using an md5 hash
 of the response content.  Many responses like redirects can have an empty
 body and this results in the same ETag for each such response.  The
 response headers may vary but an intermediate cache can serve an incorrect
 response because the ETag is not unique.

 A simple solution is to not set ETag if the content is empty - see
 attached patch.

 {{{#!python
 >>> from django.http import HttpResponseRedirect
 >>> from django.utils.cache import patch_response_headers
 >>> r1 = HttpResponseRedirect('/u1')
 >>> patch_response_headers(r1)
 >>> r2 = HttpResponseRedirect('/u2')
 >>> patch_response_headers(r2)
 >>> r1['ETag'] == r2['ETag']
 True
 }}}

-- 
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] #17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled

[Django]

#17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | 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 akaariai):

 Yes, I can see this is very complex to fix in a way that actually works
 even closely the same on every backend.

 It might be possible to just add the offset into the datetime, then do the
 conversion to the date. This all in the DB. This could actually work, as
 DST is usually around 3-4 o'clock AM, so there would not be error in date
 conversions.

 I am tempted to give this a try...

-- 
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] #17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled

[Django]

#17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | 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 aaugustin):

 I mean "we're going to take some flak".

 I plan to fix this eventually.

-- 
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] #17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled

[Django]

#17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | 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 akaariai):

 You mean contentious as in "wontfix, breaks existing programs"? In my
 opinion that would be bad. It is pretty clear to me that the current
 behavior is broken. The dates should be in the currently active time zone.

 I think I know how to fix this:
  - aggregates can return parameters (useful for other features, too
 "conditional aggregates" for example). This is returning parameters from
 the cols part of the query.
  - other needed parts already can return parameters (where conditions
 etc).
  - use the AT TIME ZONE trick above, or if that is not available, use just
 " + timedelta offset minutes".
  - hope that everything works.
 The problem is there is a _lot_ of places to fix. In addition, the ORM is
 a little complex to work with sometimes. I just can't see getting this
 into 1.4 in time.

 Any way to mark this as a known bug which _will_ be fixed in the future?
 The other way forward is introducing "at_timezone" argument for the
 operations, but how to do that for `__date` for example?

-- 
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] #17828: Admin should not handle IncorrectLookupParameters if settings.DEBUG is set

[Django]

#17828: Admin should not handle IncorrectLookupParameters if settings.DEBUG is 
set
-+-
 Reporter:  Glenn Washburn   |Owner:  nobody
  |   Status:  new
 Type:  Uncategorized|  Version:
Component:  contrib.admin|  1.4-beta-1
 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 aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 I got a totally absurd error page while working on #17830; I suppose it's
 because of this 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] r17670 - in django/trunk: django/contrib/admin tests/regressiontests/admin_filters

[noreply]

Author: aaugustin
Date: 2012-03-05 04:27:19 -0800 (Mon, 05 Mar 2012)
New Revision: 17670

Modified:
   django/trunk/django/contrib/admin/filters.py
   django/trunk/tests/regressiontests/admin_filters/tests.py
Log:
Fixed #17830 -- Modified list_filter on DateTimeFields to account for the new 
time zone support. Thanks Glenn Washburn for the report and Jannis Leidel for 
the review.


Modified: django/trunk/django/contrib/admin/filters.py
===
--- django/trunk/django/contrib/admin/filters.py2012-03-05 10:30:00 UTC 
(rev 17669)
+++ django/trunk/django/contrib/admin/filters.py2012-03-05 12:27:19 UTC 
(rev 17670)
@@ -11,6 +11,7 @@
 from django.core.exceptions import ImproperlyConfigured
 from django.utils.encoding import smart_unicode
 from django.utils.translation import ugettext_lazy as _
+from django.utils import timezone
 
 from django.contrib.admin.util import (get_model_from_relation,
 reverse_field_path, get_limit_choices_to_from_path, prepare_lookup_value)
@@ -282,44 +283,49 @@
 self.field_generic = '%s__' % field_path
 self.date_params = dict([(k, v) for k, v in params.items()
  if k.startswith(self.field_generic)])
-today = datetime.date.today()
-one_week_ago = today - datetime.timedelta(days=7)
-today_str = str(today)
+
+now = timezone.now()
+# When time zone support is enabled, convert "now" to the user's time
+# zone so Django's definition of "Today" matches what the user expects.
+if now.tzinfo is not None:
+current_tz = timezone.get_current_timezone()
+now = now.astimezone(current_tz)
+if hasattr(current_tz, 'normalize'):
+# available for pytz time zones
+now = current_tz.normalize(now)
+
 if isinstance(field, models.DateTimeField):
-today_str += ' 23:59:59'
-self.lookup_kwarg_year = '%s__year' % field_path
-self.lookup_kwarg_month = '%s__month' % field_path
-self.lookup_kwarg_day = '%s__day' % field_path
-self.lookup_kwarg_past_7_days_gte = '%s__gte' % field_path
-self.lookup_kwarg_past_7_days_lte = '%s__lte' % field_path
+today = now.replace(hour=0, minute=0, second=0, microsecond=0)
+else:   # field is a models.DateField
+today = now.date()
+tomorrow = today + datetime.timedelta(days=1)
+
+self.lookup_kwarg_since = '%s__gte' % field_path
+self.lookup_kwarg_until = '%s__lt' % field_path
 self.links = (
 (_('Any date'), {}),
 (_('Today'), {
-self.lookup_kwarg_year: str(today.year),
-self.lookup_kwarg_month: str(today.month),
-self.lookup_kwarg_day: str(today.day),
+self.lookup_kwarg_since: str(today),
+self.lookup_kwarg_until: str(tomorrow),
 }),
 (_('Past 7 days'), {
-self.lookup_kwarg_past_7_days_gte: str(one_week_ago),
-self.lookup_kwarg_past_7_days_lte: today_str,
+self.lookup_kwarg_since: str(today - 
datetime.timedelta(days=7)),
+self.lookup_kwarg_until: str(tomorrow),
 }),
 (_('This month'), {
-self.lookup_kwarg_year: str(today.year),
-self.lookup_kwarg_month: str(today.month),
+self.lookup_kwarg_since: str(today.replace(day=1)),
+self.lookup_kwarg_until: str(tomorrow),
 }),
 (_('This year'), {
-self.lookup_kwarg_year: str(today.year),
+self.lookup_kwarg_since: str(today.replace(month=1, day=1)),
+self.lookup_kwarg_until: str(tomorrow),
 }),
 )
 super(DateFieldListFilter, self).__init__(
 field, request, params, model, model_admin, field_path)
 
 def expected_parameters(self):
-return [
-self.lookup_kwarg_year, self.lookup_kwarg_month,
-self.lookup_kwarg_day, self.lookup_kwarg_past_7_days_gte,
-self.lookup_kwarg_past_7_days_lte
-]
+return [self.lookup_kwarg_since, self.lookup_kwarg_until]
 
 def choices(self, cl):
 for title, param_dict in self.links:

Modified: django/trunk/tests/regressiontests/admin_filters/tests.py
===
--- django/trunk/tests/regressiontests/admin_filters/tests.py   2012-03-05 
10:30:00 UTC (rev 17669)
+++ django/trunk/tests/regressiontests/admin_filters/tests.py   2012-03-05 
12:27:19 UTC (rev 17670)
@@ -10,6 +10,7 @@
 from django.contrib.auth.models import User
 from django.core.exceptions import ImproperlyConfigured
 from django.test import TestCase, RequestFactory
+from django.test.utils import override_settings
 from django.utils.encoding import force_unicode
 
 

Re: [Django] #17830: DateFieldListFilter "Past 7 days" filter uses naive datetime when USE_TZ is set.

[Django]

#17830: DateFieldListFilter "Past 7 days" filter uses naive datetime when 
USE_TZ is
set.
-+-
 Reporter:  Glenn Washburn   |Owner:  aaugustin
  |   Status:  closed
 Type:  Bug  |  Version:
Component:  contrib.admin|  1.4-beta-1
 Severity:  Release blocker  |   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 aaugustin):

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


Comment:

 In [17670]:
 {{{
 #!CommitTicketReference repository="" revision="17670"
 Fixed #17830 -- Modified list_filter on DateTimeFields to account for the
 new time zone support. Thanks Glenn Washburn for the report and Jannis
 Leidel 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.

Re: [Django] #17830: DateFieldListFilter "Past 7 days" filter uses naive datetime when USE_TZ is set.

[Django]

#17830: DateFieldListFilter "Past 7 days" filter uses naive datetime when 
USE_TZ is
set.
-+-
 Reporter:  Glenn Washburn   |Owner:  aaugustin
  |   Status:  new
 Type:  Bug  |  Version:
Component:  contrib.admin|  1.4-beta-1
 Severity:  Release blocker  |   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 jezdez):

 * 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] #17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled

[Django]

#17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | 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 aaugustin):

 For the record, I'm afraid this will quickly become contentious once 1.4
 is out...

-- 
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] #17830: DateFieldListFilter "Past 7 days" filter uses naive datetime when USE_TZ is set.

[Django]

#17830: DateFieldListFilter "Past 7 days" filter uses naive datetime when 
USE_TZ is
set.
-+-
 Reporter:  Glenn Washburn   |Owner:  aaugustin
  |   Status:  new
 Type:  Bug  |  Version:
Component:  contrib.admin|  1.4-beta-1
 Severity:  Release blocker  |   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 aaugustin):

 * has_patch:  0 => 1


Comment:

 To fix this problem, I had to modify `DateFieldListFilter` to avoid the
 `__year`, `__month` and `__day` lookups -- because of #17260, these don't
 work well when time zone support is enabled.

-- 
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] #17831: Admin's date list filter's "This month/year" and "Today" are incorrect when USE_TZ is set (with the postgres backend).

[Django]

#17831: Admin's date list filter's "This month/year" and "Today" are incorrect 
when
USE_TZ is set (with the postgres backend).
-+-
 Reporter:  Glenn Washburn   |Owner:  nobody
  |   Status:  closed
 Type:  Bug  |  Version:
Component:  contrib.admin|  1.4-beta-1
 Severity:  Release blocker  |   Resolution:  duplicate
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by aaugustin):

 In fact, the patch I prepared for #17830 fixes this too.

-- 
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] r17669 - django/trunk/tests/regressiontests/localflavor/fr

[noreply]

Author: aaugustin
Date: 2012-03-05 02:30:00 -0800 (Mon, 05 Mar 2012)
New Revision: 17669

Modified:
   django/trunk/tests/regressiontests/localflavor/fr/tests.py
Log:
Added change forgotten in r17668.


Modified: django/trunk/tests/regressiontests/localflavor/fr/tests.py
===
--- django/trunk/tests/regressiontests/localflavor/fr/tests.py  2012-03-05 
09:42:31 UTC (rev 17668)
+++ django/trunk/tests/regressiontests/localflavor/fr/tests.py  2012-03-05 
10:30:00 UTC (rev 17669)
@@ -55,6 +55,8 @@
 17 - Charente-Maritime
 18 - Cher
 19 - Corrèze
+2A - Corse-du-Sud
+2B - Haute-Corse
 21 - Côte-dOr
 22 - Côtes-dArmor
 23 - Creuse
@@ -62,10 +64,8 @@
 25 - Doubs
 26 - Drôme
 27 - Eure
-28 - Eure-et-Loire
+28 - Eure-et-Loir
 29 - Finistère
-2A - Corse-du-Sud
-2B - Haute-Corse
 30 - Gard
 31 - Haute-Garonne
 32 - Gers
@@ -111,7 +111,7 @@
 72 - Sarthe
 73 - Savoie
 74 - Haute-Savoie
-75 - Paris
+75 - Paris
 76 - Seine-Maritime
 77 - Seine-et-Marne
 78 - Yvelines
@@ -138,9 +138,12 @@
 974 - La Réunion
 975 - Saint-Pierre-et-Miquelon
 976 - Mayotte
-984 - Terres Australes et Antarctiques
+977 - Saint-Barthélemy
+978 - Saint-Martin
+984 - Terres australes et antarctiques françaises
 986 - Wallis et Futuna
-987 - Polynésie Française
+987 - Polynésie française
 988 - Nouvelle-Calédonie
+989 - Île de Clipperton
 '''
-self.assertHTMLEqual(f.render('dep', 'Paris'), out)
+self.assertHTMLEqual(f.render('dep', '75'), out)

-- 
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] #17833: bad translation in django.contrib.localflavor.fr.fr_departement

[Django]

#17833: bad translation in django.contrib.localflavor.fr.fr_departement
-+-
 Reporter:  anonymous|Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  contrib.localflavor  |  Version:
 Severity:  Normal   |  1.4-beta-1
 Keywords:   |   Resolution:  fixed
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 In [17668]:
 {{{
 #!CommitTicketReference repository="" revision="17668"
 Updated French departments list: fixed #17833 (typo in 28), moved Corsica
 (2A/2B) to the expected position, took into account recent changes to the
 overseas territories, and proof-read the 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.

[Changeset] r17668 - django/trunk/django/contrib/localflavor/fr

[noreply]

Author: aaugustin
Date: 2012-03-05 01:42:31 -0800 (Mon, 05 Mar 2012)
New Revision: 17668

Modified:
   django/trunk/django/contrib/localflavor/fr/fr_department.py
Log:
Updated French departments list: fixed #17833 (typo in 28), moved Corsica 
(2A/2B) to the expected position, took into account recent changes to the 
overseas territories, and proof-read the list.


Modified: django/trunk/django/contrib/localflavor/fr/fr_department.py
===
--- django/trunk/django/contrib/localflavor/fr/fr_department.py 2012-03-05 
08:47:22 UTC (rev 17667)
+++ django/trunk/django/contrib/localflavor/fr/fr_department.py 2012-03-05 
09:42:31 UTC (rev 17668)
@@ -1,6 +1,9 @@
 # -*- coding: utf-8 -*-
 
+# See the "Code officiel géographique" on the INSEE website .
+
 DEPARTMENT_CHOICES = (
+# Metropolitan departments
 ('01', u'01 - Ain'),
 ('02', u'02 - Aisne'),
 ('03', u'03 - Allier'),
@@ -20,6 +23,8 @@
 ('17', u'17 - Charente-Maritime'),
 ('18', u'18 - Cher'),
 ('19', u'19 - Corrèze'),
+('2A', u'2A - Corse-du-Sud'),
+('2B', u'2B - Haute-Corse'),
 ('21', u'21 - Côte-d\'Or'),
 ('22', u'22 - Côtes-d\'Armor'),
 ('23', u'23 - Creuse'),
@@ -27,10 +32,8 @@
 ('25', u'25 - Doubs'),
 ('26', u'26 - Drôme'),
 ('27', u'27 - Eure'),
-('28', u'28 - Eure-et-Loire'),
+('28', u'28 - Eure-et-Loir'),
 ('29', u'29 - Finistère'),
-('2A', u'2A - Corse-du-Sud'),
-('2B', u'2B - Haute-Corse'),
 ('30', u'30 - Gard'),
 ('31', u'31 - Haute-Garonne'),
 ('32', u'32 - Gers'),
@@ -97,14 +100,18 @@
 ('93', u'93 - Seine-Saint-Denis'),
 ('94', u'94 - Val-de-Marne'),
 ('95', u'95 - Val-d\'Oise'),
+# Overseas departments, communities, and other territories
 ('971', u'971 - Guadeloupe'),
 ('972', u'972 - Martinique'),
 ('973', u'973 - Guyane'),
 ('974', u'974 - La Réunion'),
 ('975', u'975 - Saint-Pierre-et-Miquelon'),
 ('976', u'976 - Mayotte'),
-('984', u'984 - Terres Australes et Antarctiques'),
+('977', u'977 - Saint-Barthélemy'),
+('978', u'978 - Saint-Martin'),
+('984', u'984 - Terres australes et antarctiques françaises'),
 ('986', u'986 - Wallis et Futuna'),
-('987', u'987 - Polynésie Française'),
+('987', u'987 - Polynésie française'),
 ('988', u'988 - Nouvelle-Calédonie'),
+('989', u'989 - Île de Clipperton'),
 )

-- 
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] #5423: "dumpdata" should stream output one row at a time

[Django]

#5423: "dumpdata" should stream output one row at a time
-+-
 Reporter:  adrian   |Owner:  ramiro
 Type:  New feature  |   Status:  assigned
Component:  Core |  Version:  SVN
  (Serialization)|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  dumpdata fixtures|  Needs documentation:  0
  memory |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by rm_):

 As promised on IRC to cramm (xrmx here) here's some results with / without
 latest lukeplant's patch on top of django 1.4b1.
 First my environment is a bit peculiar, i have a fixed limit of address
 space (the sum of all kind of memory) a process can use, in this case
 96MB. So if my process consume more than 96MB it gets killed.

 Before patch:
 {{{
 ../venv14/bin/python manage.py dumpdata store > store.json
 /venv14/lib/python2.6/site-packages/django/conf/__init__.py:75:
 DeprecationWarning: The ADMIN_MEDIA_PREFIX setting has been removed; use
 STATIC_URL instead.
   "use STATIC_URL instead.", DeprecationWarning)
 Error: Unable to serialize database:
 }}}
 process got killed so no backtrace printed, store.json is empty

 After patch:

 {{{
 ../venv14/bin/python manage.py dumpdata store > store.json
 /venv14/lib/python2.6/site-packages/django/conf/__init__.py:75:
 DeprecationWarning: The ADMIN_MEDIA_PREFIX setting has been removed; use
 STATIC_URL instead.
   "use STATIC_URL instead.", DeprecationWarning)
 }}}
 {{{
 $ ls -l store.json
 17496440 2012-03-05 10:02 store.json
 }}}

 To conclude the patch makes a huge difference in my environment, from not
 working to working.

-- 
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] #17833: bad translation in django.contrib.localflavor.fr.fr_departement

[Django]

#17833: bad translation in django.contrib.localflavor.fr.fr_departement
-+-
 Reporter:  anonymous|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  contrib.localflavor  |  Version:
 Severity:  Normal   |  1.4-beta-1
 Keywords:   |   Resolution:
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by claudep):

 * component:  Translations => contrib.localflavor
 * type:  Uncategorized => Bug
 * 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] #17833: bad translation in django.contrib.localflavor.fr.fr_departement

[Django]

#17833: bad translation in django.contrib.localflavor.fr.fr_departement
---+--
 Reporter:  anonymous  |Owner:  aaugustin
 Type:  Uncategorized  |   Status:  new
Component:  Translations   |  Version:  1.4-beta-1
 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 aaugustin):

 * owner:  nobody => aaugustin
 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 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] #13614: Back button breaks many to many widget

[Django]

#13614: Back button breaks many to many widget
-+-
 Reporter:  minarets |Owner:  julien
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.3
 Severity:  Release blocker  |   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:  1
-+-

Comment (by aaugustin):

 We're about to release 1.4 RC1, but:
 - the patch is a complete rewrite, which involves some risks,
 - the Selenium tests break under IE,
 - they also randomly break under FF.

 We're running short on time and we aren't sufficiently familiar with
 Selenium yet to make reliable and consistent tests across browsers.

 So, at this time, it appears safer to live with the current behavior and
 fix this properly in 1.4.1. While this bug can turn into a data loss
 issue, it's still an edge case. Julien agreed on this plan on IRC.

 I will leave the "release blocker" status set so we don't forget this
 ticket for 1.4.1, but we accept to release 1.4 without a fix.

-- 
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] #17788: bulk_create() "too many SQL variables" error

[Django]

#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 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 anonymous):

 'Nice' to read i'm not the only one, I just ran into this problem trying
 to play with latest stable django-cms in 1.4b1rev17666.
 the "use a better database" solution (Postgres in our case) more or less
 solved the problem

-- 
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] #17833: bad translation in django.contrib.localflavor.fr.fr_departement

[Django]

#17833: bad translation in django.contrib.localflavor.fr.fr_departement
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Translations   |Version:  1.4-beta-1
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 The spelling of department 28 is wrong

 The good one is :
  ('28', u'28 - Eure-et-Loir'),

 There is no letter "e" at the end.

 For reference: http://fr.wikipedia.org/wiki/Eure-et-Loir

-- 
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] #17829: Admin date filter's "Past 7 days" actually returns past 8 days.

[Django]

#17829: Admin date filter's "Past 7 days" actually returns past 8 days.
-+-
 Reporter:  Glenn Washburn   |Owner:  nobody
  |   Status:  reopened
 Type:  Bug  |  Version:
Component:  contrib.admin|  1.4-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by aaugustin):

 To be honest, I don't care much either. Let's keep it as DDN to get more
 opinions...

-- 
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] #17829: Admin date filter's "Past 7 days" actually returns past 8 days.

[Django]

#17829: Admin date filter's "Past 7 days" actually returns past 8 days.
-+-
 Reporter:  Glenn Washburn   |Owner:  nobody
  |   Status:  reopened
 Type:  Bug  |  Version:
Component:  contrib.admin|  1.4-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


-- 
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] #17829: Admin date filter's "Past 7 days" actually returns past 8 days.

[Django]

#17829: Admin date filter's "Past 7 days" actually returns past 8 days.
-+-
 Reporter:  Glenn Washburn   |Owner:  nobody
  |   Status:  closed
 Type:  Bug  |  Version:
Component:  contrib.admin|  1.4-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:   |  worksforme
Has patch:  0| Triage Stage:
  Needs tests:  0|  Unreviewed
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by Glenn Washburn ):

 Yes, I thought about this after submitting the ticket.  Though, I think
 this is still an issue for DateTimeFields.  Basically, I think what is
 expected, is that no future dates are selected (if it can be helped).  I
 don't really care about this being fixed, but I think it is still a 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] r17667 - django/trunk

[noreply]

Author: aaugustin
Date: 2012-03-05 00:47:22 -0800 (Mon, 05 Mar 2012)
New Revision: 17667

Modified:
   django/trunk/setup.py
Log:
Fixed #17832 -- Missing negation in a comment. Thanks mk for the report.


Modified: django/trunk/setup.py
===
--- django/trunk/setup.py   2012-03-05 08:13:09 UTC (rev 17666)
+++ django/trunk/setup.py   2012-03-05 08:47:22 UTC (rev 17667)
@@ -36,7 +36,7 @@
 return result
 return fullsplit(head, [tail] + result)
 
-# Tell distutils to put the data_files in platform-specific installation
+# Tell distutils not to put the data_files in platform-specific installation
 # locations. See here for an explanation:
 # 
http://groups.google.com/group/comp.lang.python/browse_thread/thread/35ec7b2fed36eaec/2105ee4d9e8042cb
 for scheme in INSTALL_SCHEMES.values():

-- 
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] #17832: setup.py - purelib comment

[Django]

#17832: setup.py - purelib comment
-+-
 Reporter:  mk   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Core (Other) |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  setup.py |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 In [17667]:
 {{{
 #!CommitTicketReference repository="" revision="17667"
 Fixed #17832 -- Missing negation in a comment. Thanks mk for the report.
 }}}

-- 
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] #15107: Convert core commands to use self.std(out|err) instead of sys.std(out|err)/print

[Django]

#15107: Convert core commands to use self.std(out|err) instead of
sys.std(out|err)/print
-+-
 Reporter:  mmcnickle|Owner:  mmcnickle
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by claudep):

 Just a note to any potential reviewer: as this patch is quite extensive, I
 will keep a local branch updated with current trunk. However, I will not
 spam this ticket each time I rebase my branch. So just ping me if/when you
 are interested to review it (hopefully during the 1.5 timeframe!)

-- 
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] #16433: Missing 'help_text' in admin form when showing the back reference for a OneToOne field.

[Django]

#16433: Missing 'help_text' in admin form when showing the back reference for a
OneToOne field.
---+
 Reporter:  chris@…|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by claudep):

 * needs_tests:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #17832: setup.py - purelib comment

[Django]

#17832: setup.py - purelib comment
-+-
 Reporter:  mk   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Core (Other) |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  setup.py |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by claudep):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Ready for checkin
 * type:  Bug => Cleanup/optimization
 * 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] r17666 - in django/trunk: django/contrib/admin tests/regressiontests/admin_inlines tests/regressiontests/admin_views tests/regressiontests/admin_widgets

[noreply]

Author: julien
Date: 2012-03-05 00:13:09 -0800 (Mon, 05 Mar 2012)
New Revision: 17666

Modified:
   django/trunk/django/contrib/admin/tests.py
   django/trunk/tests/regressiontests/admin_inlines/tests.py
   django/trunk/tests/regressiontests/admin_views/tests.py
   django/trunk/tests/regressiontests/admin_widgets/tests.py
Log:
Enabled the existing admin Selenium tests to be run with Internet Explorer. 
Note that some tweaks had to be made, in particular as IE7 has limited 
capabilities regarding CSS selectors.

Modified: django/trunk/django/contrib/admin/tests.py
===
--- django/trunk/django/contrib/admin/tests.py  2012-03-05 04:17:55 UTC (rev 
17665)
+++ django/trunk/django/contrib/admin/tests.py  2012-03-05 08:13:09 UTC (rev 
17666)
@@ -79,7 +79,7 @@
 identified by the CSS selector `selector`.
 """
 from selenium.common.exceptions import NoSuchElementException
-options = self.selenium.find_elements_by_css_selector('%s option' % 
selector)
+options = self.selenium.find_elements_by_css_selector('%s > option' % 
selector)
 for option in options:
 if option.get_attribute('value') == value:
 return option
@@ -90,7 +90,7 @@
 Asserts that the  widget identified by `selector` has the
 options with the given `values`.
 """
-options = self.selenium.find_elements_by_css_selector('%s option' % 
selector)
+options = self.selenium.find_elements_by_css_selector('%s > option' % 
selector)
 actual_values = []
 for option in options:
 actual_values.append(option.get_attribute('value'))

Modified: django/trunk/tests/regressiontests/admin_inlines/tests.py
===
--- django/trunk/tests/regressiontests/admin_inlines/tests.py   2012-03-05 
04:17:55 UTC (rev 17665)
+++ django/trunk/tests/regressiontests/admin_inlines/tests.py   2012-03-05 
08:13:09 UTC (rev 17666)
@@ -394,6 +394,7 @@
 Ensure that the "Add another XXX" link correctly adds items to the
 inline form.
 """
+from selenium.common.exceptions import TimeoutException
 self.admin_login(username='super', password='secret')
 self.selenium.get('%s%s' % (self.live_server_url,
 '/admin/admin_inlines/profilecollection/add/'))
@@ -401,14 +402,14 @@
 # Check that there's only one inline to start with and that it has the
 # correct ID.
 self.failUnlessEqual(len(self.selenium.find_elements_by_css_selector(
-'#profile_set-group table tr.dynamic-profile_set')), 1)
-self.failUnlessEqual(self.selenium.find_element_by_css_selector(
-'.dynamic-profile_set:nth-of-type(1)').get_attribute('id'),
+'.dynamic-profile_set')), 1)
+self.failUnlessEqual(self.selenium.find_elements_by_css_selector(
+'.dynamic-profile_set')[0].get_attribute('id'),
 'profile_set-0')
 self.failUnlessEqual(len(self.selenium.find_elements_by_css_selector(
-'form#profilecollection_form tr.dynamic-profile_set#profile_set-0 
input[name=profile_set-0-first_name]')), 1)
+'.dynamic-profile_set#profile_set-0 
input[name=profile_set-0-first_name]')), 1)
 self.failUnlessEqual(len(self.selenium.find_elements_by_css_selector(
-'form#profilecollection_form tr.dynamic-profile_set#profile_set-0 
input[name=profile_set-0-last_name]')), 1)
+'.dynamic-profile_set#profile_set-0 
input[name=profile_set-0-last_name]')), 1)
 
 # Add an inline
 self.selenium.find_element_by_link_text('Add another Profile').click()
@@ -416,24 +417,24 @@
 # Check that the inline has been added, that it has the right id, and
 # that it contains the right fields.
 self.failUnlessEqual(len(self.selenium.find_elements_by_css_selector(
-'#profile_set-group table tr.dynamic-profile_set')), 2)
-self.failUnlessEqual(self.selenium.find_element_by_css_selector(
-'.dynamic-profile_set:nth-of-type(2)').get_attribute('id'), 
'profile_set-1')
+'.dynamic-profile_set')), 2)
+self.failUnlessEqual(self.selenium.find_elements_by_css_selector(
+'.dynamic-profile_set')[1].get_attribute('id'), 'profile_set-1')
 self.failUnlessEqual(len(self.selenium.find_elements_by_css_selector(
-'form#profilecollection_form tr.dynamic-profile_set#profile_set-1 
input[name=profile_set-1-first_name]')), 1)
+'.dynamic-profile_set#profile_set-1 
input[name=profile_set-1-first_name]')), 1)
 self.failUnlessEqual(len(self.selenium.find_elements_by_css_selector(
-'form#profilecollection_form tr.dynamic-profile_set#profile_set-1 
input[name=profile_set-1-last_name]')), 1)
+'.dynamic-profile_set#profile_set-1 
input[name=profile_set-1-last_name]')), 1)