Re: [Django] #16094: Documentation for Custom permissions is ambiguous.

[Django]

#16094: Documentation for Custom permissions is ambiguous.
-+-
   Reporter:  Bradley|  Owner:  nobody
  Ayers | Status:  reopened
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  0
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by anonymous):

 Oops! Good point julien, I didn't think that through too well :/

-- 
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] #16094: Documentation for Custom permissions is ambiguous.

[Django]

#16094: Documentation for Custom permissions is ambiguous.
-+-
   Reporter:  Bradley|  Owner:  nobody
  Ayers | Status:  reopened
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  0
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * stage:  Accepted => Ready for checkin


Comment:

 Thanks for pointing this out, but it'd have been more useful if the patch
 was based on the latest trunk :)

 The missing colon is at the end of the sentence "Continuing the above
 example, the following checks if a user may". This might have to be
 backported to 1.3.X to fix r16814.

-- 
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] #16676: The 'add' filter should stringify value or argument if the other value is a string

[Django]

#16676: The 'add' filter should stringify value or argument if the other value 
is a
string
-+-
   Reporter:  dtrebbien  |  Owner:  aaugustin
   Type:  Bug| Status:  new
  Milestone: |  Component:  Template system
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by julien):

 An approach would be to return `settings.TEMPLATE_STRING_IF_INVALID`
 (which defaults to an empty string). However, I'd be happy enough with the
 doc being modified to reflect the current behaviour.

-- 
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] #16094: Documentation for Custom permissions is ambiguous.

[Django]

#16094: Documentation for Custom permissions is ambiguous.
-+-
   Reporter:  Bradley|  Owner:  nobody
  Ayers | Status:  reopened
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by bradley.ayers):

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


Comment:

 There was a missing colon in the original patch. I've corrected this
 attached 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.

Re: [Django] #16803: Unicode representation of ContentType instances is not translated

[Django]

#16803: Unicode representation of ContentType instances is not translated
+--
   Reporter:  bronger   |  Owner:  isagalaev
   Type:  Bug   | Status:  assigned
  Milestone:|  Component:  contrib.contenttypes
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  0
  UI/UX:  0 |
+--

Comment (by isagalaev):

 My bad, I should've run the whole test suite. I'll look into it shortly…

-- 
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] #16862: I'm try to implement object permission on django admin.

[Django]

#16862: I'm try to implement object permission on django admin.
+---
 Reporter:  Kidwind |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  contrib.admin
  Version:  SVN |   Severity:  Normal
 Keywords:  permission  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
UI/UX:  0   |
+---
 i'm override ModelAdmin for my object permission Backend like this

 def has_delete_permission(self, request, obj=None):
 opts = self.opts
 return request.user.has_perm(opts.app_label + '.' +
 opts.get_delete_permission(), obj) # pass parm obj

 but when i delete the obj,System back to me "Deleting the article 'test'
 would result in deleting related objects, but your account doesn't have
 permission to delete the following types of objects:article".
 why? i try to find the Root of the problem.

 in the django.contrib.admin.utils.get_deleted_objects not pass parm "obj"
 to detect the permission for related deleted obj.
 Django did not provide extension points，I can only change the django
 source code.

 when i try to implement object permission for django admin,What is the
 best solution，thank 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] #16803: Unicode representation of ContentType instances is not translated

[Django]

#16803: Unicode representation of ContentType instances is not translated
+--
   Reporter:  bronger   |  Owner:  isagalaev
   Type:  Bug   | Status:  assigned
  Milestone:|  Component:  contrib.contenttypes
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  0
  UI/UX:  0 |
+--
Changes (by carljm):

 * needs_better_patch:  0 => 1


Comment:

 Replying to [comment:6 isagalaev]:
 > Here's the first iteration of a patch. A couple of notes:
 >
 > * {{{touch tests/regressiontests/i18n/contenttypes/__init__.py}}}
 > * I don't know if there a point of attaching compiled language files
 that don't get included in the patch, it might be easier to compile them
 from tests/regressiontests/i18n/contenttypes directory by hand
 > * I left a comment in django/contrib/contenttypes/models.py regarding
 deprecation of {{{self.name}}} but wasn't sure if we should actually raise
 a DeprecationWarning there?

 I think actual deprecation of the name field should wait until we have
 schema migrations in core, so that we can actually remove the field at the
 end of the deprecation. For now the comment is fine - I might expand on it
 to note that we'll do a real deprecation later.

 Looks good otherwise, except I'm now getting four UnicodeDecodeErrors in
 the admin_views tests with this patch. Probably due to the added
 translation with non-ASCII chars in it, haven't dug in to find the best
 solution.

-- 
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] #16803: Unicode representation of ContentType instances is not translated

[Django]

#16803: Unicode representation of ContentType instances is not translated
+--
   Reporter:  bronger   |  Owner:  isagalaev
   Type:  Bug   | Status:  assigned
  Milestone:|  Component:  contrib.contenttypes
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--
Changes (by isagalaev):

 * has_patch:  0 => 1


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

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

Re: [Django] #16770: Don't wrap exceptions in TemplateSyntaxError under DEBUG

[Django]

#16770: Don't wrap exceptions in TemplateSyntaxError under DEBUG
+-
   Reporter:  jMyles|  Owner:  jMyles
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  Template system
Version:  1.3   |   Severity:  Normal
 Resolution:  fixed |   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-
Changes (by carljm):

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


Comment:

 In [16833]:
 {{{
 #!CommitTicketReference repository="" revision="16833"
 Fixed #16770 -- Eliminated TemplateSyntaxError wrapping of exceptions.
 Thanks to Justin Myles-Holmes for report and draft patch.

 Exceptions raised in templates were previously wrapped in
 TemplateSyntaxError
 (in TEMPLATE_DEBUG mode only) in order to provide template source details
 on
 the debug 500 page. The same debug information is now provided by
 annotating
 exceptions rather than wrapping them. This makes catching exceptions
 raised
 from templates more sane, as it's consistent in or out of DEBUG, and you
 can
 catch the specific exception(s) you care about rather than having to also
 catch
 TemplateSyntaxError and unwrap it.
 }}}

-- 
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] r16833 - in django/trunk: django/template django/views tests/regressiontests/templates tests/regressiontests/views/tests

[noreply]

Author: carljm
Date: 2011-09-15 18:16:25 -0700 (Thu, 15 Sep 2011)
New Revision: 16833

Modified:
   django/trunk/django/template/debug.py
   django/trunk/django/template/defaulttags.py
   django/trunk/django/views/debug.py
   django/trunk/tests/regressiontests/templates/nodelist.py
   django/trunk/tests/regressiontests/templates/tests.py
   django/trunk/tests/regressiontests/views/tests/debug.py
Log:
Fixed #16770 -- Eliminated TemplateSyntaxError wrapping of exceptions. Thanks 
to Justin Myles-Holmes for report and draft patch.

Exceptions raised in templates were previously wrapped in TemplateSyntaxError
(in TEMPLATE_DEBUG mode only) in order to provide template source details on
the debug 500 page. The same debug information is now provided by annotating
exceptions rather than wrapping them. This makes catching exceptions raised
from templates more sane, as it's consistent in or out of DEBUG, and you can
catch the specific exception(s) you care about rather than having to also catch
TemplateSyntaxError and unwrap it.

Modified: django/trunk/django/template/debug.py
===
--- django/trunk/django/template/debug.py   2011-09-15 23:55:30 UTC (rev 
16832)
+++ django/trunk/django/template/debug.py   2011-09-16 01:16:25 UTC (rev 
16833)
@@ -4,6 +4,7 @@
 from django.utils.safestring import SafeData, EscapeData
 from django.utils.formats import localize
 
+
 class DebugLexer(Lexer):
 def __init__(self, template_string, origin):
 super(DebugLexer, self).__init__(template_string, origin)
@@ -42,9 +43,9 @@
 def error(self, token, msg):
 return self.source_error(token.source, msg)
 
-def source_error(self, source,msg):
+def source_error(self, source, msg):
 e = TemplateSyntaxError(msg)
-e.source = source
+e.django_template_source = source
 return e
 
 def create_nodelist(self):
@@ -63,38 +64,31 @@
 raise self.source_error(source, msg)
 
 def compile_function_error(self, token, e):
-if not hasattr(e, 'source'):
-e.source = token.source
+if not hasattr(e, 'django_template_source'):
+e.django_template_source = token.source
 
 class DebugNodeList(NodeList):
 def render_node(self, node, context):
 try:
-result = node.render(context)
-except TemplateSyntaxError, e:
-if not hasattr(e, 'source'):
-e.source = node.source
-raise
+return node.render(context)
 except Exception, e:
-from sys import exc_info
-wrapped = TemplateSyntaxError(u'Caught %s while rendering: %s' %
-(e.__class__.__name__, force_unicode(e, errors='replace')))
-wrapped.source = getattr(e, 'template_node_source', node.source)
-wrapped.exc_info = exc_info()
-raise wrapped, None, wrapped.exc_info[2]
-return result
+if not hasattr(e, 'django_template_source'):
+e.django_template_source = node.source
+raise
 
+
 class DebugVariableNode(VariableNode):
 def render(self, context):
 try:
 output = self.filter_expression.resolve(context)
 output = localize(output, use_l10n=context.use_l10n)
 output = force_unicode(output)
-except TemplateSyntaxError, e:
-if not hasattr(e, 'source'):
-e.source = self.source
-raise
 except UnicodeDecodeError:
 return ''
+except Exception, e:
+if not hasattr(e, 'django_template_source'):
+e.django_template_source = self.source
+raise
 if (context.autoescape and not isinstance(output, SafeData)) or 
isinstance(output, EscapeData):
 return escape(output)
 else:

Modified: django/trunk/django/template/defaulttags.py
===
--- django/trunk/django/template/defaulttags.py 2011-09-15 23:55:30 UTC (rev 
16832)
+++ django/trunk/django/template/defaulttags.py 2011-09-16 01:16:25 UTC (rev 
16833)
@@ -227,17 +227,15 @@
 context.update(unpacked_vars)
 else:
 context[self.loopvars[0]] = item
-# In TEMPLATE_DEBUG mode providing source of the node which
-# actually raised an exception to DefaultNodeList.render_node
+# In TEMPLATE_DEBUG mode provide source of the node which
+# actually raised the exception
 if settings.TEMPLATE_DEBUG:
 for node in self.nodelist_loop:
 try:
 nodelist.append(node.render(context))
 except Exception, e:
-if not hasattr(e, 'template_node_source'):
-from sys import exc_info
-e.template_node_source = node.source
-

Re: [Django] #16861: Fixtures do not work with namespaced apps

[Django]

#16861: Fixtures do not work with namespaced apps
+---
   Reporter:  jlsherrill@…  |  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  Uncategorized
Version:  1.3   |   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 |
+---

Comment (by anonymous):

 Ahhh.  Thanks!  That worked just fine.

-- 
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] #16861: Fixtures do not work with namespaced apps

[Django]

#16861: Fixtures do not work with namespaced apps
+---
   Reporter:  jlsherrill@…  |  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  Uncategorized
Version:  1.3   |   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 carljm):

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


Comment:

 Models in fixtures are referred to by `"app_label.ModelName"`, where
 "app_label" is the final component of the app's dotted path (same as what
 you'd pass to e.g. "manage.py dumpdata"). So the string you're looking for
 is `"facebook.FacebookApp"` - `"allauth"` should be omitted entirely.

-- 
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] #16861: Fixtures do not work with namespaced apps

[Django]

#16861: Fixtures do not work with namespaced apps
--+---
 Reporter:  jlsherrill@…  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  Uncategorized
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+---
 If you have an app that is "foo.bar" instead of just "foo" it seems as if
 it is impossible to create fixtures for them.  For example the app
 django-allauth  includes multiples apps within it:

 * allauth.facebook
 * allauth.twitter
 * etc..

 You can use it just fine, but if you try to use a fixture, for example:
 {{{
 - model: allauth.facebook.models.FacebookApp #  (same error with
 allauth.facebook.FacebookApp)
   pk: 1
   fields:
 name: TestApp
 site: "1"
 application_id: 1234
 api_key: Foo
 application_secret: FOOO
 }}}

 importing will fail with this traceback:

 {{{
 Problem installing fixture
 '~/project/settings/../../local_apps/accounts/fixtures/initial_data.yaml':
 Traceback (most recent call last):
   File "~/beer-env/lib/python2.7/site-
 packages/django/core/management/commands/loaddata.py", line 169, in handle
 for obj in objects:
   File "~/beer-env/lib/python2.7/site-
 packages/django/core/serializers/pyyaml.py", line 54, in Deserializer
 for obj in PythonDeserializer(yaml.load(stream), **options):
   File "~/beer-env/lib/python2.7/site-
 packages/django/core/serializers/python.py", line 84, in Deserializer
 Model = _get_model(d["model"])
   File "~/beer-env/lib/python2.7/site-
 packages/django/core/serializers/python.py", line 142, in _get_model
 raise base.DeserializationError(u"Invalid model identifier: '%s'" %
 model_identifier)
 DeserializationError: Invalid model identifier: 'allauth.FacebookApp'
 }}}
 It seems that the get_model() call within _get_model() of
 /django/core/serializers/python.py is splitting the 'model' from the
 fixture which doesn't seem correct.

 Affected code (/django/core/serializers/python.py)
 {{{
 def _get_model(model_identifier):
 """
 Helper to look up a model from an "app_label.module_name" string.
 """
 try:
 #import pdb; pdb.set_trace()
 Model = models.get_model(*model_identifier.split("."))
 except TypeError:
 Model = None
 if Model is None:
 raise base.DeserializationError(u"Invalid model identifier: '%s'"
 % model_identifier)
 return Model
 }}}

-- 
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] #16803: Unicode representation of ContentType instances is not translated

[Django]

#16803: Unicode representation of ContentType instances is not translated
+--
   Reporter:  bronger   |  Owner:  isagalaev
   Type:  Bug   | Status:  assigned
  Milestone:|  Component:  contrib.contenttypes
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 isagalaev):

 Here's the first iteration of a patch. A couple of notes:

 * {{{touch tests/regressiontests/i18n/contenttypes/__init__.py}}}
 * I don't know if there a point of attaching compiled language files that
 don't get included in the patch, it might be easier to compile them from
 tests/regressiontests/i18n/contenttypes directory by hand
 * I left a comment in django/contrib/contenttypes/models.py regarding
 deprecation of {{{self.name}}} but wasn't sure if we should actually raise
 a DeprecationWarning 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.

Re: [Django] #16854: AttributeError on syncdb

[Django]

#16854: AttributeError on syncdb
-+-
   Reporter:  desh   |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Core (Management
Version:  SVN|  commands)
 Resolution:  fixed  |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  syncdb management
Needs documentation:  0  |  contenttypes
Patch needs improvement:  0  |  Has patch:  1
  UI/UX:  0  |Needs tests:  0
 |  Easy pickings:  1
-+-
Changes (by Alex):

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


Comment:

 In [16832]:
 {{{
 #!CommitTicketReference repository="" revision="16832"
 Fixed #16854 -- corrected an AttributeError coming from the contenttypes
 post-syncdb hook.  Thanks to desh 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.

[Changeset] r16832 - django/trunk/django/contrib/contenttypes

[noreply]

Author: Alex
Date: 2011-09-15 16:55:30 -0700 (Thu, 15 Sep 2011)
New Revision: 16832

Modified:
   django/trunk/django/contrib/contenttypes/management.py
Log:
Fixed #16854 -- corrected an AttributeError coming from the contenttypes 
post-syncdb hook.  Thanks to desh for the report.

Modified: django/trunk/django/contrib/contenttypes/management.py
===
--- django/trunk/django/contrib/contenttypes/management.py  2011-09-15 
07:26:35 UTC (rev 16831)
+++ django/trunk/django/contrib/contenttypes/management.py  2011-09-15 
23:55:30 UTC (rev 16832)
@@ -44,7 +44,10 @@
 # Confirm that the content type is stale before deletion.
 if to_remove:
 if kwargs.get('interactive', False):
-content_type_display = '\n'.join(['%s | %s' % (ct.app_label, 
ct.model) for ct in content_types])
+content_type_display = '\n'.join([
+'%s | %s' % (ct.app_label, ct.model)
+for ct in to_remove
+])
 ok_to_delete = raw_input("""The following content types are stale 
and need to be deleted:
 
 %s

-- 
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] #16854: AttributeError on syncdb

[Django]

#16854: AttributeError on syncdb
-+-
   Reporter:  desh   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Management
Version:  SVN|  commands)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  syncdb management
Needs documentation:  0  |  contenttypes
Patch needs improvement:  0  |  Has patch:  1
  UI/UX:  0  |Needs tests:  0
 |  Easy pickings:  1
-+-

Comment (by desh):

 That is correct, guys, it is only in the current SVN trunk and regression
 was introduced by commit at 09-09-2011.
 Version was overlooked by me ('1.3' was default value).
 Nice, seems that our company packaging bleeding edge trunk.

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

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

[Django] #16860: Provide hooks for password policy

[Django]

#16860: Provide hooks for password policy
-+
 Reporter:  PaulM|Owner:  nobody
 Type:  New feature  |   Status:  new
Milestone:   |Component:  contrib.auth
  Version:  1.3  | Severity:  Normal
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
 While it is possible to change the validation for new passwords by
 subclassing the form, I think that Django should provide a more friendly
 interface for this. We should have a pluggable password authentication
 framework which enforces no rules by default, but comes with several
 reasonable example policies which may be enabled.

 Problems to be solved include:

  * Informing the user of the various password requirements
  * Allowing policies to chain together smoothly
  * Provide flexibility for complex requirements (some may include their
 own models)
  * Backwards compatibility
  * Javascript validation assistance (someday, maybe?)
  * HTML5 support (i.e. the pattern attribute)

-- 
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] #16859: CSRF Improvements

[Django]

#16859: CSRF Improvements
-+-
 Reporter:  PaulM|Owner:  PaulM
 Type:   |   Status:  new
  Cleanup/optimization   |Component:
Milestone:   |  contrib.csrf
  Version:  1.3  | Severity:  Normal
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
 This is a ticket to keep track of general CSRF improvements we want to add
 to Django.

 This includes:

  * #16010 - add Origin checking
  * Optionally tie CSRF to sessions
  * Use signing to improve CSRF (maybe with sessions)
  * Improve domain/host checking - deal with the subdomain to subdomain
 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] #16705: r13746 makes invalid assumption that QUERY_STRING exists

[Django]

#16705: r13746 makes invalid assumption that QUERY_STRING exists
-+-
   Reporter:  raylu  |  Owner:  aaugustin
   Type:  Bug| Status:  new
  Milestone: |  Component:  Generic views
Version:  SVN|   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  |
-+-

Comment (by raylu):

 It seems like in django/middleware/common.py what you really want is

 {{{ if 'QUERY_STRING' in request.META: }}}

 Everywhere else,

 {{{ args = request.META.get('QUERY_STRING') }}}

 seems to make more sense since the check on the next line is merely {{{ if
 args }}}

-- 
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] #16858: incr() on locmem cache resets the expiry time

[Django]

#16858: incr() on locmem cache resets the expiry time
+-
   Reporter:  boxm  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Core (Cache system)
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 Alex):

 * stage:  Unreviewed => Accepted


Comment:

 Well, I think the locmem's behavior is a bit more intuitive personally,
 but we've generally tried to make the "stupid" backends do what memcached
 would do, since they're often used in development/testing.  Marking as
 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] #16858: incr() on locmem cache resets the expiry time

[Django]

#16858: incr() on locmem cache resets the expiry time
-+-
   Reporter:  boxm   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Cache system)
Version:  1.3|   Severity:  Normal
 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 boxm):

 Yes, I consider this a bug.

 As far as I can tell, memcached does not alter the expiry time of a key
 when incr()/decr() is called on it. Running the same test using a
 memcached cache backend, I get the value out at the end.

 It seems highly counter-intuitive that updating a key's value should
 suddenly reset the timeout and cause the key to expire.

-- 
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] #16838: First InlineModelAdmin not displaying "Add Another" link when related_name='+'

[Django]

#16838: First InlineModelAdmin not displaying "Add Another" link when
related_name='+'
+---
   Reporter:  jamesp|  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  contrib.admin
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---

Comment (by jamesp):

 My god, I am a mess.  You're right, it should be on the ForeignKeys.

 I need some damn sleep.  :P

-- 
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] #16858: incr() on locmem cache resets the expiry time

[Django]

#16858: incr() on locmem cache resets the expiry time
-+-
   Reporter:  boxm   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Cache system)
Version:  1.3|   Severity:  Normal
 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 Alex):

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


Old description:

> On the locmem cache backend, calling incr() causes the key's timeout
> value to be reset to the default for the cache.
>
> To reproduce:
> - setup the default cache to be locmem and with a timeout of 1 second
> >> cache.set('key', 10, 300)
> >> time.sleep(1)
> >> cache.get('key')
> 10
> >> cache.incr('key')
> >> time.sleep(1)
> >> cache.get('key')
> None
>
> The cache should still contain the key at the last line.
>
> The problem comes from the implementation of incr() in base.py which uses
> get() and set() to implement incr(). Since set() is called without a
> timeout, the cache default time is used.

New description:

 On the locmem cache backend, calling incr() causes the key's timeout value
 to be reset to the default for the cache.

 To reproduce:
 - setup the default cache to be locmem and with a timeout of 1 second
 {{{
 >> cache.set('key', 10, 300)
 >> time.sleep(1)
 >> cache.get('key')
 10
 >> cache.incr('key')
 >> time.sleep(1)
 >> cache.get('key')
 None
 }}}

 The cache should still contain the key at the last line.

 The problem comes from the implementation of incr() in base.py which uses
 get() and set() to implement incr(). Since set() is called without a
 timeout, the cache default time is used.

--

Comment:

 I'm assuming you consider this a bug, and would like it to not reset the
 expiry time ;)  What's the justification for that behavior, memcached does
 it?

-- 
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] #16858: incr() on locmem cache resets the expiry time

[Django]

#16858: incr() on locmem cache resets the expiry time
--+-
 Reporter:  boxm  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  Core (Cache system)
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+-
 On the locmem cache backend, calling incr() causes the key's timeout value
 to be reset to the default for the cache.

 To reproduce:
 - setup the default cache to be locmem and with a timeout of 1 second
 >> cache.set('key', 10, 300)
 >> time.sleep(1)
 >> cache.get('key')
 10
 >> cache.incr('key')
 >> time.sleep(1)
 >> cache.get('key')
 None

 The cache should still contain the key at the last line.

 The problem comes from the implementation of incr() in base.py which uses
 get() and set() to implement incr(). Since set() is called without a
 timeout, the cache default time 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.

Re: [Django] #16812: FieldsTests.test_urlfield_10 fails since r16760

[Django]

#16812: FieldsTests.test_urlfield_10 fails since r16760
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Forms
Version:  SVN|   Severity:  Release blocker
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_better_patch:  0 => 1


Comment:

 Note that this probably isn't a perfect way to quote an URL (I haven't
 checked the RFC yet).

 Other components should be quoted too, but with some exclusions. For
 instance, don't quote `&` and `=` in `query`: `query = urllib.quote(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] #16812: FieldsTests.test_urlfield_10 fails since r16760

[Django]

#16812: FieldsTests.test_urlfield_10 fails since r16760
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Forms
Version:  SVN|   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:

 Django masks the exception, to get the original traceback you can edit
 `django/core/validators.py` as follows:
 {{{
 Index: django/core/validators.py
 ===
 --- django/core/validators.py   (révision 16831)
 +++ django/core/validators.py   (copie de travail)
 @@ -126,6 +126,7 @@
  else:
  opener.open(req)
  except ValueError:
 +raise
  raise ValidationError(_(u'Enter a valid URL.'),
 code='invalid')
  except: # urllib2.URLError, httplib.InvalidURL, etc.
  raise broken_error
 }}}

 Django converts unicode `url` to `utf-8`, which is correct. However, it
 doesn't URLencode it. At least the path should be urlencoded. Attached
 patch works under python 2.5. 2.6 and 2.7.

 Since this fixes a broken test, it doesn't need an additional test.

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

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

Re: [Django] #14512: Documentation & tools for decorating class-based-views.

[Django]

#14512: Documentation & tools for decorating class-based-views.
---+---
   Reporter:  lrekucki |  Owner:  lrekucki
   Type:  New feature  | Status:  reopened
  Milestone:  1.4  |  Component:  Generic views
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  class-based-views
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by jacob):

 Other committers: please hold off on committing this for now: I think I've
 figured out a way to make decorators Just Work™ for classes and for
 functions, obviating the need for `view_decorator`, mixins, or anything.
 I'd like to see if that technique is viable before introducing any of
 these workarounds. See http://groups.google.com/group/django-
 developers/browse_thread/thread/8eb7db7a70896185 for the discussion.

-- 
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] #16856: Add a way to clear select_related

[Django]

#16856: Add a way to clear select_related
-+-
   Reporter:  carljm |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 There was a clear consensus on this API in #django-dev.

-- 
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] #8391: slugify template filter poorly encodes non-English strings

[Django]

#8391: slugify template filter poorly encodes non-English strings
+-
   Reporter:  bjornkri  |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  Template system
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-

Comment (by mitar):

 Ups. That was a bug. [https://bitbucket.org/mitar/django-
 missing/src/d17bac5f8a5a/missing/templatetags/url_tags.py Fixed version of
 slugify2].

-- 
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] #16857: new flush db signal

[Django]

#16857: new flush db signal
--+
 Reporter:  michaelritsema@…  |  Owner:  nobody
 Type:  New feature   | Status:  new
Milestone:|  Component:  Core (Management commands)
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+
 It would be nice to be able to distinguish between a flush db and a syncdb
 during testing. I use the post_syncdb trigger to load data, it seems odd
 that I have to do this twice at the beginning of testing. I can't find
 anyway to distinguish between the two.

-- 
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] #14512: Documentation & tools for decorating class-based-views.

[Django]

#14512: Documentation & tools for decorating class-based-views.
---+---
   Reporter:  lrekucki |  Owner:  lrekucki
   Type:  New feature  | Status:  reopened
  Milestone:  1.4  |  Component:  Generic views
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  class-based-views
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by dstufft):

 ptone asked me to include an example:

 This example is obviously not in a state to be included directly, but this
 is basically what I mean: https://gist.github.com/1220199

 It's simple, doesn't require extra helper code to make it work, and anyone
 who can grok CBV's can get how that works without requiring deciphering
 multiple layers of decorator magic.

-- 
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] #5865: cycle template tag should accept a single argument

[Django]

#5865: cycle template tag should accept a single argument
---+-
   Reporter:  gwilson  |  Owner:  munhitsu
   Type:  New feature  | Status:  reopened
  Milestone:   |  Component:  Template system
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  1
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+-
Changes (by ptone):

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


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

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

[Django] #16856: Add a way to clear select_related

[Django]

#16856: Add a way to clear select_related
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:  New feature  |   Status:  new
Milestone:   |Component:  Database
  Version:  SVN  |  layer (models, ORM)
 Keywords:   | Severity:  Normal
Has patch:  0| Triage Stage:
  Needs tests:  0|  Unreviewed
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
 If you've got a queryset that has had select_related called on it (maybe
 passed to you from some other code you don't control) there's currently no
 documented way to clear out select_related.

 One possible API is .select_related(None), which mirrors how .defer()
 works.

 The combination of this and #16855 would make .select_related() and
 .defer() more consistent with each other, which would be nice.

-- 
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] #16854: AttributeError on syncdb

[Django]

#16854: AttributeError on syncdb
-+-
   Reporter:  desh   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Management
Version:  SVN|  commands)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  syncdb management
Needs documentation:  0  |  contenttypes
Patch needs improvement:  0  |  Has patch:  1
  UI/UX:  0  |Needs tests:  0
 |  Easy pickings:  1
-+-
Changes (by carljm):

 * version:  1.3 => SVN
 * stage:  Unreviewed => Accepted


Comment:

 It's pretty clear from looking at the relevant code that this is only on
 trunk, introduced in r16739. Accepting.

 desh, if you are actually seeing it on 1.3 please note 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] #16855: select_related doesn't chain as expected

[Django]

#16855: select_related doesn't chain as expected
-+-
   Reporter:  Leo|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  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 carljm):

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


Comment:

 Agreed.

-- 
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] #16851: Accessing a forms field value in a template

[Django]

#16851: Accessing a forms field value in a template
-+---
   Reporter:  from_a_far@…   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Milestone: |  Component:  Documentation
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:  1
  UI/UX:  0  |
-+---
Changes (by carljm):

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


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

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

Re: [Django] #8060: Admin Inlines do not respect user permissions

[Django]

#8060: Admin Inlines do not respect user permissions
-+-
   Reporter: |  Owner:  dgouldin
  p.patruno@…| Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  inlines User
 Resolution: |  authentication
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by carljm):

 * stage:  Design decision needed => Accepted


Comment:

 Preventing a user from accessing the change view for an object they do
 have permissions on, or removing all inlines, just because they lack
 permissions on one inline, is clearly wrong.

 Removing an inline if the user doesn't have full permissions on the
 inlined model is definitely preferable to that.

 Ideally, inlines should respect all three individual permissions properly,
 just like the rest of the admin does. If you have only add permission, you
 should be able to add a new inline but not see existing ones (we don't
 need to do readonly_fields - the precedent set by the rest of the admin is
 that you only get to see existing records at all if you can change them).
 If you have change but not add permission, you can change existing inlines
 but not add new ones. And you only get the delete checkbox if you have
 delete permission.

-- 
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] #14512: Documentation & tools for decorating class-based-views.

[Django]

#14512: Documentation & tools for decorating class-based-views.
---+---
   Reporter:  lrekucki |  Owner:  lrekucki
   Type:  New feature  | Status:  reopened
  Milestone:  1.4  |  Component:  Generic views
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  class-based-views
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by dstufft):

 * cc: dstufft (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.

[Django] #16855: select_related doesn't chain as expected

[Django]

#16855: select_related doesn't chain as expected
-+--
 Reporter:  Leo  |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  Database layer (models, ORM)
  Version:  SVN  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+--
 If I'm doing something like:

 {{{#!python
 Foo.objects.select_related('fieldone').select_related('fieldtwo')
 }}}

 I would expect the select related to function on both `fieldone` and
 `fieldtwo`. What actually happens is that the select_related only works on
 `fieldtwo`. This is a problem for compositing queries at runtime (for
 example in search filters) and is a departure from how I would expect
 queryset methods to work.

 If the design decision is to keep it this way, there should be a note in
 the docs pointing this 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] #14512: Documentation & tools for decorating class-based-views.

[Django]

#14512: Documentation & tools for decorating class-based-views.
---+---
   Reporter:  lrekucki |  Owner:  lrekucki
   Type:  New feature  | Status:  reopened
  Milestone:  1.4  |  Component:  Generic views
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  class-based-views
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by dstufft):

 I for one think this is the wrong way of allowing someone to add something
 like requiring login to a class based view.

 For one
 {{{
 #!python
 @view_decorator(login_required)
 class ProtectedView(TemplateView):
 template_name = 'secret.html'
 }}}

 Is ugly and janky. requiring a @view_decorator makes CBV's uglier and a
 second class citizen decorator wise because of legacy code. Using a
 decorator I would also argue is the wrong approach. There is already a
 well tested, backwards compatible (with regards to python), and language
 agnostic method of changing the behavior of a classes methods.

 {{{
 #!python
 class ProtectedView(LoginRequired, TemplateView):
 template_name = 'secret.html'
 }}}

 You can make a Mixin backwards compatible with function based views easily
 enough, and this puts all the information about where the functionality of
 a particular view is coming from (in the definition of the class, where it
 belongs in my opinion). Which is all you are really doing with your
 view_decorator approach, you are just hiding the fact you are mixing in
 functionality by using a decorator and dynamically subclassing and mixing
 in.

 Additionally using a Mixin makes it easy to break the (now) decorators
 into multiple methods and allow the end user to easily modify a portion of
 it to fit their view. Currently with function based decorators this isn't
 possible, it's all or nothing. You can solve this problem by making class
 based decorators (which is sort of a Mixin anyways), but then you are
 adding even more code just so you can add a mixin via @ instead of the
 normal method of mixing in. An example use case of this is the guy who
 recently on the mailing list wanted login_required to check is_active.
 Currently his only option is to rewrite the login_required decorator.

-- 
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] #14512: Documentation & tools for decorating class-based-views.

[Django]

#14512: Documentation & tools for decorating class-based-views.
---+---
   Reporter:  lrekucki |  Owner:  lrekucki
   Type:  New feature  | Status:  reopened
  Milestone:  1.4  |  Component:  Generic views
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  class-based-views
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by ptone):

 In an effort to keep momentum on this issue, I was highlighting this
 approach in #django-dev

 There was the desire to try to keep a simple unified approach to function-
 based and class-based views decoration

 Accepting the assumption that you are only talking about decorating views
 - the following alternative approach was suggested by Jacob:
 https://gist.github.com/1219822

 This removes the need for the double call ()() syntax in Python < 2.6

 There were some subsequent comments that this would perhaps better live
 outside contrib.auth as some sort of general view utility.

 https://gist.github.com/1219822

 Would be good to see brief pro/con consideration of these two approaches -
 keeping as accepted, but if this stalls, will need to unfortunately move
 to DDN, at which point I will try to summarize for list.

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

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

Re: [Django] #16850: Testsuite failing on JSON serialization

[Django]

#16850: Testsuite failing on JSON serialization
-+-
   Reporter:  Raphael|  Owner:  nobody
  Hertzog | Status:  new
   Type:  Bug|  Component:  Core
  Milestone: |  (Serialization)
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 carljm):

 * stage:  Unreviewed => Accepted


Comment:

 We should just use that use_decimal=False option, then. I don't see a
 compelling case for changing the dumped output to use numbers instead of
 strings for decimals, given that it can lose precision in the round-trip.

-- 
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] #16852: "Save and continue editing" and "Save and add another" swapped in 1.3.1

[Django]

#16852: "Save and continue editing" and "Save and add another" swapped in 1.3.1
+-
   Reporter:  jocmeh|  Owner:  julien
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Release blocker
 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 julien):

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


Comment:

 Thanks for the report. My bad was having backported it to r16684, too.
 This is minor, but it needs to be rectified.

-- 
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] #16838: First InlineModelAdmin not displaying "Add Another" link when related_name='+'

[Django]

#16838: First InlineModelAdmin not displaying "Add Another" link when
related_name='+'
+---
   Reporter:  jamesp|  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  contrib.admin
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---

Comment (by carljm):

 #13407 was a recent bug in the same area, likely related.

-- 
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] #16838: First InlineModelAdmin not displaying "Add Another" link when related_name='+'

[Django]

#16838: First InlineModelAdmin not displaying "Add Another" link when
related_name='+'
+---
   Reporter:  jamesp|  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  contrib.admin
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---
Changes (by carljm):

 * stage:  Unreviewed => Accepted


Comment:

 Verified. Note that `related_name` actually should be on the FKs, not the
 CharFields ;-) Thanks 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] #16854: AttributeError on syncdb

[Django]

#16854: AttributeError on syncdb
-+-
   Reporter:  desh   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Management
Version:  1.3|  commands)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  syncdb management
  Unreviewed |  contenttypes
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  1
-+-
Changes (by Alex):

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


Comment:

 This was marked as version 1.3, however I suspect that this is a
 regression on trunk, is that correct?

-- 
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] #8391: slugify template filter poorly encodes non-English strings

[Django]

#8391: slugify template filter poorly encodes non-English strings
+-
   Reporter:  bjornkri  |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  Template system
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-

Comment (by yasar11732@…):

 Above slugify2 function won't fix #16853.

 {{{
 # -*- coding: utf-8 -*-
 import sys
 import re

 from django.utils import encoding

 TURKISH_MAP = {
 u'ş':'s', u'Ş':'S', u'ı':'i', u'İ':'I', u'ç':'c', u'Ç':'C', u'ü':'u',
 u'Ü':'U',
 u'ö':'o', u'Ö':'O', u'ğ':'g', u'Ğ':'G'
 }

 ALL_DOWNCODE_MAPS = [
 TURKISH_MAP,
 ]

 class Downcoder(object):
 map = {}
 regex = None

 def __init__(self):
 self.map = {}
 chars = u''

 for lookup in ALL_DOWNCODE_MAPS:
 for c, l in lookup.items():
 self.map[c] = l
 chars += encoding.force_unicode(c)

 self.regex = re.compile(ur'[' + chars + ']|[^' + chars + ']+',
 re.U)

 downcoder = Downcoder()

 def downcode(value):
 downcoded = u''
 pieces = downcoder.regex.findall(value)

 if pieces:
 for p in pieces:
 mapped = downcoder.map.get(p)
 if mapped:
 downcoded += mapped
 else:
 downcoded += p
 else:
 downcoded = value

 return value

 def slugify2(value):
 """
 Normalizes string, converts to lowercase, removes non-alpha
 characters,
 and converts spaces to hyphens.
 """
 import unicodedata
 value = downcode(value)
 value = unicodedata.normalize('NFD', value).encode('ascii', 'ignore')
 value = unicode(re.sub('[^\w\s-]', '', value).strip().lower())
 return re.sub('[-\s]+', '-', value)

 print(slugify2(u"Işık ılık süt iç"))


 }}}

 This prints "isk-lk-sut-ic", but expected value is, "isik-ilik-sut-ic".

-- 
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] #16850: Testsuite failing on JSON serialization

[Django]

#16850: Testsuite failing on JSON serialization
-+-
   Reporter:  Raphael|  Owner:  nobody
  Hertzog | Status:  new
   Type:  Bug|  Component:  Core
  Milestone: |  (Serialization)
Version:  1.3|   Severity:  Normal
 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 Raphaël Hertzog ):

 Note that the comment above was made by the simplejson author/maintainer
 (see
 https://github.com/simplejson/simplejson/issues/17#issuecomment-2105920).

-- 
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] #8391: slugify template filter poorly encodes non-English strings

[Django]

#8391: slugify template filter poorly encodes non-English strings
+-
   Reporter:  bjornkri  |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  Template system
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-

Comment (by mitar):

 You can take the above slugify2 function.

-- 
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] #16854: AttributeError on syncdb

[Django]

#16854: AttributeError on syncdb
-+-
 Reporter:  desh |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  Core (Management
  Version:  1.3  |  commands)
 Keywords:  syncdb management|   Severity:  Normal
  contenttypes   |   Triage Stage:  Unreviewed
Has patch:  1|  Easy pickings:  1
UI/UX:  0|
-+-
 When one have stale content types and trying to do syncdb, following error
 occurs:

 {{{
 Syncing...
 Creating tables ...
 Traceback (most recent call last):
   File "./manage.py", line 9, in 
 execute_manager(settings)
 ... traceback
   File "/usr/lib/python2.6/dist-
 packages/django/contrib/contenttypes/management.py", line 47, in
 update_contenttypes
 content_type_display = '\n'.join(['%s | %s' % (ct.app_label,
 ct.model) for ct in content_types])
 AttributeError: 'unicode' object has no attribute 'app_label'
 }}}

 This is because of type mismatch in list comprehension: content_types was
 list of objects, but now it is a dict with app_labels as keys and models
 as values.

-- 
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] #16850: Testsuite failing on JSON serialization

[Django]

#16850: Testsuite failing on JSON serialization
-+-
   Reporter:  Raphael|  Owner:  nobody
  Hertzog | Status:  new
   Type:  Bug|  Component:  Core
  Milestone: |  (Serialization)
Version:  1.3|   Severity:  Normal
 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 anonymous):

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


Comment:

 It looks like the problem here is that Django expects that decimal objects
 will get converted to string (by its default method) instead of a JSON
 number. This change to the default options was made for usability reasons
 in simplejson 2.2.0, most people want decimals to get encoded as numbers
 even though there's a possible loss of precision if decoded on the other
 end without the right options. This behavior can be turned back off with
 use_decimal=False on encode. The version embedded in Django also supports
 this option (default False rather than True), so explicitly specifying
 this behavior would be compatible with whichever version of dump/dumps
 ends up getting 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.

Re: [Django] #3011: Allow for extendable auth_user module

[Django]

#3011: Allow for extendable auth_user module
-+--
   Reporter:  nowell strite  |  Owner:  nobody
   Type:  New feature| Status:  new
  Milestone: |  Component:  contrib.auth
Version: |   Severity:  Normal
 Resolution: |   Keywords:  auth_user
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  1
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+--
Changes (by frankoid):

 * cc: frankoid (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] #16709: Allow username to be longer than 30 characters to use e-mailaddresses as username

[Django]

#16709: Allow username to be longer than 30 characters to use e-mailaddresses as
username
-+--
   Reporter:  wim@…  |  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  contrib.auth
Version:  1.3|   Severity:  Normal
 Resolution:  wontfix|   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 frankoid):

 * cc: frankoid (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] #16853: Slugify removes dotless "i"

[Django]

#16853: Slugify removes dotless "i"
+-
   Reporter:  yasar11732@…  |  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  Template system
Version:  1.3   |   Severity:  Normal
 Resolution:  duplicate |   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 ptone):

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


Comment:

 This seems more of a specific case of #8391, it would be worth adding your
 notes to that ticket.  There are several approaches on that ticket that
 try to solve this problem more generally

-- 
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] #8391: slugify template filter poorly encodes non-English strings

[Django]

#8391: slugify template filter poorly encodes non-English strings
+-
   Reporter:  bjornkri  |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  Template system
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-
Changes (by ptone):

 * stage:  Design decision needed => Accepted


Comment:

 see #16853 for a Turkish case

 Seems that there have been no objections to the downcode then slugify
 approach.

 This seems ready for someone to take a shot at implementing that approach
 in 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] #16837: when logging in into the admin

[Django]

#16837: when logging in into the admin
-+-
   Reporter:  Wim|  Owner:  nobody
  Feijen  | Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by jocmeh):

 What about... "Please enter the correct username and password for a staff
 account."?

-- 
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] #16853: Slugify removes dotless "i"

[Django]

#16853: Slugify removes dotless "i"
--+-
 Reporter:  yasar11732@…  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  Template system
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+-
 Hi,

 As a Turkish Django user, I need to use slugify with strings containing
 Turkish dotless i. As most Turkish developers, I also expect it to convert
 that character to ascii "i", however, It just disappears in resulting
 string. As for now, I am using a workaround I have found in here:
 http://gokmengorgen.net/post/detail/djangoda-turkce-destekli-slugify/

 Here is the workaround I currently use:
 {{{
 def slugify_unicode(value):
 value = value.replace(u'\u0131', 'i')
 value = normalize('NFKD', value).encode('ascii', 'ignore')
 value = unicode(sub('[^\w\s-]', '', value).strip().lower())
 return sub('[-\s]+', '-', value)
 }}}

-- 
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] #16852: "Save and continue editing" and "Save and add another" swapped in 1.3.1

[Django]

#16852: "Save and continue editing" and "Save and add another" swapped in 1.3.1
+---
 Reporter:  jocmeh  |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  contrib.admin
  Version:  1.3 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
UI/UX:  0   |
+---
 It seems that the IE7 specific fix from changeset 16683
 (https://code.djangoproject.com/changeset/16683) causes the "Save and
 continue editing" and "Save and add another" to be swapped from place in
 all browsers. Shouldn't IE specific fixes be in ie.css instead of
 forms.css?

-- 
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] #16851: Accessing a forms field value in a template

[Django]

#16851: Accessing a forms field value in a template
---+---
 Reporter:  from_a_far@…   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Documentation
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
UI/UX:  0  |
---+---
 Please could someone put in the documentation that you can access a forms
 field value in a template by using the following

 {{{
 {{ form.apple.value }}
 }}}

 I only ask because I couldn't find anything on the web about and it's only
 by trying it that I found it worked

-- 
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] #9519: Add QuerySet.bulk_delete() that issues only a single SQL query

[Django]

#9519: Add QuerySet.bulk_delete() that issues only a single SQL query
-+-
   Reporter:  Tarken |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  database, queryset,
   Triage Stage:  Accepted   |  delete
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by tobias):

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


-- 
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] #8060: Admin Inlines do not respect user permissions

[Django]

#8060: Admin Inlines do not respect user permissions
-+-
   Reporter: |  Owner:  dgouldin
  p.patruno@…| Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  inlines User
 Resolution: |  authentication
   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 sjaensch):

 * cc: sjaensch (added)
 * ui_ux:   => 0
 * easy:   => 0


Comment:

 I'd like to fix this bug by introducing those permission checks at the
 ModelAdmin level. Inlines where the user does not have create/edit
 privileges would be removed. ubernostrum said that some design thought
 would be needed. Here's my rationale for this implementation:

 While admin.py states that models should be edited together with their
 inlines, this does not override the permission settings. Permissions are
 always more important than admin configuration. Inline editing is
 something that's enabled when writing the software, permissions are set
 during operation. So either the user cannot access the change view because
 he does not have the necessary permissions for some inline model or we do
 remove inline forms for the models where the user lacks sufficient
 permissions. Obviously, the latter solution would be preferable if it can
 be implemented reliably.

 If there's consensus on this implementation, I'd like to go forward and
 develop a patch. I already have working prototype code since we needed
 this 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] #6485: Split off file-serving capability

[Django]

#6485: Split off file-serving capability
-+-
   Reporter:  Bastian|  Owner:  nobody
  Kleineidam   | Status:  closed
   Type:  New|  Component:  Uncategorized
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution:  wontfix|Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by guettli):

 * cc: hv@… (removed)


-- 
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] #2131: HttpResponseSendFile for serving static files handler-specific sendfile mechanism

[Django]

#2131: HttpResponseSendFile for serving static files handler-specific sendfile
mechanism
-+-
   Reporter: |  Owner:  ccahoon
  ymasuda[at]ethercube.com   | Status:  new
   Type:  New|  Component:  Core (Other)
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by guettli):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 `SendFile support` in django would be nice. But I am happy this now:
 https://github.com/johnsensible/django-sendfile


 {{{
 This is a wrapper around web-server specific methods for sending files to
 web clients.
 This is useful when Django needs to check permissions associated files,
 but does not want
 to serve the actual bytes of the file itself. i.e. as serving large files
 is not what Django is made for.
 }}}

-- 
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] #16850: Testsuite failing on JSON serialization

[Django]

#16850: Testsuite failing on JSON serialization
-+-
 Reporter:  Raphael Hertzog  |  Owner:  nobody
  | Status:  new
 Type:  Bug  |  Component:  Core
Milestone:   |  (Serialization)
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+-
 Trying to build Django 1.3.1 on Debian unstable with python 2.6 and
 python-simplejson 2.2.0 installed I get two test suite failures.

 Without python-simplejson

 {{{
 ==
 ERROR: test_serialize_unicode
 (modeltests.serializers.tests.JsonSerializerTestCase)
 Tests that unicode makes the roundtrip intact
 --
 Traceback (most recent call last):
   File "/home/rhertzog/deb/pkg/TEAMS/build-area/python-
 django-1.3.1/tests/modeltests/serializers/tests.py", line 172, in
 test_serialize_unicode
 obj_list = list(serializers.deserialize(self.serializer_name,
 serial_str))
   File "/home/rhertzog/deb/pkg/TEAMS/build-area/python-
 django-1.3.1/django/core/serializers/json.py", line 35, in Deserializer
 for obj in PythonDeserializer(simplejson.load(stream), **options):
   File "/home/rhertzog/deb/pkg/TEAMS/build-area/python-
 django-1.3.1/django/core/serializers/python.py", line 128, in Deserializer
 data[field.name] = field.to_python(field_value)
   File "/home/rhertzog/deb/pkg/TEAMS/build-area/python-
 django-1.3.1/django/db/models/fields/__init__.py", line 761, in to_python
 return decimal.Decimal(value)
   File "/usr/lib/python2.6/decimal.py", line 649, in __new__
 "First convert the float to a string")
 TypeError: Cannot convert float to Decimal.  First convert the float to a
 string

 ==
 ERROR: test_json_serializer
 (regressiontests.serializers_regress.tests.SerializerTests)
 --
 Traceback (most recent call last):
   File "/home/rhertzog/deb/pkg/TEAMS/build-area/python-
 django-1.3.1/django/utils/functional.py", line 55, in _curried
 return _curried_func(*(args+moreargs), **dict(kwargs, **morekwargs))
   File "/home/rhertzog/deb/pkg/TEAMS/build-area/python-
 django-1.3.1/tests/regressiontests/serializers_regress/tests.py", line
 373, in serializerTest
 for obj in serializers.deserialize(format, serialized_data):
   File "/home/rhertzog/deb/pkg/TEAMS/build-area/python-
 django-1.3.1/django/core/serializers/json.py", line 35, in Deserializer
 for obj in PythonDeserializer(simplejson.load(stream), **options):
   File "/home/rhertzog/deb/pkg/TEAMS/build-area/python-
 django-1.3.1/django/core/serializers/python.py", line 128, in Deserializer
 data[field.name] = field.to_python(field_value)
   File "/home/rhertzog/deb/pkg/TEAMS/build-area/python-
 django-1.3.1/django/db/models/fields/__init__.py", line 761, in to_python
 return decimal.Decimal(value)
   File "/usr/lib/python2.6/decimal.py", line 649, in __new__
 "First convert the float to a string")
 TypeError: Cannot convert float to Decimal.  First convert the float to a
 string
 }}}

 I also filed https://github.com/simplejson/simplejson/issues/17 because
 I'm not sure whether Django is improperly using simplejson or whether
 simplejson has 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] #16838: First InlineModelAdmin not displaying "Add Another" link when related_name='+' (was: First InlineModelAdmin not displaying "Add Another" link)

[Django]

#16838: First InlineModelAdmin not displaying "Add Another" link when
related_name='+'
--+---
   Reporter:  jamesp  |  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  contrib.admin
Version:  SVN |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---

-- 
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] #16838: First InlineModelAdmin not displaying "Add Another" link

[Django]

#16838: First InlineModelAdmin not displaying "Add Another" link
--+---
   Reporter:  jamesp  |  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  contrib.admin
Version:  SVN |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by jamesp):

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


Comment:

 I got your results with the code above and realized I needed to provide
 more information about my models.

 If you set up the ForeignKeys with related_name='+', then you get the
 behavior I described:

 {{{

 from django.db import models


 class Author(models.Model):
 name = models.CharField(max_length=100)


 class Subject(models.Model):
 name = models.CharField(max_length=100, related_name='+')
 author = models.ForeignKey(Author)


 class Book(models.Model):
 title = models.CharField(max_length=100, related_name='+')
 author = models.ForeignKey(Author)

 }}}

-- 
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] #16849: loaddata - --help text incorrect?

[Django]

#16849: loaddata - --help text incorrect?
---+---
 Reporter:  EvilDMP|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Documentation
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+---
 manage.py loaddata --help says: Verbosity level; 0=minimal output,
 1=normal output, 2=all output

 However, an error message also says: option -v: invalid choice: '4'
 (choose from '0', '1', '2', '3')

 -v 3 does seem to work.

 Does the --help text need to be amended?

-- 
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] r16831 - django/trunk/django/template

[noreply]

Author: carljm
Date: 2011-09-15 00:26:35 -0700 (Thu, 15 Sep 2011)
New Revision: 16831

Modified:
   django/trunk/django/template/response.py
Log:
Fixed #16848 - Adjusted SimpleTemplateResponse.__init__ to be less brittle.

Could have reverted r16830 instead, but HttpResponse shouldn't have to dance
around and do non-obvious things to keep TemplateResponse happy,
TemplateResponse should be robust against the possibility that
HttpResponse.__init__ might set self.content.

Modified: django/trunk/django/template/response.py
===
--- django/trunk/django/template/response.py2011-09-14 23:58:12 UTC (rev 
16830)
+++ django/trunk/django/template/response.py2011-09-15 07:26:35 UTC (rev 
16831)
@@ -21,10 +21,6 @@
 self.template_name = template
 self.context_data = context
 
-# _is_rendered tracks whether the template and context has been
-# baked into a final response.
-self._is_rendered = False
-
 self._post_render_callbacks = []
 
 # content argument doesn't make sense here because it will be replaced
@@ -33,6 +29,14 @@
 super(SimpleTemplateResponse, self).__init__('', mimetype, status,
  content_type)
 
+# _is_rendered tracks whether the template and context has been baked
+# into a final response.
+# Super __init__ doesn't know any better than to set self.content to
+# the empty string we just gave it, which wrongly sets _is_rendered
+# True, so we initialize it to False after the call to super __init__.
+self._is_rendered = False
+
+
 def __getstate__(self):
 """Pickling support function.
 

-- 
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] #16848: r16830 creates a lot of failures in the test suite

[Django]

#16848: r16830 creates a lot of failures in the test suite
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  HTTP handling
Version:  1.3|   Severity:  Release blocker
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by carljm):

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


Comment:

 In [16831]:
 {{{
 #!CommitTicketReference repository="" revision="16831"
 Fixed #16848 - Adjusted SimpleTemplateResponse.__init__ to be less
 brittle.

 Could have reverted r16830 instead, but HttpResponse shouldn't have to
 dance
 around and do non-obvious things to keep TemplateResponse happy,
 TemplateResponse should be robust against the possibility that
 HttpResponse.__init__ might set self.content.
 }}}

-- 
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] #16705: r13746 makes invalid assumption that QUERY_STRING exists

[Django]

#16705: r13746 makes invalid assumption that QUERY_STRING exists
-+-
   Reporter:  raylu  |  Owner:  aaugustin
   Type:  Bug| Status:  new
  Milestone: |  Component:  Generic views
Version:  SVN|   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 ptone):

 * needs_tests:  1 => 0
 * stage:  Accepted => Ready for checkin


Comment:

 There could be objections to the changes to the test client, however they
 seem coupled pretty strongly to testing this patch.

 There are a couple small other fixes tacked in, these seem minor enough to
 allow as riders to this patch.

 patch applies to trunk@16829 - tests pass

-- 
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] #15126: Misleading error in ModelForm

[Django]

#15126: Misleading error in ModelForm
-+-
   Reporter:  ingo@… |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Forms
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:  modelform fields
   Triage Stage:  Accepted   |  attributeerror widget subset
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by ptone):

 * needs_better_patch:  0 => 1
 * ui_ux:   => 0
 * easy:   => 0


Comment:

 I think the test for str is reasonable.

 I think this would be better implemented in the __init__ of
 ModelFormOptions

 also the test should use assertRaises to actually test that the assertion
 is raised on instantiation, rather than fail after a class is defined,
 which doesn't actually test your code.

 A couple minor points:

 * I believe you don't need to test for None, isinstance should suffice

 * the error should be that the option should be a iterable of strings, not
 a single string - list is too specific here

 * You don't need to determine the type of the errant value, as you only
 raise the exception for str type anyway.

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

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

Re: [Django] #14512: Documentation & tools for decorating class-based-views.

[Django]

#14512: Documentation & tools for decorating class-based-views.
---+---
   Reporter:  lrekucki |  Owner:  lrekucki
   Type:  New feature  | Status:  reopened
  Milestone:  1.4  |  Component:  Generic views
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  class-based-views
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by roalddevries):

 * needs_better_patch:  1 => 0


Comment:

 You guys are right (SVN inexperience), I corrected 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.

Re: [Django] #16848: r16830 creates a lot of failures in the test suite

[Django]

#16848: r16830 creates a lot of failures in the test suite
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  HTTP handling
Version:  1.3|   Severity:  Release blocker
 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 ptone):

 * stage:  Unreviewed => Accepted


Comment:

 Yup - just ran into this while trying to review patches - badly badly
 broken :)

-- 
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] #16848: r16830 creates a lot of failures in the test suite

[Django]

#16848: r16830 creates a lot of failures in the test suite
---+---
 Reporter:  aaugustin  |Owner:  nobody
 Type:  Bug|   Status:  new
Milestone: |Component:  HTTP handling
  Version:  1.3| Severity:  Release blocker
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+---
 http://ci.django-cms.org/job/Django/251/

-- 
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] #15633: Bad documentation of post_syncdb signal

[Django]

#15633: Bad documentation of post_syncdb signal
-+-
   Reporter:  vzima  |  Owner:  justinlilly
   Type:  Bug| Status:  assigned
  Milestone: |  Component:  Documentation
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ptone):

 * stage:  Accepted => Ready for checkin


Comment:

 applied - built docs, reads well

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