[Changeset] r16704 - django/trunk/tests/regressiontests/admin_filters

[noreply]

Author: julien
Date: 2011-08-27 23:49:29 -0700 (Sat, 27 Aug 2011)
New Revision: 16704

Modified:
   django/trunk/tests/regressiontests/admin_filters/tests.py
Log:
Repaired an admin list_filter test that wasn't testing anything special.

Modified: django/trunk/tests/regressiontests/admin_filters/tests.py
===
--- django/trunk/tests/regressiontests/admin_filters/tests.py   2011-08-28 
02:37:16 UTC (rev 16703)
+++ django/trunk/tests/regressiontests/admin_filters/tests.py   2011-08-28 
06:49:29 UTC (rev 16704)
@@ -7,7 +7,8 @@
 from django.contrib.auth.admin import UserAdmin
 from django.contrib.auth.models import User
 from django.contrib.admin.views.main import ChangeList
-from django.contrib.admin import site, ModelAdmin, SimpleListFilter
+from django.contrib.admin import (site, ModelAdmin, SimpleListFilter,
+BooleanFieldListFilter)
 
 from models import Book
 
@@ -67,6 +68,9 @@
 list_filter = ('year', 'author', 'contributors', 'is_best_seller', 
'date_registered', 'no')
 ordering = ('-id',)
 
+class BookAdminWithTupleBooleanFilter(BookAdmin):
+list_filter = ('year', 'author', 'contributors', ('is_best_seller', 
BooleanFieldListFilter), 'date_registered', 'no')
+
 class DecadeFilterBookAdmin(ModelAdmin):
 list_filter = ('author', DecadeListFilterWithTitleAndParameter)
 ordering = ('-id',)
@@ -331,7 +335,7 @@
 self.verify_booleanfieldlistfilter(modeladmin)
 
 def test_booleanfieldlistfilter_tuple(self):
-modeladmin = BookAdmin(Book, site)
+modeladmin = BookAdminWithTupleBooleanFilter(Book, site)
 self.verify_booleanfieldlistfilter(modeladmin)
 
 def verify_booleanfieldlistfilter(self, modeladmin):

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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:  new
   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 chrisdoble):

 * ui_ux:   => 0


Comment:

 I've attached a patch that will hopefully make things clearer.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16716: Regression in admin changelist with failing related admin filters

[Django]

#16716: Regression in admin changelist with failing related admin filters
+-
   Reporter:  julien|  Owner:  nobody
   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 |
+-

Comment (by julien):

 OK, actually the regression only affects the case of
 "`?nonexistantrelated__blah=x`". I'll push a fix for that soon.

 The case of "`?existantrelated__nonexistantfield=x`" also crashes but
 that problem exists in 1.2 and 1.3 too, so it's not a regression. I'll
 create a separate ticket for 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.

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

[noreply]

Author: SmileyChris
Date: 2011-08-27 19:37:16 -0700 (Sat, 27 Aug 2011)
New Revision: 16703

Added:
   django/trunk/tests/regressiontests/utils/test_no_submodule.py
Modified:
   django/trunk/django/utils/module_loading.py
   django/trunk/tests/regressiontests/utils/module_loading.py
Log:
Fixed #15525 -- Custom template tags loading breaks whenever templatetags is a 
python file

Modified: django/trunk/django/utils/module_loading.py
===
--- django/trunk/django/utils/module_loading.py 2011-08-28 02:05:32 UTC (rev 
16702)
+++ django/trunk/django/utils/module_loading.py 2011-08-28 02:37:16 UTC (rev 
16703)
@@ -11,10 +11,16 @@
 return sys.modules[name] is not None
 except KeyError:
 pass
+try:
+package_path = package.__path__   # No __path__, then not a package.
+except AttributeError:
+# Since the remainder of this function assumes that we're dealing with
+# a package (module with a __path__), so if it's not, then bail here.
+return False
 for finder in sys.meta_path:
-if finder.find_module(name, package.__path__):
+if finder.find_module(name, package_path):
 return True
-for entry in package.__path__:  # No __path__, then not a package.
+for entry in package_path:
 try:
 # Try the cached finder.
 finder = sys.path_importer_cache[entry]

Modified: django/trunk/tests/regressiontests/utils/module_loading.py
===
--- django/trunk/tests/regressiontests/utils/module_loading.py  2011-08-28 
02:05:32 UTC (rev 16702)
+++ django/trunk/tests/regressiontests/utils/module_loading.py  2011-08-28 
02:37:16 UTC (rev 16703)
@@ -18,6 +18,8 @@
 def test_loader(self):
 "Normal module existence can be tested"
 test_module = import_module('regressiontests.utils.test_module')
+test_no_submodule = import_module(
+'regressiontests.utils.test_no_submodule')
 
 # An importable child
 self.assertTrue(module_has_submodule(test_module, 'good_module'))
@@ -40,6 +42,11 @@
 import types  # causes attempted import of regressiontests.utils.types
 
self.assertFalse(module_has_submodule(sys.modules['regressiontests.utils'], 
'types'))
 
+# A module which doesn't have a __path__ (so no submodules)
+self.assertFalse(module_has_submodule(test_no_submodule, 'anything'))
+self.assertRaises(ImportError, import_module,
+'regressiontests.utils.test_no_submodule.anything')
+
 class EggLoader(unittest.TestCase):
 def setUp(self):
 self.old_path = sys.path[:]

Added: django/trunk/tests/regressiontests/utils/test_no_submodule.py
===
--- django/trunk/tests/regressiontests/utils/test_no_submodule.py   
(rev 0)
+++ django/trunk/tests/regressiontests/utils/test_no_submodule.py   
2011-08-28 02:37:16 UTC (rev 16703)
@@ -0,0 +1 @@
+# Used to test for modules which don't have submodules.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15525: Custom template tags loading breaks whenever templatetags is a python file

[Django]

#15525: Custom template tags loading breaks whenever templatetags is a python 
file
+---
   Reporter:  the_drow  |Owner:  the_drow
   Type:  Bug   |   Status:  closed
  Milestone:  1.4   |Component:  Template system
Version:  1.2   | Severity:  Normal
 Resolution:  fixed | Keywords:  templatetags
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  1
Patch needs improvement:  1 |
+---
Changes (by SmileyChris):

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


Comment:

 In [16703]:
 {{{
 #!CommitTicketReference repository="" revision="16703"
 Fixed #15525 -- Custom template tags loading breaks whenever templatetags
 is a python file
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r16702 - django/trunk/docs/ref/models

[noreply]

Author: mtredinnick
Date: 2011-08-27 19:05:32 -0700 (Sat, 27 Aug 2011)
New Revision: 16702

Modified:
   django/trunk/docs/ref/models/instances.txt
Log:
Slightly rewrite @permalink and get_absolute_url() documentation.

Part 2 of the model instance documentation changes. Slightly tidied up
get_absolute_url() and @permalink documentation to collapse some of the
earlier versions into a preferred learning order. I'm still not
amazingly happy with this, but larger rewrites are needed to the URLconf
stuff across a few files before I can get it into the most natural
order, I suspect. That's a slightly longer-term project.

Modified: django/trunk/docs/ref/models/instances.txt
===
--- django/trunk/docs/ref/models/instances.txt  2011-08-28 02:05:20 UTC (rev 
16701)
+++ django/trunk/docs/ref/models/instances.txt  2011-08-28 02:05:32 UTC (rev 
16702)
@@ -414,60 +414,82 @@
 .. method:: Model.get_absolute_url()
 
 Define a ``get_absolute_url()`` method to tell Django how to calculate the
-canonical URL for an object. For example::
+canonical URL for an object. To callers, this method should appear to return a
+string that can be used to refer to the object over HTTP.
 
+For example::
+
 def get_absolute_url(self):
 return "/people/%i/" % self.id
 
-Django uses this in its admin interface. If an object defines
-``get_absolute_url()``, the object-editing page will have a "View on site"
-link that will jump you directly to the object's public view, according to
+(Whilst this code is correct and simple, it may not be the most portable way to
+write this kind of method. The :func:`permalink() decorator `,
+documented below, is usually the best approach and you should read that section
+before diving into code implementation.)
+
+One place Django uses ``get_absolute_url()`` is in the admin app. If an object
+defines this method, the object-editing page will have a "View on site" link
+that will jump you directly to the object's public view, as given by
 ``get_absolute_url()``.
 
-Also, a couple of other bits of Django, such as the :doc:`syndication feed
-framework `, use ``get_absolute_url()`` as a
-convenience to reward people who've defined the method.
+Similarly, a couple of other bits of Django, such as the :doc:`syndication feed
+framework `, use ``get_absolute_url()`` when it is
+defined. If it makes sense for your model's instances to each have a unique
+URL, you should define ``get_absolute_url()``.
 
 It's good practice to use ``get_absolute_url()`` in templates, instead of
 hard-coding your objects' URLs. For example, this template code is bad::
 
+
 {{ object.name }}
 
-But this template code is good::
+This template code is much better::
 
 {{ object.name }}
 
+The logic here is that if you change the URL structure of your objects, even
+for something simple such as correcting a spelling error, you don't want to
+have to track down every place that the URL might be created. Specify it once,
+in ``get_absolute_url()`` and have all your other code call that one place.
+
 .. note::
-The string you return from ``get_absolute_url()`` must contain only ASCII
-characters (required by the URI spec, `RFC 2396`_) that have been
-URL-encoded, if necessary. Code and templates using ``get_absolute_url()``
-should be able to use the result directly without needing to do any
-further processing. You may wish to use the
+The string you return from ``get_absolute_url()`` **must** contain only
+ASCII characters (required by the URI specfication, `RFC 2396`_) and be
+URL-encoded, if necessary.
+
+Code and templates calling ``get_absolute_url()`` should be able to use the
+result directly without any further processing. You may wish to use the
 ``django.utils.encoding.iri_to_uri()`` function to help with this if you
-are using unicode strings a lot.
+are using unicode strings containing characters outside the ASCII range at
+all.
 
 .. _RFC 2396: http://www.ietf.org/rfc/rfc2396.txt
 
 The ``permalink`` decorator
 ~~~
 
-The problem with the way we wrote ``get_absolute_url()`` above is that it
-slightly violates the DRY principle: the URL for this object is defined both
-in the URLconf file and in the model.
+The way we wrote ``get_absolute_url()`` above is a slightly violation of the
+DRY principle: the URL for this object is defined both in the URLconf file and
+in the model.
 
-You can further decouple your models from the URLconf using the ``permalink``
-decorator:
+You can decouple your models from the URLconf using the ``permalink`` 
decorator:
 
 .. function:: permalink()
 
-This decorator is passed the view function, a list of positional parameters and
-(optionally) a dictionary of named parameters. Django then works out the 
correct
-full URL path using the URLconf, substituting the parameters you have given 
into
-the URL. For example, if your URLconf contain

[Changeset] r16701 - django/trunk/docs/ref/models

[noreply]

Author: mtredinnick
Date: 2011-08-27 19:05:20 -0700 (Sat, 27 Aug 2011)
New Revision: 16701

Modified:
   django/trunk/docs/ref/models/instances.txt
Log:
Documentation edits for model instance docs.

First of two parts. Mostly adding cross references to other parts of the
documentation.

Modified: django/trunk/docs/ref/models/instances.txt
===
--- django/trunk/docs/ref/models/instances.txt  2011-08-27 04:55:02 UTC (rev 
16700)
+++ django/trunk/docs/ref/models/instances.txt  2011-08-28 02:05:20 UTC (rev 
16701)
@@ -23,7 +23,7 @@
 
 The keyword arguments are simply the names of the fields you've defined on your
 model. Note that instantiating a model in no way touches your database; for
-that, you need to ``save()``.
+that, you need to :meth:`~Model.save()`.
 
 .. _validating-objects:
 
@@ -39,31 +39,34 @@
 3. Validate the field uniqueness
 
 All three steps are performed when you call a model's
-``full_clean()`` method.
+:meth:`~Model.full_clean()` method.
 
-When you use a ``ModelForm``, the call to ``is_valid()`` will perform
-these validation steps for all the fields that are included on the
-form. (See the :doc:`ModelForm documentation
-` for more information.) You should only need
-to call a model's ``full_clean()`` method if you plan to handle
+When you use a :class:`~django.forms.ModelForm`, the call to
+:meth:`~django.forms.Form.is_valid()` will perform these validation steps for
+all the fields that are included on the form. See the :doc:`ModelForm
+documentation ` for more information. You should only
+need to call a model's :meth:`~Model.full_clean()` method if you plan to handle
 validation errors yourself, or if you have excluded fields from the
-ModelForm that require validation.
+:class:`~django.forms.ModelForm` that require validation.
 
 .. method:: Model.full_clean(exclude=None)
 
-This method calls ``Model.clean_fields()``, ``Model.clean()``, and
-``Model.validate_unique()``, in that order and raises a ``ValidationError``
-that has a ``message_dict`` attribute containing errors from all three stages.
+This method calls :meth:`Model.clean_fields()`, :meth:`Model.clean()`, and
+:meth:`Model.validate_unique()`, in that order and raises a
+:exc:`~django.core.exceptions.ValidationError` that has a ``message_dict``
+attribute containing errors from all three stages.
 
 The optional ``exclude`` argument can be used to provide a list of field names
-that can be excluded from validation and cleaning. ``ModelForm`` uses this
-argument to exclude fields that aren't present on your form from being
-validated since any errors raised could not be corrected by the user.
+that can be excluded from validation and cleaning.
+:class:`~django.forms.ModelForm` uses this argument to exclude fields that
+aren't present on your form from being validated since any errors raised could
+not be corrected by the user.
 
-Note that ``full_clean()`` will *not* be called automatically when you
-call your model's ``save()`` method, nor as a result of ``ModelForm``
-validation. You'll need to call it manually when you want to run model
-validation outside of a ``ModelForm``.
+Note that ``full_clean()`` will *not* be called automatically when you call
+your model's :meth:`~Model.save()` method, nor as a result of
+:class:`~django.forms.ModelForm` validation. You'll need to call it manually
+when you want to run one-step model validation for your own manually created
+models.
 
 Example::
 
@@ -79,9 +82,10 @@
 
 This method will validate all fields on your model. The optional ``exclude``
 argument lets you provide a list of field names to exclude from validation. It
-will raise a ``ValidationError`` if any fields fail validation.
+will raise a :exc:`~django.core.exceptions.ValidationError` if any fields fail
+validation.
 
-The second step ``full_clean()`` performs is to call ``Model.clean()``.
+The second step ``full_clean()`` performs is to call :meth:`Model.clean()`.
 This method should be overridden to perform custom validation on your model.
 
 .. method:: Model.clean()
@@ -100,11 +104,11 @@
 if self.status == 'published' and self.pub_date is None:
 self.pub_date = datetime.datetime.now()
 
-Any ``ValidationError`` raised by ``Model.clean()`` will be stored under a
-special key that is used for errors that are tied to the entire model instead
-of to a specific field. You can access these errors with ``NON_FIELD_ERRORS``::
+Any :exc:`~django.core.exceptions.ValidationError` exceptions raised by
+``Model.clean()`` will be stored in a special key error dictionary key,
+``NON_FIELD_ERRORS``, that is used for errors that are tied to the entire model
+instead of to a specific field::
 
-
 from django.core.exceptions import ValidationError, NON_FIELD_ERRORS
 try:
 article.full_clean()
@@ -115,15 +119,15 @@
 
 .. method:: Model.validate_unique(exclude=None)
 
-This method is similar to ``clean_fields``, but validates all uniq

Re: [Django] #16716: Regression in admin changelist with failing related admin filters

[Django]

#16716: Regression in admin changelist with failing related admin filters
+-
   Reporter:  julien|  Owner:  nobody
   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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16187: Refactor lookup system

[Django]

#16187: Refactor lookup system
-+-
   Reporter:  UloPe  |  Owner:  UloPe
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Database layer
  Milestone: |  (models, ORM)
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 julien):

 See also #11670 which tackles the conflicts that already exist with the
 'year', 'month' and 'day' lookups.

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

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

Re: [Django] #11670: Minor limitation using fields named 'year' in related searches.

[Django]

#11670: Minor limitation using fields named 'year' in related searches.
-+-
   Reporter:  andy@… |  Owner:
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by ramiro):

 See also ticket:8424#comment:13 for a similar problem and #16187 (possibly
 a long term solution). There is also another ticket or thread I can't find
 right now that proposed changing lookup names to all uppercase.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16716: Regression in admin changelist with failing related admin filters

[Django]

#16716: Regression in admin changelist with failing related admin filters
+---
   Reporter:  julien|  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
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 aaugustin):

 * stage:  Unreviewed => Accepted


Old description:

> This issue was collaterally revealed by the report in #16714. When an
> admin filter spanning relationships is invalid (e.g.
> "?nonexistentrelated__blah=", or
> "?existentrelated__nonexistentfield="), the changelist simply crashes
> and returns a 500 page. Up to Django 1.3, such an anomaly would cause a
> 302 redirection (accompanied with the "?e=1" querystring) instead of
> crashing.
>
> This regression possibly occurred when the Changelist class was slightly
> modified to build the custom admin filters feature.

New description:

 This issue was collaterally revealed by the report in #16714. When an
 admin filter spanning relationships is invalid (e.g.
 "`?nonexistentrelated__blah=`", or
 "`?existentrelated__nonexistentfield=`"), the changelist simply
 crashes and returns a 500 page. Up to Django 1.3, such an anomaly would
 cause a 302 redirection (accompanied with the "`?e=1`" querystring)
 instead of crashing.

 This regression possibly occurred when the `Changelist` class was slightly
 modified to build the custom admin filters feature.

--

Comment:

 Fixed formatting:)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16717: Add optional [as VARNAME] to trans template tag

[Django]

#16717: Add optional [as VARNAME] to trans template tag
-+-
   Reporter:  jezdez |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:
  Milestone: |  Internationalization
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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-
Changes (by aaugustin):

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


Comment:

 I had to refactor the test client a bit to write tests for this issue. I
 modified the default `environ` dictionary used by
 `django.test.client.RequestFactory` to contain exactly the variables
 required by the WSGI spec (plus `HTTP_COOKIE` because we want to support
 coookies here). The test suite still passes :)

 This change is slightly backwards incompatible. If third-party code uses
 Django's `RequestFactory` or `Client` for testing, and contains bugs
 similar to this one (ie. rely on a variable whose presence isn't
 guaranteed), its tests may fail after this change. I think this minor
 incompatibility is acceptable in the context of a bug fix. We could even
 argue it's a good thing to reveal unnoticed bugs.

 I made two other small changes:
 - `CommonMiddleware` used `if request.GET:` to test if there is a query
 string, and then accessed `request.META['QUERY_STRING']`. I replaced the
 check with: `if request.META.get('QUERY_STRING', ''):` to make it obvious
 that it's safe to access `request.META['QUERY_STRING']` at the next line.
 ''This changes very subtly the behavior of "append slash" and "prepend
 www" redirects. Previously, invalid query strings (like `'&'`) wouldn't be
 passed on. I can't say if it was intentional. Now they are. It's really an
 edge case and I think it's worth making this code more explicit. If you
 disagree, just don't commit this part.''
 - I stumbled upon an unrelated typo in the generic_views tests and fixed
 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.

Re: [Django] #7497: AppAdmin class for customizing app listing in admin index

[Django]

#7497: AppAdmin class for customizing app listing in admin index
-+---
   Reporter:  mrts   |  Owner:  nobody
   Type:  New feature| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Someday/Maybe  |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
Changes (by bendavis78):

 * cc: bendavis78 (added)
 * ui_ux:   => 0
 * easy:   => 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] #14051: Signals for transaction commit/rollback

[Django]

#14051: Signals for transaction commit/rollback
-+-
   Reporter:  Ask Solem  |  Owner:  nobody
  | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by dtrebbien):

 * cc: dtrebbien (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] #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:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  1 |  Easy pickings:  1
  UI/UX:  0 |
+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16516: Blocktrans should tolerate bad locale data

[Django]

#16516: Blocktrans should tolerate bad locale data
-+-
   Reporter:  simon29|  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:
  Milestone: |  Internationalization
Version:  1.3|   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 aaugustin):

 * stage:  Accepted => Ready for checkin


Comment:

 Oh right, you modified the signature in the docs, not in the code. How did
 I manage to mis-read 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] #3591: add support for custom app_label and verbose_name

[Django]

#3591: add support for custom app_label and verbose_name
-+-
   Reporter: |  Owner:  adrian
  jkocherhans| Status:  reopened
   Type:  New|  Component:  Core (Other)
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Fixed on   |  Easy pickings:  0
  a branch   |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-

Comment (by bendavis78):

 I noticed that in the admin, app titles are not run through .title(), as
 they were before the patch.  It should be:

 {{{#!python
 app_dict[app_label] = {
 'name':
 apps.find_app(app_label)._meta.verbose_name.title(),
 'app_url': app_label + '/',
 'has_module_perms': has_module_perms,
 'models': [model_dict],
 }}}
 (contrib/admin/sites.py, line 352)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16717: Add optional [as VARNAME] to trans template tag (was: Added optional [as VARNAME] to trans template tag)

[Django]

#16717: Add optional [as VARNAME] to trans template tag
-+-
   Reporter:  jezdez |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:
  Milestone: |  Internationalization
Version:  SVN|   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  |
-+-

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16717: Added optional [as VARNAME] to trans template tag

[Django]

#16717: Added optional [as VARNAME] to trans template tag
-+-
 Reporter:  jezdez   |Owner:  nobody
 Type:  New feature  |   Status:  new
Milestone:   |Component:
  Version:  SVN  |  Internationalization
 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
-+-
 Part of this year's SoC about form rendering
 (https://github.com/gregmuellegger/django/tree/soc2011/form-rendering) had
 to deal with dynamically changing the label of a form field in the
 template. For that purpose it's required to easily set a context variable
 with a translated string. E.g.:

 {{{
 {% trans "Your full name" as full_name %}
 ...
 {% formfield form.full_name with label=full_name %}
 ...
 }}}

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

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

Re: [Django] #11670: Minor limitation using fields named 'year' in related searches.

[Django]

#11670: Minor limitation using fields named 'year' in related searches.
-+-
   Reporter:  andy@… |  Owner:
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by julien):

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


Comment:

 This was again reported in #16714. Note that the same issue occurs with
 fields named 'month' and 'day' as well as 'year'.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16714: Can't filter by a related object's field called 'year', 'month' or 'day'

[Django]

#16714: Can't filter by a related object's field called 'year', 'month' or 'day'
-+-
   Reporter:  Clueless   |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution:  duplicate  |   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 julien):

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


Comment:

 ... and this was actually already reported in #11670 :-)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16714: Can't filter by a related object's field called 'year', 'month' or 'day' (was: Can't list_filter across a relationship on a SmallIntegerField)

[Django]

#16714: Can't filter by a related object's field called 'year', 'month' or 'day'
-+-
   Reporter:  Clueless   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (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 julien):

 * component:  contrib.admin => Database layer (models, ORM)
 * severity:  Release blocker => Normal


Old description:

> If you have a SmallIntegerField on a model that is related via a foreign
> key then you can't use that field as an option in list_filter. Doing so
> gives you the correct distinct options in the list page sidebar, but if
> you try to select any of them you receive a 302 redirect to /?e=1, as if
> you had used an unexpected query-string parameter.
>
> Here's a small example to try yourself:
>
> {{{
> # models.py
>
> from django.db import models
>
> class Rel(models.Model):
> year = models.SmallIntegerField(default=2010)
>
> class Src(models.Model):
> rel = models.ForeignKey(Rel)
>
> # admin.py
>
> from models import Rel, Src
> from django.contrib import admin
>
> class RelAdmin(admin.ModelAdmin):
> model = Rel
> list_filter = ('year',)
> admin.site.register(Rel, RelAdmin)
>
> class SrcAdmin(admin.ModelAdmin):
> model = Src
> list_filter = ('rel__year',)
> admin.site.register(Src, SrcAdmin)
> }}}
>
> I'm running Django 1.3, MySQL 5.5, on Arch Linux.

New description:

 UPDATE: The problem was originally reported in the admin but it appears it
 is rather an issue with the ORM -- see discussion below.

 If you have a SmallIntegerField on a model that is related via a foreign
 key then you can't use that field as an option in list_filter. Doing so
 gives you the correct distinct options in the list page sidebar, but if
 you try to select any of them you receive a 302 redirect to /?e=1, as if
 you had used an unexpected query-string parameter.

 Here's a small example to try yourself:

 {{{
 # models.py

 from django.db import models

 class Rel(models.Model):
 year = models.SmallIntegerField(default=2010)

 class Src(models.Model):
 rel = models.ForeignKey(Rel)

 # admin.py

 from models import Rel, Src
 from django.contrib import admin

 class RelAdmin(admin.ModelAdmin):
 model = Rel
 list_filter = ('year',)
 admin.site.register(Rel, RelAdmin)

 class SrcAdmin(admin.ModelAdmin):
 model = Src
 list_filter = ('rel__year',)
 admin.site.register(Src, SrcAdmin)
 }}}

 I'm running Django 1.3, MySQL 5.5, on Arch Linux.

--

Comment:

 Some further investigation shows that the problem has nothing to do with
 the type of field (SmallIntegerField, CharField, ...) -- the issue is in
 fact with the *name* of the field. The same "`TypeError: Related Field has
 invalid lookup: `" exception is raised for any fields named `year`,
 `month` or `day` on the related model. There is obviously some sort of
 conflict with the date lookup system, although it seems strange that the
 RelatedField isn't more smart about it. It's also strange that this issue
 didn't surface for all those years as the use case is quite trivial...

 There's still a regression with the way the admin changelist handles
 exceptions (the dev version crashes with a 500 instead of redirecting) and
 I've created a separate ticket for that: #16716.

 Let's keep this ticket here to discuss the ORM issue. This is not a
 regression though, as it already existed at least in 1.3, so I'm removing
 the 'blocker' flag.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16716: Regression in admin changelist with failing related admin filters

[Django]

#16716: Regression in admin changelist with failing related admin filters
+-
 Reporter:  julien  |Owner:  nobody
 Type:  Bug |   Status:  new
Milestone:  |Component:  contrib.admin
  Version:  1.3 | Severity:  Normal
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
 This issue was collaterally revealed by the report in #16714. When an
 admin filter spanning relationships is invalid (e.g.
 "?nonexistentrelated__blah=", or
 "?existentrelated__nonexistentfield="), the changelist simply crashes
 and returns a 500 page. Up to Django 1.3, such an anomaly would cause a
 302 redirection (accompanied with the "?e=1" querystring) instead of
 crashing.

 This regression possibly occurred when the Changelist class was slightly
 modified to build the custom admin filters 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] #16516: Blocktrans should tolerate bad locale data

[Django]

#16516: Blocktrans should tolerate bad locale data
-+-
   Reporter:  simon29|  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:
  Milestone: |  Internationalization
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by claudep):

 I added the deactivate_all call to allow for translation.override to set
 no translation at all. While I was completing the docs, I also realized
 that the *existing* deactivate parameter was undocumented. This last bit
 could have been part of a separate issue.

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

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

Re: [Django] #16516: Blocktrans should tolerate bad locale data

[Django]

#16516: Blocktrans should tolerate bad locale data
-+-
   Reporter:  simon29|  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:
  Milestone: |  Internationalization
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by aaugustin):

 To apply the patch, I first removed the chunk about the binary .mo file,
 and then I ran: `msgfmt -o
 tests/regressiontests/i18n/other/locale/fr/LC_MESSAGES/django.mo
 tests/regressiontests/i18n/other/locale/fr/LC_MESSAGES/django.po`

 The fix and the tests for the original issue are OK. You're right,
 `TEMPLATE_STRING_IF_INVALID` isn't a good idea here.

 Regarding the changes to `translation.override`, I don't understand why
 you added the `deactivate`; it isn't used anywhere by this patch; is it a
 fix for a separate issue?

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

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

Re: [Django] #16516: Blocktrans should tolerate bad locale data

[Django]

#16516: Blocktrans should tolerate bad locale data
-+-
   Reporter:  simon29|  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:
  Milestone: |  Internationalization
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by claudep):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #16516: Blocktrans should tolerate bad locale data

[Django]

#16516: Blocktrans should tolerate bad locale data
-+-
   Reporter:  simon29|  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:
  Milestone: |  Internationalization
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 claudep):

 * needs_better_patch:  0 => 1


Comment:

 I understand your concern about using the 'en' translation. But I'm
 opposed to use the TEMPLATE_STRING_IF_INVALID setting. If a translation
 has an error, the logical fallback is to use the original untranslated
 string, not the empty string (which is default for
 TEMPLATE_STRING_IF_INVALID).

 So I will try to improve the patch by replacing the 'en' hardcoded value
 by a NullTranslations instance (which corresponds to the original string,
 whatever the original language is).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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  |
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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:  nobody
   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 dtrebbien):

 I prefer Aymeric's first patch. Preserving backward compatibility with
 behavior that contradicts the docs does not seem preferable to making the
 behavior conform to current wording. Also, I think that returning an empty
 string is more consistent with the template system's tendency to return
 nothing if there was an error (e.g.: attempting to print an undefined
 variable).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16516: Blocktrans should tolerate bad locale data

[Django]

#16516: Blocktrans should tolerate bad locale data
-+-
   Reporter:  simon29|  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:
  Milestone: |  Internationalization
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by aaugustin):

 I think the proper solution is to output
 `settings.TEMPLATE_STRING_IF_INVALID` when the translation string is
 invalid.

 I'm against hardcoding a fallback to `'en'`:
 - if someone builds a website in Greek and the English translation is
 wrong, this doesn't fix the error;
 - if someone builds a website in Turkish and the German translation is
 wrong, I don't know what happens, but if it works it's a hack :)

 Currently, the `'en'` locale is special-cased in only one place:
 `django.views.i18n.javascript_catalog`. This has bugged me for a long
 time, the implementation is incredibly convoluted, and I still can't
 figure out why it's necessary. Apparently, you were involved in #14924, so
 you probably know this piece of code better than I do :)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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:  nobody
   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 aaugustin):

 In theory, I find it slightly better to display nothing that to display a
 wrong result. For instance, if someone adds total price and shipping cost
 with this filter (an horrible idea for sure, and a strong argument against
 the existence of the `add` filter), and accidentally has one of these
 values represented as a string, the resulting price would be wrong.

 In practice, I understand the value of preserving backwards compatibility.

 I'm attaching an alternative patch that changes the docs to match the
 code. I'm still slightly in favor of the initial patch. But what really
 matters is to resolve the inconsistency between the code and the docs, one
 way or another.

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

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