[Django] #17738: Add a time zone FAQ

[Django]

#17738: Add a time zone FAQ
-+-
   Reporter:  aaugustin  |  Owner:  aaugustin
   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  |
-+-
 Feedback on the new time zone support shows that many developers aren't
 familiar with aware datetime objects.

 The time zone docs should be refactored to highlight the common issues in
 a FAQ, in order to help everyone learn the new rules.

-- 
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:  nobody
 Type:  Bug  |   Status:  reopened
Component:  contrib.admin|  Version:  1.3
 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:  1
-+
Changes (by julien):

 * severity:  Normal => Release blocker


Comment:

 I'm marking this ticket as release-blocker as it's a serious data loss
 issue. I think we're pretty close to a solution with the patch but I'm
 going to write comprehensive Selenium tests for multiple browsers to be
 certain.

-- 
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] #17737: collectstatic copies wrong files to STATIC_ROOT

[Django]

#17737: collectstatic copies wrong files to STATIC_ROOT
-+
 Reporter:  pigletto |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  contrib.staticfiles  |Version:  1.3
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+
 In specific situation, in Django 1.3.1, second run of collecstatic command
 might copy wrong files to STATIC_ROOT. This is dangerous situation in
 production environment.

 Attached test and patch against tags/1.3.1

 This issue doesn't exist in current trunk (Django 1.4) but seems to me
 that it might been fixed 'accidentally' so I also attach (passing) test
 for current trunk.

 To reproduce the issue:
 1. INSTALLED_APPS = ['appA', 'appB']
 2. static files in apps:
 {{{
 appA/
static/
 file.js

 appB/
static/
 file.js
 }}}

 3. Modification date of file.js in '''appB''' is newer than modification
 date of file.js in '''appA'''

 4. run collectstatic '''twice'''

 At first run everything is OK. File from appA is copied to STATIC_ROOT (as
 documentation says duplicate files are taken in order of apps in
 INSTALLED_APPS), but in second run file.js is replaced by ''wrong'' one -
 from '''appB'''.

 This is caused by use of:

 {{{
  shutil.copy2(source_path, full_path)
 }}}

 in copy_file method at collectstatic.py.

 shutil.copy2 preservers original file modification date what causes that
 file.js from '''appB''' is considered newer than file in STATIC_ROOT.

-- 
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] #17736: django.contrib.gis.geos.polygon from_bbox loss of floating-point accuracy

[Django]

#17736: django.contrib.gis.geos.polygon from_bbox loss of floating-point 
accuracy
---+
 Reporter:  tdihp@…|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 from_bbox use a string formatting to generate a geom instance, this will
 loose accuracy, when it matters

 for example:


 {{{
 >>> import math
 >>> from django.contrib.gis.geos import Polygon
 >>> l,t,r,b = 0.0,0.0,math.pi,math.pi
 >>> Polygon.from_bbox((l,t,r,b)).coords
 (((0.0, 0.0), (0.0, 3.14159265359), (3.14159265359, 3.14159265359),
 (3.14159265359, 0.0), (0.0, 0.0)),)
 >>> Polygon(((l,t),(r,t),(r,b),(l,b),(l,t))).coords
 (((0.0, 0.0), (3.141592653589793, 0.0), (3.141592653589793,
 }}}

-- 
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:  Database layer   |  Version:  1.2
  (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:  1|
-+-
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.

[Changeset] r17568 - in django/trunk: django/template docs/releases tests/regressiontests/templates

[noreply]

Author: SmileyChris
Date: 2012-02-20 18:59:05 -0800 (Mon, 20 Feb 2012)
New Revision: 17568

Modified:
   django/trunk/django/template/loader_tags.py
   django/trunk/docs/releases/1.4.txt
   django/trunk/tests/regressiontests/templates/tests.py
Log:
Fixed #17660 -- Standardize extends tag token parsing

Modified: django/trunk/django/template/loader_tags.py
===
--- django/trunk/django/template/loader_tags.py 2012-02-20 19:08:56 UTC (rev 
17567)
+++ django/trunk/django/template/loader_tags.py 2012-02-21 02:59:05 UTC (rev 
17568)
@@ -1,5 +1,6 @@
 from django.conf import settings
-from django.template.base import TemplateSyntaxError, Library, Node, TextNode, 
token_kwargs
+from django.template.base import TemplateSyntaxError, Library, Node, TextNode,\
+token_kwargs, Variable
 from django.template.loader import get_template
 from django.utils.safestring import mark_safe
 
@@ -74,26 +75,23 @@
 class ExtendsNode(Node):
 must_be_first = True
 
-def __init__(self, nodelist, parent_name, parent_name_expr, 
template_dirs=None):
+def __init__(self, nodelist, parent_name, template_dirs=None):
 self.nodelist = nodelist
-self.parent_name, self.parent_name_expr = parent_name, parent_name_expr
+self.parent_name = parent_name
 self.template_dirs = template_dirs
 self.blocks = dict([(n.name, n) for n in 
nodelist.get_nodes_by_type(BlockNode)])
 
 def __repr__(self):
-if self.parent_name_expr:
-return "" % self.parent_name_expr.token
-return '' % self.parent_name
+return '' % self.parent_name.token
 
 def get_parent(self, context):
-if self.parent_name_expr:
-parent = self.parent_name_expr.resolve(context)
-else:
-parent = self.parent_name
+parent = self.parent_name.resolve(context)
 if not parent:
 error_msg = "Invalid template name in 'extends' tag: %r." % parent
-if self.parent_name_expr:
-error_msg += " Got this from the '%s' variable." % 
self.parent_name_expr.token
+if self.parent_name.filters or\
+isinstance(self.parent_name.var, Variable):
+error_msg += " Got this from the '%s' variable." %\
+self.parent_name.token
 raise TemplateSyntaxError(error_msg)
 if hasattr(parent, 'render'):
 return parent # parent is a Template object
@@ -212,15 +210,11 @@
 bits = token.split_contents()
 if len(bits) != 2:
 raise TemplateSyntaxError("'%s' takes one argument" % bits[0])
-parent_name, parent_name_expr = None, None
-if bits[1][0] in ('"', "'") and bits[1][-1] == bits[1][0]:
-parent_name = bits[1][1:-1]
-else:
-parent_name_expr = parser.compile_filter(bits[1])
+parent_name = parser.compile_filter(bits[1])
 nodelist = parser.parse()
 if nodelist.get_nodes_by_type(ExtendsNode):
 raise TemplateSyntaxError("'%s' cannot appear more than once in the 
same template" % bits[0])
-return ExtendsNode(nodelist, parent_name, parent_name_expr)
+return ExtendsNode(nodelist, parent_name)
 
 @register.tag('include')
 def do_include(parser, token):

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2012-02-20 19:08:56 UTC (rev 17567)
+++ django/trunk/docs/releases/1.4.txt  2012-02-21 02:59:05 UTC (rev 17568)
@@ -1031,6 +1031,17 @@
 management commands in a script, use
 :djadmin:`manage.py help --commands ` instead.
 
+``extends`` template tag
+
+
+Previously, the :ttag:`extends` tag used a buggy method of parsing arguments,
+which could lead to it erroneously considering an argument as a string literal
+when it wasn't.  It now utilises ``parser.compile_filter`` like other tags.
+
+The internals of the tag aren't part of the official stable API, but in the
+interests of full disclosure, the ``ExtendsNode.__init__`` definition has
+changed which may break any custom tags that use this node class.
+
 Features deprecated in 1.4
 ==
 

Modified: django/trunk/tests/regressiontests/templates/tests.py
===
--- django/trunk/tests/regressiontests/templates/tests.py   2012-02-20 
19:08:56 UTC (rev 17567)
+++ django/trunk/tests/regressiontests/templates/tests.py   2012-02-21 
02:59:05 UTC (rev 17568)
@@ -1204,6 +1204,9 @@
 'inheritance40': ("{% extends 'inheritance33' %}{% block opt 
%}new{{ block.super }}{% endblock %}", {'optional': 1}, '1new23'),
 'inheritance41': ("{% extends 'inheritance36' %}{% block opt 
%}new{{ block.super }}{% endblock %}", {'numbers': '123'}, '_new1_new2_new3_'),
 
+# Expression starting and ending with a quote
+'inheritance42': ("{% extends 'in

Re: [Django] #17660: extends template tag mishandles filter expressions

[Django]

#17660: extends template tag mishandles filter expressions
-+
 Reporter:  FunkyBob |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 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 SmileyChris):

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


Comment:

 In [17568]:
 {{{
 #!CommitTicketReference repository="" revision="17568"
 Fixed #17660 -- Standardize extends tag token parsing
 }}}

-- 
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] #17735: 1.4 release notes don't mention that user messages are gone

[Django]

#17735: 1.4 release notes don't mention that user messages are gone
---+--
 Reporter:  poirier|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.4-beta-1
 Severity:  Normal |   Resolution:  invalid
 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 ramiro):

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


Comment:

 We list features/APIs that are removed in the release notes for the
 version where it is deprecated (N) and not in the release notes for
 version N+2 when it is completely removed.

 Also, there is a deprecation timeline document where the note you ask for
 is listed under the 1.4 heading.

 For this specific case URLs are
 https://docs.djangoproject.com/en/dev/releases/1.2/#user-messages-api and
 https://docs.djangoproject.com/en/1.3/internals/deprecation/ respectively.

-- 
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:  Database layer   |  Version:  1.2
  (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:  1|
-+-

Comment (by anonymous):

 Replying to [comment:7 carljm]:

 > This seems like a weak argument to me.

 I 100% agree with Carl here. I don't know where the contention regarding
 {{{auto_now}}} and {{{auto_now_add}}} came from, but it's completely
 unwarranted and ridiculous. It's a perfectly valid feature with a
 perfectly sane and non-hacky implementation. Everyone wants timestamps for
 updated_on and created_on at some point in their project, and this offers
 a way to do it on a base model without having to use signals or anything
 else (which I would deem to be overkill).

-- 
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:  Database layer   |  Version:  1.2
  (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:  1|
-+-
Changes (by streeter):

 * cc: streeter (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] #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:  Database layer   |  Version:  1.2
  (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:  1|
-+-

Comment (by anonymous):

 I've pasted a basic implementation (no patch, since I did this the
 subqueries.py of my site-packages vs my local src copy, and because of the
 timezone stuff that I'm not sure how to handle).

 https://gist.github.com/1872523#L83

 I've tested this locally, in case it's OK as-is, and somebody wants to
 make a patch an add tests.

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

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

Re: [Django] #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:  Database layer   |  Version:  1.2
  (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:  1|
-+-
Changes (by carljm):

 * component:  Documentation => Database layer (models, ORM)


Comment:

 Replying to [comment:2 lrekucki]:
 > It's a backwards incompatible change and there are a lot of people
 depending on it. Quoting the docs:
 >
 > > Be aware that the update() method is converted directly to an SQL
 statement. It is a bulk operation for direct updates. It doesn't run any
 save() methods on your models, or emit the pre_save or post_save signals
 (which are a consequence of calling save()).
 >
 > It doesn't explicitly refer to the {{{auto_now}}} option, but that was
 always a hack, so you don't have to implement it on {{{pre_save}}}
 yourself. I would be in favour of leaving the current behaviour and add a
 documentation note to docs about how it works with {{{auto_now}}}.

 This seems like a weak argument to me. As acknowledged, the docs say
 nothing about `auto_now` and `qs.update()`. If one reads all the relevant
 docs, I think one would reasonably assume that `auto_now` should work in
 case of a queryset update too, and I see no technical argument against it
 doing so. To argue that the feature should remain broken when it could be
 fixed because it was "always a hack" makes no sense to me. If the feature
 is a hack in a seriously bad sense, then it should either be removed, or
 fixed so that it is no longer a hack.

 I think that this is a bug, and we should fix bugs, not document them,
 even if someone might be depending on the buggy behavior. I have a hard
 time imagining the case where someone puts `auto_now` on a field but is
 relying on that field *not* being updated in case of a bulk update, or how
 this fix would break that code.

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

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

Re: [Django] #17726: Admin's Recent Actions broken for multiple admin site instances with unique registered models

[Django]

#17726: Admin's Recent Actions broken for multiple admin site instances with 
unique
registered models
-+-
 Reporter:  smacleod |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  admin, multiple  | Triage Stage:
  admin sites, recent actions|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by chipx86):

 * cc: chipx86@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #17735: 1.4 release notes don't mention that user messages are gone

[Django]

#17735: 1.4 release notes don't mention that user messages are gone
---+
 Reporter:  poirier|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.4-beta-1
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 User messages were deprecated in 1.2
 (https://docs.djangoproject.com/en/dev/releases/1.2/#user-messages-api)
 and are gone in 1.4, but don't seem to be mentioned in the 1.4 release
 notes.

-- 
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] #16406: Allow separate access to matches from urlpatterns and extra_context args

[Django]

#16406: Allow separate access to matches from urlpatterns and extra_context args
-+-
 Reporter:  apollo13 |Owner:
 Type:   |  antoviaque
  Cleanup/optimization   |   Status:  new
Component:  Core (Other) |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  resolvers, reverse   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by antoviaque):

 * owner:  nobody => antoviaque


-- 
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] #17734: 302 redirect to standard language for non-i18n URL's when returning 404.

[Django]

#17734: 302 redirect to standard language for non-i18n URL's when returning 404.
--+
 Reporter:  petar@…   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  SVN
 Severity:  Release blocker   |   Resolution:
 Keywords:  urlconf, i18n | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by brocaar):

 When implementing this feature during the DjangoCon sprints, jezdez and I
 discussed this issue / side-effect. From what I can remember, we discussed
 different approaches to fix this side-effect. In the end, we decided to
 leave it as it was (I forgot the exact reason, but probably since the
 solutions we found made it too complex).

 The most simple approach would be (I think, but feedback is welcome) to
 use the same logic as the `CommonMiddleware` uses for the `APPEND_SLASH`
 logic. Before redirecting the user to the language-prefixed URL, it will
 then first test if the prefixed URL version is resolvable, if not, it
 doesn't redirect the user. This would then mean that the
 `LocaleMiddleware` would share some logic with the `CommonMiddleware`
 because it should know about the `APPEND_SLASH` setting. If this setting
 is set to `True`, it should test for both `/en/something` and
 `/en/something/`. I'm not sure if that is desirable...

 What happens now when the user requests `/something`, the
 `LocaleMiddleware` will redirect the user (assuming it detects the
 language as en) to `/en/something`, then the `CommonMiddleware` will
 redirect the user to `/en/something/`.

 What do you guys think?

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

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

Re: [Django] #17733: Default timezone settings are different from the operating systems'

[Django]

#17733: Default timezone settings are different from the operating systems'
-+-
 Reporter:  berdario |Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Documentation|  1.4-alpha-1
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by aaugustin):

 * has_patch:  0 => 1
 * component:  Uncategorized => Documentation


-- 
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] #17733: Default timezone settings are different from the operating systems'

[Django]

#17733: Default timezone settings are different from the operating systems'
-+-
 Reporter:  berdario |Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Uncategorized|  1.4-alpha-1
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 `None` would be a more neutral value that `'America/Chicago'` for
 `TIME_ZONE`, but changing that would be backwards incompatible -- the
 default dates back to before `None` was made a legal value. Also, it's one
 of these small bits of history that are part of Django's character...
 (granted, that's very subjective).

 I think it's best to keep the comment short in the `settings.py` template
 and elaborate the various possibilities in the docs. I'm attaching a patch
 along these lines. I you think it addresses your concerns, could you
 change the "Triage Stage" to "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] #17497: Confusing exception message when using values_list with relations

[Django]

#17497: Confusing exception message when using values_list with relations
-+-
 Reporter:  ojii |Owner:
 Type:   |  antoviaque
  Cleanup/optimization   |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by antoviaque):

 * has_patch:  0 => 1


Comment:

 Cf attached file for a first attempt at fixing this. Since I'm new to
 django development, please be gentle in the review : )

 One thing that is unsatisfactory about this patch is that it doesn't
 properly handle the case where the QuerySet has an extra(select=...) and a
 lookup error on the first name of a field_names containing a LOOKUP_SEP.
 In such a case, it should correctly show the list of available field names
 on the right model, but won't show the available extra() parameters, which
 could in turn be confusing.

 However, the only way I could see to solve this was to mingle with the
 FieldError() exception, to include the model & field name on which the
 exception occurs. But I wasn't too sure about this, and it seems a little
 overkill.

 Anyway - if you see a better way to solve this, let me know, I'll be happy
 to implement it differently.

-- 
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] #16758: Documentation for TEMPLATE_CONTEXT_PROCESSORS could use additional warning.

[Django]

#16758: Documentation for TEMPLATE_CONTEXT_PROCESSORS could use additional 
warning.
-+-
 Reporter:  cyclops  |Owner:  anonymous
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by timo):

 In [17567]:
 {{{
 #!CommitTicketReference repository="" revision="17567"
 [1.3.X] Fixed #16758 - Added a warning regarding overriding default
 settings; thanks cyclops for the suggestion & Aymeric Augustin for the
 patch.

 Backport of r17566 from trunk.
 }}}

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

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

[Changeset] r17567 - django/branches/releases/1.3.X/docs/ref

[noreply]

Author: timo
Date: 2012-02-20 11:08:56 -0800 (Mon, 20 Feb 2012)
New Revision: 17567

Modified:
   django/branches/releases/1.3.X/docs/ref/settings.txt
Log:
[1.3.X] Fixed #16758 - Added a warning regarding overriding default settings; 
thanks cyclops for the suggestion & Aymeric Augustin for the patch.

Backport of r17566 from trunk.

Modified: django/branches/releases/1.3.X/docs/ref/settings.txt
===
--- django/branches/releases/1.3.X/docs/ref/settings.txt2012-02-20 
19:08:22 UTC (rev 17566)
+++ django/branches/releases/1.3.X/docs/ref/settings.txt2012-02-20 
19:08:56 UTC (rev 17567)
@@ -6,6 +6,13 @@
 :local:
 :depth: 1
 
+.. warning::
+
+Be careful when you override settings, especially when the default value
+is a non-empty tuple or dict, like :setting:`MIDDLEWARE_CLASSES` and
+:setting:`TEMPLATE_CONTEXT_PROCESSORS`. Make sure you keep the components
+required by the features of Django you wish to use.
+
 Available settings
 ==
 

-- 
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] #16758: Documentation for TEMPLATE_CONTEXT_PROCESSORS could use additional warning.

[Django]

#16758: Documentation for TEMPLATE_CONTEXT_PROCESSORS could use additional 
warning.
-+-
 Reporter:  cyclops  |Owner:  anonymous
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timo):

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


Comment:

 In [17566]:
 {{{
 #!CommitTicketReference repository="" revision="17566"
 Fixed #16758 - Added a warning regarding overriding default settings;
 thanks cyclops for the suggestion & Aymeric Augustin for the 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.

[Changeset] r17566 - django/trunk/docs/ref

[noreply]

Author: timo
Date: 2012-02-20 11:08:22 -0800 (Mon, 20 Feb 2012)
New Revision: 17566

Modified:
   django/trunk/docs/ref/settings.txt
Log:
Fixed #16758 - Added a warning regarding overriding default settings; thanks 
cyclops for the suggestion & Aymeric Augustin for the patch.

Modified: django/trunk/docs/ref/settings.txt
===
--- django/trunk/docs/ref/settings.txt  2012-02-20 18:58:34 UTC (rev 17565)
+++ django/trunk/docs/ref/settings.txt  2012-02-20 19:08:22 UTC (rev 17566)
@@ -6,6 +6,13 @@
 :local:
 :depth: 1
 
+.. warning::
+
+Be careful when you override settings, especially when the default value
+is a non-empty tuple or dict, like :setting:`MIDDLEWARE_CLASSES` and
+:setting:`TEMPLATE_CONTEXT_PROCESSORS`. Make sure you keep the components
+required by the features of Django you wish to use.
+
 Available settings
 ==
 

-- 
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] r17565 - django/branches/releases/1.3.X/docs/topics

[noreply]

Author: timo
Date: 2012-02-20 10:58:34 -0800 (Mon, 20 Feb 2012)
New Revision: 17565

Modified:
   django/branches/releases/1.3.X/docs/topics/auth.txt
   django/branches/releases/1.3.X/docs/topics/class-based-views.txt
Log:
[1.3.X] Fixed #17390 - Added a note to topics/auth.txt regarding how to 
decorate class-based generic views; thanks zsiciarz for the patch.

Backport of r17564 from trunk.

Modified: django/branches/releases/1.3.X/docs/topics/auth.txt
===
--- django/branches/releases/1.3.X/docs/topics/auth.txt 2012-02-20 18:57:51 UTC 
(rev 17564)
+++ django/branches/releases/1.3.X/docs/topics/auth.txt 2012-02-20 18:58:34 UTC 
(rev 17565)
@@ -1174,10 +1174,17 @@
 Limiting access to generic views
 
 
-To limit access to a :doc:`generic view `, write a thin
-wrapper around the view, and point your URLconf to your wrapper instead of the
-generic view itself. For example::
+Controlling access to a :doc:`class-based generic view 
`
+is done by decorating the :meth:`View.dispatch 
`
+method on the class. See :ref:`decorating-class-based-views` for the details.
 
+Function-based generic views
+
+
+To limit access to a :doc:`function-based generic view `,
+write a thin wrapper around the view, and point your URLconf to your wrapper
+instead of the generic view itself. For example::
+
 from django.views.generic.date_based import object_detail
 
 @login_required

Modified: django/branches/releases/1.3.X/docs/topics/class-based-views.txt
===
--- django/branches/releases/1.3.X/docs/topics/class-based-views.txt
2012-02-20 18:57:51 UTC (rev 17564)
+++ django/branches/releases/1.3.X/docs/topics/class-based-views.txt
2012-02-20 18:58:34 UTC (rev 17565)
@@ -584,6 +584,8 @@
 want every instance of a view to be decorated, you need to take a
 different approach.
 
+.. _decorating-class-based-views:
+
 Decorating the class
 
 

-- 
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] #17390: Describe how to do auth for Class Based Views in the main Auth docs

[Django]

#17390: Describe how to do auth for Class Based Views in the main Auth docs
-+-
 Reporter:  ncoghlan@…   |Owner:  zsiciarz
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by timo):

 In [17565]:
 {{{
 #!CommitTicketReference repository="" revision="17565"
 [1.3.X] Fixed #17390 - Added a note to topics/auth.txt regarding how to
 decorate class-based generic views; thanks zsiciarz for the patch.

 Backport of r17564 from trunk.
 }}}

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

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

Re: [Django] #17390: Describe how to do auth for Class Based Views in the main Auth docs

[Django]

#17390: Describe how to do auth for Class Based Views in the main Auth docs
-+-
 Reporter:  ncoghlan@…   |Owner:  zsiciarz
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timo):

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


Comment:

 In [17564]:
 {{{
 #!CommitTicketReference repository="" revision="17564"
 Fixed #17390 - Added a note to topics/auth.txt regarding how to decorate
 class-based generic views; thanks zsiciarz for the 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.

[Changeset] r17564 - django/trunk/docs/topics

[noreply]

Author: timo
Date: 2012-02-20 10:57:51 -0800 (Mon, 20 Feb 2012)
New Revision: 17564

Modified:
   django/trunk/docs/topics/auth.txt
   django/trunk/docs/topics/class-based-views.txt
Log:
Fixed #17390 - Added a note to topics/auth.txt regarding how to decorate 
class-based generic views; thanks zsiciarz for the patch.

Modified: django/trunk/docs/topics/auth.txt
===
--- django/trunk/docs/topics/auth.txt   2012-02-19 16:53:55 UTC (rev 17563)
+++ django/trunk/docs/topics/auth.txt   2012-02-20 18:57:51 UTC (rev 17564)
@@ -1457,10 +1457,17 @@
 Limiting access to generic views
 
 
-To limit access to a :doc:`generic view `, write a thin
-wrapper around the view, and point your URLconf to your wrapper instead of the
-generic view itself. For example::
+Controlling access to a :doc:`class-based generic view 
`
+is done by decorating the :meth:`View.dispatch 
`
+method on the class. See :ref:`decorating-class-based-views` for the details.
 
+Function-based generic views
+
+
+To limit access to a :doc:`function-based generic view `,
+write a thin wrapper around the view, and point your URLconf to your wrapper
+instead of the generic view itself. For example::
+
 from django.views.generic.date_based import object_detail
 
 @login_required

Modified: django/trunk/docs/topics/class-based-views.txt
===
--- django/trunk/docs/topics/class-based-views.txt  2012-02-19 16:53:55 UTC 
(rev 17563)
+++ django/trunk/docs/topics/class-based-views.txt  2012-02-20 18:57:51 UTC 
(rev 17564)
@@ -584,6 +584,8 @@
 want every instance of a view to be decorated, you need to take a
 different approach.
 
+.. _decorating-class-based-views:
+
 Decorating the class
 
 

-- 
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] #16237: Auth docs point to old function generic views instead of generic CBV

[Django]

#16237: Auth docs point to old function generic views instead of generic CBV
-+-
 Reporter:  rasca|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  SVN
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  class based views| Triage Stage:  Accepted
  generic|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by timo):

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


Comment:

 Duplicate of #17390 which has a 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] #16605: Can't client.login() in tests if contrib.SessionMiddleware is not in MIDDLEWARE_CLASSES

[Django]

#16605: Can't client.login() in tests if contrib.SessionMiddleware is not in
MIDDLEWARE_CLASSES
---+
 Reporter:  jbalogh|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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
---+

Comment (by btimby):

 Hi, I suffered from this change as well when updating to Django 1.4. I am
 using a derived SessionMiddleware class that allows views to "opt-out" of
 updating the session expiry.

 Checking for a subclass would resolve my woes as well. I will attach a
 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] #17728: Filtering of annotated querysets broken with timezone-aware datetimes

[Django]

#17728: Filtering of annotated querysets broken with timezone-aware datetimes
-+-
 Reporter:  gg   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:  regression   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * severity:  Normal => Release blocker


Comment:

 I haven't assessed the bug report yet, but it's probably a release
 blocker.

-- 
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] #17734: 302 redirect to standard language for non-i18n URL's when returning 404.

[Django]

#17734: 302 redirect to standard language for non-i18n URL's when returning 404.
--+
 Reporter:  petar@…   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  SVN
 Severity:  Release blocker   |   Resolution:
 Keywords:  urlconf, i18n | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by carljm):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * severity:  Normal => Release blocker
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Marking as a release blocker since this is a significant bug in a new
 feature.

-- 
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] #6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__ method

[Django]

#6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__
method
-+-
 Reporter:  favo |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

 * type:  Cleanup/optimization => Bug


Comment:

 Closed #16073 (which was specifically about incorrect m2m signals in the
 admin, as a result of this) as duplicate. Marking this a bug rather than a
 cleanup/optimization; previous to the existence of m2m signals it may have
 been the latter, but at this point the signaling problem makes it 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.

Re: [Django] #16073: Django admin save not sending post remove action with m2m changed signal

[Django]

#16073: Django admin save not sending post remove action with m2m changed signal
---+-
 Reporter:  sam@…  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.3
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  m2m_changed| Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by carljm):

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


Comment:

 Replying to [comment:8 anonymous]:
 > Can I suggest that a note be added to the django documentation about
 this limitation - it would've saved me many hours of hair-tearing and
 self-recrimination.

 This ticket and #6707 are both in Accepted state, meaning that the
 intention is to fix them, not to declare them a known limitation.

 Closing this as a duplicate of #6707 - this bug is just a symptom of that
 one.

-- 
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] #14497: ModelAdmin.readonly_fields isn't graceful with filefields.

[Django]

#14497: ModelAdmin.readonly_fields isn't graceful with filefields.
-+-
 Reporter:  Keryn Knight |Owner:
|  adamjforster
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  feature admin| Triage Stage:  Accepted
  readonly filefield |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  1
Easy pickings:  0|
-+-

Comment (by akaariai):

 You might want to check out the admin's Selenium test cases found from
 django/contrib/admin/tests.py. Seems like the perfect fit for testing
 this.

-- 
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] #17733: Default timezone settings are different from the operating systems'

[Django]

#17733: Default timezone settings are different from the operating systems'
-+-
 Reporter:  berdario |Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Uncategorized|  1.4-alpha-1
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

Re: [Django] #16366: contrib.auth.tests.context_processors.AuthContextProcessorTests.test_session_not_accessed fails when project loads other middleware that access the session.

[Django]

#16366: 
contrib.auth.tests.context_processors.AuthContextProcessorTests.test_session_not_accessed
fails when project loads other middleware that access the session.
-+-
 Reporter:  jsdalton |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:  test | 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 ryankask):

 * cc: dev@… (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] #16366: contrib.auth.tests.context_processors.AuthContextProcessorTests.test_session_not_accessed fails when project loads other middleware that access the session.

[Django]

#16366: 
contrib.auth.tests.context_processors.AuthContextProcessorTests.test_session_not_accessed
fails when project loads other middleware that access the session.
-+-
 Reporter:  jsdalton |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:  test | 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 ryankask):

 * severity:  Normal => Release blocker


Comment:

 I'm marking this as a "release blocker" on the basis of Aymeric Augustin's
 recent message (http://groups.google.com/group/django-
 developers/browse_thread/thread/cdd0f2b6e2d1141e).

 It's not a major issue but I would consider it a regression because
 Django's tests are failing for some users and a reasonable fix is ready.

 Please let me know if this is not the right action.

-- 
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] #14497: ModelAdmin.readonly_fields isn't graceful with filefields.

[Django]

#14497: ModelAdmin.readonly_fields isn't graceful with filefields.
-+-
 Reporter:  Keryn Knight |Owner:
|  adamjforster
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  feature admin| Triage Stage:  Accepted
  readonly filefield |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  1
Easy pickings:  0|
-+-

Comment (by adamjforster):

 I'm not sure how to test this, can someone else take a look?

-- 
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] #17728: Filtering of annotated querysets broken with timezone-aware datetimes

[Django]

#17728: Filtering of annotated querysets broken with timezone-aware datetimes
-+-
 Reporter:  gg   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:  regression   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #17734: 302 redirect to standard language for non-i18n URL's when returning 404.

[Django]

#17734: 302 redirect to standard language for non-i18n URL's when returning 404.
--+---
 Reporter:  petar@…   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Internationalization  |Version:  SVN
 Severity:  Normal|   Keywords:  urlconf, i18n
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 I'm using [Tastypie] to supply an API for my project. This API should be a
 language independent URI, while some other applications have language
 dependent URI's. This leaves me with the following URLConf:

 {{{
 from django.utils.translation import ugettext_lazy as _
 from django.conf.urls.defaults import patterns, include, url
 from django.conf.urls.i18n import i18n_patterns

 urlpatterns = patterns('',
 url(r'^api/', include(v1_api.urls)),
 )

 urlpatterns += i18n_patterns('',
 url(_(r'^something/'), include('something.urls')),
 )
 }}}

 When I raise a `404` in the API, the `LocaleMiddleware` detects this and
 tries to redirect to `/en/api/[..]`. I think this happens because
 `is_language_prefix_patterns_used` always returns `True` because it loops
 through '''all''' the URL's in the URLConf and finds a locale URL.
 However, the URL for the API is not an Locale URL.

 [Tastypie]: https://github.com/toastdriven/django-tastypie

-- 
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] #17733: Default timezone settings are different from the operating systems'

[Django]

#17733: Default timezone settings are different from the operating systems'
--+-
 Reporter:  berdario  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Uncategorized |Version:  1.4-alpha-1
 Severity:  Normal|   Keywords:  timezone
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+-
 The settings.py template reads:

 "On Unix systems, a value of None will cause Django to use the same
 timezone as the operating system."

 but by leaving the TIME_ZONE off, it will use the TIME_ZONE defined in the
 global_settings... compared to explicitly overriding it with None: that
 instead will indeed use a django.utils.timezone.LocalTimezone instance

 this is quite unexpected

 moreover: the django.utils.timezone code warns that in case of problems,
 you'd be better off with pytz than by trying to use LocalTimezone

 so, using None to automatically detect the system timezone as suggested,
 will prevent django from using pytz, even if it was installed

 I don't know if it's fine to suggest that None could be used without
 warning about that, but in case I think it would be better to

 - change the value in django/conf/global_settings.py to None

 or

 - change the comments inside
 django/conf/project_template/project_name/settings.py

-- 
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] #17686: file.save crashes on unicode filename

[Django]

#17686: file.save crashes on unicode filename
--+
 Reporter:  sylvain.lebon@…   |Owner:  nobody
 Type:  Uncategorized |   Status:  new
Component:  File uploads/storage  |  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
--+

Comment (by sylvain.lebon@…):

 What you say makes sense, but I don't think that's my point.

 What I'm saying is that my system is configured tu use UTF-8 :
 {{{sys.getfilesystemencoding()}}} gives me {{{"UTF-8"}}}, but
 {{{safe_join}}} won't give me a UTF-8 encoded string. A
 {{{.encode("utf-8")}}} should be applied to the string before it is passed
 to os.stat, but the {{{File.save()}}} doesn't handle that. I figured it
 might be a bug of {{{safe_join}}} not to give a string in the same
 encoding it was passed.

 In any case, I don't manage to get {{{safe_join}}} giving back a string
 that my os.stat can handle. Is it as safe as it pretends to be?

 Anyhow, I agree with you that the FileStorage docs could be more precise
 on some points, including this one.


 Replying to [comment:1 lrekucki]:
 > This is a common error, which actually isn't Django related:
 >
 > Most file system related functions in Python (like {{{os.stat}}}) accept
 unicode strings which are then encoded using the default encoding of the
 file system (see
 http://docs.python.org/library/sys.html#sys.getfilesystemencoding). This
 is actually the only sane thing to do - if you pass a manually encoded
 string you'll have no guarantee it will match what was actually written on
 the FS. On Unix platforms, this depends on the user's *locale*. Thus if
 the user you're running the server on, doesn't have a properly set
 {{{LC_ALL}}}, {{{LANG}}}, etc. in his enviroment, the FS encoding will be
 assumed ASCII  and os.stat will crash.
 >
 > I'm marking this as accepted, because I think it's worth putting a note
 about this in FileStorage docs.

-- 
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] #14518: Field.to_python not called on foreign key IDs

[Django]

#14518: Field.to_python not called on foreign key IDs
-+-
 Reporter:  wolever  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (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 kitsunde):

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