Re: [Django] #5611: HTTPRequest should check content-type before parsing post body

[Django]

#5611: HTTPRequest should check content-type before parsing post body
--+
 Reporter:  paulegan  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  reopened
Component:  HTTP handling |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by slacy):

 * cc: slacy@… (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] #18215: Don't assume POST data is always application/x-www-form-urlencoded

[Django]

#18215: Don't assume POST data is always application/x-www-form-urlencoded
---+--
 Reporter:  slacy  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  HTTP handling  |  Version:  1.4
 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 ramiro):

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


Comment:

 Duplicate of #5611.

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

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

[Django]

#18216: Problem run manage.py
-+-
 Reporter:  Chriskras|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ramiro):

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


Comment:

 TicketClosingReasons/UseSupportChannels

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

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

[Django]

#18216: Problem run manage.py
--+
 Reporter:  Chriskras |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I want the code below is run with python. I give the following command:
 python manage.py sql and then I get all errors. What is the solution?


 {{{
 #!/usr/bin/env python
 import os
 import sys
 sys.path.append('/home/test/')
 sys.path.append('/home/test/standAlone')
 #sys.path.append('/home/test/standAlone/myApp')
 #os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings")

 if __name__ == "__main__":
  os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name
 }}.settings")
  from django.core.management import execute_from_command_line
  execute_from_command_line(sys.argv)

 }}}

 

 Error:

 {{{
 Traceback (most recent call last):
   File "manage.py", line 12, in 
 execute_from_command_line(sys.argv)
   File "/home/test/django/core/management/__init__.py", line 443, in
 execute_from_command_line
 utility.execute()
   File "/home/test/django/core/management/__init__.py", line 382, in
 execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/test/django/core/management/__init__.py", line 261, in
 fetch_command
 klass = load_command_class(app_name, subcommand)
   File "/home/test/django/core/management/__init__.py", line 69, in
 load_command_class
 module = import_module('%s.management.commands.%s' % (app_name, name))
   File "/home/test/django/utils/importlib.py", line 35, in import_module
 __import__(name)
   File "/home/test/django/core/management/commands/sql.py", line 4, in
 
 from django.core.management.sql import sql_create
   File "/home/test/django/core/management/sql.py", line 6, in 
 from django.db import models
   File "/home/test/django/db/__init__.py", line 11, in 
 if DEFAULT_DB_ALIAS not in settings.DATABASES:
   File "/home/test/django/utils/functional.py", line 184, in inner
 self._setup()
   File "/home/test/django/conf/__init__.py", line 42, in _setup
 self._wrapped = Settings(settings_module)
   File "/home/test/django/conf/__init__.py", line 95, in __init__
 raise ImportError("Could not import settings '%s' (Is it on
 sys.path?): %s" % (self.SETTINGS_MODULE, e))
 ImportError: Could not import settings '{{ project_name }}.settings' (Is
 it on sys.path?): No module named {{ project_name }}.settings
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #13971: Excluding a declared field in ModelForm in form’s subclass

[Django]

#13971: Excluding a declared field in ModelForm in form’s subclass
+--
 Reporter:  mitar   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  1.2
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  | Triage Stage:  Design decision needed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by codysomerville):

 * cc: cody.somerville@… (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] #8620: ModelForm.Meta.exclude only excludes model fields, not form fields

[Django]

#8620: ModelForm.Meta.exclude only excludes model fields, not form fields
-+--
 Reporter:  levity   |Owner:  shimonrura
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by codysomerville):

 * cc: cody.somerville@… (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] #8620: ModelForm.Meta.exclude only excludes model fields, not form fields

[Django]

#8620: ModelForm.Meta.exclude only excludes model fields, not form fields
-+--
 Reporter:  levity   |Owner:  shimonrura
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by codysomerville):

 See duplicate ticket:13971 for additional discussion/patches on this
 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] #13971: Excluding a declared field in ModelForm in form’s subclass

[Django]

#13971: Excluding a declared field in ModelForm in form’s subclass
+--
 Reporter:  mitar   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  1.2
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  | Triage Stage:  Design decision needed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by codysomerville):

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


Comment:

 Closing this as a duplicate of ticket:8620

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #18215: Don't assume POST data is always application/x-www-form-urlencoded

[Django]

#18215: Don't assume POST data is always application/x-www-form-urlencoded
---+
 Reporter:  slacy  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  HTTP handling  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 It seems as though the code in HttpRequest that takes the raw POST data
 and turns it into request.POST (a QueryDict instance) always assumes that
 the incoming data is form encoded.  In fact, the QueryDict class itself
 does the decoding, which seems a bit odd to me.

 Many web application frameworks are using JSON (application/javascript or
 text/json, usually) encoded POST bodies, and other frameworks will use
 (gasp!) XML.  Django should look at the request.meta['CONTENT_TYPE'] of
 the incoming data, and use the right deterializers.   Supported
 deserializers should be "form encoded" (the current), json (via
 simplejson) and likely XML .

 REST frameworks like django-rest-framework and tastypie have better
 handling of POST/PUT data than Django itself, irrespective of the
 "RESTyness" of the whole thing.

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

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

[noreply]

Author: claudep
Date: 2012-04-26 12:56:20 -0700 (Thu, 26 Apr 2012)
New Revision: 17941

Modified:
   django/trunk/django/core/management/commands/flush.py
   django/trunk/django/core/management/commands/syncdb.py
Log:
Removed direct print statements from django management commands.


Modified: django/trunk/django/core/management/commands/flush.py
===
--- django/trunk/django/core/management/commands/flush.py   2012-04-26 
18:06:17 UTC (rev 17940)
+++ django/trunk/django/core/management/commands/flush.py   2012-04-26 
19:56:20 UTC (rev 17941)
@@ -82,4 +82,4 @@
 call_command('loaddata', 'initial_data', **kwargs)
 
 else:
-print "Flush cancelled."
+self.stdout.write("Flush cancelled.\n")

Modified: django/trunk/django/core/management/commands/syncdb.py
===
--- django/trunk/django/core/management/commands/syncdb.py  2012-04-26 
18:06:17 UTC (rev 17940)
+++ django/trunk/django/core/management/commands/syncdb.py  2012-04-26 
19:56:20 UTC (rev 17941)
@@ -1,5 +1,4 @@
 from optparse import make_option
-import sys
 import traceback
 
 from django.conf import settings
@@ -82,12 +81,12 @@
 
 # Create the tables for each model
 if verbosity >= 1:
-print "Creating tables ..."
+self.stdout.write("Creating tables ...\n")
 for app_name, model_list in manifest.items():
 for model in model_list:
 # Create the model's database table, if it doesn't already 
exist.
 if verbosity >= 3:
-print "Processing %s.%s model" % (app_name, 
model._meta.object_name)
+self.stdout.write("Processing %s.%s model\n" % (app_name, 
model._meta.object_name))
 sql, references = connection.creation.sql_create_model(model, 
self.style, seen_models)
 seen_models.add(model)
 created_models.add(model)
@@ -97,7 +96,7 @@
 
sql.extend(connection.creation.sql_for_pending_references(refto, self.style, 
pending_references))
 
sql.extend(connection.creation.sql_for_pending_references(model, self.style, 
pending_references))
 if verbosity >= 1 and sql:
-print "Creating table %s" % model._meta.db_table
+self.stdout.write("Creating table %s\n" % 
model._meta.db_table)
 for statement in sql:
 cursor.execute(statement)
 
tables.append(connection.introspection.table_name_converter(model._meta.db_table))
@@ -115,19 +114,19 @@
 # Install custom SQL for the app (but only if this
 # is a model we've just created)
 if verbosity >= 1:
-print "Installing custom SQL ..."
+self.stdout.write("Installing custom SQL ...\n")
 for app_name, model_list in manifest.items():
 for model in model_list:
 if model in created_models:
 custom_sql = custom_sql_for_model(model, self.style, 
connection)
 if custom_sql:
 if verbosity >= 2:
-print "Installing custom SQL for %s.%s model" % 
(app_name, model._meta.object_name)
+self.stdout.write("Installing custom SQL for %s.%s 
model\n" % (app_name, model._meta.object_name))
 try:
 for sql in custom_sql:
 cursor.execute(sql)
 except Exception, e:
-sys.stderr.write("Failed to install custom SQL for 
%s.%s model: %s\n" % \
+self.stderr.write("Failed to install custom SQL 
for %s.%s model: %s\n" % \
 (app_name, 
model._meta.object_name, e))
 if show_traceback:
 traceback.print_exc()
@@ -136,10 +135,10 @@
 transaction.commit_unless_managed(using=db)
 else:
 if verbosity >= 3:
-print "No custom SQL for %s.%s model" % (app_name, 
model._meta.object_name)
+self.stdout.write("No custom SQL for %s.%s 
model\n" % (app_name, model._meta.object_name))
 
 if verbosity >= 1:
-print "Installing indexes ..."
+self.stdout.write("Installing indexes ...\n")
 # Install SQL indices for all newly created models
 for app_name, model_list in manifest.items():
 for model in model_list:
@@ -147,12 +146,12 @@
 index_sql = 
connection.creation.sql_indexes_for_model(model, self.style)
 if index_sql:
 if verbosity >= 2:
-print 

Re: [Django] #18211: Add a signal to notifying when a ModelAdmin has been registered with an AdminSite

[Django]

#18211: Add a signal to notifying when a ModelAdmin has been registered with an
AdminSite
---+--
 Reporter:  filip.dupanovic@…  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:
 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 Keryn Knight ):

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


Comment:

 Are you able to provide a concrete example of how this would be
 beneficial, or fix problems you're running into that aren't solved by
 catching AlreadyRegistered/NotRegistered and taking the appropriate
 action; eg:
 {{{
 try:
 admin.site.unregister(MyModel)
 # [...]
 except NotRegistered:
 pass
 # Or do some other things, and then register a new ModelAdmin
 admin.site.register(MyModel, MyAdmin)
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #18214: Serializers do not serialize iterators

[Django]

#18214: Serializers do not serialize iterators
-+-
 Reporter:  moritzs  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  serialization json   |  Needs documentation:  0
  xml|  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by claudep):

 * needs_better_patch:   => 0
 * component:  Core (Serialization) => Documentation
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 **that yields Django objects**. [1, 2, 3] are not Django objects.
 Accepting on the base that what are Django objects might be more clearly
 explained in the documentation.

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

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

[Changeset] r17940 - in django/trunk/tests/regressiontests: forms/tests templates

[noreply]

Author: claudep
Date: 2012-04-26 11:06:17 -0700 (Thu, 26 Apr 2012)
New Revision: 17940

Modified:
   django/trunk/tests/regressiontests/forms/tests/fields.py
   django/trunk/tests/regressiontests/templates/tests.py
Log:
Removed unneeded deprecation warning silencing in test suite.


Modified: django/trunk/tests/regressiontests/forms/tests/fields.py
===
--- django/trunk/tests/regressiontests/forms/tests/fields.py2012-04-26 
17:48:50 UTC (rev 17939)
+++ django/trunk/tests/regressiontests/forms/tests/fields.py2012-04-26 
18:06:17 UTC (rev 17940)
@@ -48,14 +48,6 @@
 
 class FieldsTests(SimpleTestCase):
 
-def setUp(self):
-self.save_warnings_state()
-warnings.filterwarnings('ignore', category=DeprecationWarning,
-module='django.core.validators')
-
-def tearDown(self):
-self.restore_warnings_state()
-
 def test_field_sets_widget_is_required(self):
 self.assertTrue(Field(required=True).widget.is_required)
 self.assertFalse(Field(required=False).widget.is_required)

Modified: django/trunk/tests/regressiontests/templates/tests.py
===
--- django/trunk/tests/regressiontests/templates/tests.py   2012-04-26 
17:48:50 UTC (rev 17939)
+++ django/trunk/tests/regressiontests/templates/tests.py   2012-04-26 
18:06:17 UTC (rev 17940)
@@ -13,7 +13,6 @@
 import os
 import sys
 import traceback
-import warnings
 from urlparse import urljoin
 
 from django import template
@@ -22,8 +21,8 @@
 from django.template import loader
 from django.template.loaders import app_directories, filesystem, cached
 from django.test import RequestFactory
-from django.test.utils import (get_warnings_state, restore_warnings_state,
-setup_test_template_loader, restore_template_loaders, override_settings)
+from django.test.utils import (setup_test_template_loader,
+restore_template_loaders, override_settings)
 from django.utils import unittest
 from django.utils.formats import date_format
 from django.utils.translation import activate, deactivate, ugettext as _
@@ -152,10 +151,6 @@
 
 class Templates(unittest.TestCase):
 def setUp(self):
-self._warnings_state = get_warnings_state()
-warnings.filterwarnings('ignore', category=DeprecationWarning,
-module='django.template.defaulttags')
-
 self.old_static_url = settings.STATIC_URL
 self.old_media_url = settings.MEDIA_URL
 settings.STATIC_URL = u"/static/"
@@ -164,7 +159,6 @@
 def tearDown(self):
 settings.STATIC_URL = self.old_static_url
 settings.MEDIA_URL = self.old_media_url
-restore_warnings_state(self._warnings_state)
 
 def test_loaders_security(self):
 ad_loader = app_directories.Loader()

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #18214: Serializers do not serialize iterators

[Django]

#18214: Serializers do not serialize iterators
--+
 Reporter:  moritzs   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Core (Serialization)  |Version:  SVN
 Severity:  Normal|   Keywords:  serialization json xml
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 According to [https://docs.djangoproject.com/en/dev/topics/serialization/
 serialization documentation] the given object "can be any iterator that
 yields Django objects, but it'll almost always be a !QuerySet". But it
 does not work with iterators.

 Example:
 {{{
 #!python
 >>> from django.core import serializers
 >>> json_serializer = serializers.get_serializer('json')()
 >>> json_serializer.serialize([1, 2, 3])
 Traceback (most recent call last):
   File "", line 1, in 
   File "trunk/django/core/serializers/base.py", line 46, in serialize
 concrete_model = obj._meta.concrete_model
 AttributeError: 'int' object has no attribute '_meta'
 >>>
 >>> xml_serializer = serializers.get_serializer('xml')()
 >>> xml_serializer.serialize([1, 2, 3])
 Traceback (most recent call last):
   File "", line 1, in 
   File "trunk/django/core/serializers/base.py", line 43, in serialize
 self.start_object(obj)
   File "trunk/django/core/serializers/xml_serializer.py", line 42, in
 start_object
 raise base.SerializationError("Non-model object (%s) encountered
 during serialization" % type(obj))
 SerializationError: Non-model object () encountered during
 serialization
 }}}
 One should either change the documentation or make this work.

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

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

Re: [Django] #14593: CZBirthNumberField expects two arguments to clean()

[Django]

#14593: CZBirthNumberField expects two arguments to clean()
---+-
   Reporter:  idangazit|Owner:  idangazit
   Type:   |   Status:  closed
  Component:  contrib.localflavor  |  Version:  1.2
   Severity:   |   Resolution:  fixed
   Keywords:   | Triage Stage:  Accepted
  Has patch:  0|  Needs documentation:  0
Needs tests:  0|  Patch needs improvement:  0
---+-

Comment (by claudep):

 In [17939]:
 {{{
 #!CommitTicketReference repository="" revision="17939"
 Removed deprecated gender check in cz localflavor. Refs #14593.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r17939 - in django/trunk: django/contrib/localflavor/cz tests/regressiontests/localflavor/cz

[noreply]

Author: claudep
Date: 2012-04-26 10:48:50 -0700 (Thu, 26 Apr 2012)
New Revision: 17939

Modified:
   django/trunk/django/contrib/localflavor/cz/forms.py
   django/trunk/tests/regressiontests/localflavor/cz/tests.py
Log:
Removed deprecated gender check in cz localflavor. Refs #14593.


Modified: django/trunk/django/contrib/localflavor/cz/forms.py
===
--- django/trunk/django/contrib/localflavor/cz/forms.py 2012-04-26 17:15:40 UTC 
(rev 17938)
+++ django/trunk/django/contrib/localflavor/cz/forms.py 2012-04-26 17:48:50 UTC 
(rev 17939)
@@ -50,7 +50,6 @@
 """
 default_error_messages = {
 'invalid_format': _(u'Enter a birth number in the format XX/ 
or XX.'),
-'invalid_gender': _(u'Invalid optional parameter Gender, valid values 
are \'f\' and \'m\''),
 'invalid': _(u'Enter a valid birth number.'),
 }
 
@@ -73,23 +72,11 @@
 # Birth number is in format YYMMDD. Females have month value raised by 
50.
 # In case that all possible number are already used (for given date),
 # the month field is raised by 20.
-if gender is not None:
-import warnings
-warnings.warn(
-"Support for validating the gender of a CZ Birth number has 
been deprecated.",
-DeprecationWarning)
-if gender == 'f':
-female_const = 50
-elif gender == 'm':
-female_const = 0
-else:
-raise ValidationError(self.error_messages['invalid_gender'])
+month = int(birth[2:4])
+if (not 1 <= month <= 12) and (not 21 <= month <= 32) and \
+(not 51 <= month <= 62) and (not 71 <= month <= 82):
+raise ValidationError(self.error_messages['invalid'])
 
-month = int(birth[2:4]) - female_const
-if (not 1 <= month <= 12):
-if (not 1 <= (month - 20) <= 12):
-raise ValidationError(self.error_messages['invalid'])
-
 day = int(birth[4:6])
 if not (1 <= day <= 31):
 raise ValidationError(self.error_messages['invalid'])

Modified: django/trunk/tests/regressiontests/localflavor/cz/tests.py
===
--- django/trunk/tests/regressiontests/localflavor/cz/tests.py  2012-04-26 
17:15:40 UTC (rev 17938)
+++ django/trunk/tests/regressiontests/localflavor/cz/tests.py  2012-04-26 
17:48:50 UTC (rev 17939)
@@ -1,5 +1,3 @@
-import warnings
-
 from django.contrib.localflavor.cz.forms import (CZPostalCodeField,
 CZRegionSelect, CZBirthNumberField, CZICNumberField)
 
@@ -8,17 +6,6 @@
 
 
 class CZLocalFlavorTests(SimpleTestCase):
-def setUp(self):
-self.save_warnings_state()
-warnings.filterwarnings(
-"ignore",
-category=DeprecationWarning,
-module='django.contrib.localflavor.cz.forms'
-)
-
-def tearDown(self):
-self.restore_warnings_state()
-
 def test_CZRegionSelect(self):
 f = CZRegionSelect()
 out = u'''
@@ -75,20 +62,6 @@
 }
 self.assertFieldOutput(CZBirthNumberField, valid, invalid)
 
-# These tests should go away in 1.4.
-# http://code.djangoproject.com/ticket/14593
-f = CZBirthNumberField()
-self.assertEqual(f.clean('880523/1237', 'm'), '880523/1237'),
-self.assertEqual(f.clean('885523/1231', 'f'), '885523/1231')
-self.assertRaisesRegexp(ValidationError, unicode(error_invalid),
-f.clean, '881523/', 'm')
-self.assertRaisesRegexp(ValidationError, unicode(error_invalid),
-f.clean, '885223/', 'm')
-self.assertRaisesRegexp(ValidationError, unicode(error_invalid),
-f.clean, '881523/', 'f')
-self.assertRaisesRegexp(ValidationError, unicode(error_invalid),
-f.clean, '885223/', 'f')
-
 def test_CZICNumberField(self):
 error_invalid = [u'Enter a valid IC number.']
 valid ={

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #18038: Remove the 'supports_inactive_user' backwards-compatibility flag

[Django]

#18038: Remove the 'supports_inactive_user' backwards-compatibility flag
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  contrib.auth |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 In [17938]:
 {{{
 #!CommitTicketReference repository="" revision="17938"
 Fixed #18038 -- Removed the 'supports_inactive_user' backwards-
 compatibility flag. Thanks Aymeric Augustin for the initial patch and
 Ramiro Morales for the review.
 }}}

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

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

[Changeset] r17938 - in django/trunk: django/contrib/auth django/contrib/auth/tests docs/topics

[noreply]

Author: claudep
Date: 2012-04-26 10:15:40 -0700 (Thu, 26 Apr 2012)
New Revision: 17938

Modified:
   django/trunk/django/contrib/auth/__init__.py
   django/trunk/django/contrib/auth/backends.py
   django/trunk/django/contrib/auth/models.py
   django/trunk/django/contrib/auth/tests/__init__.py
   django/trunk/django/contrib/auth/tests/auth_backends.py
   django/trunk/docs/topics/auth.txt
Log:
Fixed #18038 -- Removed the 'supports_inactive_user' backwards-compatibility 
flag. Thanks Aymeric Augustin for the initial patch and Ramiro Morales for the 
review.


Modified: django/trunk/django/contrib/auth/__init__.py
===
--- django/trunk/django/contrib/auth/__init__.py2012-04-25 19:17:47 UTC 
(rev 17937)
+++ django/trunk/django/contrib/auth/__init__.py2012-04-26 17:15:40 UTC 
(rev 17938)
@@ -1,4 +1,3 @@
-from warnings import warn
 from django.core.exceptions import ImproperlyConfigured
 from django.utils.importlib import import_module
 from django.contrib.auth.signals import user_logged_in, user_logged_out
@@ -20,11 +19,6 @@
 cls = getattr(mod, attr)
 except AttributeError:
 raise ImproperlyConfigured('Module "%s" does not define a "%s" 
authentication backend' % (module, attr))
-
-if not hasattr(cls, 'supports_inactive_user'):
-warn("Authentication backends without a `supports_inactive_user` 
attribute are deprecated. Please define it in %s." % cls,
- DeprecationWarning)
-cls.supports_inactive_user = False
 return cls()
 
 def get_backends():

Modified: django/trunk/django/contrib/auth/backends.py
===
--- django/trunk/django/contrib/auth/backends.py2012-04-25 19:17:47 UTC 
(rev 17937)
+++ django/trunk/django/contrib/auth/backends.py2012-04-26 17:15:40 UTC 
(rev 17938)
@@ -5,7 +5,6 @@
 """
 Authenticates against django.contrib.auth.models.User.
 """
-supports_inactive_user = True
 
 # TODO: Model, login attribute name and password attribute name should be
 # configurable.

Modified: django/trunk/django/contrib/auth/models.py
===
--- django/trunk/django/contrib/auth/models.py  2012-04-25 19:17:47 UTC (rev 
17937)
+++ django/trunk/django/contrib/auth/models.py  2012-04-26 17:15:40 UTC (rev 
17938)
@@ -200,14 +200,13 @@
 anon = user.is_anonymous()
 active = user.is_active
 for backend in auth.get_backends():
-if anon or active or backend.supports_inactive_user:
-if hasattr(backend, "has_perm"):
-if obj is not None:
-if backend.has_perm(user, perm, obj):
-return True
-else:
-if backend.has_perm(user, perm):
-return True
+if hasattr(backend, "has_perm"):
+if obj is not None:
+if backend.has_perm(user, perm, obj):
+return True
+else:
+if backend.has_perm(user, perm):
+return True
 return False
 
 
@@ -215,10 +214,9 @@
 anon = user.is_anonymous()
 active = user.is_active
 for backend in auth.get_backends():
-if anon or active or backend.supports_inactive_user:
-if hasattr(backend, "has_module_perms"):
-if backend.has_module_perms(user, app_label):
-return True
+if hasattr(backend, "has_module_perms"):
+if backend.has_module_perms(user, app_label):
+return True
 return False
 
 

Modified: django/trunk/django/contrib/auth/tests/__init__.py
===
--- django/trunk/django/contrib/auth/tests/__init__.py  2012-04-25 19:17:47 UTC 
(rev 17937)
+++ django/trunk/django/contrib/auth/tests/__init__.py  2012-04-26 17:15:40 UTC 
(rev 17938)
@@ -1,6 +1,6 @@
 from django.contrib.auth.tests.auth_backends import (BackendTest,
 RowlevelBackendTest, AnonymousUserBackendTest, NoBackendsTest,
-InActiveUserBackendTest, NoInActiveUserBackendTest)
+InActiveUserBackendTest)
 from django.contrib.auth.tests.basic import BasicTestCase
 from django.contrib.auth.tests.context_processors import 
AuthContextProcessorTests
 from django.contrib.auth.tests.decorators import LoginRequiredTestCase

Modified: django/trunk/django/contrib/auth/tests/auth_backends.py
===
--- django/trunk/django/contrib/auth/tests/auth_backends.py 2012-04-25 
19:17:47 UTC (rev 17937)
+++ django/trunk/django/contrib/auth/tests/auth_backends.py 2012-04-26 
17:15:40 UTC (rev 17938)
@@ -104,12 +104,6 @@
 
 
 class SimpleRowlevelBackend(object):
-supports_inactive_user = False
-
-# This class also supports tests for anonymous user permissions, and
-# inactive user 

Re: [Django] #18208: Escape translations by default

[Django]

#18208: Escape translations by default
-+-
 Reporter:  tonnzor  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:   |  Version:  1.4
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tonnzor):

 Replying to [comment:5 claudep]:
 > And now your security argument is lost. How can you know that the
 translation will be really safe?

 It is the same secure as '''|safe''' :)  You can use it in specific places
 you trust or wrap into sandbox.

 However, with translation tags we cannot use safe or escape filters so
 easy.

 Finally, we can turn unsafe by default if you think it more reasonable.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #18212: GenericIPAddressField does not handle verbose_name and name args like other field types

[Django]

#18212: GenericIPAddressField does not handle verbose_name and name args like 
other
field types
-+-
 Reporter:  toofishes|Owner:
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  fields   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by claudep):

 * status:  reopened => new
 * owner:  nobody =>
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Replying to [comment:2 toofishes]:
 > Source: https://docs.djangoproject.com/en/1.4/topics/db/models/#verbose-
 field-names

 You are right, sorry. Now the problem to fix it is that we have a backward
 compatibility problem, for people who did define the protocol as first
 argument of GenericIPAddressField. As the field type has been added in
 1.4, this could be fixed in 1.4.1 with a loud warning. Other opinions
 welcome.

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

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

[Django]

#18208: Escape translations by default
-+-
 Reporter:  tonnzor  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:   |  Version:  1.4
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Replying to [comment:4 tonnzor]:

 > Then your case would look this way:
 > {{{
 > {% blocktrans safe %}This is very important{% endblocktrans %}
 > =>
 > This is very important
 > }}}

 And now your security argument is lost. How can you know that the
 translation will be really safe? For me, this is mere complication for a
 small benefit.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15076: inspectdb to quote ForeignKey class names to avoid need to reorder classes/solve circular dependencies

[Django]

#15076: inspectdb to quote ForeignKey class names to avoid need to reorder
classes/solve circular dependencies
-+-
 Reporter:  saschwarz|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.2
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  inspectdb|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ramiro):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #18038: Remove the 'supports_inactive_user' backwards-compatibility flag

[Django]

#18038: Remove the 'supports_inactive_user' backwards-compatibility flag
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  contrib.auth |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ramiro):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #18038: Remove the 'supports_inactive_user' backwards-compatibility flag

[Django]

#18038: Remove the 'supports_inactive_user' backwards-compatibility flag
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  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 claudep):

 * needs_better_patch:  1 => 0


Comment:

 In the last patch, I only added:[[BR]]
 "Do not forget to test for the ``is_active`` attribute of the user in your
 own
 backend permission methods."

 If Aymeric wanted to add more, I think we should then open a seperate
 ticket.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15574: IndexError: list index out of range caused by inline formsets

[Django]

#15574: IndexError: list index out of range caused by inline formsets
+--
 Reporter:  poswald |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  SVN
 Severity:  Normal  |   Resolution:
 Keywords:  inline formset  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by mat):

 * cc: django@… (added)
 * version:  1.3-beta => SVN
 * stage:  Design decision needed => Unreviewed


Comment:

 I've been bitten by this in production, did some digging and have a
 possible solution.

 This problem has several variants:
 - If there are multiple relations and one of the relation other than the
 last
   one is deleted outside the current change view, you will get a "Please
 correct
   the error below" message... without showing where the error occured,
 because
   it's happening on a pk field, which is hidden.
 - If there is only one relation or there are multiple relations but only
 the last
   one is deleted, you'll get the `IndexError`
 - In addition, if you try to delete an already deleted relation, you'll
 get a `ValidatorError`,
   which isn't caught because it doesn't happen inside a form's `clean()`
 method,
   and will generate a 500 error.

 Since the user has no way to correct/avoid this himself, I think the
 correct answer
 to this problem is to simply ignore the forms in question. The worst thing
 that could
 happen is that he'll lose any modification made to the concerned form(s),
 but that's
 better than losing all his work on the page itself.

 I'm attaching a patch that does exactly that, with a lot of tests to cover
 the different
 variants. The heart of the problem lies in the fact that django
 `BaseModelFormSet` tries to find
 an instance for each form in the formset even if it doesn't make sense
 sometimes.
 Because `ModelForms` will consider a `None` instance as a request for
 creation, the
 best way to handle this, IMHO, is to bail early and remember how many
 forms are
 problematic.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #18212: GenericIPAddressField does not handle verbose_name and name args like other field types

[Django]

#18212: GenericIPAddressField does not handle verbose_name and name args like 
other
field types
-+-
 Reporter:  toofishes|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  fields   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by toofishes):

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


Comment:

 I didn't include every other field, but literally every other core field
 type takes verbose_name as a first argument, not a keyword argument, if it
 comes first. Note that they are also all documented the same way as the
 example you called out- none of them explicitly list verbose_name in the
 arguments list.

 Please look at the `test_field_verbose_name` method I added. In addition,
 I've attached a patch that tests *every single core field type*, and all
 of them take a keyword-less first parameter as verbose name. This is 23
 field types in all.

 Not only that, I can quote your own documentation which refutes your
 statement that "nothing in the current documentation guarantees that the
 first argument to any field constructor will be the verbose_name":

 > == Verbose field names ==
 > Each field type, except for ForeignKey, ManyToManyField and
 OneToOneField, takes an optional first positional argument -- a verbose
 name. If the verbose name isn't given, Django will automatically create it
 using the field's attribute name, converting underscores to spaces.

 Source: https://docs.djangoproject.com/en/1.4/topics/db/models/#verbose-
 field-names

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

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

[Django]

#18208: Escape translations by default
-+-
 Reporter:  tonnzor  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:   |  Version:  1.4
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by tonnzor):

 Replying to [comment:3 claudep]:
 > We can not decide to simply make all translations unsafe, because it is
 perfectly legal to add markup inside translatable strings.

 If we have any suspicion on escaping translations -- let's make it
 explicit -- to escape them or not.

 Then your case would look this way:
 {{{
 {% blocktrans safe %}This is very important{% endblocktrans %}
 =>
 This is very important
 }}}

 For cases when '''safe''' was not provided or '''unsafe''' parameter was
 given -- it would work the way you explained.

 If it makes more sense for your -- we can treat translations as '''safe by
 default''' (though that was the proposal). It will be still very handy for
 developers to explicitly set escaping (or disabling 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] #18208: Escape translations by default

[Django]

#18208: Escape translations by default
-+-
 Reporter:  tonnzor  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:   |  Version:  1.4
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * stage:  Unreviewed => Design decision needed


Comment:

 Difficult issue. If on one side I understand your concern, on the other
 side, translations are assimilated to your own code. We can not decide to
 simply make all translations unsafe, because it is perfectly legal to add
 markup inside translatable strings. For example:
 {{{
 {% blocktrans %}This is very important{% endblocktrans%}
 }}}
 would then lead to content like:
 {{{
 C'est btrès/b important
 }}}

 So I'm afraid the only viable thing we can do is to warn about such
 possible issues and recommend to check translations before putting them in
 production. Note that bad translations can also lead to data loss
 ("Delete" translated by "OK" on a button), so generally speaking, you have
 to trust translators 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.

[Django] #18213: loaddata should allow empty fixtures

[Django]

#18213: loaddata should allow empty fixtures
---+
 Reporter:  lsaffre|  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Uncategorized  |Version:  SVN
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The `loading` management command does the following test:


 {{{
 # If the fixture we loaded contains 0 objects, assume that an
 # error was encountered during fixture loading.
 if objects_in_fixture == 0:
 self.stderr.write(
 self.style.ERROR("No fixture data found for '%s'. (File format may
 be invalid.)\n" %
 (fixture_name)))
 if commit:
 transaction.rollback(using=using)
 transaction.leave_transaction_management(using=using)
 return

 }}}

 I suggest to either remove this test or to add a setting to disable it.
 Because a fixture returning no objects is a perfectly possible edge case
 (depending on some local configuration settings) when using Python
 fixtures .

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #18206: Disable bytecode in manage.py by default to avoid project clutter.

[Django]

#18206: Disable bytecode in manage.py by default to avoid project clutter.
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  bytecode   | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by aaugustin):

 FWIW I agree with Claude -- if Django's defaults diverged from Python's,
 most people would consider that 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] #16345: INTERNAL_IPS has issues with IPv6, IPv4

[Django]

#16345: INTERNAL_IPS has issues with IPv6, IPv4
-+-
 Reporter:  narzola@…|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  INTERNAL_IPS IPv4| Triage Stage:  Accepted
  IPv6   |  Needs documentation:  1
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by aaugustin):

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


Comment:

 I don't think the problem is specific to the debug toolbar; it affects
 anything that relies on `INTERNAL_IPS`.

 Also, please avoid closing tickets anonymously.

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

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

[Django]

#18208: Escape translations by default
-+-
 Reporter:  tonnzor  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:   |  Version:  1.4
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by tonnzor):

 Replying to [comment:1 ramiro]:
 > See #10449. I'd go even further and say this is a duplicate.

 It is similar but covers a different case -- when translations are used in
 widgets and is not very clear. My issue is about direct translations
 usage.

 Moreover -- #10449 didn't have any activity for a year, so maybe this one
 will have more attention being quite different case.

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

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

Re: [Django] #17756: GeoDjango missing pyspatialite support

[Django]

#17756: GeoDjango missing pyspatialite support
-+
 Reporter:  danols   |Owner:  danols
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+

Comment (by claudep):

 Yes, Debian. And you are right, the -dev packages are not installed, so
 that should be part of the complementary instructions.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #18212: GenericIPAddressField does not handle verbose_name and name args like other field types

[Django]

#18212: GenericIPAddressField does not handle verbose_name and name args like 
other
field types
-+-
 Reporter:  toofishes|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:  fields   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 Nothing in the current documentation guarantees that the first argument to
 any field constructor will be the verbose_name.

 For example, GenericIPAddressField is documented as:

 {{{
 class GenericIPAddressField([protocol=both, unpack_ipv4=False,
 **options])
 }}}

 verbose_name should always be used as a keyword parameter, like most other
 field init parameters.

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

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

[Django]

#18092: Composite indexes
-+-
 Reporter:  ivan_virabyan|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by ivan_virabyan):

 Thanks for pointing out! Searching didn't give me any results on this
 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] #5805: Specify multicolumn indexes.

[Django]

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

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

[Django]

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

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